[Xastir-dev] Tactical Callsigns

[Curt, WE7U]

On Tue, 29 Jul 2008, Tom Hayward wrote:

> - When creating/defining a TAC call, give a toggle box "Make Public /
> Broadcast" (default: disabled). Most of the time, I don't need or want
> to transmit my tactical calls. I would keep an array of all TAC calls,
> and another array with pointers to those Public TACs that need to be
> transmitted.

How about a set of radio buttons to specify the default mode:

     private
     public
     Force a choice each time

This way if you normally operate as a stand-alone system and/or
don't wish to publicize, set the first.  Set the 2nd if it's a
public event and you want to let all the hams know what's going on.
The 3rd forces you to choose public or private each time you create
a new TAC call.  With a set default it speeds up creation and
reduces mistakes.

We already have a hash for TAC calls so we'd just need another list
for those that were public.


> - Add a Send-All-TAC's function, very similar to Transmit Now.

As in Send-All-Public-TAC's I presume.


> If
> someone finishes setting up their station and wants the TACs
> immediately, all they have to do is request them by voice, and the
> local operator can hit Send-All-TACs (hmm, should the remote operator
> be able to query over APRS for the TACs, initiating the same
> Send-All-TACs function?)

I was planning on the Send-All-TAC's thing.  Hadn't thought about
queries WRT this.  We already have queries, no reason we couldn't
add another!


> - Send out the TACs tagged with Public on a predetermined time,
> configured in the timing settings.

We could send them through the standard message system, perhaps with
some small mods to time-outs and a method to kill them easily when
we change something in the TAC's.  This would give us the
exponential backoff timing which is better for RF:  More updates
when data is changed, then it backs off over time.

Channel utilization:  Should we add another message to the queue for
each added TAC?  That'll give the higher update rate for new stuff
and let the older stuff decay.  Another possibility would be to kill
the old messages and create a new one with an updated list and
faster timing each time a change is made.  We might end up sending
multiple messages if several TAC's are defined due to message size
limitations.


> - When a Public TAC is cleared locally, clear it over the air
> (likewise with a clear-all-TACs function).

Yea, with repeats.

So...  It sounds like the public/private thing is useful/desired, so
I'll try to stick with that.  It may be a while before everything is
fleshed out.

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"