Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS resolution

Gregg Wonderly gregg at wonderly.org
Tue Oct 2 19:49:57 UTC 2007


Keith VE7GDH wrote:
> My comments aren't meant to "shoot APRS down". It is very useful and has 
> the can be used for many everyday functions as well as in disasters. I 
> just think that OpenTRAC has the potential to allow us to get more out 
> of it. Case in point... OpenTRAC will have an almost unlimited ability 
> to add more symbols. APRS has only a handful of unused symbols. There 
> was enough room to add a farm tractor, but not a skier. Every mobile 
> APRS user not in a vehicle, aircraft, on horseback or in a wheelchair is 
> a jogger... none are standing still, walking, skiing, hiking or whatever.

Many will say it's not possible.  But ultimately, we could demand that the 
applications utilize the AX.25 PID field correctly.  That field is called 
"protocol id" and as such, designates the "application" protocol that is being 
conveyed within the AX.25 packet.  APRS has a designated PID of 0xF0 or 240.  It 
should be possible for another protocol to coexist.  The problem, of course, is 
that during the migration, there would be old systems that could not understand 
the new systems data.  Some people might be motivated to send a copy of the APRS 
packet as an opentrac packet too, which would "JAM up" the frequencies as some say.

So, what we really need is an APRS client software package which is night and 
day better than what exists today.  It would need to support both APRS and 
openTRAC.  It would need to be prepared to provide a change over to opentrac.

All the Kenwood D700 and THD7A owners would be left out, and this would be "a 
bad thing" for many.

All in all, it will be a very difficult thing to make happen, "on frequency". 
However, with enough devices and software to support it, a bit of rebel action 
could make it happen "on frequency", but there would be a lot of pain to deal 
with because of the existing infrastructure and dependencies.

One starting point, might be to define an APRS 3rd party packet type that 
designates OpenTrac data, and just start sending it out that way.  Then, it 
would at lease be ignored correctly by software that doesn't "understand".

Gregg Wonderly
W5GGW




More information about the aprssig mailing list