J1939-73 DBC File - Heavy Duty Diagnostics (DM1, DM2, ...)

If you are just looking to analyze data from heavy duty vehicles through signals like speed, RPM, temperatures etc then the J1939 DBC will suffice. However, if you also need to diagnose issues in the vehicle, the J1939-73 DBC offers a convnient tool in decoding relevant diagnostic information. Tools like our Python API support loading of both DBC files in parallel.

If you're using our CANedge, we can offer to decode a sample log file with the DBC before you decide whether to purchase the J1939-73 DBC file (this sample conversion is 100% free). This way you can see exactly what data parameters you can extract from a specific vehicle (or multiple vehicles) before deciding. Simply contact us with your data samples.

To decode J1939-73 data, you'll need a softare tool that supports J1939 diagnostics (like e.g. Vector tools) or a tool that at least supports ISO TP (transport protocol) as the data relevant to J1939-73 is normally communicated across multiple frames. If you are e.g. using our CANedge CAN bus data loggers, you can leverage our Python API to handle the decoding of your J1939 data via the J1939-73 DBC file. This also means that you can e.g. visualize the decoded signals in dashboard tools like Grafana - see our dashboard playground as an example of this.

The J1939-73 standard specifies how to decode diagnostic messages like DM1, DM2 etc. - however, constructing a DBC file based on this can be cumbersome and time-consuming. By using our J1939-73 DBC file you'll save significant time and complexity vs. constructing your own from scratch.

The J1939-73 DBC information serves as a powerful enhancement on top of your basic J1939 DBC data (speed, RPM, ...) by providing information on active/past issues in a vehicle - letting you quickly pinpoint problems. This information can be visualized in dashboards like our J1939-73 Grafana playground example.

Different software tools handle J1939-73 diagnostic messages differently. Some tools expect the Diagnostic Trouble Codes to be packed as complete signals of 32 bit each, performing the unpacking within the software. This works well if your software has existing handling for J1939-73. If that is not the case, you will most likely prefer to split out each DTC into sub components: SPN, Failure Mode Identifier (FMI), Occurrence Count (OCC) and Conversion Method (CM). This enables you to perform a tool agnostic analysis of your decoded data, hence why this split version is our default methodology.

We do, however, also offer a version that includes each DTC as a combined signal - you can request this version if you buy the J1939-73 DBC file.

To decode the J1939-73 data, you'll need a software/API tool that can handle multiframe decoding (ISO TP). If you're using our CANedge, you can process the data via our Python API to extract signals. For example, the DM1 message may contain a large number of Diagnostic Trouble Codes across multiple frames. Our API lets you re-assemble these frames and extract data for each DTC separately. This data can then be further processed as per your requirements using the API - or you can write it to e.g. a timeseries database and visualize the results in e.g. Grafana dashboards.

Note that you cannot e.g. use this DBC file in tools like the asammdf GUI, since it does not (yet) support J1939 ISO TP multiframe decoding. Similarly, other CAN software may treat J1939 ISO TP differently, which may require tweaks to the DBC. For such cases, you are welcome to reach out to us for sparring and support in adapting the DBC for your requirements.

A DTC consists of multile signals, including in particular the SPN. The SPN is useful in identifying the root cause of the DTC - i.e. what part of the vehicle is causing the problem. In some cases, the SPN will be a standardized J1939 SPN - while in other cases it will be proprietary.

If you order our J1939 DBC file (based off the J1939 Digital Annex), it will provide you with a lookup table that you can use to map standardized SPNs to their names and descriptions. This can in turn be used to create e.g. value mappings in tools like Grafana dashboards (as per our playground).

Note that when interpreting DTCs from e.g. a DM1 message, you'll need to construct the 'final' SPN by taking the sum of the SPN signal and the SPN_High signal. This is due to the nature of how the signal encoding is constructed in J1939-73 vs. what is possible to construct in DBC files. In our dashboard playground example, you can see how we e.g. achieve this via some simple query manipulation. Similarly, you can achieve this via our Python API by creating calculated signals.

We'll inform you if there is an update to a DBC file revision that you've purchased within the same J1939-73 standard revision. For example, if you've bought a DBC file corresponding to the SAE J1939-73 2022-08 release, you'll be able to get updates for this version.

However, the legal license for the underlying SAE J1939 details is linked to each publication. As such, you would need to make a separate purchase if you want to get updated to a more recent publication.

No, the J1939-73 DBC file solely contains diagnostic message information, letting you extract and decode DTC details from heavy-duty vehicles. For decoding the basic J1939 data like speed, RPM, temperatures etc, see instead our J1939 DBC file.

We are very open to requests for additions - if you're looking for specific aspects of the J1939 standard to be added, let us know and we'll get back to you asap. For any further questions, please contact us - we always aim to get back in < 24 hours.

Should you identify any issues, please contact us and we'll review and resolve them.