[arm-allstar] Local Inactivity Timer: Pros/Cons

ve3rwj at winsystem.org ve3rwj at winsystem.org
Wed Apr 12 12:17:16 EDT 2023


Hi.

 

I have a policy question.

This is as much about reassuring some people, as much as it is sensible
policy.

The club to which I belong is about to add an Allstar node to their 2 M
machine. I help maintain and configure the node.

 

Some people have expressed concerns about users connecting it to large
networks/busy nets, and it staying connected for long periods of time,
"tying up our repeater". (The fact that our repeater is quiet almost 24/7 is
immaterial)

I assure them that no, our repeater is not going to become one of those 24/7
Echolink rebroadcasters. Nets are fun but there is a limit, right?

 

I already script some automatic connections and disconnections, along with
spoken voice announcements warning of the impending connection. The
announcements play two minutes ahead.

And, I regularly ask which nets the membership would like to hear during the
week.

I also urge people to take the initiative if they want to disconnect from
something, by simply pushing PTT during a break in traffic and disconnect
using DTMF!

We've even changed the "disconnect all" command to *73 so it's easier to
remember.

 

And yet, some people are still concerned.

 

So, there is now talk of an inactivity timer for the Allstar node once it
joins the analog repeater.

 

What amount of local inactivity do people feel is sufficient to trigger an
automatic disconnect?

I'm thinking 30 minutes.

People can always reconnect if they want.

 

By "local" I mean no key ups from RF going into our node. Again, I'm not
sure if that level of control is possible. Inactivity might just be
inactivity across the node as a whole, in either direction.

 

Thoughts? Ideas? Things I may not have considered?

What happy  medium have you found for this?

 

All opinions welcome.

 

Thanks

 

Chris, ve3rwj

 



More information about the ARM-allstar mailing list