CAN-Do: User Manual

Table of Contents:

1. Main Screen
2. I/O Control Screen
3. Dashboard Screen
4. Filters Screen
5. -- Message IDs
6. -- Recipe Use
7. -- Graphing Functions
8.
...
12. CSV File Writing Screen

Main Screen

One does not use this screen very much any more.

I/O Control
One needs CAN Messages to work with, and they all come in
via the functions on the I/O Control Screen, from:
1. Reading an existing Log file, or
2. recording "live" CAN-data via one or more Comm Ports.

So, click the "I/O Control" button to go there.

I/O Control Screen

This screen handles variations of three different functions:

1. Reading saved CAN Messages from our Binary-format Log files into memory, usually for some form of analysis.

2. Reading "live" CAN Messages into memory (about 20 million can be stored) from an operating, "resting", or charging LEAF, usually via the Logging Port on an SOC-Meter (or equivalent) through a virtual COMM Port on the PC.

3. Writing in-memory CAN Messages out to a Binary Log file for later use. Now, three ASCII-Text file formats are available when "exporting" the CAN-Messages for other uses or programs.

----------
To get started, Read an existing Binary Log file into memory:

1. Browse for a Log file that you have downloaded, usually a ".evc" file (an EV-CAN Log).
2. Double-click the file name in the browser window to get the file name and path into the adjacent file-name field.
3. Click the Read Bin Log button to read the entire file into memory. Reading a 6-hour Log file (6,000,000 CAN Messages) might take only 6 seconds.

