Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Tom Parker via EV]

On 14/03/17 07:07, Bill Dube via EV wrote:


Outstanding work Tom.
Not many folks have the ability (or patience) to tackle this job, but 
a lot of us will use this. Makes the Leaf battery module so much more 
useful as a functional unit.


To be clear my contribution so far is only

* writing a simple tool to explore how the system behaves when messages 
are modified
* writing a configuration file for kayak and a wireshark dissector to 
decode some of the can bus messages
* finding the car mostly works when the battery can send messages to it 
and it cannot send messages to the battery
* discovering which signals the leaf instrument cluster is using for the 
capacity, temperature and state of charge displays


The work to decipher enough of the Leaf BMS to use it outside the car 
was done by others.

___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Cor van de Water via EV]

Hi Bill,
Maybe we should talk.
My understanding was that the BMS communication was already well enough
understood to allow an app like LeafSpy, but indeed we are finding new
bits and pieces here. Very interesting.

My daily driver has 2 Leaf packs including 2 BMS (LBC) which are both
wired to the cabin, currently terminating in a toggle switch and an
ELM327 so I can use LeafSpy to alternate between the two BMS'es to
monitor both packs which are 2 independent strings, wired in parallel to
the main contactors.

My plan is to adapt the "CANary" that some Leaf folks have used to
display the info from the Leaf's 2 CAN buses and instead, write a
program to inquire of both BMS'es via both CAN buses and display the
statuses of the two packs on the two LCD displays of the CANary.

One other wild idea is to take a WinTerm and boot it in DOS, since my
truck's Dolphin controller needs a DOS program to be configured, then
add a larger LCD monitor that I mount behind the seat, just visible
through the rear window above the truck bed and display consumption
(miles per kWh) and power, voltage, current and other geek things on to
draw attention to the fact that this is not just a regular S10 truck.
Since many LCD monitors run on 12V, just like the WinTerm, all I need is
the IGN wire to power it and display the WinTerm VGA output. All that is
needed is a small program receiving the Dolphin serial output and
decoding it, to generate the display info. That might also lead to
reverse engineering the current DOS program to program the controller,
which in turn will help to keep the controller accessible in future
decades as DOS computers are dying...
Luckily there are still some around and I found a rather recent laptop
that has a serial RS232 bus which I can boot in DOS. The WinTerm is much
more rugged than a laptop and is essentially a Windows computer without
drives so plugging in a memory stick and booting it in DOS is for now
the most rugged DOS computer I can think of - but requires external
keyboard and monitor, which I can turn into a feature...
Oh and a WinTerm can be had for almost nothing...

But first I need to get around to assemble the two CANary hardware sets
that I ordered and verify everything works, then start programming...
In the mean time the two Leaf BMS'es keep the two packs nicely balanced
with just feeding them 12V continuously even without Leaf surrounding
them.

Cor van de Water 
Chief Scientist 
Proxim Wireless 
  
office +1 408 383 7626Skype: cor_van_de_water 
XoIP   +31 87 784 1130private: cvandewater.info 

http://www.proxim.com

This email message (including any attachments) contains confidential and
proprietary information of Proxim Wireless Corporation.  If you received
this message in error, please delete it and notify the sender.  Any
unauthorized use, disclosure, distribution, or copying of any part of
this message is prohibited.


-Original Message-
From: EV [mailto:ev-boun...@lists.evdl.org] On Behalf Of Bill Collins
via EV
Sent: Monday, March 13, 2017 10:38 AM
To: ev@lists.evdl.org
Subject: Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

It sounds like the BMS is well understood enough to do something that
I've thought about: building a module to combine the outputs of two (or
more) packs or to use the 30kWh pack in a car built with the 24kWh pack.

Bill
___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA
(http://groups.yahoo.com/group/NEDRA)

___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Sean Korb via EV]

Thanks Tom, this gives us a lot of room to build.  We could even have
real time R or RShiny output to a display to do trends and
predictions.

sean

