[aprssig] APRS resolution

[Andrew Rich]

I have been running APRS on one line and then RAW on the next line.

One for UI-VIEW and the other for later playback to google earth.

It is annoying when you are tracking a plane on aprs and it is not on the
tarmac.


----------------------------------------------------------------------------
Andrew Rich VK4TEC
vk4tec at people.net.au <mailto:vk4tec at people.net.au>
http://www.tech-software.net




-----Original Message-----
From: aprssig-bounces at lists.tapr.org
[mailto:aprssig-bounces at lists.tapr.org]On Behalf Of Gregg Wonderly
Sent: Wednesday, 3 October 2007 5:50 AM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] APRS resolution


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

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig