[aprssig] APRS radios

[Scott Miller]

>   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 
processing.

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 
implement properly.

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.

Scott
N1VG