LEAF CANbus decoding. (Open discussion)

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
On my 2019 Leaf, I'm monitoring the DLC connector near the steering wheel, pins 6 & 14, trying to see the primary CAN bus data. Using an oscilloscope, I'm not seeing any data at all on either line, they're both sitting at the recessive voltage of about 2.5.
Everything I've read suggests there should be bits flying out of that connector, but for me they're just flat. If I plug in my LeLINK ODB adapter, LeafSpy is able to read all the usual stuff.
I'm thinking I'm doing something really wrong here - anybody seen this before? Wondering if I've badly misunderstood the nature of that bus.
 
cwpaynter said:
On my 2019 Leaf, I'm monitoring the DLC connector near the steering wheel, pins 6 & 14, trying to see the primary CAN bus data. Using an oscilloscope, I'm not seeing any data at all on either line, they're both sitting at the recessive voltage of about 2.5.
Everything I've read suggests there should be bits flying out of that connector, but for me they're just flat. If I plug in my LeLINK ODB adapter, LeafSpy is able to read all the usual stuff.
I'm thinking I'm doing something really wrong here - anybody seen this before? Wondering if I've badly misunderstood the nature of that bus.

Check here: http://www.mynissanleaf.com/viewtopic.php?t=10396#p239692

Remember, the CAN bus produces a differential signal between the two pins. When inactive, both pins are at 2.5 volts.
 
Yes, that's the problem, both lines are at the recessive 2.5 volts, indicating no data on the bus. I expect to see CAN hi going up to about 3.5 volts for a dominant bit, and CAN lo going to about 0V, but they're both steady at 2.5V. That LeafSpy still works indicates to me that the CAN bus is functional and I'm just not using it right. In my case I have a short odb cable plugged in with the scope ground on 4 or 5, and the probe on pin 16 or 4. I've also tried a differential measurement with the scope ground on CAN lo and the probe on CAN hi, there's essentially no voltage between them. (The scope's earth ground is floating due to a missing ground pin on the extension cable from the house)

I don't see why no data should be coming out, but I wonder if the DLC connector needs to have a couple pins shorted to indicate that it should become active? Or perhaps I misunderstood the bus, and have to request every message? I understood that the various modules are all transmitting stuff to each other, and that I would be able to see that data whizzing by.
 
cwpaynter said:
Yes, that's the problem, both lines are at the recessive 2.5 volts, indicating no data on the bus. I expect to see CAN hi going up to about 3.5 volts for a dominant bit, and CAN lo going to about 0V, but they're both steady at 2.5V. That LeafSpy still works indicates to me that the CAN bus is functional and I'm just not using it right. In my case I have a short odb cable plugged in with the scope ground on 4 or 5, and the probe on pin 16 or 4. I've also tried a differential measurement with the scope ground on CAN lo and the probe on CAN hi, there's essentially no voltage between them. (The scope's earth ground is floating due to a missing ground pin on the extension cable from the house)

I don't see why no data should be coming out, but I wonder if the DLC connector needs to have a couple pins shorted to indicate that it should become active? Or perhaps I misunderstood the bus, and have to request every message? I understood that the various modules are all transmitting stuff to each other, and that I would be able to see that data whizzing by.

That CAN pair just isn't being accessed. Try looking at the other CANs referenced in the link. Avoid shorting pins. You can back-probe
the connector when LeafSpy is connected to verify a signal.
 
cwpaynter said:
On my 2019 Leaf, I'm monitoring the DLC connector near the steering wheel, pins 6 & 14, trying to see the primary CAN bus data. Using an oscilloscope, I'm not seeing any data at all on either line, they're both sitting at the recessive voltage of about 2.5.
Everything I've read suggests there should be bits flying out of that connector, but for me they're just flat. If I plug in my LeLINK ODB adapter, LeafSpy is able to read all the usual stuff.
I'm thinking I'm doing something really wrong here - anybody seen this before? Wondering if I've badly misunderstood the nature of that bus.
I only had a 2019 LEAF briefly on a test drive, so didn't have much time to poke about, but using the cable I have for my 2016 LEAF and OVMS module, the only packets I logged were active requests and replies on addresses 7XX. I didn't see any routine CAR or EV bus packets on addresses 0XX--6XX, as I would normally expect in the older models. So my guess is that the 2019 OBD port is connected to some gateway device which will only relay 7XX traffic.
 
