MiEV-CAN

[priusfan]

helllo
I tested shortly v187 with an obdlink

my interface has a default speed of 500000, so I used only one part of the script.

it was necessary to add a command in the script to avoid "DATA ERROR" (with frames with less than 8 data bytes)
this command is ATCAF0

it is a bit tricky to use because we are blind; it would be nice to see in another small panel the answers in realtime.

the fields for comport and speed are not wide enough.

I had no time to check if a log was generated

to change permanently the interface's speed, follow this old guide but adapting the initial speed to 115k instead of 38k

 

[garygid]

After sending a command manually, click the Read button, and the
OBDLink response will be shown in the right-side (vertical) list.

CAN-Do v187 does not yet actually Log the OBDLink output,
but you should be able to see some of the data in the right-side
list by starting the OBDLink and quickly clicking the Read button.

Thanks for your help, it saves me much time experimenting.

This added command is to turn off Filters, correct?

Is that just needed for the ELM-based units?

The newer units, based on the STM2111 chip, do they need
the same Filter turn-off?

Is the initial default baud rate for some chips 32k, others 115.2k,
and a permanently changed unit could be almost anything?

If one has an unknown unit with an unknown baud rate,
is there any way to recover and reset it to the factory default?

 

[priusfan]

hello
ATCAF0 removes CAN autoformatting.

filters are another matter.
with STN11xx (compared to ELM327) filtering is a wonderful feature allowing to pass only filtered frames to USB or BT.
this is strategic in case of BT : with iMiev (or hybrids from toy) you have around 1600 frames/sec; you could never pass this flow thru BT.

also it allows the listening app to see only interesting frames and that leaves more time to do usefull things (instead of filtering the content of big buffers...).
with elm327, you can use only one filter; with stn11xx you can use several (at least 4 , this is what I tested)...

it is easy enough to clear dynamically the filters and add new filters.

about bps, old units were running @38k, newer @115k
to find what is the speed for an interface: just try to connect with real term (for instance) with different standard speeds and send the command ATI until you get an answer.

 

[MLucas]

Tried running the 187 with the Ion log file, after uploading the log I tried to 'Read Bin Log' with 'Run Dash' option checked. The screen flickered and then a message appeared saying it was complete. Probably haven't gotten to this part yet. Just wanted to let you know what I found so far.

 

[garygid]

CAN-Do v188 is here:
http://www.wwwsite.com/puzzles/cando/CAN-Do-v188.zip

which includes a Recipe and a OBDLink Script.
This version reads the RealTerm log file's date and time
field, and generates the CAN-Do style time stamps, and
DATE-Time Pseudo Messages.

So, reading the RealTerm files should be working well.

The included OBDLink Script file includes the ATCAF0
command to turn off the CAN Auto-Formatting in the OBDLink.

The sample Logs are here:
http://www.wwwsite.com/puzzles/cando/OBDLinkLogs.zip

which has the iON log Read and a new CAR-CAN Log (.can) written
by CAN-Do, with the Date-Time Pseudo Messages (PID = FFF)
and time stamps added by CAN-Do when reading the
original RealTerm log file into memory.

The memory should be able to hold about 20 millon CAN Messages.

Again, feedback is encouraged.

 

[garygid]

I have not yet added an iMiEV Dashboard to CAN-Do.
Maybe sometime next week.

First, I want to get the OBDLink direct logging implemented.

--------------------
Note: I found that using Comm Port 4 (instead of 3) on my
Vista 32-bit machine works as expected, with no need to
plug in the OBDLink twice.

There is (or was) something strange with the Comm Port 3.

 

[jjlink]

Yes, reading the RealTerm files I previously captured seems be working well.

Here are a couple of capture files to play with (from this morning).

The first one starts with a fully charged battery pack:
https://dl.dropbox.com/u/27729958/i-Miev_capture3.zip

The second one is the trip back home witch dropped off the first bar just before arriving home:
https://dl.dropbox.com/u/27729958/i-Miev_capture4.zip

 

[garygid]

Here is yet another version of CAN-Do, v189:
http://www.wwwsite.com/puzzles/cando/CAN-Do-v189.zip

This is just a minor update of v188, and this zip file
contains just the CAN-Do (v189) program itself.

This v189 processes the dates from the RealTerm Log slightly
differently, so that the Date-Format settigs for your Local
(Europe vs USA) should not confuse the date processing in CAN-Do:
I convert the Log entries to the unambiguous "10 Aug 2012" format
before I process them.

In the sample Log files proviced above, I saw 52 PIDs in the
iON log file, but 58 and 60 in the iMiev files. Sometimes,
errors in the logging data will show up as "bogus" PIDs.

When creating the list of PIDs on the first page of CAN-Do,
it now tells you the total number of PIDs (MsgIDs). One is
the FFF Pseudo-ID used for CAN-Do's once-a-minute
Date-Time Log entry. So, the iON Log sows 53 PIDs.

That list of PIDs also shows the length of the data (usually 0 to
8 bytes), but it shows an asterisk (*) if the PID has more than
one length, which is not impossible, but rarely done.
So, the (*) might possibly indicate some error in the Log data.

In one of the sample iMiev log files, I found two PIDs (6D2
and 6DA) that each had more than one data-length.

Cheers, Gary

 

[garygid]

jjlink,
I looked at the ".can" files, and ...
it appears that you might be getting a lot of garbage data.
There are many PIDs, many with multiple data-lengths.

Or, perhaps this is not really a ".can" file written by CAN-Do?
Looking at the contents of the file with a Hex Editor ...

Oh, it is a RealTerm Log file, which should have a ".txt" or
possibly a ".csv" file extension.

