Visualizing Nissan Leaf SoC (%) in CAN Bus Telematics Dashboard
Case Studies / CSS Electronics
CSS Electronics
CSS Electronics is a developer of CAN bus hardware incl. CAN/LIN data loggers and sensor-to-CAN modules [Note: This is an 'in-house' case study].
What problem did you solve?
In order to provide a useful case study for our recent Unified Diagnostic Services (UDS) tutorial I wanted to record battery data from my Nissan Leaf Tekna 2019 using the CANedge2. The purpose was to evaluate the feasibility of collecting State of Charge (SoC%) and battery pack temperatures via UDS (a common request from our end users). I also wanted to use our CANmod.gps (GNSS & 3D IMU) and CANmod.temp (4 x thermocouples) to put the data in context.
Tip: Download the Nissan DBC, data and dashboard here.
Tip: See also our ChatGPT + CAN intro using EV6 data!
Read similar case studies for the Tesla, Enyaq and Kia EV6.
How did you solve it?
As explained in our UDS intro, info on how to request/decode State of Charge is proprietary - and only known to the OEM. However, in the specific case of the Nissan Leaf, others have previously done some reverse engineering, sharing the results online. According to the forum, the Nissan Leaf should respond to UDS-style requests with multiframe CAN ISO-TP responses.
The asammdf GUI Tabular Display is great for quickly reviewing raw CAN frames for
light reverse engineering.
I configured the CANedge2 with a fixed 500K baud rate and two request messages of 5000 ms frequency and a delay between them of 2000 ms. Because the data is packaged across multiple frames, I also added a 'Flow Control' message to be sent with a 50 ms delay after each of the two request messages. You can see my Configuration File in our sample data.
As a general rule, when you send CAN frames into an active CAN bus, caution is required. When you e.g. request OBD2 PIDs, you do so within a standardized protocol and it's practically impossible to cause any harm unless you actively try to do so. However, if you test out proprietary CAN frames as in this case study, it is strongly recommended that all testing is done while the car is at a stand-still with the handbrake drawn.
In this specific case study I send infrequent requests with low priority CAN IDs - meaning that it's highly unlikely to cause busload issues and any CAN IDs used by the vehicle will retain higher priority than my requests. However, I could in principle be triggering unexpected events/reactions from the vehicle as I'm relying on information from an online forum and not the OEM - hence the need for caution. Further, as a precaution I would disconnect the logger when the vehicle is turned off or charging.
From my online research I came to the conclusion that the older models (pre 2018) of the Nissan Leaf would provide access to the raw CAN traffic via the OBD2 connector - which is why you may encounter DBC files online for this type of data. However, more recent models like my 2019 car block access to the raw CAN traffic when using the OBD2 connector by inserting a gateway. In addition, the vehicle does not support OBD2 requests, which is increasingly the case for EVs as OBD2 is not required per se. However, as shown in this case study, the car does respond to diagnostic requests using what appears to be a variant of the UDS protocol - though using a service 0x21 instead of the expected UDS service, 0x22 (ReadDataByIdentifier).
After 2 minutes I extracted the MF4 log file and reviewed it in raw form via the asammdf tabular display. Based on this, it became evident that the forum post details on the signal bit position were incorrect (or outdated).
To 'reverse engineer' the SoC signal I would therefore log data over two periods while noting the displayed state of charge value from the vehicle dashboard. In addition, I would assume that SoC would be a 3 byte motorola signal (as indicated by the forum). Using this information I managed to identify the start bit for the SoC signal through iterative conversion from HEX to DEC (comparing vs. the dashboard values), after which I could create a simple CAN database (DBC file) for storing this information. The battery pack temperatures were simple as the bit positions matched the forum specifications.
With this resolved, I could install the full kit in the trunk of my Nissan Leaf, using a DB9-extension-cable to connect the Channel 1 to my car's OBD2 connector. The trunk was preferred because it allowed me to install the CANmod.gps as per the sensor fusion requirements - with minimal configuration changes.
Get the 'EV data pack'
Want to try working with real electric car data?
Download your 'EV data pack' - incl. sample data, configuration files & DBC files from popular electric cars:
- Kia EV6
- Nissan Leaf
- Tesla Model 3
- Skoda Enyaq
- and more ...
This also contains the 3000+ km Kia EV6 dataset (100+ signals)!
Learn more
Finally, I collected data across a number of trips and used our InfluxDB & Grafana dashboard integration to visualize the data as per the playground link. This output method was selected as it enables me to leverage the built-in UDS multiframe decoding functionality of our open source Python API.
What benefit has this led to?
This mini project provides a practical illustration of how you can create rich datasets from e.g. electric vehicles using the CANedge/CANmod devices. In particular, being able to remotely monitor State of Charge and correlate it with various temperatures (outside, inside, battery packs) can be useful for academia studies and vehicle fleet management. Further, it helps showcase how different tools can be helpful in analyzing the data - incl. e.g. the asammdf GUI for ad hoc analyses and telematics dashboards for browser-based visualization.
— Martin Falch, co-owner at CSS Electronics
Products used in this case study
Ready to log data from your EV?
Get your CAN logger today!
