- #MD tokens

[jeroenbeijer]

Hi,

First of all, thanks for your great work!

It seems that with the latest version(s) of libacars some messages that jaero attempts to decode are not decoded. When building and running against an older version of libacars they are correctly decoded. The messages that fail seem to be these that start with the "- #MD" token, for example this H1:

• #MD/A6 PIKCPYA.ADS.66168A07040B000C000D010E011000D9FB

When I strip off the first part of the message in jaero and pass "/PIKCPYA.ADS.66168A07040B000C000D010E011000D9FB" it works fine.
Now this is of course easy enough but since it seems this was not issue in earlier versions of libacars I just want to check with you if you think this needs to be done in jaero or if perhaps it is an issue in libacars.

Additionally, in longer messages, additional "- #MD" tokens can be found. I could only get these to decode by stripping away these tokens in jaero. Same question there I guess, should the client take care of stripping these off the message before attempting to decode?

Many thanks!

Jeroen

[szpajder]

It seems that with the latest version(s) of libacars some messages that jaero attempts to decode are not decoded. When building and running against an older version of libacars they are correctly decoded.

Which version works and which doesn't?

The messages that fail seem to be these that start with the "- #MD" token, for example this H1: - #MD/A6 PIKCPYA.ADS.66168A07040B000C000D010E011000D9FB When I strip off the first part of the message in jaero and pass "/PIKCPYA.ADS.66168A07040B000C000D010E011000D9FB" it works fine.

So probably libacars 1.x works, and 2.x doesn't. This is documented in CHANGELOG.md: - - Incompatible change: ACARS parser now strips sublabel and MFI (Message Function Identifier) fields from the message text, if present. Their values are stored in la_acars_msg structure in sublabel and mfi fields. In text and JSON output they are printed as separate fields. - - - Incompatible change: MIAM parser and ARINC-622 ATS message parser now expect sublabel and MFI fields to be stripped by the caller, otherwise the parser will ignore the message. This operation can be performed with minimal fuss using la_acars_extract_sublabel_and_mfi function. Now this is of course easy enough but since it seems this was not issue in

earlier versions of libacars I just want to check with you if you think this needs to be done in jaero or if perhaps it is an issue in libacars.

You have to update your code when migrating across major versions of the library. Compatibility is preserved across minor versions only.

Additionally, in longer messages, additional "- #MD" tokens can be found. I could only get these to decode by stripping away these tokens in jaero. Same question there I guess, should the client take care of stripping these off the message before attempting to decode?

This is a sublabel. Whenever such a message is fragmented into multiple blocks, the sublabel gets prepended to the message text in every block and has to be stripped before reassembly. If the client performs reassembly on its own, then it must take care of it (manually or using the abovementioned la_acars_extract_sublabel_and_mfi() function). The easier way is to use the reassembly engine included in libacars, it takes care of all the necessary quirks. This is done with la_acars_parse_and_reassemble() function. Refer to API_REFERENCE.md for details and to the dumphfdl <https://github.com/szpajder/dumphfdl> code for an usage example.

[jeroenbeijer]

Thanks for the quick reply. Indeed it worked with version 1.x

I have added a call to la_acars_extract_sublabel_and_mfi() to find the sublabel and offset as per your suggestion. Since the message is already assembled I just stripped the sublabels off the full message and it all works now :-)

Thanks again!