[aprssig] tactical call identifier packet

[Shawn Stoddard]

Wes Johnston wrote:
> Could we create a new packet type that would force the display of a 
> tactical callsign instead of an object's real callsign? 
>  
> For example... if I want to map ai4px-9 to "wes' car" on my display, I 
> can do it on each client, but I have to program each client to know 
> when it sees ai4px-9 to display wes car.  What if there was a packet 
> that could "suggest" tactical calls.  I could program one client to 
> send packets which the rest would see and they'd know which tactical 
> calls to display w/o me having to program each one.  Yes, it's a 
> little extra overhead on 144.39.
>  
> The reasoning for this is to do with rfid badges.  It would be 
> extremely simple to use a serial RFID reader, such as the one sold by 
> parallax to spit out the badge serial number.  An attached open track 
> (Whoops... I've just volunteered Scott for this, eh?) could construct 
> an aprs packet using a canned (and pseudo randomized GPS position) and 
> that badge number.  To aprs clients it would appear as an object (like 
> what I do with the rino radios) with a "faked" position.  It would be 
> nice if the open tracker knew the badge ID number and converted it to 
> a callsign, but I feel that's impractical given the memory constraints 
> of the tracker.    And, you'd have to program each tracker with a list 
> of expected badge numbers and which callsigns they map to.  This could 
> be problematic when new folks come to help in an event.
>  
> Wes
> ------------------------------------------------------------------------
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>   
Anybody every thought about using something like a DNS server? Have one 
system that accepts inquiries about serial numbers and maps them to call 
signs. Since APRS acts a lot like a single broadcast domain clients that 
overhead a request-reply could just cache the entry, minimizing traffic. 
The mappings could be aged out of the cache and/or reverified 
periodically. Then you only have one place to update the mapping. I 
grant you doing this would require a change to all APRS clients but so 
would any major change.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20080724/2da72f0b/attachment.html>