Lukeyson

Background:

ELM327. Open the box. Turn it on. Hook up to CAN bus. Auto sense protocol OK. Issue J1979 Mode 03 request for DTC's.

The ELM327 sets it's CAN header to 7E0 by default, so this Mode03 request is only issued to the PCM right?

I have an airbag warning light, with Light Flash Code 53, which is one of two DTC's. (Buzzer Short to GND, or Short to +ve). When I issue the request as above, I don't get any DTC's at all. And thinking about it, if I'm only sending the request to the PCM, why should it?

After all, J1979 is an EPA driven standard, and what has the Airbag got to do with the environment right?

I don't have access to 1979 or 14229, so I'm at a bit of a disadvantage.

So my question is this: Should I be getting non-PCM DTC's when issuing a command like that?

If I set the CAN header to be that of another module (I do have the CAN module addresses, and I know they stand a good chance of being OK, because when I issue any request I get a 7F reply rather than no data) then I would need to enter a custom PID query to get the DTC's for that module right? Such as a Mode22 request for PID?


Can someone tell me if I'm on the right track? I understand that anything in Mode22 is proprietary of course, I'm not asking for that info. I'm just trying to get the theory right behind access non-PCM DTC's.



Lukeyson<br /><br />

Carlocutor

Yes, I believe you can use the ELM327 to get DTCs from controllers other than "the" PCM (engine controller, as opposed to the transmission controller, etc.), if the those other modules are designed to respond to OBD requests for DTCs, which is another matter.

If an OBD DTC request is issued to 0x07df (a functional address), then any controller designed to respond *may* do so (e.g. transmission controller, etc.). The ELM327 seems to issue OBD requests (at least the initial "discovery" request) to 0x07df which is a kind of "global" functional address. But I'm not sure how it handles responses from modules other than the ECU at address 0x07e0.

Maybe if you set the CAN header as such "AT SH 7df" (which appears to be its default setting for 11-bit CAN) it will show responses from any responding controller?

Lukeyson

OK, I've done some homework too.

Knowing the addresses of my modules (and mine adhere for the most part to recommended addresses in 14229) is only half the battle. With some serious help from a friend, and a good read of J2190, I finally got what I wanted.

Firstly, like you said, I set the header to be one of the ECU's on my bus. (In this case, 720 for the Instrument Cluster).

Then I issued the following command:

220200

That was a Mode22 command that is in some ways parallel to the Mode03 command for requesting DTCs in J1979. This query returns to me how many DTC's I have. In this case I had 3.

Then I issued the Mode18 query for DTC's from all functional types:

1800FF00

That returned two lines of data for 3 DTC's. In between each 2 byte DTC was a 'status' value that told me things like: if the light was on, if the error was pending, or if it was something from the past but is now OK and still needs to be manually cleared.

With those 2-byte values I was able to use the normal 2-Byte to DTC method for finding the DTC values.

In this case, it turned out that it was complaining about open-circuits for both left and righ hand indicators, and there was no Fuel Sender signal. These were all 'historical, waiting for manual clear' status. Which is cool, because last week I took the cluster out to put it on my bench to learn more about CAN.

Mode14 was then the clue to clearing those DTC's.


Lukeyson

mrbean_phillip

Good find, glad you got the "53" fixed

Seems like you're making great progress, much better than i am - still struggling to finalize the carputer, but getting very close. Will keep you posted.

__________________
F6 Tornado Project Log - nearing completion

Lukeyson

Well, no I didn't. These were DTC's from the Cluster, and I've yet to find DTC's from the Restraints Module. In this car, the IC was on the CAN bus, wheres the Restrain module is on the ISO bus.

So I'm off to learn more about module addressing in ISO....


Lukeyson

Carlocutor

I have found a restraints module on an ISO network on a Ford vehicle at address 0x58. So, for example, to request passenger seat belt status, you might form the request like this:

0x6458f1225a01

0x64 is priority/type
0x58 is module address
0xf1 is tester address
0x22 is mode
0x5a01 requests passenger seat belt

Actually, I think this requests a reading of current (milliamps, I would guess), from which you could infer buckled-ness.

But of course your restraints module might be at a different address, or respond to different messages, etc.

Lukeyson

Yep, 58 is the address I have in my references too. However, I issued my command with e4 as the first byte and got no response.

Looking at J2178 it appears to me that I need to be mainly concerned about the bit that declares the request to be a 'physical' request rather than 'functional'. I'll try it with a different first byte and see if that works.

But yeah, I had set my header to e458f1 on the elm, and tried to issue a 220200 request - but no response at all I'm afraid. The ELM327 automatically puts in the PCI, CRC and padding for me.

Which is why the need for more reading.

On our cars, the ABS Module(28) and a Park Aid Module(B2) are on the ISO Bus as well. (On some higher series cars, the 6 Speed Auto Transmission (18) also has ISO access). Both the ABS and Auto modules are dual connected to both ISO and CAN, but use ISO for diagnostics.


Lukeyson

Lukeyson

So now I'm curious.

Do you have any other Restraint Module PIDS with Scaling that might be useful Mr Cutor?

There's been some movement lately in people finding PIDS and Scaling for Ford PCM's, but I'd be pretty keen to see what other PIDS are out there for any other Ford module (Instrument Clusters, ABS, Body Control, Audio Display, Park Aid and Transmission Modules etc)


Lukeyson