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 <ev@lists.evdl.org> 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 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 value on the can bus is > literally the number of bars (0x0 -> no bars, 0xC -> 12 bars). > > Ed Blackmond earlier reported that his car shows the original capacity not > the new capacity after he replaced the cells while keeping the original BMS > module. What data do you see on this field? > > The indicated temperature on the instrument cluster is controlled by another > muxed field, when 0x5C0 is 0x40, the indicated temperature is controlled by > the 3rd byte of 0x5C0. This mux has 3 values, on this car all 3 are similar > in the 3rd byte, but only the when the mux is 0x40 does the 3rd byte control > the temperature in the instrument cluster. > > Many thanks to Carl at https://bluecars.nz/ for letting me torture his car. > > _______________________________________________ > 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) > -- Sean Korb spk...@spkorb.org http://www.spkorb.org '65 Suprang,'68 Cougar,'78 R100/7,'60 Metro,'59 A35,'71 Pantera #1382 "The more you drive, the less intelligent you get" --Miller "Computers are useless. They can only give you answers." -P. Picasso _______________________________________________ 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)
