-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Message type 24 (Class B static data) does not detect and correctly decode part B #7
Comments
Message types 22, 25 and 26 have a similar issue with the broadcast/addressed bit indicating different field decoding. My first idea was to have an optional "type decoders" to post-process the message, that are invoked based on message type. The type decoders could be managed as a list in MessageDecoder similar to the field decoders. But simpleais enumerating/decoding fields on access complicates things a bit.. How about a "subtype" structure in the MessageDecoder class with:
For example for msg type 24:
and then query that in the iterators and getters to only return applicable fields:
caveat, mothership is even more complicated and overlaps with dimensions:
|
Thanks for mentioning this. Just to understand the priority, is this something you actively need? Or is it more a desire to have everything correct? |
I can work around it with a few lines of Python code. But for the common msg type 24 (sent by pleasure boats), it's a bit jarring to see the invalid names when using aist. Though that might be an oversight in aist as I now see that you already check for partno in there. |
I implemented a fix in astuder@6105c45 It introduces the concept of subtypes, where the value of one field controls the decoding of other fields. Each unique subtype creates a trimmed instance of MessageDecoder, which is requested by the constructor of Sentence if applicable. This fixes the issue with overlapping field definitions when decoding type 22 (channel management) and type 24 (static data report):
mothership_mmsi still is a problem as its handling requires more complex rules depending on mmsi field. I haven't seen this in use in the wild yet. This fix also improves support for dest_mmsi in type 25/26 (single/multiple slot binary message), but those messages probably still won't return the data field. Though, according to AIVDM documentation, these message types haven't been seen in the wild. This branch also fixes warnings about escaping of backslashes in aivdm_translate.py |
Message type 24 comes in two variants, called "part A" and "part B". simpleais always returns both sets of fields.
Example message:
!AIVDM,1,1,,B,H5NhCmTN7B=400500000001P0004,0*56
Decoded by simpleais:
Correct decoding (via Maritec):
The output for shipname may be uninitialized memory, at one occasion I got
C: DRIVE
- Edit: Never mind, there's a ship with that name :)This type may require some custom handling as the documentation for AIVDM merged both definitions into the same table:
https://gpsd.gitlab.io/gpsd/AIVDM.html#_type_24_static_data_report
The text was updated successfully, but these errors were encountered: