Comment field jibberish in compressed Mic-E packets

[craigerl]

The comment field is "]=" for the following Mic-E packet, which is compressed. You probably know this, as the comment field s gibberish in your documents.

{
    "raw": 'K6EYE-9>SWTUVY,WR6ABD,K6FGA-1*,WIDE2:`26SmJ`E/]"4V}=',
    "from": "K6EYE-9",
    "to": "SWTUVY",
    "path": ["WR6ABD", "K6FGA-1*", "WIDE2"],
    "via": "",
    "format": "mic-e",
    "symbol": "E",
    "symbol_table": "/",
    "posambiguity": 0,
    "latitude": 37.7615,
    "mbits": "111",
    "mtype": "M0: Off Duty",
    "longitude": -122.4425,
    "speed": 25.928,
    "course": 268,
    "altitude": 63,
    "comment": "]=",  #<---------
}

[craigerl]

Scope expanded to all packet-types which use compression (position, weather, etc). comment is jibberish.

[rossengeorgiev]

Hi @craigerl, thanks for the report. Look to me like the packet is parsed correctly. ]= is whats left in the comment. From the APRS protocol document I can see that ] is inserted by some devices.

Not sure what the =, but it might another special case. I cannot find anything in the spec about it. Looking at aprs.fi, the decoded result matches aprslib:

https://aprs.fi/?c=raw&call=K6EYE-9&limit=5&view=decoded

However, when I look at station info, the ] and = are stripped from the comment. I need more information about this edge case before any code changes are made.

Regarding the position and weather packets, I need examples.

[craigerl]

Yah, I think you're right. I recall hessu wanting to know something about new radios when they're brought to market, some have these unique characters, ultimately filtered from aprsis. I could be wrong on this tho.

[shackrat]

Curious why this has not been acted on.. It's a documented part of the spec..

http://www.aprs.org/aprs12/mic-e-types.txt

`......_% Yaesu FTM-400DR [new in Aug 2013] (message capable)

Where T is the Mic-E TYPE byte (" ",">","]","`","'")
Where ........ is the free text portion of the format
Where aaa}.... like:  "Taaa}....Mv" is optional altitude
Where "M" represents the Manufacturer Byte 
Where "v" represents a version Byte

[shackrat]

I've submitted PR #85 to fix this issue by parsing and removing the Mic-E radio information from the comment.

[wb2osz]

This causes a lot of confusion.
According to the documentation, the original MIC-E put a space between the fixed part and the comment:

xxxxxxxx  (space)  comment      Original MIC-E

Sometimes you will see this form, without anything between the fixed part and the comment. In this case, we don’t know what generated the packet.

xxxxxxxx  (no space)  comment       Unknown

When Kenwood adopted the MIC-E format, they put a different character before the comment field to identify the equipment type.

xxxxxxxx  >  comment            TH-D7
xxxxxxxx  ]  comment            TM-D700

When later models were introduced, an additional character was placed at the end of the comment.

xxxxxxxx  >  comment  =         TH-D72
xxxxxxxx  >  comment  ^         TH-D74
xxxxxxxx  >  comment  &     TH-D75

xxxxxxxx  ]  comment  =         TM-D710

This is known as the legacy format. For later equipment, a new format is used.

• A prefix of ` indicates a system capable of messaging. • A prefix of ‘ indicates not capable of messaging, e.g. a tracker.

At the end we now have a two character suffix for the manufacturer and model. Examples:

     xxxxxxxx  `  comment  _(           Yaesu FT2D  (messaging capable)
xxxxxxxx  `  comment  _0        Yaesu FT3D  (messaging capable)
    xxxxxxxx  `  comment  _3        Yaesu FT5D  (messaging capable)

xxxxxxxx  ‘  comment  |3        Byonics TinyTrack 3 (no messaging)
    xxxxxxxx  ‘  comment  |4        Byonics TinyTrack 3 (no messaging)

Any optional altitude is at the beginning of the comment, after any device identifier prefix and before any suffix. Example:

     xxxxxxxx  `  "4-} comment  _(  

Rather than hardcoding these rules, application developers are encouraged to read a file at runtime so users can update the database without waiting for a new software release.

aprs.org hasn't been updated for a couple years. https://github.com/aprsorg/aprs-deviceid is now the accepted authority for the device identifier codes.

Let me know if you have any questions.

73, John WB2OSZ