[obdgpslogger] Mode $06

Michael Carpenter malcom2073 at gmail.com
Thu Dec 22 21:06:57 EST 2011


That's the kicker, what exactly IS Mode $06?

In short, Mode $06 returns a whole bunch of tests against a whole bunch of
components, gives you min, max, current value, and from that you can glean
pass/fail on components.

Mode 6 in CAN is different than Mode 6 in non-can vehicles. Most of my
experience thus far is with CAN vehicles, but I'm hoping to expand what I
know as I play more with my car.

In a nutshell (For CAN)
0600 returns a list of supported OBDMID's (OBD Monitor ID's). This is a
list of component systems that will be under test.
You request them like so:
0601
0602
etc.

Some monitor ID's are standardized. Some test ID's are standardized. The
rest are MFG specific, and generally unknown. What IS known is the values,
min, max, and what type of return it is.

What is returned, is a list of what tests are being run for that particular
monitor. Example time:
0601 could potentailly return “7E8 10 1C 46 01 81 0E 0A CB 7E8 21 06 54 0E
D8 01 87 10 7E8 22 00 9D 00 00 01 2C 01 7E8 23 88 10 00 84 00 00 02 7E8 24
58 00 00 00 00 00 00 ”

Split that on the header:

7E8 10 1C 46 01 81 0E 0A CB
7E8 21 06 54 0E D8 01 87 10
7E8 22 00 9D 00 00 01 2C 01
7E8 23 88 10 00 84 00 00 02
7E8 24 58 00 00 00 00 00 00

Remove the header and counter bytes, reorganize the arrangement of the bytes

0181 0E 0ACB 0654 0ED8
0187 10 009D 0000 012C
0188 10 0084 0000 0258
00  00 00 00 00 00

So we have three messages for OBDMID (OBD Monitor ID) 0×01. TID 0×81, TID
0×87, and TID 0×88. All three of these are manufacturer specific TID’s, so
we don’t actually have any information on what they mean, but we can still
parse out the values. The third byte signifies how to parse the messages
0x0E means the result is in Amps, and you multiply it by 0.001. The fourth
and fifth bytes are the value (0ACB), 2763. Multiplied by the mulitplier,
and it’s 2.763Amps. The sixth and Seventh bytes are a minmum value, which
multipled by the multiplier works out to 1.62Amps, and the eighth and ninth
are the maximum which is 3.8Amps. Our value is between the min and max, so
the test passes.

Easy right?
0181: Min: 1.62Amps, Max: 3.8Amps, Value: 2.763Amps, Test: Passed
And so on and so forth. I listed a bunch of what the parse bytes meant on
mp3car, and I'm tracking my progress on my own website/blog to help keep
track of my experimentation.

All three of those messages are MFG proprietary messages, so we haven't a
clue what they're measuring. But we know they pass. That being said, a lot
of the returns are standard tests, those three happen to not be.

In playing around, I've found that mode 6 could actually potentially help
you diagnose down to the component level a fault in the system. (Misfire
counts on a particular cylinder + bad o2 sensor voltages == replace o2
sensor and check spark?) All in all very useful stuff... implemented in a
lot of pay-for programs. I think having obdsim simulate it would be greatly
beneficial in letting more open source applications take advantage of this
information and implement it in their own applications. What you could do,
is return a list of "standard" tests with a randomized value, either
passing, or not (both would be beneficial, as well as the ability to set
what's not passing), to allow users' applications to trigger warnings on a
failure of a particular test/component.

Once I get more information on mode 6 for non can vehicles, I'll try to let
you know... A lot of rambling and information, I know sorry.

On Thu, Dec 22, 2011 at 10:17 AM, Gary Briggs <chunky at icculus.org> wrote:

> One of the things on my list for a while has been other modes
>
> I already have different stuff in place for different modes in obdsim, I
> just haven't, you know, implemented it yet.
> Fundamentally, I still am not entirely sure what mode 6 *is*. Could you
> clarify a little?
>
> In the meantime, I'm out of town another week. I'll be on IRC again when
> I'm back. If you let me know some idea of what mode 6 is and how it's
> used, I'll ponder how to make it work with obdsim
>
> Gary
>
> On Thu, Dec 22, 2011 at 04:15:10AM -0800, Michael Carpenter wrote:
> > So,
> >
> > I've been rambling about this for a short time now, but being as
> Chunky_Ks
> > hasn't been on irc ill post it here. Obdsim should support mode 6
> requests.
> > I can work with you on what is expected, I recently got it working in
> > libobd, so I don't think it would be difficult in obdsim. The only
> question
> > is how do you handle ecu type for headers? A CAN ecu will reply to a
> mode 6
> > request differently than a non CAN ecu, so it makes a difference.
> >
> > - Michael Carpenter
>
> > _______________________________________________
> > obdgpslogger mailing list
> > obdgpslogger at icculus.org
> > http://icculus.org/mailman/listinfo/obdgpslogger
>
> _______________________________________________
> obdgpslogger mailing list
> obdgpslogger at icculus.org
> http://icculus.org/mailman/listinfo/obdgpslogger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/obdgpslogger/attachments/20111222/9fc86e31/attachment.htm>


More information about the obdgpslogger mailing list