Mitsubishi I-Miev Forum

Jjlink,
This "distorted" data is coming from somewhere.
Have you looked at it with my new "(*) Errors"checkbox?

What driver, if any, did you install with the OBDLink?

Was it the one that came on the CD with the device?

See if there are any options in the Comm Port settings
for your data connection to the OBDLink SX.

If there is Serial Enumeration, make sure that you
have it un-checked.
If there is Latency, perhaps lower it

I can try to connect my OBDLink SX device
to my Win7 laptop.

jjlink wrote:
I had installed ODBwiz v2.13.1, I just uninstalled it for now.
I'm not sure where the MSCOM32.OCX came from. I will have to go to my backup disk to compare it to your copy.
Serial Emulation is off, I will check Latency and try the new "(*) Errors" checkbox when I test again this afternoon.

Thanks

Ok, I just did a quick 5 minute drive test with the new "(*) Errors" checkbox and it says I got 58 errors on 396,561 records. I believe it said 5 errors on the comm input error count. I used com27 rather that com10 this time, Serial Emulation is off, Latency was changed to 8 from 16.

Any other ideas?


58 msg-IDs by JJLINK, on Flickr

No great ideas, but I had to fuss with the settings
for a 4-port RS232-to-USB adapter that I use
before I could get totally good data with Vista.

Now, I am not absolutely sure that CAN-Do is not
causing the errors during input, but ... it is hard to test
when things happen so fast and so infrequently.
They could come from the OBDLink but I did not get
any errors like this with the LEAF and The USB-connected
OBDLink SX.

I have made a new CAN-Do v204 with a "Clean (*)" button to
"move" these error messages from the parent MsgID into another MsgID,
thereby "cleaning" the wrong-length data messages from the parent.

The new MsgIDs are DD0 through DDF, so that they are not confused
with the normal MsgIDs (which are 7FF and below).

This fuction looks at all your listed MsgIDs, finds the dominant
data length, and changes the MsgID of the "error" Messages
of length N to MsgID = 0xDDN, keeping the same N data length.

http://www.wwwsite.com/puzzles/cando/CAN-Do-v204.zip

Try it on the "corrupted" 24 million charging log.
It helps in displaying ad graphing the data.

jjlink,
From your picture, I see that MsgID 200 has at least one (*) error.

You can try v204 on that log, to get familiar with what
the new functions do.

jjlink,
What is the Comm Port buffer size?

While gathering data, the Error field is in pink on the right
side of the Message-Count field. With a "Show Buffer Size"
(or similar wording) checkbox, one can see the maximum
number of bytes that were in the Comm Port buffer each
second, allowing you to judge if bytes might be getting lost
while logging.

Also, do not check the "Show Dashboard" checkbox while
logging, because that might be taking too much compute time,
but that would usually show up in the Max Buffer size, I
believe.

I will try to go through the code for capturing the logs,
and look for any data clobbering. Unlikely since you are
only running one channel of log-capturing, but I will look.

Cheers, Gary

garygid wrote:jjlink,
What is the Comm Port buffer size?

While gathering data, the Error field is in pink on the right
side of the Message-Count field. With a "Show Buffer Size"
(or similar wording) checkbox, one can see the maximum
number of bytes that were in the Comm Port buffer each
second, allowing you to judge if bytes might be getting lost
while logging.

Also, do not check the "Show Dashboard" checkbox while
logging, because that might be taking too much compute time,
but that would usually show up in the Max Buffer size, I
believe.

I will try to go through the code for capturing the logs,
and look for any data clobbering. Unlikely since you are
only running one channel of log-capturing, but I will look.

Cheers, Gary

Ok, for 238678 capture records, max buffer size shows as 888. This was just for a minute of driving. The max buffer size seem to grow pretty fast during this small amount of capture time.

Comm Port buffer size send/receive is 4096.

Yes, I just tried the "Clean (*)" button.

Thanks

I graphed the D8 byte (0xFF) of the DD0 through DD7 "Error (*)" MsgIDs
and they are sprinkled throughout the 6 hours of logging.

I looked at the CAR-CAN OBDLink format logging code,
and I did not find any errors, but there was a small
error in the EV-Comm version of the logging code,
which nobody has used yet. But, nothing that would
produce "distorted" messages.

I think the Max Buffer Used is just over one second.
However, I will add a Max Buffer Used for the whole
logging session, and the Error Count, to the message
at the end of the logging session.

jjlink,

The message that you got after clicking the Show MsgIDs button
does not count any errors, it is just telling you that there are 58
MsgIDs in the list that was just created.

The "(*) Errors" checkbox only works when one double-clicks
a a MsgID in the list, then it tels you about the "errors"
(of this non-dominant data length type) in the messages
in that have that one MsgID.

I will change the tool-tip to mention doube-click.

However, the part of the list that I can see shows that
MsgID 200 has at least one such error.
I will put out another version of CAN-Do is a short while.

Cheers, Gary

CAN-Do v205, mostly minor changes, some better messages, I hope.

http://www.wwwsite.com/puzzles/cando/CAN-Do-v205.zip

Please let me know what you experience, mentioning the Version Number.

garygid wrote:CAN-Do v205, mostly minor changes, soe better messages, I hope.

http://www.wwwsite.com/puzzles/cando/CAN-Do-v205.zip

Please let me know what you experience, mentioning the Version Number.

Thanks, I will try it first thing in the morning.