[aprssig] BALDY APRS Station

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Tue May 22 03:33:29 EDT 2012


APRSISCE/32 supports displayable Nicknames for just that purpose.  It 
will eventually be able to transmit them as shared TACTICAL callsigns.  
The concept is that ANY station can be assigned ANY position and be 
displayed as such on the net controller's screen.  And when a new 
station takes over a tactical position, simply re-assign the nickname.  
xastir supports the same concept.

This is effectively separating the station from the information, but 
only for display.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/21/2012 10:37 PM, Jim Alles wrote:
> I wrote some suggestions on page 11 here 
> <http://www.tapr.org/psr/psr116.pdf>, and I hope for the day that a 
> callsign-identified mobile station can 'push around' an object with 
> tactical identifier and the automatic GPS location of the station.
>
> My approach would be to separate the address (callsign) from the 
> information, since they tend to spontaneously combust when brought 
> together ;)
>
> Peace,
> Jim A.
>
> On Mon, May 21, 2012 at 2:16 PM, Lynn W. Deffenbaugh (Mr) 
> <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>> wrote:
>
>     Similar to frequency objects (but limited to 6 characters for
>     stations, not 9 for objects), make it a suffix on the tactical
>     call.  That way both events can quickly see SAGn, FIN, STR (or
>     GO), but they all have a 2 character suffix within the 6 first
>     characters or after a - in an object.
>
>     SAGnEV (station) or EVSAGn
>     TAILEV (station) or EVTAIL
>     FINISH-EV (object) or EV-FINISH
>     START-EV (object) or EV-START
>
>     and so forth where EV is a unique (hopefully) tag describing the
>     event.  It could, of course, always come first (as shown) which
>     would aid APRS-IS wildcard filters, but I find the suffix more
>     quickly deciferable for the station's function.
>
>     Just because there's a lot of bad-mouthing of "couch potatoes" and
>     "it wasn't meant for global views", doesn't mean that tactical
>     collisions can be blithely ignored.  If we all pay attention to
>     making our tacticals unique for a specific event, then we have
>     nothing to worry about even when a 2m opening happens during the
>     event and we start hearing packets from a similar even two states
>     away!
>
>     The issue isn't specific to APRS-IS, but can happen on RF as well,
>     so it's worth striving for some sort of uniqueness before Murphy
>     drops that band opening in the middle of your (non-unique) event.
>
>
>     Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
>     On 5/21/2012 1:59 PM, n7qnm-lists at nwlink.com
>     <mailto:n7qnm-lists at nwlink.com> wrote:
>
>         As a frequent "client" of the ORIGINAL (at least in time)
>         BALDY and a
>         frequent "luker" here;  I think both John and Lyle have some
>         good points.
>
>         Is there perhaps another way (Comment?) for INFRASTRUCTURE
>         stations to
>         identify their location to folks with limited display width
>         (ala HamHud or
>         Kenwoods)?    That might help address the issue; but at the
>         same time one
>         could then use local filters to eliminate "noise" from DISTANT
>         tactical
>         calls.
>
>         Other the other hand, there's still a potential issue here,
>         particularly
>         if folks don't follow the right PATH rules.   I can easily see
>         calls  like
>         "SAG" or "START" or "FINISH" being used by two groups within
>         range of the
>         same mountaintop.  That would definitely cause chaos.
>
>         Perhaps some some sort of prefix could be added - ala SMSAG1,
>         SMSTART, or
>         SMFIN (Seattle Marathon)?
>
>         Clay
>         N7QNM
>         N7QNM-9
>         N7QNM-10
>
>             I repeat my original PS:
>
>                 No, I'm not trying to start a flame war about Tactical
>                 station IDs.
>                  I'm just trying to help the collisions get sorted out
>                 as I notice them.
>
>
>             On 5/21/2012 9:11 AM, John Gorkos wrote:
>
>                 A considerate APRS manager would include RFONLY or
>                 NOGATE in the path
>                 of all tactical stations.
>
>             Actually, that choice alienates a bunch of hams assisting
>             with an event
>             that may not have APRS RF capability but COULD remain
>             aware of the
>             overall situation via an APRS-IS client filtered to the
>             local area to
>             avoid any potential interference from duplicate tactical
>             calls.  You
>             might as well keep all your packets 7 bytes shorter (the
>             length of a
>             path component in the AX.25 header) and let the APRS-IS do
>             whatever it
>             wills with the tactically-named stations' packets.
>
>             Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
>             and Win32
>
>                 John Gorkos
>                 AB0OO
>
>
>             _______________________________________________
>             aprssig mailing list
>             aprssig at tapr.org <mailto:aprssig at tapr.org>
>             https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>
>         _______________________________________________
>         aprssig mailing list
>         aprssig at tapr.org <mailto:aprssig at tapr.org>
>         https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto:aprssig at tapr.org>
>     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120522/6950b909/attachment.html>


More information about the aprssig mailing list