CAN-Do: a CAN-message Analysis Tool

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
We could have more than two charge timers. As many as we want. Just send the next start time to the VCM every time the system wakes up for a charging session. I assume this is what the HV-BAT (Li-ion battery controller) is doing so we would have to make sure our command comes after the one from the HVBAT to the VCM. Anyway, not sure how much *need* there is for this utility, but we are talking about hacking here (not cracking - there's a difference) and hackers generally don't need any other reason than "because I can." :) Just exploring project ideas...
 
garygid said:
1. Yes, the AVR-CAN board can be used to send CAN messages.

2. There is a safety "interlock" in the AVR-CAN board wiring that would need to be "jumpered" to allow (proper) firmware to send messages.

3. Are we sure the EV-CAN buss is still OFF after the charging "nozzle" has been plugged in?
(I have not yet checked.)

4. The EV-CAN buss is certainly active during charging.

5. A "Stop Charging" message (if we knew it) could give us a User-Settable Charge-To-SOC Stop-Point, instead of just the 80% and 100% that we have now.

7. However, always "aborting" charging this way MIGHT not allow battery equalization to occur properly

I just confirmed that, indeed, the Canbus becomes active as soon as you connect the charger and stays active even though charging doesn't start (due to timer setting).
 
TickTock said:
garygid said:
1. Yes, the AVR-CAN board can be used to send CAN messages.

2. There is a safety "interlock" in the AVR-CAN board wiring that would need to be "jumpered" to allow (proper) firmware to send messages.

3. Are we sure the EV-CAN buss is still OFF after the charging "nozzle" has been plugged in?
(I have not yet checked.)

4. The EV-CAN buss is certainly active during charging.

5. A "Stop Charging" message (if we knew it) could give us a User-Settable Charge-To-SOC Stop-Point, instead of just the 80% and 100% that we have now.

7. However, always "aborting" charging this way MIGHT not allow battery equalization to occur properly

I just confirmed that, indeed, the Canbus becomes active as soon as you connect the charger and stays active even though charging doesn't start (due to timer setting).

Cool. I stand corrected. I forgot that mine is powered off USB instead of the OBD-II connector. I guess it's just the USB port that's turned off while waiting for the timer.
 
Another observation: Even when unplugged, pressing the timer off button results in the Canbus getting activated. I suspect there are devices on the bus listening when you are unplugged - just noone talking.
 
CAN bus operational states:
(Note: I might not have the official terminology below.)

1. No-Power: Inactive, with "no" drivers powered on, and even the High and Low voltages are not present.

2. Inactive: The bus is powered, but no messages are being transmitted.

3. Active: Messages are present on the bus. In general one cannot tell who transmitted the message. Any attached bus transiever could be listening, but messages might be ignored.

At this point, the SOC-Meter only listens, it does not transmit.
 
Hi Gary,
I work for a company that uses CAN to communicate with devices in a climate control system for big rig trucks.

I don't know that much yet about CAN but I know in one of our diagnostic tools, there are nodes that send their address embedded in the message. For example node 128 would send a message to node 9, then node 9 would reply with either a NAK, ACK or data. Does this sound right?

There is also available a small (about 4") color graphics display with a touch screen. It has an RS-232 or I2C interface. It can be programmed for different static backgrounds and then you display data. I have a couple and would be happy to send you one to play with if you like.

Michael
 
Just downloaded it, and under Win7 x64, it's complaining "Component 'MSCOMM32.OCX' or one of its dependencies not correctly registered: a file is missing or invalid"

I tried downloading and installing the VB6 runtime from here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24417" onclick="window.open(this.href);return false;
But that didn't help.

For the above problem (but on 32 bit machines) you need only run the 'regsvr32.exe' against MSCOMM32.OCX as an administrator in the C:\Windows\system32 directory using Command Prompt. For a 64 bit machine.... you would need to determine what the 'regsvr32.exe' equivilent program is (? possible the same) and run it from the appropriate directory.


For eg, for Windows 7 32-bit machine with above error (my problem this morning) - I just did:

1) found 'Command Prompt' using Start menu... Right clicked the icon and said 'run as Administrator'
2) navigated to C:\Windows\system32
3) entered: regsvr32.exe MSCOMM32.OCX <enter>

solved! now when you double click Gary's program - the error is gone and it works.
 
garygid said:
CAN-Do v148 has been posted at
http://www.wwwsite.com/puzzles/cando/" onclick="window.open(this.href);return false;

This versions displays Battery Pack Output (Volts and Amps) on
the CAN-Do Dashboard. It also has a way to speed up the
Dashboard display by processing only 1 of every N messages.

However, you can see (what appears to be) the DC L2 charging amps
almost "steady" at about 8 amps in (for example -8.2), and
the voltage climbing from about 350 to near 400 volts
as the "6-hour" charging Log is read in.

