LEAF CANbus decoding. (Open discussion)

[turbo2ltr]

I think people underestimate what it takes to keep track of SOC/capacity for a pack. It's a pretty complex algorithms to calculate SOC while you are dumping current in and out of the battery. This can cause the value to drift to the actual SOC. Once the battery is at rest, they can reset that value because it's more accurate to calculate when you know the battery has been sitting for a while and settled back down.

What Gary said is true, but this could be another piece of the puzzle.

 

[davewill]

Problem: I parked, and now an e-fuel Bar, there before, is now gone:

A given bar will appear and disappear at a different SOC
if the battery pack is charging or discharging.

Think of it this way:

1. When discharging, the bar goes OFF when it is "empty".
If ON, a bar stays ON, no matter if that bar is 25% or 75% full.

2. When charging, an OFF bar does not go ON until it is about half full.

3. When (re) starting the car, the bars "fill" (like during charging), and
a 75% full bar will appear, but a 25% full bar will not.

At least that's my theory.

It's called hysteresis, and is necessary to keep digital readouts from toggling back and forth between two states due to inaccuracies in reading the battery state when the actual reading is very close to the boundary. The trouble is that the overlap is so humongous here. They've based it on the granularity of the bars when it should be based on the accuracy of the SOC readings themselves.

Interestingly, I haven't noticed much, if any, issue with the raw SOC data we've been graphing. It seems to rise without backtracking when charging, and I've only noticed one instance going back up during the drive sequence, which was hopefully regen. Was the data filtered or have the graphs been showing all the data points? We may not even need hysteresis on the new SOC readout if this holds.

EDIT: Nissan may have done this on purpose to keep regen from increasing the number of bars in most situations. We would, of course, rather see the regen, but most ICE drivers expect their fuel gauge to only go down during driving.

 

[garygid]

Most definitely, the car might adjust its professed SOC while the car is "resting".

When we can "see" the internal SOC value, before parking and after, we will be able to determine if the SOC remains constant, changes a bit, or re-adjusts a lot.

 

[evnow]

3. When (re) starting the car, the bars "fill" (like during charging), and
a 75% full bar will appear, but a 25% full bar will not.

At least that's my theory.

Possible - and that would be a bug.

 

[garygid]

Poster CAN-Do v1.2.4 last night,
which shows a few more values on its "dashboard".

www.wwwsite.com/puzzles/cando/

 

[Coffee_Slurry]

Interestingly, I haven't noticed much, if any, issue with the raw SOC data we've been graphing. It seems to rise without backtracking when charging, and I've only noticed one instance going back up during the drive sequence, which was hopefully regen. Was the data filtered or have the graphs been showing all the data points? We may not even need hysteresis on the new SOC readout if this holds.

I agree, davewill. The 10-bit 'SOC' value is very smooth and has little or no bounce, during charge or driving. I have been able to kick it up a value or two by downhill regen, but I've never seen it bump up at rest.

Further, it's really linear. A constant-power charge results in almost a straight-line graph. (The next time I have a deep discharge to study, I want to correlate the EVSE power draw and accumulated energey with the SOC value, each minute, and see if even the dips and inflections are represented in the power draw.)

All this indicates that it is a computed or derived value based on some kind of coulomb-counting, rather than a direct instantaneous computation from current/voltage. Really, it seems a perfect fit for a 0-100% SOC gauge, with 0.4% resolution.

 

[TomT]

I installed it on my Windows 7 laptop and it runs fine. All the hardware appears to work correctly as well so Ill be doing some laptop driving tomorrow! Next stop, a standalone display...

Poster CAN-Do v1.2.4 last night,
which shows a few more values on its "dashboard".

http://www.wwwsite.com/puzzles/cando/

 

[Coffee_Slurry]

Adding a small display to the Atmel development board and displaying the SOC should be relatively easy.
...
Who wants to select a suitable easy-to-read display?

The 'raw' 4-bit Optrex style displays are ubiquitous, cheap, and come in all colors and sizes. I have some VFD ones that are bright enough for in-car use.

But for simplicity in wiring and programming, the SerLCD ones are hard to beat.
That's why they're often out of stock.

I picked up the 4x20 line SerLCD display from Sparkfun. It seems like it will do fine, and it's already well-supported by Arduino. The sparkfun CAN-BUS Shield already has a 3-pin port for it.

 

[Coffee_Slurry]

Poster CAN-Do v1.2.4 last night,
which shows a few more values on its "dashboard".

What hardware does this want to interface to as a CAN adapter? Are most people just replaying the stored logs, or did they build an AVR with the same data format as yours?

 

[rainnw]

Lithium ion battery capacity also depends on the current draw. They will appear to have higher capacities if current draw is low, and lower capacities if current draw is high.

It is true that at rest, the pack will actually change voltage level slightly. I usually see them go up. But this is raw data.

While you can track power going in and out of the pack all you want, and adapting it to whatever formula, the only metric you receive from a Lithium ion battery is voltage. The voltage range is a nice slope in relationship to its remaining capacity, although it has very quick drops from 100% full to this slope, and then near the end, it drops off very quickly. However, when you are putting a load on the battery (or charging it), this value will be skewed compared to just looking at the open circuit voltage.