On Sun, Mar 12, 2017 at 6:07 AM, Tom Parker via EV  wrote:
> I wrote a man in the middle for the leaf battery communication. It uses
> can4python and Kayak's kcd format to describe the signals. It probably only
> works on Linux. Source code is here
> https://carrott.org/git/leaf-can-utils.git
>
> It decodes all the messages received on one interface (from the battery)
> into signals, lets me change their values, and then re-encodes them back
> into the can bus format, recalculates the new checksum when necessary and
> sends them out the other interface (to the car).
>
> Yesterday I spent some time testing it on a Gen 1 leaf at
> https://bluecars.nz
>
> We cut the can bus wires inside the battery box, just after they go through
> the water proof connector to the outside and connected about 1 metre of thin
> figure 8 wire to each side of the cut. This let us access the bus on the car
> and the bus on the battery while the battery was plugged in under the car.
> It's possible to get enough slack in the internal battery loom to feed the
> connector all the way through the machined hole and make room for some extra
> wires to pass through.
>
> With the two pairs connected together, the car behaved normally, going into
> ready and spinning the wheels.
>
> The BMS module terminates the bus so we connected a termination resistor to
> the car side of the cut and used termination on the CAN interface talking to
> the battery. We plugged the other end of the man in the middle to the OBD2
> port and didn't use termination.
>
> The MitM just worked.
>
> The car is very tolerant of errors on the CAN bus. You can stop the battery
> messages and it goes into turtle mode and all the battery info disappears
> off the instrument cluster. When you re-start the battery messages it goes
> back to normal mode and the battery info reappears. Start-up is quite
> critical, if you don't let the battery send it's start up messages the car
> doesn't go into ready mode. The car never shut down or went into a permanent
> turtle mode while I was messing with data on the bus -- it always went back
> to normal mode if I restored the unmodified messages flow from the BMS. I
> modified the data in nearly every field to see what would happen.
>
> The car will go into ready and turn the wheels even when it cannot send
> messages to the battery. This means the startup sequence doesn't involve a
> car to battery handshake, even if the car is expecting some startup messages
> from the battery within a time window. The "check engine" light comes on and
> it does record some DTCs:
> * P3180 (EVC-249) VCM detects an error signal that is received from LBC via
> CAN communication for 0.02 seconds or more.
> * P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the
> following state remains for 2.8 seconds or more: LBC's calculation result to
> the VCM-set example question is incorrect.
>
> My MitM only works in one direction (from the battery to the car) and it
> turns out my CAN bus setup wouldn't let two programs play together, so when
> I started a CAN repeater (candump -b) to copy data from the car to the
> battery I got corrupted frames and no buffer space errors. I'm going to make
> the MitM work in both directions to resolve this.
>
> If you play a different car's battery messages into this car, it does not go
> into ready. I didn't spend much time on this and I didn't write code to
> start the BMS messages at the right time, I just started playing the
> recording of a running BMS and switched the car on. One experiment that I
> should have tried was to start the car with it's real battery and then
> switch to messages recorded from a different car. There are some new DTCs
> when you try to start a the car while playing messages recorded from another
> car including
>
> * P3102 Li-ion Battery ID Registration must be performed if the Li-ion
> battery controller or VCM is replaced.
>
> The next experiment is to swap in a BMS module from another car.
>
> I figured out some more of the BMS protocol by messing with the data and
> seeing how the car reacted.
>
> The Fuel Gauge display on the instrument cluster is powered by the GIDs
> signal (the first 10 bits of 0x5BC), not the state of charge signal (first
> 10 bits of 0x55B). I guess it knows how many GIDS is "full" because the
> battery will have fewer gids and still read full as it ages.
>
> 0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects the
> Fuel Gauge, lower numbers mean more bars, all other things being the same.
> Maybe this is used to calculate how many GIDs each bar is worth? I haven't
> explored this.
>
> The battery capacity gauge (the bars outside the fuel gauge) is controlled
> by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of the 5th byte)
> is 0x3, 0x5BC bits 16-19 (ie 

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Bill Dube via EV]

Outstanding work Tom.
Not many folks have the ability (or patience) to tackle this job, but 
a lot of us will use this. Makes the Leaf battery module so much more 
useful as a functional unit.


A bit like "LeafSpy", but for the serious EV hacker. :-)

Bill D.

___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Bill Collins via EV]

It sounds like the BMS is well understood enough to do something that I've 
thought about: building a module to combine the outputs of two (or more) packs 
or to use the 30kWh pack in a car built with the 24kWh pack.

Bill
___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Tom Parker via EV]

On 13/03/17 04:39, Jay Summet via EV wrote:
The next time I use a Leaf pack on an EV I want to be able to just 
plug it in "unmodified" and make use of the existing BMS and CAN 
interface, it's good to know that people are making good progress on 
the "auto" side of this.


