J1939 Data Logger - Easy Truck Fleet Telematics (WiFi, 4G)

If you're new to vehicle telematics and fleet management, consider below basic definition:

The goal of vehicle telematics is to collect vehicle, driver & environmental data
— and use the data to optimize fleet operations

Vehicle telematics is commonly used in heavy-duty fleet management (trucks, buses, construction, mining, ...), prototype field testing and light trucks/service cars (delivery vans, postal services, police cars, taxis, ...). It is used by both vehicle OEMs (Original Equipment Manufacturers) and end users (e.g. construction site managers, fleet managers etc.). In some cases, the telematics system is owned by the OEM and served to an end user in the aftermarket - while in other cases, an aftermarket user may set up their own fleet management system.

A Telematics Control Unit (TCU) is a telematics device installed in a vehicle, facilitating the tracking of data from the vehicle.

Most telematics control units support the following features:

• GPS tracking: The TCU often records GPS data to track the vehicle position
• WiFi/3G/4G/GSM: The TCU needs to transfer the data to a server for processing

Today, most truck fleet management involves simple TCUs that communicate GPS data to enable route optimization and planning. However, these basic telematics systems typically do not collect data from the vehicle sensors (i.e. J1939 data).

Learn more about the CANedge2

Advanced telematics control units like the CANedge may support the following:

• CAN bus data logging: Some TCUs support logging of CAN bus data, incl. SAE J1939 and FMS
• Edge processing: A TCU may need to perform 'edge processing' of the data (filtering, compression, triggers, ...)
• Memory: Some TCUs have memory buffers (e.g. an SD card) to buffer data in zones with no connectivity
• Over-the-air updates: To enable vehicle fleet management at scale, over-the-air updates of firmware/configs are required
• Data requests: It may be relevant to enable requesting of data via CAN bus, e.g. to log diagnostic trouble codes (DTC)
• Modularity: Often it is necessary to add external sensors (e.g. temperature, ...) to the TCU (e.g. communicated via CAN)
• Security: Modern TCUs should support secure telematics, incl. TLS data transfer, data encryption etc

Traditional telematics may be a good fit for some - but it comes with a number of downsides:

• Low specs: Most telematics dongles do not enable the type of pro spec logging required by vehicle OEMs
• High costs: You pay a monthly fee which quickly adds up - incl. potential vendor lock-ins
• Complex platforms: One-size-fits-all platforms typically entail significant complexity - and may not fit your use case
• No data ownership: Your sensitive data is sent to the telematics provider's server, not your own
• Poor security: Many telematics solutions struggle with security issues, leaks and GDPR/CCPA challenges

The CANedge has been designed to offer a different solution:

• Pro specs: The CANedge is a unique combination of professional-grade CAN logging - with the convenience of telematics
• Zero fees: You only pay for the hardware - all software/APIs are 100% free and open source
• Simple-to-use: The device is simple-to-use and lets you start small, gradually scaling to more advanced setups
• Zero lock-in: Data is uploaded to your own server via your WiFi access points or 3G/4G - with no vendor lock-in
• Interoperable: data & config files use standard formats (MDF4, JSON), easing integration and enabling use of your favorite tools
• Secure: The device can encrypt data & passwords on the SD (e.g. for GDPR/CCPA compliance) - and upload data via HTTPS

To learn more about the advantages, contact us.

The CANedge2 connects via WiFi, while the CANedge3 connects via 3G/4G (via your own SIM card). This lets you select the option that best suits your deployment needs (and you can of course mix the two variants).

Generally, the CANedge is often deployed by automotive OEM engineers for use in prototype fleet testing. Here, there is often a need to transfer huge amounts of data - but not necessarily in near real-time. For this type of use case, the unique combination of a pro specs CAN logger with SD card and WiFi/LTE telematics capability is ideal.

When selecting the right CAN logger for your use case, it's important to consider whether you need WiFi/LTE or not. The CANedge2/CANedge3 is ideal for J1939 telematics, but for some use cases you may prefer the CANedge1 J1939 logger. The CANedge1 is identical to the CANedge2/CANedge3, except that it does not offer remote data transfer. The CANedge1 may be sufficient if you e.g. need to only collect data rarely, from few vehicles - or on an event-based basis. For example, some end users deploy the CANedge1 as a J1939 blackbox logger and only collect data if an issue occurs. If you're in doubt which option you need, please contact us.

Some J1939 applications have built-in GPS data that is communicated via the CAN bus - and which can be decoded using a standard J1939 DBC. However, other vehicles do not broadcast this information by default. If you need to add GPS and/or 3D inertial sensor data to your J1939 telematics data, you can use a CANedge incl. GNSS/IMU.

Most commercial trucks and heavy duty vehicles use the SAE J1939 protocol (or the derived FMS standard) for the vehicle CAN bus sensor network. A CAN logger can therefore serve as a truck data logger, assuming it can record the raw CAN bus data (which will in this case be equivalent to J1939 data).

In contrast to e.g. passenger cars, this means that the method for converting data to physical values (aka human-readable form) is standardized across many brands, years and manufacturers. From a vehicle data logging perspective, this allows end users (e.g. fleet managers or operators) to get data for their fleet management systems, without having access to the proprietary conversion rules owned by the OEMs (original equipment manufacturers).

To decode raw J1939 data from e.g. a truck or tractor, you'll need a database of conversion rules. Typically, a J1939 DBC file is used for this purpose. A J1939 DBC file takes outset in the official SAE J1939 standards, which provide conversion info for a large share of the data that is potentially available in a given vehicle.

However, most vehicles also use a number of proprietary parameters - this data still conforms to the J1939 standard, but you'll need to reverse engineer the CAN data to identify how to interpret these specific parameters.

With that in mind, we've listed below some examples of data parameters that may be available in J1939 heavy duty vehicles:

If you've logged a range of CAN IDs from your truck, bus, harvester or other J1939/FMS vehicle, you can identify what J1939 PGNs are contained in your data. To do so, use our CAN ID to PGN converter or learn more on our J1939 DBC page.

Yes, the CANedge2 is basically a CAN bus data logger - meaning that it can record raw CAN data from any high speed CAN bus (ISO 11898-2) application. This includes practically all vehicles, including car fleets like taxis, police cars, ambulances etc.

Typically you'll then log OBD2 data, which can be seen as the equivalent to J1939 data - but for passenger cars.

If you're interested in car fleet management, check out our OBD2 data logger article.

The ELD mandate is a US regulation that specifies that operators of certain commercial vehicles will need to use electronic logging devices (ELD) to monitor driver activity. This can include operational data like hours of service (HOS). It basically replaces the requirement for paper log books.

The CANedge can be a simple low cost method for storing these logs by recording the relevant J1939 parameters - either to the SD card, or alternatively transferring the data to your own server for automated compliance. To learn more, contact us.