Decoding an encoded message returns different values
See original GitHub issueI’ve tried decoding an encoded message in both Cantools 28.6.0 and 22.0.1, and I’m seeing the same behavior where one signal’s value is lost somehow.
>>> msg.decode(msg.encode({ 'signal1': -250.0, 'signal2': -250.0, 'signal3': 1, 'signal4': 2, 'signal5': 3, 'signal6': 4, 'signal7': 0 }))
{'signal1': -250.0, 'signal2': -250.0, 'signal3': 1, 'signal4': 0, 'signal5': 3, 'signal6': 4, 'signal7': 0}
I noticed that https://github.com/eerimoq/cantools/blob/master/tests/test_database.py contains quite a few instances of checking whether the decoded message matches the original message passed through something equivalent to msg.decode(msg.encode(msg_payload))
, so I’m unsure where the issue lies. All of my signals in this CAN message are big-endian, and I also noticed this weird inconsistency when printing the start and length values for my signals in this message:
>>> sorted([(sig.start, sig.length) for sig in msg.signals], key=lambda sig: sig[0])
[(6, 15), (22, 15), (35, 4), (39, 4), (41, 2), (55, 8), (59, 3)]
Some of the signals seem to overlap for some reason. Am I misunderstanding how the signals are laid out in this particular message?
I took a look at the message dump, which looks fine however: https://pastebin.com/0UufZbuj
Please let me know if more information is necessary.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6
This is a partial dump of that message actually:
So it makes sense how 0x34BC is directly in the message actually. Thanks for the clarifications!
You’re right the encoding and decoding issue is actually a result of the signal value not matching the scale.
Is this the correct way to encode 0x34BC starting at bit 6 then?
If that is, there are actually only 14 bits that can fit starting at bit 6, right?