MF4 decoder troubleshooting

The below provides guidance if you are not seeing the expected output when decoding your data.

Check the basics

  1. Ensure that you have read the MF4 decoder documentation
  2. Ensure that you are using the latest MF4 decoders
  3. Ensure that your MDF is directly from the CANedge[1]
  4. Check if your DBC can be opened in the free CANDB++ tool (to check syntax errors)
  5. Check that you have correctly assigned prefixes to your DBC files (e.g. can1-)[2]
  6. Drag & drop your log file onto the mdf2csv_decode executable and review the results
  7. If a specific message is not as showing, double check your DBC file for that message
  8. Check if your MDF raw data contains the CAN/LIN ID (e.g. via asammdf)
  9. Make sure there are no ‘message key collisions’ (the MF4 decoders will warn of this)[3]

As a general tip, you can also try decoding your data via the command line for details as below:

mdf2csv_decode -i 00000001.MF4 --verbosity=5

Compare vs. asammdf

If you tried the above, but you’re still not seeing the expected results, you can try using the asammdf GUI to help isolate if the issue appears linked to the MF4 decoders or something else:

  1. Load your raw CANedge MDF log file in the asammdf GUI
  2. In the Bus Logging tab, load the DBC files you use for testing
  3. Ensure that each DBC is applied as per the prefix channel (e.g. can1-mydbc.dbc to CAN1)
  4. Decode the data in asammdf and compare it vs the MF4 decoder output

If asammdf outputs the same results as the MF4 decoders, then the issue is most likely with your DBC file, or simply that your raw data in fact has no messages matched by the DBC files. In this case, use the asammdf GUI to review your raw CAN bus trace to identify the root cause. You can also review the ‘Bus Logging’ summary statistics in asammdf to see which messages were matched by your DBC file(s).

If asammdf outputs the expected results, while the MF4 decoders do not, the most likely reason is a DLC mismatch[4] between your DBC file and the actual message payload. You can check this by reviewing the raw data in the asammdf GUI.

Test if invalid Parquet

If you believe your issue relates to invalid Parquet files being generated, we recommend that you test this locally. Specifically, you can download the free Tad viewer and test if the Parquet file opens as expected. If not, we recommend contacting us as per below.

Contact us

If you are still unable to identify the root cause, please contact us and share the raw MF4 file, correctly named DBC file and details on the expected vs. observed output. If you are unable to share your entire DBC file, you can try creating a minimal/sanitized version of it that replicates the issue.

[1]The MF4 decoders do not support MDF files from 3rd party hardware/software tools. For example, MDF files recorded by Vector tools are not supported. Similarly, MDF files from the CANedge which have been saved/exported/concatenated via e.g. asammdf, MATLAB or other tools will also not work. MDF files that have been finalized via the mdf2mdf MF4 converter are supported, however.
[2]The prefixes must be defined so that they match the CAN/LIN channel containing the data you’re attempting to apply the DBC file to. If you e.g. assign the prefix can1- to your DBC file, it will not be used for decoding any data on CAN Channel 2, for example. You can have multiple DBC files assigned to the same CAN/LIN channel.
[3]If you have one or more DBC files on a single CAN channel where CAN IDs are identical, this will cause an error and the decoding will not work (the decoder will produce a warning about collisions). Note that the MF4 decoders are more ‘strict’ than asammdf in regards to this, hence you may experience that asammdf decodes your data without issues. To solve collisions, you can remove excess duplicate CAN IDs from your DBC file(s) to ensure uniqueness. As a ‘special case’ of this, if you have a J1939 DBC file with overlapping 18-bit PGNs (but unique 29-bit CAN IDs), the decoder will also consider this as a collision. As before, you can manually remove duplicate entries. Alternatively, if you do not wish to match data at the PGN level, you can change your DBC file to a non-J1939 type with exact 29-bit ID matching by changing the field BA_ "ProtocolType" "J1939"; to BA_ "ProtocolType" ""; in a text editor.
[4]The asammdf GUI will attempt to decode messages where the DBC file has a matching ID, even if the DLC is not matched. For example, you raw data may contain a message with DLC of 6, while your DBC file states that this message has a DLC of 8. In this case, the asammdf GUI will still decode the 6 bytes as per the DBC file, while the MF4 decoder ignores the message entirely. To resolve this, update your DBC file to have the correct DLC value for each message.