Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle
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
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
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 the low nibble of the
Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle
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
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
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
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 th
[EVDL] Nissan Leaf CAN Bus Man in the Middle
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 v