bus_logging_map 29-bit ID identification

[Mark0ne]

in raw bus logs, the bus_logging_map dictionary is useful to find data from a specific message.

Although it's rare, it's perfectly possible to have two CAN IDs of the same integer number:
0x500
0x00000500
but one is a 29-bit extended ID and the other is an 11-bit standard CAN ID.

In this case, the dictionary wouldn't work, the second entry would just overwrite the first. Has this been considered?
In *.dbc file syntax, extended IDs are identified by SETting bit 31 TRUE.
Cheers,
Mark

[danielhrisca]

something to think about

[paweller]

in raw bus logs, the bus_logging_map dictionary is useful to find data from a specific message.

May I kindly ask how to do so? Unfortunately, I do not know what the key and value numbers from the bus_logging_map dictionary tell me. Thanks and cheers.

[Mark0ne]

My understanding is:
The bus_logging_map shows the bus-types and the received message identifiers. It also tells you which group those message identifiers are on.
A group is basically a time axis - a collection of signals that only have one 'master' time axis.

I've only worked with CAN logs. In this case:
mdf.bus_logging_map['CAN'] gives a dictionary of CAN_Channel : CAN_logging_map (these are not types!)
CAN_logging_map is a dictionary of: messageID : group (both int)

In the logs I have, all CAN traffic is actually on group=5.

rawSigs = mdf.get(group=5, index=0) returns a signal containing all of the CAN data. You then need to filter by message ID, which is index [5] in the samples tuple

rawSigs.samples[0][5] Gives the CAN ID of the first frame received

[Mark0ne]

To clarify, I'm mostly using it as a list of the recorded CAN IDs within a log.