[aprssig] Packet routing, path specification.

[Jason Winningham]

On Jun 23, 2005, at 11:19 AM, Bill Vodall wrote:

> I'd suggest that brain dead trackers should be replaced with TNC's and
> flexible application software.   A tracker gives you a small portion
> of APRS functionality and no "communications" capabilities.

I doubt that people transmitting $GPGGA sentences are using an 
application; otherwise, we'd be seeing packets from that app, instead.

Depending on what you're doing, a full TNC and APRS app may be wasted, 
or may be prohibitive in terms of size, power consumption, etc.

I could fly a laptop running xastir connected to a KPC3+ as the APRS 
rig on a balloon, but that'd be dumb when I can fly an opentracker rig 
for a pound or less.

In the case of storm spotters, the EOC needs to know where the report 
is originating.  A dumb tracker may do a better job than a voice 
report, and wouldn't need APRS decode capability.

I don't do SAR, but I'd imagine that knowing where search teams are 
(and have been) is quite useful for the command post, even if teams 
can't receive APRS and see where other teams are located.

Does a weather station need receive capability?

Those are just a few examples; I'm sure there are others.

> By changing the path on the fly, or using better software to control
> the path,

Trackers can do that, to a limited extent.  I can easily rig a toggle 
switch for an OpenTracker to manually switch between two different 
paths.

>  you can probably more then make up for the few extra bytes
> created by the long NMEA sentences.

Quite a bit more than a few bytes.  grabbing 3 examples from an old log 
file:

$GPGGA sentence: 69 byte payload
standard APRS position report, with time, speed, and heading: 35 bytes
standard APRS position report, position only: 20 bytes
Mic-E packet from a D700: 14 bytes

$GPGGA uses about 5 times as much payload bandwidth than Mic-E, and 
includes less useful information.  Even including the headers, it's 
double (or worse).

-Jason
kg4wsv