Can't Encode/Decode BasicVehicleContainerHighFrequency

[Rom-1T]

Hello,

I truly appreciate your efforts in developing a UPER ASN1 encoder for Java applications. However, I am encountering challenges with encoding/decoding a specific CAM data container, the BasicVehicleContainerHighFrequency. Strangely, I can encode every sub-data correctly (Heading, Speed, etc.), but there seems to be an issue with the BasicVehicleContainerHighFrequency data container.

To provide context for my project, I aim to establish a V2X communication protocol between an Android application (utilizing Java) and a vehicle (using a C++ stack, which is already operational). I am currently testing the encoding/decoding functionality through a Python application for flexibility. It's important to note that I am not utilizing BTP or Geonet, as my network layer is MQTT-based so I am only encoding ITS Container. The DENM works perfectly.

I suspect there may be difficulties in declaring the BasicVehicleContainerHighFrequency correctly. Could you assist me in resolving this issue?

Thank you,

[alexvoronov]

Hi!

It's been long time since I've looked at those containers. Since you got DENM to work, there is hope that BasicVehicleContainerHighFrequency will also work :)

What errors do you get? What is the difference in UPER messages between what you get with gcdc-asn1 and Python-encoded UPER message? How does messages look when compared with asn1-playground outputs?

Android used to have a problem with field ordering: it was not preserving field order when iterating through fields using reflection, so results were inconsistent. The hope was that Android will eventually return fields in the declaration order, just like Java.

[Rom-1T]

I believe the issue stems from the definition of BasicVehicleContainerHighFrequency itself, as it appears to be the smallest container causing problems with encoding/decoding. While I can successfully encode and decode using your encoder and decoder, there seems to be a lack of interoperability. The challenge lies in identifying any substantial differences in the ASN1-like declaration. I've attached a screenshot of my test results for reference. In the test, I encoded a BasicVehicleContainerHighFrequency using a trusted source and your encoder, then compared them.

As you can observe, the beginning works fine, but issues arise towards the end.

I am exploring potential workarounds and considering not encoding/decoding V2X messages on Android. Regardless, I appreciate your project. Thank you.

[alexvoronov]

Looks like byte 9 is different for this Pedestrian message. There might be a bug in gcdc-asn1, but I'd need your help in identifying it. Could you please remove the last field and see if the messages by your trusted encoder and by gcdc-asn1 become the same? Then keep removing fields one-by-one until the messages by your trusted encoder and by gcdc-asn1 become the same. This will point to the problematic field. Then we can look into the detailed binary representation of that field. I guess one field type has the wrong binary representation.

…

On Mon, Feb 5, 2024 at 9:26 AM Rom-1T ***@***.***> wrote: I believe the issue stems from the definition of BasicVehicleContainerHighFrequency itself, as it appears to be the smallest container causing problems with encoding/decoding. While I can successfully encode and decode using your encoder and decoder, there seems to be a lack of interoperability. The challenge lies in identifying any substantial differences in the ASN1-like declaration. I've attached a screenshot of my test results for reference. In the test, I encoded a BasicVehicleContainerHighFrequency using a trusted source and your encoder, then compared them. Capture.d.ecran.du.2024-02-05.09-18-56.png (view on web) <https://github.com/alexvoronov/gcdc-asn1/assets/109967942/e3666145-a354-48ba-bd26-7ab25e7890ef> As you can observe, the beginning works fine, but issues arise towards the end. I am exploring potential workarounds and considering not encoding/decoding V2X messages on Android. Regardless, I appreciate your project. Thank you. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECSICVDRWMVZ42FUMFRFTYSCJSJAVCNFSM6AAAAABCWLBXWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRWGQ2DOOJZHA> . You are receiving this because you commented.Message ID: ***@***.***>

[Rom-1T]

Great news! I implemented your suggested method, and it revealed two problematic data fields: CurvatureCalculationMode and YawRate. However, those data container should work fine by themselves. In fact they are, the problems lies in the BasicVehicleContainerHighFrequency because when I make CurvatureCalculationMode and LongitudinalAcceleration OPTIONNAL and the YawRate MANDATORY it also works. Maybe the BasicVehicleContainerHighFrequency can not handle more than 7 data container encoding ?

To address this, I modified my trusted encoder ASN1 files, designating both yawRate and curvatureCalculationMode as OPTIONAL. I made the same adjustments to your CoopIts class definition. With these changes, I can now successfully send and receive CAM. In the end I can't modify the ASN1 files of my receiving system which mean I have to find another way of fixing this encoding/decoding problem

[alexvoronov]

Great that you've found the difference! Depending on what you mean by "hardcode", you could set any value in the constructor. There might be a bug somewhere in the implementation of CurvatureCalculationMode or YawRate. I see that at least one of them has an "extension marker", which could allow arbitrary extension to the encoding, could that be a source of difference? If you find how exactly it should behave, feel free to share your solution :-)

…

On Mon, Feb 5, 2024 at 12:01 PM Rom-1T ***@***.***> wrote: Great news! I implemented your suggested method, and it revealed two problematic data fields: CurvatureCalculationMode and YawRate. To address this, I modified my trusted encoder ASN1 files, designating both yawRate and curvatureCalculationMode as OPTIONAL. I made the same adjustments to your CoopIts class definition. With these changes, I can now successfully send and receive CAM. I plan to delve into the technical specifications of CurvatureCalculationMode and YawRate for a more in-depth understanding. As a potential quick fix, I am considering hard-coding the encoding for these two fields since I don't have any immediate plans to use them. Have you any idea how I can "hardcode" this ? — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECSIDHPAN7BNWUTMY22Y3YSC3YLAVCNFSM6AAAAABCWLBXWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRWG4ZDCOJTGM> . You are receiving this because you commented.Message ID: ***@***.***>