caederus said:
cwpaynter said:
On my 2019 Leaf, I'm monitoring the DLC connector near the steering wheel, pins 6 & 14, trying to see the primary CAN bus data. Using an oscilloscope, I'm not seeing any data at all on either line, they're both sitting at the recessive voltage of about 2.5.
Everything I've read suggests there should be bits flying out of that connector, but for me they're just flat. If I plug in my LeLINK ODB adapter, LeafSpy is able to read all the usual stuff.
I'm thinking I'm doing something really wrong here - anybody seen this before? Wondering if I've badly misunderstood the nature of that bus.
I only had a 2019 LEAF briefly on a test drive, so didn't have much time to poke about, but using the cable I have for my 2016 LEAF and OVMS module, the only packets I logged were active requests and replies on addresses 7XX. I didn't see any routine CAR or EV bus packets on addresses 0XX--6XX, as I would normally expect in the older models. So my guess is that the 2019 OBD port is connected to some gateway device which will only relay 7XX traffic.

Yes, like most later vehicles, e.g. M/B, BMW, Porsche, the Plus most likely has a central gateway to access other ECUs not directly
connected to the OBDII connector, but are on slower speed single-ended low speed bus, e.g. inst cluster.
 
caederus said:
cwpaynter said:
On my 2019 Leaf, I'm monitoring the DLC connector near the steering wheel, pins 6 & 14, trying to see the primary CAN bus data. Using an oscilloscope, I'm not seeing any data at all on either line, they're both sitting at the recessive voltage of about 2.5.
Everything I've read suggests there should be bits flying out of that connector, but for me they're just flat. If I plug in my LeLINK ODB adapter, LeafSpy is able to read all the usual stuff.
I'm thinking I'm doing something really wrong here - anybody seen this before? Wondering if I've badly misunderstood the nature of that bus.
I only had a 2019 LEAF briefly on a test drive, so didn't have much time to poke about, but using the cable I have for my 2016 LEAF and OVMS module, the only packets I logged were active requests and replies on addresses 7XX. I didn't see any routine CAR or EV bus packets on addresses 0XX--6XX, as I would normally expect in the older models. So my guess is that the 2019 OBD port is connected to some gateway device which will only relay 7XX traffic.

@caederus

have 2018 leaf tekna 40kw, can you explain exactly how to send an active request on 7xx adresses with a ELM module over the ODB plug.
you may also PM me
 
Thank you for the suggestions folks, I didn't see any traffic on the other CAN buses either, but I now have a few strategies to try tonight:

  • try to transmit requests on the bus using a Pycom LoPy4 board with a CAN transceiver
    use the same hardware to drive around and see if that stimulates any traffic
    borrow a buddy's CAN -> USB dongle and sniff using that, and possibly transmit requests.
 
virol said:
have 2018 leaf tekna 40kw, can you explain exactly how to send an active request on 7xx addresses with a ELM module over the OBD plug.
LEAF active queries and replies use UDS over ISO-TP. Unfortunately the wikipedia documentation is incomplete, and the addresses and data bytes are not defined by the standard anyway, so are all informed guesswork.

A simple example would be reading the odometer, where both query and reply each fit in single packets:
Code:
Query: 743#022119FFFFFFFFFF
Reply: 763#056119005D6AFFFF
743 is the query address for the instrument cluster
The first data byte 02 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 2 in the lower 4 bits means there are two UDS data bytes (21 19):
- - 21 is the UDS service ID "Read data by local ID", which takes one parameter
- - 19 is the local ID, which the instrument cluster interprets as odometer.
The remaining FF bytes are padding.

763 is the reply address (for the instrument cluster)
The first byte 05 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 5 in the lower 4 bits means there are five UDS data bytes (61 19 00 5D 6A)
- - 61 19 is the same as in the query, with 0x40 added to the service ID to indicate it is a reply.
- - 005D6A is the odometer reading.
The remaining FF bytes are padding.
 
ybpvin said:
I wonder, thank you. how can I read the byte eeprom dashboard?

Seriously doubt it can be read via any CAN bus, i.e. the cluster processor's flash memory (EEPROM). Most likely you'll need to pull the cluster,
and even then without knowing the processor type (unlikely separate EEPROM), not easy.
 
Ah, it literally just adjusts the odometer. That is not very useful, I was hoping it was a proper scan tool. This is just a tool to mess with odometers to make the car look younger...
 