....

Hi Gary,

I implemented a CAN data logger for a iMiEV recently. That was easy - because the manufacturer supplied us with a 'CAN gateway' - a piece of hardware that filtered the data coming out of the Drivetrain bus - and prevented us from writing into the bus. The 'it was easy' was thanks to them supplying us with a CAN Signal Configuration matrix - which told us which CAN ID's contained which messages, and which signals, as well as their data type (motorolla) and the bit locations - lengths, scalings, normalizations etc.! The same kinds of information that your followers will soon be loosing sleep over - trying to discover on their own!

Thus I became familiar with CAN-bus in this context.

I have today downloaded your software, very cool, and am trying to experiment with different byte masks etc. as you all are too.

I just have a couple questions:

1) has anyone done any controlled experiments while logging data from the ODB port, with the hope of 'calibrating' or 'decyphering' the data? for Example, if you think you know which message represents the L2 Amps during a charge - you could simply use a self powered clamp on current transformer attached to a voltmeter while charging, say for 2 minuites after it has stabalized, then you could revisit the data knowing first hand the direct measurement of the Amperage over that conductor. Then you would play with the scaling etc. until the numbers match.

2) has anyone done something like the above - regarding the suspected SOC contained in 5BC? the iMiEV for example, contains their SOC as an 8-bit (not ten) word in their 2nd byte, which you normalize to run from 0 to 250, meaning physical range of -5% (at bit value zero) to +120% (at full 8 bit). So the owner of a LEAF could for example, ignore their warnings and run the batteries to near zero - then begin a 110 VAC charge event (or 220 whatever) monitoring what you think is the SOC signal on the 5BC message - and assume the beginning is zero (or perhaps minus 5 for the iMiEV example!) and allow it to plateau at what should mean full (100% or perhaps 120%). Did someone already do that? like... was that '6 hour charge' constructed in this way? from 'a dead car' to 'a full battery'?


Thanks,
 
Too bad that Nissan is SO much less supportive of such projects and information! They could take an example from Mitsubishi!

All we get is FUD from the likes of Mark Perry with regards to Ingineer's EVSE upgrade...

clbLEAF said:
I implemented a CAN data logger for a iMiEV recently. That was easy - because the manufacturer supplied us with a 'CAN gateway' - a piece of hardware that filtered the data coming out of the Drivetrain bus - and prevented us from writing into the bus. The 'it was easy' was thanks to them supplying us with a CAN Signal Configuration matrix - which told us which CAN ID's contained which messages, and which signals, as well as their data type (motorolla) and the bit locations - lengths, scalings, normalizations etc.!
 
TomT said:
Too bad that Nissan is SO much less supportive of such projects and information! They could take an example from Mitsubishi!

All we get is FUD from the likes of Mark Perry with regards to Ingineer's EVSE upgrade...

We hope to change that when we meet with the LEAF Chief Vehicle Engineer in December. We've also gotten in contact with their Marketing/Advertising firm.
 
The 6-hour charging log that I have On-Line (old LEAF Bars firmware) started from about 10% or 20%, not Turtle Mode.

As we get more "LEAF-turner" (detectives) playing with the Logging, I am sure that more experiments will be done.

For the more fanatic Detective:
I am delivering my first 3-channel (EV, Car, and AV CAN-bus) Logging System this week. I still need to test it. At least two of us have been using prototype 3-channel logging systems for several months.
 
Actually, additional Hardware is needed.
Now, the LLS uses the same "SOC-Meter" firmware, but that
MIGHT change as the SOC-Meter functions become more complex.

The LEAF-Logging System (LLS) uses three AVR-CAN boards
(one for each CAN bus) instead of just one.

Then, each board needs a GOOD RS232 connection to the PC ...
running CAN-Do, which can record all three channels simultaneously.

The Display and Push-buttons become optional extras.

For more info see the LLS thread(s).
 
Hi Gary,
I got a chance to really use your unit last night. It sure helped when I started getting really low on charge after a trip to Livermore to sign paperwork for my wife's new Mitsubishi MiEV.

It was very comforting to know that I still had 14% SOC left when the range meter was flashing 7 miles at me.

Admittedly, the last miles drop very slowly down that low, but it's still great knowing the exact SOC.

I remember the EV1 had a nasty habit of indicating 10 miles of range and then suddenly plunging to three dashes the next minute.

Thanks for all your hard work in developing this device.

Michael
 
Suggestion for future release:
When a subset of the message range is selected for plotting in the "Message Range to Plot" fields, have the histograms of each Byte only reflect the data within that window.

I was looking for a Motor Volts signal. Since, given the battery volts, battery amps, and motor amps, we can figure out what the motor volts must be it would be easier to find if I could zoom into a section and dismiss most Byte fields by inspection without actually plotting them.
 
Back
Top