Convert J1939 diagnostic messages via software/API tools
The DBC contains 50+ DM messages split into signals
Send us a CANedge log file for a free sample decoding
Benefit from free corrections based on large user base
Avoid manually constructing the DBC file from scratch
Includes J1939-73 PDF + license (price: 167$)
What is a DBC file?
A DBC file is a standardized method for storing the "rules" on how to interpret raw CAN bus data. In particular, it contains details on what 'signals' (e.g. RPM, Vehicle Speed, …) are contained within which 'messages' (i.e. CAN IDs).
In the J1939 standard, messages are referred to as Parameter Group Numbers (PGN) and signals as Suspect Parameter Numbers (SPN).
Further, a DBC file includes names, descriptions, positions and lengths of the signals - as well as how to offset and scale them.
This DBC file download includes:
- A J1939-73 DBC file with details for DM1, DM2, ..., DM52
- The J1939-73 standard PDF
- One legal license (1 user, 1 PC) matching the J1939-73 license (stand-alone price: 167$)
CSS Electronics acts as a re-seller for the Society of Automotive Engineers (SAE) for the J1939 database file. Terms include the SAE terms related to purchase.
When is the database useful?
The J1939 protocol is used across most heavy-duty vehicles, including commercial trucks, tractors, transit buses etc. Because the protocol is standardized, you can use our J1939 DBC file to decode data across the majority of heavy-duty vehicle brands/models.
The J1939-73 DBC file complements our J1939 DBC by adding decoding information on the J1939 diagnostic messages, also known as DM1, DM2 etc. These messages contain critical information on potential issues in a heavy-duty vehicle through warning lamp statuses and Diagnostic Trouble Codes (DTC). The latter contain information on which part of the vehicle has issues (through an SPN identifier) and e.g. what type of failure is present (though a failure mode identifier).
For basics on J1939 data logging, see our J1939 telematics intro.
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.
Check out the tech specs and FAQ above - or buy now!
Do you have any questions?Contact us
|Standard(s)||J1939-73 (2022-08) - PDF is included in download|
|Multipacket||Multipacket syntax is used for the multipacket PGNs included in the DBC|
|Descriptions||Partial message/SPN descriptions included in DBC (full included in PDF)|
|Value tables||Some value tables are included|
|Network nodes||Not included|
|DTC methodology||DTCs are split into SPN, SPN_High, Failure Mode Identifier, Occurrence Count, Conversion Method|
|15+ DTCs for each relevant DM (actual number depends on number of active DTCs in vehicle)|
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.