Announcement

Collapse
No announcement yet.

FORD ISO9141 - can any OBD2 tools sniff it correctly?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • FORD ISO9141 - can any OBD2 tools sniff it correctly?

    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

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

    Comment


    • #3
      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

      Comment


      • #4
        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

        Comment


        • #5
          Originally posted by Lukeyson View Post
          The tools appear to concatenate query and reply messages, thinking they are one message, and error when the message length is too long.
          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.

          Comment


          • #6
            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

            Comment


            • #7
              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

              Comment


              • #8
                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

                Comment


                • #9
                  9600 is the lowest speed

                  Comment


                  • #10
                    The AU has ISO9141?

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


                    Lukeyson

                    Comment


                    • #11
                      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.

                      Comment


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



                        Luke

                        Comment


                        • #13
                          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."

                          Comment


                          • #14
                            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

                            Comment


                            • #15
                              Originally posted by Lukeyson View Post
                              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
                              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.

                              Comment

                              Working...
                              X