[aprssig] APRS radios
scott at opentrac.org
Sun May 25 12:03:39 CDT 2008
> I know it's a massive task to implement APRS on a big computer, using
> a scripting language which is very good for implementing string parsers.
> It's even more work in C. It must be really, really hard to implement
> all of it properly in a tiny embedded device with very little memory.
I can vouch for that. Base91 encoding, for example - or the funky
exponential speed scheme used for Mic-E. Sure, it's one line of code in
BASIC. It's not even that bad in C when you've got an FPU (or fast
enough emulation), room for all of the libraries, and stack space to
hold everything. The OpenTracker+ has a grand total of 16k of code
space and 384 bytes of RAM, with no floating point. It manages to do
the important stuff, but it takes a lot of lookup tables and annoying
tricks that make for some ugly code.
The spec was designed for BASIC on a fast PC, where floating point math
is effortless but bit manipulation is tedious. Its 'simple'
computations are only simple in a high-level language, on a platform
with plenty of processing power and memory to spare.
The other major APRS implementation headache is the way extensions are
inconsistently added. There's no standard format to extend anything -
properly parsing all of the options and extensions means writing a long
list of conditions and exceptions, and it relies heavily on fast string
Now, I fully understand WHY this is. Bob's always said he's not a
programmer, and APRS is more the result of incremental evolution than
design, so Bob, don't take this as a personal attack. But please don't
delude yourself or anyone else into thinking that APRS is 'simple' to
Garmin's binary protocol is a major pain to implement on an embedded
platform, too (lots of floating point, coordinates in radians,
velocities given in X/Y/Z components) but at least the structure is
consistent. The vocabulary is irritating, but the grammar is
well-defined. APRS has neither a consistent vocabulary OR grammar,
beyond the most basic 'this character indicates format type', and even
that is violated by things like Mic-E's use of the TOCALL field.
It's difficult to convey to a non-programmer, or even to a casual
programmer, why consistency is important, and how it directly affects
the maintainability of a complicated system and the programmer's ability
to implement the system correctly and to avoid subtle bugs arising from
combinations of conditions that weren't considered, and whose
possibility isn't obvious because of the complexity of the system.
A proper protocol can be expressed with a formal grammar (see BNF), and
if it's a stateful protocol, its states and their transitions can be
documented in a state diagram. This lets us look at the code and verify
that it's correct, and that there aren't any contradictions, undefined
details, or unanalyzed possibilities.
APRS is not this sort of protocol, and you can't really expect to make a
rigorous analysis of the parser code when it's full of nested if-then's,
and when the specification itself is ambiguous or vague.
Anyway, sorry to rant - we all love APRS despite its warts, but don't go
making it out to be something it's not (i.e., simple.)
On a completely unrelated subject, don't forget - Mars Phoenix lands
(well, hopefully) today. Live coverage on NASA TV.
More information about the aprssig