caederus said:
virol said:
have 2018 leaf tekna 40kw, can you explain exactly how to send an active request on 7xx addresses with a ELM module over the OBD plug.
LEAF active queries and replies use UDS over ISO-TP. Unfortunately the wikipedia documentation is incomplete, and the addresses and data bytes are not defined by the standard anyway, so are all informed guesswork.

A simple example would be reading the odometer, where both query and reply each fit in single packets:
Code:
Query: 743#022119FFFFFFFFFF
Reply: 763#056119005D6AFFFF
743 is the query address for the instrument cluster
The first data byte 02 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 2 in the lower 4 bits means there are two UDS data bytes (21 19):
- - 21 is the UDS service ID "Read data by local ID", which takes one parameter
- - 19 is the local ID, which the instrument cluster interprets as odometer.
The remaining FF bytes are padding.

763 is the reply address (for the instrument cluster)
The first byte 05 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 5 in the lower 4 bits means there are five UDS data bytes (61 19 00 5D 6A)
- - 61 19 is the same as in the query, with 0x40 added to the service ID to indicate it is a reply.
- - 005D6A is the odometer reading.
The remaining FF bytes are padding.

@cadreus, I have a working CAN transceiver now, and confirm there's nothing happening on the bus, until I activate LeafSpy. I can sniff both sides of that conversation, and am seeing various requests and responses, and can decode the ISO-TP packets to reassemble the UDS messages. I can blindly send those commands over my own interface, and I get the responses, including the VIN number in one case. This is all good, but I'm not seeing much info on the canmsgs spreadsheet about those UDS commands. Are you aware of a list of what those commands mean?
 
I repeated the Celeron55 project with zapuky the engine Nissan a bodice of 2013. The engine powered from the socket 220 volts)).
Now I want to program a power generation algorithm the engine, but I cannot find can codes of management of command of the inverter.
What Id operates this funtion?
 
caederus said:
virol said:
have 2018 leaf tekna 40kw, can you explain exactly how to send an active request on 7xx addresses with a ELM module over the OBD plug.
LEAF active queries and replies use UDS over ISO-TP. Unfortunately the wikipedia documentation is incomplete, and the addresses and data bytes are not defined by the standard anyway, so are all informed guesswork.

A simple example would be reading the odometer, where both query and reply each fit in single packets:
Code:
Query: 743#022119FFFFFFFFFF
Reply: 763#056119005D6AFFFF
743 is the query address for the instrument cluster
The first data byte 02 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 2 in the lower 4 bits means there are two UDS data bytes (21 19):
- - 21 is the UDS service ID "Read data by local ID", which takes one parameter
- - 19 is the local ID, which the instrument cluster interprets as odometer.
The remaining FF bytes are padding.

763 is the reply address (for the instrument cluster)
The first byte 05 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet.
- 5 in the lower 4 bits means there are five UDS data bytes (61 19 00 5D 6A)
- - 61 19 is the same as in the query, with 0x40 added to the service ID to indicate it is a reply.
- - 005D6A is the odometer reading.
The remaining FF bytes are padding.

"005D6A is the odometer reading."...and decoding that gives us 23,914kms?
 
NiallDarwin said:
"005D6A is the odometer reading."...and decoding that gives us 23,914kms?
Yes, that's correct, and unlike some other distance and speed values whose units can change depending on region of manufacture or user display preference, this one always seems to be in km.
 
It looks like the 2019 Leaf has a different electrical configuration than the earlier cars. What I would do is go to https://www.nissan-techinfo.com and pay for a one day subscription for $20 to get the 2019 service manual. The 2011/2012 manuals that I have had a whole section on the CAN bus architecture of the vehicle.

It's likely the CAR CAN bus has been removed from the OBD connector, and replaced with a new "diagnostic bus" that talks just to the VCM, which can relay the message onto the requested module by decoding the query address and sending it onward to the appropriate bus where the module is located. Older leaf VCMs do this already on the CAR can bus to the EV CAN bus. It's how an ELM327 can talk to modules on the EV CAN bus (BMS, Inverter, HVAC, etc.). When leafspy first came out Turbo3 was requiring modified ELM327s which looked at the EV bus directly, which quickly ended when this phenomenon was discovered. I think Nissan's official diagnostics tools take the same approach as LeafSpy does today, just querying for info instead of looking at the values being shot around by the various modules.

Is EV CAN still present on pins 12 and 13?
 
Back
Top