The BMS is already understood mostly enough to use in a conversion. 
While it evidently logs an error when the car is missing, it's quite 
happy to tell you the battery current, voltage, remaining capacity and 
cell voltage levels. There are some more signals that would be a good 
idea to follow but I don't know if anyone has identified them:


* High voltage discharge permit signal
* System main relay ON permit signal
* Insulation resistance signal
* Li-ion battery dischargeable power signal

___
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

[Jay Summet via EV]

Great info, thanks!

The next time I use a Leaf pack on an EV I want to be able to just plug 
it in "unmodified" and make use of the existing BMS and CAN interface, 
it's good to know that people are making good progress on the "auto" 
side of this.


Jay

On 03/12/2017 06:07 AM, Tom Parker via EV wrote:

I wrote a man in the middle for the leaf battery communication. It uses
can4python and Kayak's kcd format to describe the signals. It probably
only works on Linux. Source code is here
https://carrott.org/git/leaf-can-utils.git

It decodes all the messages received on one interface (from the battery)
into signals, lets me change their values, and then re-encodes them back
into the can bus format, recalculates the new checksum when necessary
and sends them out the other interface (to the car).

Yesterday I spent some time testing it on a Gen 1 leaf at
https://bluecars.nz

We cut the can bus wires inside the battery box, just after they go
through the water proof connector to the outside and connected about 1
metre of thin figure 8 wire to each side of the cut. This let us access
the bus on the car and the bus on the battery while the battery was
plugged in under the car. It's possible to get enough slack in the
internal battery loom to feed the connector all the way through the
machined hole and make room for some extra wires to pass through.

With the two pairs connected together, the car behaved normally, going
into ready and spinning the wheels.

The BMS module terminates the bus so we connected a termination resistor
to the car side of the cut and used termination on the CAN interface
talking to the battery. We plugged the other end of the man in the
middle to the OBD2 port and didn't use termination.

The MitM just worked.

The car is very tolerant of errors on the CAN bus. You can stop the
battery messages and it goes into turtle mode and all the battery info
disappears off the instrument cluster. When you re-start the battery
messages it goes back to normal mode and the battery info reappears.
Start-up is quite critical, if you don't let the battery send it's start
up messages the car doesn't go into ready mode. The car never shut down
or went into a permanent turtle mode while I was messing with data on
the bus -- it always went back to normal mode if I restored the
unmodified messages flow from the BMS. I modified the data in nearly
every field to see what would happen.

The car will go into ready and turn the wheels even when it cannot send
messages to the battery. This means the startup sequence doesn't involve
a car to battery handshake, even if the car is expecting some startup
messages from the battery within a time window. The "check engine" light
comes on and it does record some DTCs:
* P3180 (EVC-249) VCM detects an error signal that is received from LBC
via CAN communication for 0.02 seconds or more.
* P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the
following state remains for 2.8 seconds or more: LBC's calculation
result to the VCM-set example question is incorrect.

My MitM only works in one direction (from the battery to the car) and it
turns out my CAN bus setup wouldn't let two programs play together, so
when I started a CAN repeater (candump -b) to copy data from the car to
the battery I got corrupted frames and no buffer space errors. I'm going
to make the MitM work in both directions to resolve this.

If you play a different car's battery messages into this car, it does
not go into ready. I didn't spend much time on this and I didn't write
code to start the BMS messages at the right time, I just started playing
the recording of a running BMS and switched the car on. One experiment
that I should have tried was to start the car with it's real battery and
then switch to messages recorded from a different car. There are some
new DTCs when you try to start a the car while playing messages recorded
from another car including

* P3102 Li-ion Battery ID Registration must be performed if the Li-ion
battery controller or VCM is replaced.

The next experiment is to swap in a BMS module from another car.

I figured out some more of the BMS protocol by messing with the data and
seeing how the car reacted.

The Fuel Gauge display on the instrument cluster is powered by the GIDs
signal (the first 10 bits of 0x5BC), not the state of charge signal
(first 10 bits of 0x55B). I guess it knows how many GIDS is "full"
because the battery will have fewer gids and still read full as it ages.

0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects
the Fuel Gauge, lower numbers mean more bars, all other things being the
same. Maybe this is used to calculate how many GIDs each bar is worth? I
haven't explored this.

