AllowedManeuvers Enum wrong?

[jkordani]

For the allowed manuevers enum list, it seems like the values are backwards from where they should be. In Asn1 bit streams, the first bit is the highest bit. I was having trouble finding examples of other enums in the project, but it doesn't seem like there is a consistent convention for this. Is it more correct to list the enum values by bit number and let the implementation figure out the bit ordering, or bake in the value, where allowedManueverStraight would hold the value of 2048?

[kjrush]

Thanks for bringing this to our attention! I believe this bitstring has been used successfully in the legacy CARMA version 2 signalized intersection transit (to determine which lanes transit straight through the intersection) with standards-compliant MAP/SPaT messages. So somehow that data is being interpreted correctly at the guidance level, at least; it's possible however that somehow the bit order is being flipped elsewhere in our message processing stack. That'd essentially result in two defects that cancel each other out, which would be nice to correct. We'll take a look and see if that's the case and update you on what we find!

Thanks again!

[jkordani]

Thanks for looking into it! From what I see, if the raw value from the asn1 bit string were stuffed into this field, the offsets would be simply wrong (flipped, and shifted 1 bit). I'm using the asn1c library to parse the streams and it supplies enums that map to the bit positions (not values) identical to the asn1 spec. I haven't figured out how to make use of the libraries interpretation of a bit string however. I'm happy to help investigate but I don't know where to look just yet