MiEV-CAN

[garygid]

Look at the 4th post on the 3rd Page of this thread (see below)
for a list of the AT commands that tell the OBDLink to assume a
CAN bus and just listen to (and output to the PC) all the
Messages.

Bonjour,
on my side, yes, I can log all the messages.
to avoid bufferoverflow, you should change the default interface'speed from 115kbps to 500000bps (once only)
a) connect to your interface with a terminal @115kpbs
b) send the command "stsbr 500000"
c) reconnect @500000bps

see this thread

d)now, to monitor all the messages, send following sequence:
"ATSP6" ' CAN 11 bits @ 500k
"ATE0" ' Echo OFF
"ATH1" ' Header ON
"ATL0" ' no crlf
"ATS0" ' suppress spaces
"ATMA" ' Monitor All

if you get CanErrors, add the command ATCAF0

I sent to Gary a MP with a link to a big log and to an excel spreadsheet used for detailing this log.

I hope the iMiev is exactly the same as Peugeot iOn regarding CAN messages...

NOTE: Is that speed-setting command STSBR or ST$BR?

Please report what you tried, how, and with what software.

The OBDwiz software might try to do too much, automatically,
when it starts up. You might need to use a simple dumb terminal
program to send just the AT commands that we want to use.

We want to NOT let the OBDLink do its normal job of
writing to the CAN bus and trying to get the car's error codes.

Passive listening... Good, writing to the bus... Bad, at least until
we know a lot more about what is safe to write, and how
to use the responses.

 

[MLucas]

While waiting for my hardware to come in, I've been analyzing PriusFan's excel workbook (log_analyser_passive_ion_56.xlsx) and found some interesting data. Does anyone have a recommendation for sharing documents for this project? I don't feel like making a dozen screen captures, loading them to facebook, and getting the http links for everything. For now I'll describe what I found and once we agree, I can upload my copy of PriusFan's Ion log.

I started with PID 208 and made a chart for each byte. I found P4 and P6 have the same line profile as speed from PID 412 - P1 although the scale is from 192 to 199 instead of 0 to 100. I also found the same speed profile in PID 200 for P2 and P4 with the same 192 - 199 scale. I didn't see any other 192 to 199 range values in any of the other PIDS on the base worksheet.

While comparing PID 200 to PID 208, I found another profile that was interesting. P5 and P7 have very similiar profiles, not exact but very close in most points except for a few. I found the exact profile in PID 200 for P3 and P5 as P7 in PID 208.

I moved on to PID 215 and created line charts for each of the bytes with ranges. I found p0 has a speed profile with a scale of 0 to 48 which is almost half of the speed range on PID 412 - P1. P2 and P4 on PID 215 provide a very interestinig profile, a very linear escalation from 0 at 9:50:24 to 252 at 9:54:04, where it drops all the way back down to zero. From there it rises back to 17 for the rest of the log.

I'll keep at this and let you know what else I find.

 

[garygid]

There is real-time data that one tries to capture, usually
adding a time stamp to the data. This needs to be done
locally, at the time the logging is done.

Since many OBD interfaces do not append time stamps
to the data, usually an external program must do that.

RealTerm and CAN-Do can add time-stamps, but RealTerm
only time-stamps to one second, while CAN-Do stamps
to about one milli-second (ms).

Capturing the real-time data without the time stamps
is not so helpful, since integration over time is cannot
be done with any accuracy.

For example, one might have Speed, and want to integrate
that to get Distance traveled. Or, integrate Power consumption
to get the amount of energy (fuel) used.

Then, there is a log file, that can be shared, which includes
the time-stamp information.

 

[priusfan]

.....
Passive listening... Good, writing to the bus... Bad, at least until
we know a lot more about what is safe to write, and how
to use the responses.

Hello
I know for sure how to ask a "polite question" to the BMU (Battery Management Unit). I mean no christmas tree, in fact this is the exact question from the "garagetool".
I know the structure for the answer (46 bytes) , but I have no idea, yet, of what is the use of each of these bytes.

about stsbr, in my message , there was a link on the word thread, from there, you get lots of details on bufferoverflow...

about opening a space for sharing documents, googledocs is maybe not the best solution, because my original xls is huge (>40 MB).
but I could open a private space on my personal FTP, with access only (with userid & pwd) to interested people

 

[iDriver]

I'd recommend "Drop Box" for the file sharing. You can have the file available to Anyone, or actually require some authentication. It's up to you.

