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
Re: [EVDL] 800mi Bolt trip ... (San Jose<>LA on ccs)
As I previously stated, (and especially the last sentences of the news item),
it leaves the reader to think anything to do with EVs is lacking.
Both Cor and David rightly said something like: EV driver should embrace the
EV way of driving (clam, less insanity to race to the next red light,
sticking with a steady speed at the speed limit, etc.).
As many know, I read many many news items multiple times at day to find the
ones that I post. Of those mentioning the Bolt EV, are quite positive. As I
stated before, what they complain about is expecting a $38k vehicle have a
less spartan/plasticky feel to it (it is a $15k ice turned EV, it is going
to be like a cheap $15k ice). See,
http://electric-vehicle-discussion-list.413529.n4.nabble.com/Bolt-EV-experience-tp4685003.html
But the next wave of EV drivers that buy the Bolt have already drank GM
dealership's sales-rep koolaid who are going to mis-state that the Bolt is
like an ice. Then, with new Bolt drivers having been told that, we are going
to see more of these types of news items where people haven't embraced the
EV way of enjoying life.
IMO, even if an EV had a 1000 mile range, there needs to be a change in the
former ice-driver's driving style (less wasteful, clamer, ... more
enjoyable).
In an item I will post later from automobilemag.com mentions the Bolt is
like a ice ...
2017 AUTOMOBILE All-Stars: The Winners ...
Our consensus was represented in phrases such as, “drives like a real car,”
or, “I wouldn’t hesitate to recommend a Bolt as a daily driver to many
people I know.” A clear statement of why was summed up with, “The Bolt can
be used like a normal gasoline-powered vehicle.” ...
So, between GM dealership reps seeking a quick sale (saying falsehoods for
fun& profit), media outlet items like
http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-800mi-Bolt-trip-w-EV-ignorant-Mom-amp-teen-angst-gt-20kW-ccs-EVSE-frustrated-td4686115.html
saying similar generalizations, and comments from other Bolt EV owners in
public (word of mouth) using the wrong wording when bragging about their new
EV ...
the plugin community is going have lots of EV drivers that still have
ice-driving habits ...
::sad::
For EVLN EV-newswire posts use:
http://evdl.org/evln/
{brucedp.neocities.org}
--
View this message in context:
http://electric-vehicle-discussion-list.413529.n4.nabble.com/Re-800mi-Bolt-trip-San-Jose-LA-on-ccs-tp4686125p4686150.html
Sent from the Electric Vehicle Discussion List mailing list archive at
Nabble.com.
___
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)
[EVDL] EVLN: EV-newswire posts for 20170312
http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-18k-Gratis-X1-Electric-jet-ski-promises-eco-friendly-watersports-td4686148.html
EVLN: $18k Gratis X1 Electric jet ski promises eco-friendly watersports
... if you're looking for a electric personal watercraft choices ... you're
... so fortunate … you now have it ... opens doors to riding on waterways
that don't allow gas-powered machines ...
http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-LagosU-students-Dove-P1-EV-gt-Africa-s-first-electric-car-v-td4686147.html
EVLN: LagosU students' Dove P1 EV> Africa’s first electric car (v)
2015 Dove P1 University of Lagos students build Africa's first electric ...
However, some students of the University of Lagos(UNILAG) are thinking ahead
of most and trying to change that trend by building what could be the car of
the ...
http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-Yooz-e-LSVs-gt-Iran-Made-Twizy-clone-amp-Renault-doesn-t-care-r-200km-ts-80kph-td4686146.html
EVLN: 'Yooz' e-LSVs> (Iran-Made Twizy clone& Renault doesn't care) r:200km
ts:80kph
Mar 5, 2017 - Electric cars developed at a knowledge-based firm affiliated
to the Islamic... ... 60729. The development of electric cars got a boost
after the ... The electric vehicle is named 'Quadro' and has been developed
by university-based firm Parax Co. However, the commercial name for the
vehicle is 'Yooz' ...
+
http://electric-vehicle-discussion-list.413529.n4.nabble.com/China-forcing-67-000-Taxi-ice-to-switch-to-Electric-in-order-to-cut-back-on-pollution-td4686145.html
China forcing 67,000 Taxi ice to switch to Electric in order to cut back on
pollution
... mandate will force thousands of taxi drivers to switch to Electric …
Effective immediately, Beijing will begin a phase-out process … Plan Is a
Logistical Nightmare ...
http://evdl.org/evln/
For all EVLN EV-newswire posts
{brucedp.neocities.org}
--
View this message in context:
http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-EV-newswire-posts-for-20170312-tp4686149.html
Sent from the Electric Vehicle Discussion List mailing list archive at
Nabble.com.
___
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)
[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
