Archives

OK... Here's what I've been pondering for the last week or so. SGII (in the simplest sense) is a thing on a well defined bus speaking in well defined protocols. So I decided to figure out what makes this thing tick. That's where the problems were presented. Apparently "well defined" means "secret unless you pay the membership dues". The dues I refer to are the fees ISO levies for specs. Kinda blows me away. All the RFC's for TCP/IP and the like are posted publicly on a thousand sites, but ISO is $50-100 a spec. So where I can't get a spec I insert a good helping of WAG.

So lets begin...

ScanGauge speaks multiple languages. I'm a Prius driver, so from hear on out, I'm looking at CAN, or CANSF (CAN Short-bus, Fast signaling) <ref1 (http://www.greenhybrid.com/discuss/showpost.php?p=114272&postcount=2)>. Now, the language ScanGauge speaks on that bus is OBD-II (many specs cover this, so I don't know which to site). Basically, OBD-II is a Query/Response protocol. You ask a question, you get an answer. So to up date the gauges, SG asks a series of questions over and over again with some idle period in-between. That period is defined by the RATE variable {FAST, NORMAL, SLOW}.

So lets take coolant temp. The way to ask that question is to send 0x0105 down to the bus. Well, that's what you would send through the CMNDS screen. So now SGII figures out it's speaking CANSF at the other end of the bus, so before it puts the request to the wire, he's got to convert it to CAN speak. The first step is to encode the OBD-II command into an 8 byte request. The request ends up looking something like this:

{0x02, 0x01, 0x05, 0x55, 0x55, 0x55, 0x55, 0x55}

So that's a bit closer to CAN speak, the 0x02 is the amount of data, the 0x55 are something else. I think the represent inert bus cycles, or basically NOPs.

So now we have a CANish request that we need to address and place on the bus. First thing to do is to find the address. The standard (don't know which) dictates that if you want to speak 11 bit CAN (apparently there are 2 CAN dialects) as opposed to 29 bit CAN, the address that stuff hanging off OBD-II is supposed to use is 0x7DF. So now when we address and checksum the message, it might end up looking like:

{0x07, 0xEF, 0x88, 0x02, 0x01, 0x05, 0x55, 0x55, 0x55, 0x55, 0x55, 0x03, 0x63, 0xFF, 0x80}

Note the message starts with the first binary 1 and ends with the last binary 1, the 0s at the beginning and end are just to make it easier to read. Also the checksum of 0x1B1 is a bit of a guess on a CRC-15 calculation <ref2 (http://en.wikipedia.org/wiki/Controller_Area_Network)>.

So our
{0x01, 0x05} made it down to the bus as:
{0x07, 0xEF, 0x88, 0x02, 0x01, 0x05, 0x55, 0x55, 0x55, 0x55, 0x55, 0x03, 0x63, 0xFF, 0x80}

Now presumably someone will see the message addressed 0x7DF and respond. This is where I'm totally lost, and I have no idea how this happens, suffice to say at this point something magic happens. After the bit of magic the answer appears on the bus... twice. Once at 0x7E8 and once at 0x7E9

0x7E8: {0x07, 0xF4, 0x08, 0x03, 0x41, 0x05, 0x6E, 0x55, 0x55, 0x55, 0x55, 0x04, 0x17, 0xFF, 0x80}
0x7E9: {0x07, 0xF4, 0x88, 0x03, 0x41, 0x05, 0x6E, 0x55, 0x55, 0x55, 0x55, 0x04, 0x17, 0xFF, 0x80}

Now, SGII should be watching the bus for a message to either 0x7E8 or 0x7E9, so when it finds it, the HW/FW strips of the PHY layer stuff and bubbles up the response to our original {0x01, 0x05} request with our answer. That answer is:

{0x41, 0x05, 0x6E}

The last byte is the actual temperature 0x6E or 70c in base 10.

So there is lots of magic happening here that I don't understand, and am too cheap to pay ISO for the answers, so if anyone knows them, fess up ;). Actually, I'm just after someone to check my work or tell me where I'm off base.

Ultimately what I want to know is how to stuff CAN requests through the OBD-II interface as malformed requests (if possible). There is one concept used a lot on OBD-II land called modes <ref3 (http://en.wikipedia.org/wiki/OBD-II_PIDs)>. Basically the mode, in a way, provides a target for the message. In the previous example, we used mode $01. This is the get-status mode. There are vehicle-specific modes, but no one has found (or posted) what those modes are for the Prius II. The Ford Escape has mod $22 to get nice data, and the Prius Classic has mode $E5, I believe, to get SoC info. So that's about as far as I got this week, so perhaps I'll learn a bit more over the weekend (or realize that the stuff I posted is totally off base).

Thoughts?

11011011

I've been looking for the specs as well.

Just a correction. Free *drafts* are often available on the net. Final documents cost real money. So for C/C++, any "enthusiast" can download a near final draft for free and learn a lot about the fundamentals of the languages. (That, and there's a shelf-o-books on the languages at your local Big Box Book Store.)

Finding a "OBD-II For Dummies" - not so much.

I had hoped to find more information in the FSM (Factory Service Manual), but the information there is limited as well. The "HDS" (Honda Diagnostic System) plugs into the "DLC" (Data Link Connector, more commonly known as OBD-II port).

You might find hunting on sae.org (particularly forums.sae.org) helpful.

-mr. bill

Ultimately, I think you will just need the mode and PID values for the Prius to use the new SG user-programmable gauge feature. That is, if all of the Prius stuff is on OBD-II compatible servers. The most important stuff for the FEH is sent by the Traction Battery Control Module, which is not stand-alone OBD-II compatible. Thus, knowledge of the message ID for the TBCM is needed to get the data. Ron DeLong at Linear-Logic has told me that the current SG can be connected to the OBD-II connector at the same time as any other diagnostic tool and it will display what the other tool is sending. That might be a way to see what mode and PID stuff for the Prius is. I haven't done it because it would require making a special connector to allow both tools to be connected at the same time.
That and the fact that I already know all this for the FEH.

I am supposed to get my beta SG on Monday, and Ron has said that there is an extensive manual on how to use the user-programmable features. Probably much of what you want to know is in there; when I get it I will ask Ron how much of it I can disclose, if any. Did you step through all of the modes above 0x09 on your car yet? I know you said 0x22,0x23,and 0xAE didn't return anything, but it shouldn't take that long for the rest of them if you don't change the PID from 0x0000. Of course, if the Prius doesn't respond to PID 0000, you're wasting your time. It's hard to believe there is no knowledge base for the Prius enhanced PIDs yet, but I'm sure it will appear quickly once the new SG is in owners' hands.

Wow... let me be the first to congratulate on a beta ScanGauge. Sounds like RC is right around the corner.

I haven't started my bit banging project yet. One reason is that I can't quite get the decodes on the bit mask. I just want to make sure I'm not off by one. For example

0120 returns 80018001 which is in binary

1000 0000 0000 0001 1000 0000 0000 0001

So I read that as bit 0, 15, 16 and 31. So that should define support for 21, 30, 31, 40 (or is it 20, 2F, 30, 3F).

A bigger problem that I am running into is that with CanView (a Prius product that does all the heavy lifting), no one seems to care what PIDs work, so there is very little research done on it. I don't mind getting CanView, but what I really want to know is the HOW all this works, and the WHAT works (both in OBD-II and CAN), much more than the data that is behind the research. To get the data I just mail off my $500 bucks and hook up CanView.

Just a jigsaw puzzle for me to try to put together.

Anyone know of a USB controlled one line LCD display. Basically just a two or 4 character display. If I ever get this stuff figured out, I can hook up to my PC and have a special gauge displayed on a little LCD on my dash. I can't seem to get the nack of driving looking at CanView, it's so far down from my driving line of sight.

11011011

Hey, it looks like PID 40 is supported, so if you send 0140, you should get back the supported PIDs from 40 to 60. If 60 is supported, you can send it to find PIDs 60 to 80, etc. On my FEH, PID 40 returns a zero for PID 60.

I may trek over to a Toyota Dealer and see if I can test drive a Prius (or TCH or THH), and maybe record a few things during the drive........

I wonder if all the modes $01, $22, etc.. support the same 0x00, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, 0xE0 method for finding service mappings.

I should have some data soon..

11011011

Hi Carl:

___A bit OT but is there a way to upload the SG-II’s output in real time to a laptop vs. the upcoming memory storage and transferring it up at home after the drive? This question will become extremely relevant in about a month or so. I have some calls in for Ron wrt this question but have not connected up with him directly yet :(

___Good Luck

___Wayne

OK... Here's the first run of supported PIDs of the 2007 Prius

To find them I did the following CMNDS

XXYY where XX is the mode and YY {00, 20, 40, 60, 80, A0, C0, E0}. The return you get back is a bitmap letting you know which of next 32 PIDs are supported. If the return you get back is odd, then go ahead and advance YY by 20. I tried XX of 01-0F.

Example

0100: 4100981A8013 (odd, so keep going)
0120: 412080018001 (odd, so keep going)
0140: 4040FE1C2000 (even, so I can stop)

$01 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 * * * * * *
10 * * *
20 * *
30 * *
40 * * * * * * * * * * *
50 *

$06 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 * * *
10
20 * *
30 *
40 *
50
60 *
70
80 *
90
A0 * * * * * *

$08 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 * *

$09 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 * * * * * * *

Now, when I start doing the six nibble PIDs, what's the form

XXYYZZ advancing ZZ by 0x20 for each odd (not even) response? When ZZ rolls, to I advance YY or XX?

11011011

OK... did a bit more poking... Tried XXYYZZ with XX = 0x10 - 0x50. and YY = ZZ = 0x00

Actually got a return on 0x3F0000 of 0x7F3F11. Based on this (http://en.wikipedia.org/wiki/OBD-II_PIDs), I should have gotten back 0x7F0000????????.

11011011

Actually, getting back 0x7F3F11 from 0x3F0000 isn't that unusual. You don't always get the correct response when using the SG CMNDS mode, because, as Hobbit alluded to earlier, the CAN message filtering isn't controllable in the current SG. It looks like a mode 0x3F PID of 0x3F11 is supported, did you get any data bits or just the 0x7F3F11? I don't know if a mode 0x3F would have a two-byte PID for sure, but it seems likely. I do know that the '04 and up Prius supports at least 369 enhanced PIDs, so it would have to be 2 bytes. Did you then try sending 0x3F3F11 and see if you got back something like 0x7F3F11aabb?

Wayne, I will ask Ron tomorrow (if I do indeed get the beta SC tomorrow) about the data logging status.

Got the exact same response at 7F. 7F0000 returned 7F7F11. According to the swiss summary of the OBD-II spec (part 3, page 10) here (http://autos.groups.yahoo.com/group/Prius_Technical_Stuff/files/OBD%20Info/), mode $3F and $7F are not valid modes. So it looks like Toyota is not implementing any vehicle specific modes in the Prius.

11011011

At some point I was given to understand that the CAN IDs map
either to individual ECUs, or to a "broadcast" type of thing
that I believe is that 7DF id. There was some fairly defined
set of ECU types, something like 7E0 for engine, 7E1 for trans,
etc -- but I don't know if that's standard or how rigidly the
manufacturers have to adhere to it. And in the answers, the ID
winds up with another bit turned on so if the engine ECU is
queried at 7E0 the answer comes from 7E8 [don't quote me on that,
I'm just parroting some stuff I read somewhere]. And that's
just in the CAN layer -- these extra query/response differentiator
bits happen elsewhere too, such as in the OBD-II layer where
a query for PID 00 goes in as 00 and comes out as 40 with a
bit to indicate "this is a response".
.
The protocols involved in all of this have been a *nightmare*
in the industry since their inception, and there are some groups
vigorously trying to standardize this to the point where any
independent auto tech can use off-the-shelf tools to get all the
diag info they need, and also re-flash firmware into ECUs when
needed via something called J2534 "passthrough" protocol. See
the NASTF (http://www.nastf.org/) website for a glimpse of what they're up against. The
car manufacturers grudgingly allow for a minimum set of standard
data exchange [such as generic OBD-II to carry emissions info]
but over and above that they just arrogantly assume they can
do whatever they want and either not document it or make some
of it available at a very dear price. It really sucks.
.
_H*

At some point I was given to understand that the CAN IDs map
either to individual ECUs, or to a "broadcast" type of thing
that I believe is that 7DF id. There was some fairly defined
set of ECU types, something like 7E0 for engine, 7E1 for trans,
etc -- but I don't know if that's standard or how rigidly the
manufacturers have to adhere to it. And in the answers, the ID
winds up with another bit turned on so if the engine ECU is
queried at 7E0 the answer comes from 7E8 [don't quote me on that,
I'm just parroting some stuff I read somewhere]. And that's
just in the CAN layer -- these extra query/response differentiator
bits happen elsewhere too, such as in the OBD-II layer where
a query for PID 00 goes in as 00 and comes out as 40 with a
bit to indicate "this is a response".
.
The protocols involved in all of this have been a *nightmare*
in the industry since their inception, and there are some groups
vigorously trying to standardize this to the point where any
independent auto tech can use off-the-shelf tools to get all the
diag info they need, and also re-flash firmware into ECUs when
needed via something called J2534 "passthrough" protocol. See
the NASTF (http://www.nastf.org/) website for a glimpse of what they're up against. The
car manufacturers grudgingly allow for a minimum set of standard
data exchange [such as generic OBD-II to carry emissions info]
but over and above that they just arrogantly assume they can
do whatever they want and either not document it or make some
of it available at a very dear price. It really sucks.
.
_H*

Yep, I think I have the 11 bit can addresses I'm after (such as 7E8 and the like), but I have no way to stuff those into OBDII. I was hoping that Toyota implemented some sort of pass-thru PID, but that doesn't look to be the case. The only stuff out there is in the standard modes of 0x01 - 0x0F, nothing exotic. Only thing I can do now is to decode all the PIDs for $01, $06, $08, $09. Least I am only missing one spec instead of many.

May start looking for an CAN sniffer for my PC, too bad no one sells them yet. Heard the ELM adapters don't speak CAN yet, and most have resorted to wiring up their own. Any thoughts on where to get a CAN <-> PC adapter for < $400? Preferably one with the software to get the baudrates matched and stuff like that. I think CAN is speaking on a frequency that serial ports have a hard time matching.

The quest continues.

11011011

The ELM 327 (http://elmelectronics.com/DSheets/ELM327DS.pdf) speaks CAN. And last I heard, Attila Vass was
using the CAN232 (http://www.can232.com/) interface to passively pull data from the
DLC. The data rate will definitely overwhelm most RS232
interfaces even if cranked to 115.2 kbaud or better, but
setting some acceptance registers can help stem the tide.
Lawicel apparently also makes a USB interface (http://www.canusb.com/), which might
be able to keep up and log the full datastream. But a lot
of what's flying around is realtime control stuff; answering
OBD-II queries is said to be any ECU's *last* priority which
is one reason it's generally still dog-slow even on a half-
meg canbus.
.
_H*

Ahh.. Attilla's site (http://www.vassfamily.net/ToyotaPrius/CAN/CAN232/index.html) is making a lot more sense now. So I could get the CANUSB, but I still need some USB LCD to display what I want while driving. I'm spoiled by the SGII and I don't want to have to look down at my laptop to get the correct data reading. All I need is an LCD one or two characters wide, but I've yet to see anything.

If I had a fancier cell phone I could display it on there (via bluetooth) but my old Sony T610 doesn't have a bluetooth API that mortals are allowed to play with.

11011011

Hi Dan:

___I spoke with Ron today about an advanced use of the next gen - data logging SG-II. While speaking to him about that issue, I mentioned your name more then a few times wrt this thread. I suspect that you may want to give him a call so as to beta test the data logging setup.

___Good Luck

___Wayne

I'm on it ;)

11011011