Much easier, and file size limit is (300meg per file) should be fine.

 

[MLucas]

Take a look at PID 374 - P0 & P1. Its the first profile that I have seen of something starting at a high value and going to a lower value, possibly SOC?

 

[priusfan]

I wil check 374 tomorrow....

pid200 contains 2 pairs p2_p3 & p4_p5 proportional to the speed with a better resolution & frequency.
offset is 192*256

 

[priusfan]

Take a look at PID 374 - P0 & P1. Its the first profile that I have seen of something starting at a high value and going to a lower value, possibly SOC?

you are right...
SoC formula is (P1 - 10) / 2
checked on 3 points (and compared using the "garagetool").

 

[garygid]

What is the "garagetool", please?

I have started adding OBDLink control and input format to CAN-Do.

 

[garygid]

Why would a Real SOC have a low end of minus 5?

 

[priusfan]

@gary: the following reports were obtained with what I call "the garage tool"
(Interface & Software used by Peugeot)

1) SoC =99.5% (read 209 on pid 374)

2) SoC=14% (read 38 on pid 374)
; there was only one blinking bar and the SoC will not be allowed to drop much below

we have another intermediate mesure point : SoC=36% read 82 on pid 374

 

[garygid]

Battery cell voltage, average = 4.0875 (Pack voltage / 88),
Min = 4.085, max = 4.090 at 99.5 "SOC".

OK, a "state of charge" can be defined in many ways,
and matching the "garagetool" output is just one of
them. Watching the raw value to see what it does
as the Pack is charged and discharged, that will
begin to tell us what property is being represented.

There is manufacturer laboratory SOC, published values,
usable values, and various actually-used in real applications
values. Then, there are various guesses about what
each value actually represents.

Using the derived value is only good after we agree
on the formula. But, we can all compare the raw values.

However, having this "Rosetta Stone" to help find the
values of interest in the data is VERY HELPFUL.

Finding the a value that goes up as the Pack is charged,
and down as it is used is very helpful, but there might
be another similar variable that was used by the
"garagetool" to report this "soc" percentage.

 

[garygid]

Looks like the Pack has 44 modules of 2 "cells" (or parallel cell-pairs) each,
with a temperature measurement from each module.

 

[garygid]

Some of these values may appear on the CAN bus as we just listen
and Log, but some might require an active Request written to the bus,
with the values appearing in the collection of data that is received in response.

I will work on CAN-Do more this morning.

When I get my OBDLink SX working and logging from at least
one vehicle, who wants to try it out and make suggestions
for improvements before I post this version online?

Probably should be somebody who has an OBDLink (virtual Comm Port)
and has CAN-Do working on their computer.

PM me with your email address and/or phone number.

 

[garygid]

You can get CAN-Do and real LEAF log files, with a Recipe file,
online at www.wwwsite.com/puzzles/cando/

It appears that OBDwiz does not actually Log all messages.
Is that correct, or do I need to learn more about using it?

RealTerm will gather logs, but the time stamps are a bit
coarse, only to the second. But, that is not bad, and
usable for most of our work.

 

[jjlink]

Ok, I captured a log file using RealTerm, let me know if it looks like anything.
https://dl.dropbox.com/u/27729958/i-Miev_capture1.zip

 

[priusfan]

excellent
could you make another capture with realterm but ticking the time stamp YMDHS???

so we can check the periodicity of each PID , and also I will be able to use my excel analyser...

 

[jjlink]

excellent
could you make another capture with realterm but ticking the time stamp YMDHS???

so we can check the periodicity of each PID , and also I will be able to use my excel analyser...

Yes, I can do it right now, I just wasn't sure if it was working or not. I post it in a few minutes.

Ok, Its ready on the same url:
https://dl.dropbox.com/u/27729958/i-Miev_capture1.zip

 

[priusfan]

ok, here is the result for this first capture
it is the zip of an excel file.
there is some garbage in the first second I forgot to remove...

next capture: driving one or 2 minutes,
and what is the status of the SoC on the board?
also what is the external temperature?

 

[jjlink]

ok, here is the result for this first capture
it is the zip of an excel file.
there is some garbage in the first second I forgot to remove...

next capture: driving one or 2 minutes,
and what is the status of the SoC on the board?
also what is the external temperature?

Capture2: https://dl.dropbox.com/u/27729958/i-Miev_capture2.zip
SoC ~50%
External Temp: 61 F