Tyler-2
commented
2 years ago There may be all sorts of errors there since I wrote it while perusing the spec.... The suggested fix and TLDR are probably sufficient to get the gist.
Open Tyler-2 opened 2 years ago
Tyler-2
commented
2 years ago There may be all sorts of errors there since I wrote it while perusing the spec.... The suggested fix and TLDR are probably sufficient to get the gist.
At this line, a space is inserted between the
statusvar (Referred to asComment fieldin the UI, I think), and the preceding speed, freq, alt vars.https://github.com/ge0rg/aprsdroid/blob/2041ba3497647c279b1bd61a37f98042c1329cc7/src/AprsService.scala#L242
The
(APRS 1.0 doc, page 94, APRS Data Formats)
commentin APRS terminology is always the last field:Going forward I will refer to the
commentmeaning the user-providedcomment, consistent with the APRS spec documentation ofcomment. APRSDroid internally refers to (I think) thecommentasstatus. And erroneously (again, I think) calls the variable which contains APRSdata extensionsand the APRScomment, "comment". I believe this is a mistake.The
frequencyandaltitudedata is notdata extensionbut are actually just text that is treated as part of thecommentfield.APRSDroid uses un-timestamped position reports.
Course/speed is an optional
data extensioncomponent in the APRSDroid packets.Lat/Long reports without timestamps or
data extensioncomponentsThis is a Lat/Long position report without timestamp, sent from APRSDroid:
=3742.94N\07749.29Wk Some commentNote the
spacebetween theWkandSome comment. W is the end of theLongfield.kis my symbol code. The comment then would beSome comment. Wrong.symbol codeis aspace, it indicates there is no Course/Speed/Range/Altitude value. But APRSDroid does not send compressed position reports.>instead of the=in our example packet specify that if the status report includes a Maidenhead Grid Locator, the status text must start with a space. But we are not APRS does not sent status report packets, and the data format APRSDroid uses does not havestatus text.Test 001234is the comment. In the second example, the comment isTest /A=001234.The altitude is ALWAYS 6 characters long in the comment. Therefore it does not need to be followed by a space, but there might be other reasons to do that.... If you see
/A=in the comment field, the next 6 characters are the altitude in feet.So it seems to me that the space is inappropriate in the case of
=3742.94N\07749.29Wk Some commentwhich should instead read=3742.94N\07749.29WkSome commentand packets that contain altitude data maybe shouldn't look like:
=3742.94N\07749.29Wk/A=000169 Some commentbut should instead look like=3742.94N\07749.29Wk/A=000169Some commentor=3742.94N\07749.29WkSome comment /A=000169if theexampleis to be followed without explanation.Section conclusion: The space preceding the APRSDroid comment is not appropriate except maybe when the
/A=xxxxxxprecedes it.Lat/Long reports without timestamps, with
data extensioncomponentsAPRS data extension fields are always 7 byte. Which means they do not need a delimiter (like a space) to terminate them. But they do occasionally need a space sometimes to pad them out. But that's not what's happening in APRSDroid.
Confusion when using the
frequencyobjecthttp://www.aprs.org/info/freqspec.txt
APRS FREQUENCY FORMATSsection adds some confusion here. Thefrequencyobject is also part of the comment field. Some effort was made to make sure this was easily human readable but also parse-able.A simplified summary of the rules for the frequency object in APRSDroid is:
FFF.FF MHzorFFF.FFFMHzfor instance. It must always be 10 bytes long.MHzmust be mixed case on transmission.mhzorMHZetc) in decode/receipt.They include this example:
FFF.FFFMHz comment...This is the only reference to a
trailingspace for the frequency object, and the space is never mentioned otherwise as far as I can tell.However there is reference to an optional "not in the spec"
leadingspace:It isn't clear to me what they meant to do with the leading delimiter on the frequency data. The leading delimiter isn't necessary for decoding...
The reference to the
intentthere implies that if you use the free form textcommentfield to contain interesting custom attributes like frequency, you can delimit those with a space or/. That way, maybe, APRS clients that don't understand them are able to skip over them. But I don't understand how you're supposed to know that the field is "over". Spaces can't be delimiters all the way through the comment, in this way....So there can be a space or
/or other delimiter before the frequency object "to make it more readable" (for who?). That's aleading space.A packet with a frequency object and altitude in APRSDroid currently looks like this:
=3742.94N\07749.29Wk146.520MHz/A=000158 Some commentand I believe it should look like this, if the "leading space" is actually desirable:=3742.94N\07749.29Wk146.520MHz /A=000158Some commentImpact
PHGdata doesn't work.Suggested fixes
Make the comment field consist of one of, depending on which fields are defined:
status_spd +...status_freq + " " + status + " " + status_altstatus + " " + status_altstatus_freq + " " + statusstatusI wouldn't actually even want to put a leading or following space in front of
status_altbut based on the example packets it seems allowable.TLDR
It appears APRSDroid is unconditionally inserting a space between the
commentfield and thesymbol code, when there should ~not be a space there at all~ only maybe be spaces involved between the altitude, frequency, and user provided comment fields.