[aprssig] APRS radios
Scott Miller
scott at opentrac.org
Sun May 25 13:34:33 EDT 2008
> 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
More information about the aprssig
mailing list