[aprssig] APRS radios

[Scott Miller]

> Third party and Objects is where I think the spec overly complicated APRS.  It was so simple.  An object is NOT a special packet with its own formats.  It is simply a position report of an object name that is not a callsign.  So the name has to be in the packet, and not in the AX.25 header where the callsign is.
> 
> On receipt, all one was supposed to do was chop off the header, and then use what remained (which now contains a NAME instead of a call) as if it had been received on RF directly.  Just rearrange the name into a pseudo packet and then continue parsing like any other packet.

Ok... what if the object has the '_' symbol?  Do you interpret the 
000/000 extension as wind direction and speed, as you would for a 
non-object packet?  Or would it be course/speed, per the object report 
format on page 68?  According to that, wind isn't one of the allowable 
extensions.

This is exactly the sort of inconsistency I'm talking about.  A formal 
grammar would specify exactly what can and can't go where.

> Same with 3rd party.  Simply strip off the header, and then drop it directly through the rest of the parser.  A simple one-line process.

Well, my C implementation is about 10 lines, but that's because it's got 
to make a few checks for safety - to make sure it isn't missing the 
delimiter, for example.

> So in that sense, I agree that the APRS spec is a monster in how it tediously attempts to document these things as separate enteties.  Again, it tries to make objects a completely different animal, when they are simply a position report with a NAME other than a callsign.  So follow-on authors tend to build object parsers, when in fact, an object should be treated identical to the position parser of all other packets.

Exactly why a formal grammar is needed.  You'd have something like:

<position> :== <lat-lon> | <compressed>

<position-report> ::= <symbol> <position> | <extension> | <comment>

<object> ::= <object-name> <position-report>

That tells you explicitly that whatever is in <position-report> can go 
in the object, including the compressed position data, extension, and so on.

Scott
N1VG