[aprssig] Packet routing, path specification.
jdw at eng.uah.edu
Thu Jun 23 11:59:58 CDT 2005
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
> 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
$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).
More information about the aprssig