The battery capacity gauge (the bars outside the fuel gauge) is
controlled by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of
the 5th byte) is 0x3, 0x5BC bits 16-19 (ie the low nibble of the 3rd
byte) contains the capacity bars. I haven't yet used 

[EVDL] Nissan Leaf CAN Bus Man in the Middle

[Tom Parker via EV]

I wrote a man in the middle for the leaf battery communication. It uses 
can4python and Kayak's kcd format to describe the signals. It probably 
only works on Linux. Source code is here 
https://carrott.org/git/leaf-can-utils.git


It decodes all the messages received on one interface (from the battery) 
into signals, lets me change their values, and then re-encodes them back 
into the can bus format, recalculates the new checksum when necessary 
and sends them out the other interface (to the car).


Yesterday I spent some time testing it on a Gen 1 leaf at 
https://bluecars.nz


We cut the can bus wires inside the battery box, just after they go 
through the water proof connector to the outside and connected about 1 
metre of thin figure 8 wire to each side of the cut. This let us access 
the bus on the car and the bus on the battery while the battery was 
plugged in under the car. It's possible to get enough slack in the 
internal battery loom to feed the connector all the way through the 
machined hole and make room for some extra wires to pass through.


With the two pairs connected together, the car behaved normally, going 
into ready and spinning the wheels.


The BMS module terminates the bus so we connected a termination resistor 
to the car side of the cut and used termination on the CAN interface 
talking to the battery. We plugged the other end of the man in the 
middle to the OBD2 port and didn't use termination.


The MitM just worked.

The car is very tolerant of errors on the CAN bus. You can stop the 
battery messages and it goes into turtle mode and all the battery info 
disappears off the instrument cluster. When you re-start the battery 
messages it goes back to normal mode and the battery info reappears. 
Start-up is quite critical, if you don't let the battery send it's start 
up messages the car doesn't go into ready mode. The car never shut down 
or went into a permanent turtle mode while I was messing with data on 
the bus -- it always went back to normal mode if I restored the 
unmodified messages flow from the BMS. I modified the data in nearly 
every field to see what would happen.


The car will go into ready and turn the wheels even when it cannot send 
messages to the battery. This means the startup sequence doesn't involve 
a car to battery handshake, even if the car is expecting some startup 
messages from the battery within a time window. The "check engine" light 
comes on and it does record some DTCs:
* P3180 (EVC-249) VCM detects an error signal that is received from LBC 
via CAN communication for 0.02 seconds or more.
* P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the 
following state remains for 2.8 seconds or more: LBC's calculation 
result to the VCM-set example question is incorrect.


My MitM only works in one direction (from the battery to the car) and it 
turns out my CAN bus setup wouldn't let two programs play together, so 
when I started a CAN repeater (candump -b) to copy data from the car to 
the battery I got corrupted frames and no buffer space errors. I'm going 
to make the MitM work in both directions to resolve this.


If you play a different car's battery messages into this car, it does 
not go into ready. I didn't spend much time on this and I didn't write 
code to start the BMS messages at the right time, I just started playing 
the recording of a running BMS and switched the car on. One experiment 
that I should have tried was to start the car with it's real battery and 
then switch to messages recorded from a different car. There are some 
new DTCs when you try to start a the car while playing messages recorded 
from another car including


* P3102 Li-ion Battery ID Registration must be performed if the Li-ion 
battery controller or VCM is replaced.


The next experiment is to swap in a BMS module from another car.

I figured out some more of the BMS protocol by messing with the data and 
seeing how the car reacted.


The Fuel Gauge display on the instrument cluster is powered by the GIDs 
signal (the first 10 bits of 0x5BC), not the state of charge signal 
(first 10 bits of 0x55B). I guess it knows how many GIDS is "full" 
because the battery will have fewer gids and still read full as it ages.


0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects 
the Fuel Gauge, lower numbers mean more bars, all other things being the 
same. Maybe this is used to calculate how many GIDs each bar is worth? I 
haven't explored this.


The battery capacity gauge (the bars outside the fuel gauge) is 
controlled by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of 
the 5th byte) is 0x3, 0x5BC bits 16-19 (ie the low nibble of the 3rd 
byte) contains the capacity bars. I haven't yet used the mux field 
support in the kcd format to express this -- can4python doesn't support 
it so I had to hand code it. The cluster does not remember the capacity 
-- changing this value directly manipulates the number of bars 
displayed, the