fix decode choices #624
fix decode choices #624
Conversation
your understanding of how the DBC file format works is probably slightly wrong, as things are supposed to be like this: the choices are based on internal values (i.e., the values send over the wire). If scaling was taken into account before resolving names, it would be pretty difficult to specify any named values considering that scaling factors and offsets are often floating point values and thus subject to rounding errors... |
|
maybe the dbc designer was wrong...? actually just taken the offset in to account it works good,cause the scalar is one and it must be one for enumeration.but the offset does not change the value range.so,i think the dbc i use is a probly wrong designing or unnecessary for enum offset as you say.i will fix this in just my code在 2023年11月18日，03:43，Andreas Lauser ***@***.***> 写道：
Is this a bug or is there some other consideration?
your understanding of how the DBC file format works is probably slightly wrong, as things are supposed to be like this: the choices are based on internal values (i.e., the values send over the wire). If scaling was taken into account before resolving names, it would be pretty difficult to specify any named values considering that scaling factors and offsets are often floating point values and thus subject to rounding errors...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
as I see it, that is almost certainly the case. If you really are not able to fix that particular DBC, you can decode your messages using |
|
ok and thanks for all.在 2023年11月18日，16:39，Andreas Lauser ***@***.***> 写道：
maybe the dbc designer was wrong...?
as I see it, that is almost certainly the case. If you really are not able to fix that particular DBC, you can decode your messages using msg.decode(data, scaling=False, decode_choices=False) and manually do the scaling/decoding as a post processing step...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
hi ：
I noticed that the values used for decoding choices are not scaled. Is this a bug or is there some other consideration? For example, here is my choice list [-1: good, 0: ok, 1: good], with a scale and shift of 1, -1. When the value is 2, after decoding, it becomes 2 * 1 - 1 = 1, which means "good." However, when I select the decode choice, it is interpreted as the numerical value 1 instead of "good." This is because 2 is not in the choice list, so it returns the decoded value of 2 * 1 - 1 = 1, rather than "good." If the value is 1, it actually equals 1 * 1 - 1 = 0. However, in this case, it returns "good." Is there a bug or is there a specific reason for this behavior?