Lukeyson

Ford seems to have some sort of proprietary implementation of ISO9141 on it's cars.

My experience is that the ELM and J2534 style tools can send and receive messages on Ford's ISO9141, but they can't be used effectively for sniffing because of the custom way that Ford implement the message length.

The tools appear to concatenate query and reply messages, thinking they are one message, and error when the message length is too long.

Has anyone else experienced this or found a way around it? I'd imagine that support for this method would need to be added to the microcode on an ELM for it to work right.


Lukeyson

MP3Car.com

 

techbod

not sure if this can help
http://www.scantool.net/support/inde...&kbarticleid=3

Lukeyson

Interesting link, but not helpful for my specific issue.

These are Australian Fords, and the German Bosch 5.3 ABS modules, Canadian Airbag Modules and Mexican Bosch Reverse Park Aid Modules all use what appears to be an implementation of ISO9141 that does not conform 100% to the standard - like in the 1st byte format and the Init process.

It's curious to note that not even that Ford Protocols table shows ISO for Ford. But then I find that a lot - US or European specifications that don't match what Ford builds in Australia.


Lukeyson

techbod

fords in the UK tend to lean toward KPW2000 and ISO was mentioned before but I never seen it,
the ABS 5.3 Bosch can be probed with a breakout box due to the small size of the cable adapter there are a few ABS systems used here Mecatronic III / Mecatronic III with traction control ( TCS ) and of course Bosch 5.3

joeyoravec

You probably need to adjust the P-timers. When there's a delay you use these timers to decide if you got one long message or two separate messages. The timeout is surely faster for non-emissions networks. Don't you have a Mongoose? It's adjustable on there.

techbod

Mongoose now that looks interesting ( I googled it ) not available in the UK hmmmm I wonder why as the cash register clicks at the dealers lol

Lukeyson

Well, while I do I have a Mongoose, the problem is I don't have two. You see, when I am using J2534 software with the tool (Like Ford Module Programming for example), I need something else to sniff what's going on.....


Lukeyson

Foggy16

Also with Ford Australia it seems that they sometimes use different Baud rates i.e the AU model uses ISO at a baud rate off 9400

techbod

9600 is the lowest speed

Lukeyson

The AU has ISO9141?

I thought it was just J1850PWM (Standard Corporate Protocol) ?


Lukeyson

Foggy16

I found a reference to the AUs in the manual for a high end scan tool which said that they used a form of ISO with custom timing and initiation routines.

Lukeyson

Are you able to post more detail about the reference? Either how to find it ourselves, or a snippet from it?



Luke

Foggy16

Hi Luke,

Will try to find the reference for you. Unfortunately my home pc's harddrive failed the other day and I lost everything.


I have found this reference to ford aus and iso which I thought you might be interested in but its not as good as the one I had before.


"The Siemens K-Line protocol exists on a vehicle
line found in both Australia and Taiwan. It uses
the standard ISO 9141 physical layer running at
10.4Kb/s. It does not follow the standard clientserver
model. Rather, when the PCM awakens it
starts transmitting a circular buffer of DTC and
PID information. The tester does not send any
request message; it waits for when the PID or DTC
of interest is transmitted and grabs it. The period
of this circular stream of diagnostic data is roughly
50 milliseconds."

Lukeyson

OK, that will be interesting to see if I see that on an AU Falcon.

However on a BA Falcon the ISO9141 implementation seems different again. It does use the query/response model.

The big ticket item for me is that the 1st Octet of any message sent MUST the number of bytes being sent. If you try to construct a header using the ISO9141 standard method, no queries will work.

However, when I construct a message with this first Octet set correctly, I am able to send a message fine, and receive a message that itself has the 1st Octet set to the length of the message.

It would seem to me that, rather than relying on timers to know when a message has ended, in this implementation the sniffing scantool would need to know to read the 1st octet, count out the bytes for message 1, then would know that the very next byte would be the first byte of the next message.

At the moment when I use an ELM or a Mongoose to scan, both tools get confused as to when the query message ends and the response begins. In some cases because the header is completely non ISO, the sniff picks up nothing. But other times it picks up the query/response stuff and thinks it's the one message.



Luke

joeyoravec

You should probably revisit your assumptions. On ISO14230 two frames can be back-to-back so the tool needs to parse the data for a length and use timers. On ISO9141 a gap is required, so the data has no infuence whatsoever on how the bitstream gets broken into messages and the tool depends only on timers.

On the Mongoose you can adjust adjust P1_MAX which "sets the maximum inter-byte time for ECU responses." The default of 20ms is compatible with Ford's specification of 0-20ms. At this point I would pull out the oscilloscope and try to measure the actual timing between bytes, try to tweak P1_MAX, etc. I'll send you an IM about this if I see you online later.

MP3Car.com