Now ... I see ... I get a Run-Time error "9" from Visual Basic
when I try to read them into CAN-Do.

I will investigate.

---------
Suggestion, zipping log files will make them substantially smaller,
and have better data integrity during upload and download.

 

[MLucas]

Glad I held off on testing.

I got my FTDI cable and programmer in last night. I'll work on uploading a program to log data from my LeafCan this weekend. I'll do a recharge log and see what happens.

 

[garygid]

jjlink,
At record 635099, PID 231 has a data lenght of 20 hex characters
(10 bytes of data), and the maximum is 8 bytes.
Apparently there is some garbage data in the RealTerm Log.

So, I will add a check for this error, which I should have done already.
Version 1.90 comming soon to a place near you.

 

[jjlink]

Ok, I renamed the Realterm log files to .csv and zipped them up.

Yes, I saw that error also.

Thanks

 

[garygid]

jjlink,
Using the latest version (v190) of CAN-Do:
http://www.wwwsite.com/puzzles/cando/CAN-Do-v190.zip
(just the program, which now includes this data-length check)...

Your log 3 has 2 data-length errors, in about 916k records.
Looking at the list of PIDs on CAN-Do's first page, it appears
that the data might be a bit corrupted in some spots.

Your Log 4 has 3 length errors, in about 1 million records,
which is only about a 9 minute log.

Here the list of PIDs looks much better, although perhas not
perfect, so what did you do differently in masking tis Log 4?

Gettig a really reliable, noise free data stream
is one of the major challenges in doing logging.

Cheers, Gary

 

[garygid]

jjlink,
Good work, the zipped log files are one-tenth
the size of the original RealTerm files.

What hardware are you using to read the CAN bus
and send the data to RealTerm in the PC?
(I have an OBDLink SX, but I have no iMiev.)

Are you using a USB connection, or BlueTooth?
(I suspect USB to get this high data rate.)

What Data Rate are you using, 500,000 baud?

What Serial-to-USB chip does the hardware use?
My driver for the OBDLink SX is an FTDI driver,
so it is apparently not a Prolific chip, but an FTDI chip.

What is your buffer size set to, about 4k bytes?

Try using Comm Port 4 instead of Comm 3.

What OS?

Have you unchecked "Serial Enumerator"
on the properties of the Comm Port that you use?

 

[jjlink]

jjlink,
Good work, the zipped log files are one-tenth
the size of the original RealTerm files.

What hardware are you using to read the CAN bus
and send the data to RealTerm in the PC?
(I have an OBDLink SX, but I have no iMiev.)

Are you using a USB connection, or BlueTooth?
(I suspect USB to get this high data rate.)

What Data Rate are you using, 500,000 baud?

What Serial-to-USB chip does the hardware use?
My driver for the OBDLink SX is an FTDI driver,
so it is apparently not a Prolific chip, but an FTDI chip.

What is your buffer size set to, about 4k bytes?

Try using Comm Port 4 instead of Comm 3.

What OS?

Have you unchecked "Serial Enumerator"
on the properties of the Comm Port that you use?

I am using this:

OBDLink SX
USB

its on Win7x64 i5-CPU

for Captures 1 & 2 I used COM27:

for chapters 3 & 4 I used COM1.
COM1: was initially set up 115,200 baud, 8,N,1N.

with these commands sent to it:
stsbr 500000
500000 (reconnect at 500000)
ATSP6
ATE0
ATH1
ATL0
ATS0
ATCAF0
ATMA

Yes, the "Serial Enumerator" was checked, I just unchecked it.

only COM1: and high COM ports like 27 & up are available.
see this: https://dl.dropbox.com/u/27729958/COM-Ports.JPG

Buffer size is 4k

Suggestions?

 

[garygid]

The Comm Port "in use" just means that at one time the port
was used by some device, not that it is being used now.

Generally, when you plug the same USB device into the SAME
USB port a second time, the OS will assign the same (as used
the last time) Comm Port again, from the "reserved" in-use list.

However, if you plug the same USB device into a different
Comm Port, the OS will usually assign a new (unused) port
number, gradually "using" more and more ports.

Usually I stay away from ports 3 and below, and have had
some strange behaviors trying to use port 3.

Also, Visual Basic 6 (that I am using to program CAN-Do)
only accepts ports 1 through 16. It does not support
ports higher than 16.

 

[jjlink]

Ok, I will continue to use COM1: then. Thanks for the info.

 

[priusfan]

hello,
I am just starting to explore really CAN-Do... (with data I know).
There are so many things to do with this tool, I will need to read the manual.

imho, missing infos regarding iMiev (& iOn) , at this time:

a better odomoter, (not so difficult to find for an efficient team like on this forum )

the battery capacity in AH when fully charged (almost impossible to find without the "garagetool").
FYI, within 2 months and 1800kms, the capacity of my battery, according the "garagetool", went from 45.0 to 44.2AH

 

[jjlink]

Ok, here is a new capture.

https://dl.dropbox.com/u/27729958/i-Miev_capture5.zip

I'm hoping it has fewer errors now that I unchecked the "Serial Enumerator" (whatever that is for).

 

[priusfan]

hello,
here is a picture of a nexus 7 using the BT dongle from Andy Honecker.
the application is stable, but the start doesnot work perfectly each time....
the second number (50.0) on the left side is the SoC , bad label when I took the picture....
the police is too small for most of the labels and figures....
if somebody wants to try it, it is here
it should work on android devices with a good res (min 800 x 480).

addendum: it is necessary to create a folder BTION on sdcard to store logs and the bt's macadress