CANSignalEncoder appears to drop extended id.

[8bitgeek]

If I understand correctly. I believe that in this scenario CANSignalEncoder is dropping extended ID when converting signal to raw packet. I've also attached the DBC I'm working with in this example.

[CANSignalEncoder-issue-dbc.zip]

[rkollataj]

I think that the problem is caused by CAN ID that you are using. Extended CAN id is 29bit long (i.e. 0x1ffffff) and your ids seems to be bigger than that. Furthermore according to DBC specification signals with extended CAN id should have most significant bit in CAN id set. This simply means that all fo your IDs should be - CAN_ID | 0x1000000.

[8bitgeek]

Thank you. Okay, I suspected there might be something goofy going on there.
I'm sorry I'm a newbie with both .dbc files, and extended IDs.
I am the producer of the DBC file.
I will forward your response to the producers of the file and get that corrected.
I think we can close this issue.
Thanks again!!

[8bitgeek]

• ...NOT the producer of the DBC file...

[8bitgeek]

Just FYI.
This is SAE J1939.
I think that may have something too do with the way they are encoding the IDs

[rkollataj]

From what I can see J1939 also uses 29 bit CAN ID. However as you mentined this may be some additional info that is encoded in DBC on to of standard 29 bits. Do you have any clue on how to figure this out?

[8bitgeek]

I am reviewing J1939 from sources such as https://assets.vector.com/cms/content/know-how/_application-notes/AN-ION-1-3100_Introduction_to_J1939.pdf and others.

Nothing is jumping out at me.

Yes, it seems that J1939 encodes the IDs in a specific way, but it should still end up at 29 bit from what I can understand.

I have forwarded what I know (and don't know) up the chain of command, and I've requested some help with clarification on the intent with these IDs. So I should know a little more by Monday or Tuesday.

[rkollataj]

The above should fix problem with "strange" J1939 IDs.

@8bitgeek let me know if you will learn anything interesting about 32bit of CAN ID beeing set in J1939 DBC.

[8bitgeek]

Thank you @rkollataj, I have tested that patch and applied a similar patch to my application which also consumes the same DBC file.
It is working as expected.
I will let you know if I discover anything as to why the high-bit is being set.