Note: If you check the Show Dashboard checkbox before Reading, you will get a FAST view of some of the data that is contained in the Messages (like RPM, Battery Volts, State-of-Charge, etc. When showing the Dashboard, the Reading and showing of the 6-hour log takes about 3 minutes instead of 6 seconds.

After the Read-In is complete, go to the Filters screen.

----------
Logging: Reading CAN-Message data from your SOC-Meter via a (virtual) COMM Port.

1. Select the CAN-bus type, usually EV.
2. Set the Comm Port number (get it from the device manager).
3. To better observe if your logging is "working" (getting data), check the "Show Counts" checkbox.
4. No need to set baud rate (115200) or the "8,n,1,no" parameters, since CAN-Do does that.
5. Start the Comm-Reading, and good, typical EV-CAN data should show (count) about 200 messages per second.
6. Note: On one Vista system, I had to start CAN-Do with a Right-Click and select "Run as Administrator", or the Comm-Port opening/use would fail.
7. Yes, a GOOD (usually FTDI-chip based) RS232-to-USB Adapter is usually required. All the "modern" less-expensive ($5 to $13 or so) adapters that I have bought and tried recently ... appear to create a lot of errors.

Dashboard Screen

This screen attempts to show, in some human-readable manner, much of the data that we THINK/HOPE we have "discovered" in the many CAN Messages.

All the data in each message comes in as "unknown" bits, each message with (up to) 8 bytes of "data".

When we suspect that we have identified meaningful bits, and have some idea of how to interpret them, we try to display the values on this "dashboard", to better understand their possible meanings.

When the "Show Dashboard" checkbox (on the I/O Control screen) is checked, incoming messages (live from the Comm Port(s), or read high-speed from a Log file) are "decoded" and hopefully-meaningful data is displayed.

Filters Screen - Message IDs

Each CAN-Message has a 3-character (3 nibbles, as hex) Identification, or MsgID. The typical EV-Log has about 20 different MsgIDs. We want to see what these MsgIDs are, and how many times each occured in the in-memory message-log data.

1. After reading some CAN Messages into memory, Click the See MsgIDs button at the top of the screen.

2. In a few seconds, all of the different message IDs will be listed at the left, with a count of how many of each type of message are present.

3. Next, to see the data associated with any one type of message, click its MsgID in the list.

The different data values found in the 8 data bytes (of the selected message type) will be displayed, along with the number of occurances of that value (in Hex).

For example, if we observed that one data byte has only values 2, 3, ... ,12, with approximately equal occurance counts, and the log was for a 6-hour charge to 100%, we might suspect that we had found a "Fuel Bars" value.

Clicking the Graph button right beneath the "suspected" Data column, one can learn more.

Filter Screen - Recipe Use

Much of the data is more complex, and difficult to decode.

a. Some values have bits in adjacent data bytes.
b. Some values are only meaningful when a third byte has specific bits ON.

As we "discover" new values, we can specify a "formula" or "recipe" for the value, and save the Recipe for later use. Making variations of the Recipes (and comparing different Recipes) helps us to better understand the data values.

For example, select the Recipe for SOC Percent, and Graph Function. You should see something meaningful, generally going up with charging (or substantial Regen), and going down as the LEAF is driven.

Choosing the Fuel Bars Recipes, choosing a different color, and Graph Function again should show the Fuel Bars (perhaps Old-Bars) plotted over the SOC values.

The combination should appear meaningful.

------------
The Formulas:
a. The selected MsgID is first.
b. Optionally, a "condition" for the formula: Data Byte Number (DN, where 0 = no condition), a hex Mask value (MM), and a hex "equals" value (EE).

When D# is > 0 and the data value DD masked with MM (DD AND MM) does NOT equal EE, that message is NOT graphed.

For example data byte 6 might need its top two bits to be "10" for the rest of the formula to be meaningful. Use 6 C0 80 to only plot the "filtered" messages.

Then DN NN SS select the 1st data byte, where DN is the byte number NN is a mask ANDed with the data byte's value, and SS is generally positivebto indicate shifting the byte value to the left, zero for no shift, and negative to indicate shifts to the right.

The 2nd data byte is described by the next DN, NN, and SS. They operate the same way as the 1st data byte, and the 1st abd 2nd results are added together to make a "raw" value.

To make beter sense of the raw value, it might need to be "scaled" in two ways.

a. If a raw value of 0 to 180 really represents temperatures of -40 to 140 we would specify that 40 raw equals 0 scaled: a zero-offset of 40. Also, of the temperature was not -40 to 140, but really -20 to 70, we would need to divide by 2 (or multiply by 0.5): thus specify a Scale Factor of 0.500

With Zero Offset and Scale Factor selected, we just need to decide what values to graph, maybe 100 max and -50 minimum.

That would be a trial formula.

If it turns out to be worth saving, give the Recipe a suitable name (usually starting with EV:, AV:, CR:, or QC, and ADD it to your Recipe list. Then, BEFORE quitting, SAVE your new Recipe list. CAUTION: The Save OVERWRITES the original Recipe file.

Filter Screen - Graphing Functions

I/O Control - CAN Message Logging

I/O Control - Saving Logs

Event Markers - while Logging

You can define 10 "Event Messages" that can be inserted into the stream of CAN-Messages being logged.

You press a digit key (0-9) during Loging, and the corresponding Event Message is inserted as a pseudo-CAN message into your Log. Each message can be 24 ASCII characters long.

For example, if you are looking for a foot-on-brake-pedal message, you might define "Foot On Brake" and "Foot Off Brake" to help you find the related sections of your Log.

Eventually (not implemented yet), as you graph a variable with "Show Events" checked, small numbered arrows (or vertical lines) would be added to the plot.

Monitoring Message Changes while Logging

Graph Screen Usage

Select Range

Save: Ctrl-Alt Print Screen

CSV File Writing Screen
(In version 1.5.8 of CAN-Do.)

Some people want to extract a subset of the data from the otherwise massive Log data,
having it "exported" into a CSV file that they are familiar with manipulating, graphing, etc.

This function provides a fairly flexible tool for such extractions, writing a "standard" CSV file.

Yes, there are probably a few "bugs" left in it.
Some things have not yet been implemented (Date/Time, Relative Time).
Also missing are some checks, like checking that an EV-Recipe uses only EV Log Messages.

Operation
The left column lists the Recipes currently defined (usually read in from a "Recipe" file).

Clicking on a listed Recipe name adds that Recipe to the list of Fields that will be output to the CSV file that you are creating (or overwriting).

Clicking on a name in the Fields list will highlight it, and that field can then be:

1. moved up or down in the list
2. deleted from the list
3. marked as Value, Trigger, or Occurance (the default is Value).

A Value-Field contains the latest value produced by its Recipe (or zero, if it has not yet occured).

A Trigger field contains the same value as a Value field, but whenever its Recipe is "activated" (by processing a suitable Log message), that causes a CSV record to be written. The fields in the written CSV record contain the "latest" values produced by their corresponding Recipes.

An Occurance field contains a Count of how many times the Recipe has been "activated".
The Field name will have an "-O" appended to the Recipe name. Zero means "none".

So, to write any CSV records, there must be at least ONE Trigger field,
but there may be more than one if you wish.

Browse and Write CSV File should be obvious. The CSV file is written with one Header-record, which contains the names of the Recipes for each column of data.

There are some Pseudo-Recipes that can be added to the Field list
by clicking a button (to the right of the Field list):
1. Log Record Number
2. CSV Record Number
3. Log Message-ID
4. Date/Time from the Log File of the Trigger (not yet implemented)
5. Relative Time (from the beginning of the Log File) of the Trigger (not yet implemented)

I hope this is a helpful tool for some folks. Cheers.

Other 2

Other 3

I will atrempt to take sections and contributions posted below and
incorporate them into the above "Sections".

Once this thread grows to contain some real substance, I will also put
the information into a "CAN-Do User Manual" (.pdf) which I will put on-line at
http://www.wwwsite.com/puzzles/cando/" onclick="window.open(this.href);return false;

Thanks for any contributions, suggestions, corrections,
better explanations, better wording, etc.

OK, Gary here is the start of a rudimentary user manual:

1) Download the latest version of the program, the latest recipe file (varParmList), and at least one log file (.ecv) from Gary's site and put them in the same directory
2) Start the program by double clicking the .exe file
3) Load a log file as follows:
Click on IO Control button
Click the Browse Bin button on right middle of IO Control Dialog box
Browse to select the log file you downloaded and double click on it
Click the Read Bin Log button on the left middle of the IO Control Dialog box
Note: if you check the Run Dashboard checkbox before clicking the Read Bin Log button, the Dash will show the values quickly changing during the logged run! Fun to watch, and interesting. You can click on the 2X Faster and 2X Slower buttons on the Dashboard to change the speed of the run. Don't change the number in the edit box between them manually--it doesn't do anything--only use the Faster and Slower buttons
4) Click on See Filters button (located on both the main program window and the IO Control Dialog box)
5) Click on All Messages button in lower right of Filter Messages and Graph Functions window
6) Click Get Msg IDs button in the same window as step #5
7) Click one of the listed Message IDs in the list box in the upper left side of same window
8) Look at the range of data for each byte.
9) Select a recipe and Graph the Function to get ideas.

I added a first-pass at several sections of the User Manual.

This should be enough to get most people started.

garygid said:

Much of the data is more complex, and difficult to decode.

a. Some values have bits in adjacent data bytes.
b. Some values are only meaningful when a third byte has specific bits ON.

Click to expand...

Gary, any thoughts on why there would be such an (apparently) convoluted system? Are they trying to hide this info so it isn't easy to decode, or is there a good reason why this is structured so?

Not convoluted, we are just looking at it as bytes.

They appear to use an N-bit "structure" (N = 8 x M, M = 0 to 8), which contains various values, flags, codes, etc. that are quite clear if you have the right structure definition, AND the meaning of all the values and codes.

They did not choose to make that info public, it appears.

So, we guess.