And then all we are talking about is one cell! Just imagine the complexity when you try to manage a whole load of them at once. Lithium Ion battery packs are extremely difficult to manage.

 

[garygid]

mogur,
What hardware are you using to "capture" the CAN-buss data?

What format is the "recovered" CAN-message data?

My next step is to read real-time data, and display it on my evolving "dashboard" as I Log the data for later examination.

Our Atmel uP is programmed to produce a Check-Byte, then 2 message ID bytes, then 8 data bytes, for each message [CC DD ND D1 D2 D3 D4 D5 D6 D7 D8]. The Check-Byte (CC) lets us sync to extract the messages from the byte stream. However, we can program the Atmel uP to produce another more-common format, if desired.

The logical interface into the CAN-Do program is a (virtual) Comm Port. Initially I will support one Comm port for the EV-CAN buss, then add the Car-CAN and AV-CAN busses.

I will also add support for writing and reading several CAN-Log file formats, if others desire.

I just ordered some hardware:
1. AVR-CAN, a Development Board for an Atmel AT90CAN128 microprocessor, about $52 each. These will be powered by the 12v from the car's CAN bus.

2. An ODB2 type pass-through connector with all 16 pins wired to a cable that exits the side, about $21 each. With this one cable and three 9-pin "D" connectors, I can attach to three of the Atmel boards to extract the EV, Car, and AV messages simultaneously.

3. A 4-port RS232 to one USB, handling High Speed (1 Mb/sec) data, for about $65. I hope to be able to plug 3 or 4 of the AVR-CAN boards directly into this thin "box". Power for this box comes from the USB port. This way, it costs more than a simple 115k-bit RS232-to-USB "adapter" (less than $5 each), but I can get by with only ONE USB port, like on a little "netbook" (small laptop).

I will post exact ordering links if anybody is interested.

 

[TomT]

I'm lucky enough to have access to a Intrepid Systems Valuecan USB Adapter from another project and which still seems to work. If I had to buy one from scratch today, I'm not sure what I'd get...
But since I suspect it is a matter of when, not if this, gives up the ghost, I'd like to have another option so please do post the info.

mogur,
What hardware are you using to "capture" the CAN-buss data?

I just ordered some hardware:
I will post exact ordering links if anybody is interested.

 

[Coffee_Slurry]

Is the AVR-CAN an Atmel product?

I have the Atmel ATDVK90CAN1 kit from way back (2006?) but it was $130 at the time and needed the Atmel STK to plug into.

The Sparkfun CAN-BUS Shield has some unique advantages:

• GPS header
• SerLCD header
• microSD slot
• 4-dir joystick input

Paired with an Arduino, really, it's right on target for a dash-mounted self-contained system. It should total out to ~$100 in parts with a 2x20 display.

If you are considering other data/storage formats, I would recommend the Lawicel data format. It has been cloned by other vendors, and Lawicel has both RS232 and USB adapters that use it. Seems the closest thing to a text standard.

(The downside is that it is ASCII text, so it's twice as much data to transfer. Sure is easy to parse/inspect, though.)

The Arduino UNO boards have gotten away from using the FTDI and similar chips to convert from async to USB. It's a much cleaner fix.

I'm finding that my high-sped FTDI adapters don't work well on slower/older machines at 230kbps. Bytes get dropped pretty often, and I suspect the machines just aren't keeping up with all the incoming USB traffic. Having on-board microSD should relieve a lot of that pressure, since a 2GB card could store weeks of driving & charging data.

 

[Coffee_Slurry]

I'm lucky enough to have access to a Intrepid Systems Valuecan USB Adapter from another project and which still seems to work.

Lucky dog! Are you using VehicleSpy?

I'm so bummed my ValueCAN has died.. The serial port shows up, but none of their software or mine works with it. And I suspect it's doing bad things to the CAN bus as it causes spurious errors.

 

[TomT]

Yeah, somewhere there was an older registered version of it but I can't find it so I'm running their trial version for the moment. I guess I should contact them and see if they can find it in their records and if I'm entitled to a free current version...

I'm lucky enough to have access to a Intrepid Systems Valuecan USB Adapter from another project and which still seems to work.

Lucky dog! Are you using VehicleSpy?

I'm so bummed my ValueCAN has died.. The serial port shows up, but none of their software or mine works with it. And I suspect it's doing bad things to the CAN bus as it causes spurious errors.

 

[garygid]

In making our CAN-Log file, we remove the Check-Sync byte (from our 11-byte "extracted-data" high-speed (115kb works) RS232 byte stream from the Atmel) and prefix two time-stamp bytes [SS MM] to each message to make 12-byte fixed-length records for the Log file.

The SS is the MSB of the 16-bit value [ssss ssmm mmmm mmmm]. The s's are the seconds (0 to 59), and the m's are the milli-second (0 to 999).

Actually, time stamps are not crutical at this stage of analysis (only one CAN buss). Right now, I do not use them, so they could be zero.

 

[lemketron]

Adding a small display to the Atmel development board and displaying the SOC should be relatively easy.
...
Who wants to select a suitable easy-to-read display?

The 'raw' 4-bit Optrex style displays are ubiquitous, cheap, and come in all colors and sizes. I have some VFD ones that are bright enough for in-car use.

But for simplicity in wiring and programming, the SerLCD ones are hard to beat.
That's why they're often out of stock.

I picked up the 4x20 line SerLCD display from Sparkfun. It seems like it will do fine, and it's already well-supported by Arduino. The sparkfun CAN-BUS Shield already has a 3-pin port for it.

It looks like it might be cheaper to go with an AVR-CAN board (AT90CAN128) and just add the display directly to that for displaying SOC... I'm interested in getting some Arduino gear to learn about with my kids, but the the AVR-CAN is about the same price as a sparkfun CAN-BUS shield by itself (without the Arduino). I guess the key would be whether AVR-CAN could directly drive the SOC display...

For development, it looks like the Arduino IDE can also be used with AVR-CAN as discussed on the Arduino forum.

Or is it just easier (and perhaps worth the extra $20) to use an Arduino with the CAN-BUS shield since it includes the display connector making everything "plug-n-play" ?

What about enclosures? I see the Arduino Project Enclosure on the LEAF CAN-bus wish list, but that looks like it will only hold the board and shield, not the display. Any ideas for an enclosure that would also hold the display?

 

[garygid]

My goal is to have hardware that will display in real time, as well as do logging for later analysis.

The AVR-CAN appears to be an Atmel product, under "Automotive". I believe this AT90CAN128 (16 MHz, 128k-bit flash, 4k RAM, and 4k EEPROM) uP includes CAN-decoding hardware, so it is very easy to program.

Further, all the pins of the uP (many unused) come out to two headers, so "plugging on" a daughter board (a display, etc.) should be very easy.

We anticipate modifying the Atmel code to display the SOC as soon as we identify a suitable display and source. If you have an exact link to something that would work well for this application, that would speed things along.

We have c-type (I think) source code, a compiler, and a loader, so we can provide hex ... and I assume the loader is a program and a cable.

If you are nearby or will pay shipping, we can do the Loading of the Atmel for you.

However, those with other hardware should be easy enough for CAN-Do to support.

If you post exact info about your RS232 serial-byte message format, and I will try.

 

[Coffee_Slurry]

but the the AVR-CAN is about the same price as a sparkfun CAN-BUS shield by itself (without the Arduino).

It appears there are multiple devices going by "AVR-CAN", and it's not clear which one we're talking about.
Olimex is $39 euro.
http://www.olimex.com/dev/avr-can.html

Sparkfun is $53
http://www.sparkfun.com/products/8279

SK Pang $34 Euro (same as olimex?)
http://www.skpang.co.uk/catalog/avrcan-at90can128-development-board-p-292.html

Here's a raw header board for $30:
http://www.sparkfun.com/products/655

Any of these, if it can do what we need, is cheaper than Arduino UNO ($30) + CAN Shield ($45).

There are advantages to the AT90CAN128: Internal CANBus is a big plus, since you don't have to interface to the Microchip parts. Probably lower overhead and cpu-loading as well.
Arduino uses the ATmega328, with 32K flash and 2K SRAM, 1K EEPROM is less potent than the AT90CAN part, if code size becomes an issue. (128k-bit flash, 4k RAM, and 4k EEPROM)

The advantages to the Arduino+Shield combo are the microSD slot, GPS header, joystick, and existing software (both Arduino itself, and the CANbus example code)

I put a lot of value in the microSD slot, since that's a ready-to-go logging solution right there. No laptop required. Between a 4x20 serial LCD display that just plugs in with three wires:
http://www.sparkfun.com/products/9568
, an enclosed microSD, and NMEA GPS input, I'm thinking it's a good place to start.

If someone wants to productize something, the AT90CAN128 is an obvious choice for a custom board. That would rock.. add a 4-bit LCD interface (cheaper than serial), microSD, some input buttons, GPS header. If you wanted more than one CAN interface, then you're back to the Microchip solutions. It does have 2 UARTs.

 

[lemketron]

Between a 4x20 serial LCD display that just plugs in with three wires: (http://www.sparkfun.com/products/9568), an enclosed microSD, and NMEA GPS input, I'm thinking it's a good place to start.

The main issue I have with that is that it seems like a pretty lousy LCD to use for something in the car.
This white/blue 16x2 LCD looks interesting and comes in shield form with buttons too, but I don't know if it's available domestically.

If someone wants to productize something, the AT90CAN128 is an obvious choice for a custom board. That would rock.. add a 4-bit LCD interface (cheaper than serial), microSD, some input buttons, GPS header. If you wanted more than one CAN interface, then you're back to the Microchip solutions. It does have 2 UARTs.

Yeah, I'm guessing the AT90CAN128 would be a better choice for a productized version. But for ease of assembly for individually built units, the arduino+shield may be a better choice. Unless you want bare boards and wires in your car, though, the choice of display may come down to selecting a display+enclosure that works well. I guess I was hoping there might be an arduino+shield+lcd combo already available with a compatible enclosure...