Announcement

Collapse
No announcement yet.

Distinguishing ECUs

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

  • Distinguishing ECUs

    I'm trying to make some changes so that I can log from multiple ECUs simultaneously. Lacking a substantial set of differing hardware sims and cars, I was hoping someone here could advise a little.

    If I really want to distinguish all the ECUs, and which features which ECUs support, do I need to turn on headers all the time? That's not particularly impactful for me performance-wise, but I was wondering if that's the only way.
    I assume that it is, because if I have two ECUs, one responds to one PID, and the other responds to a different PID, then I'd otherwise have no way to tell which one responded.

    Having got to the point where I've decided I need headers on all the time, how do I reliably parse with headers on? Does each protocol support a different header format when I get it back from the car, or do they all work roughly the same way? Does anyone have a simple, formal-ish, short list of what the header format is for each of the protocols?

    OBDSim is pretty mickey-mouse right now:
    Code:
    >ATH1
    OK
    >0100
    7E8 06 41 00 FF FF FF FE
    >
    7E8 and 06 is just hardcoded.

    Finally, given a list of ECUs, ... how do I know which of them I might actually care about? I'm told that as a rule of thumb, the ECU I probably want is the one with the lowest ID. How does that change in the face of hybrid cars? I'm envisaging an RPM graph with two plots stacked on top of each other, for each engine. How would I distinguish them? When I request RPM in mode 1, will I likely just see two separate

    Thank-you very much,
    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  • #2
    Unfortunately, there are no rules about ecu id's. Only guide lines that not everybody follows. With 11-bits can-id's there's no way of telling what ecu if doing what (engine, gearbox). Except when you are lucky enough to see an ecu with support for oxygen sensors. That's an engine - but early diesels do not have oxygen sensors.

    Comment


    • #3
      Yeah, that's the impression I was left with :-/

      So is there at least a standard format for headers? Or do you have a list of all the header formats currently known?

      Gary (-;
      OBDGPSLogger, for logging OBDII and/or GPS data
      OBDSim, an OBDII/ELM327 software simulator
      mp3car forums: obdgpslogger, obdsim

      Comment


      • #4
        J1850 and ISO protocols all have pretty similiar header structures:

        <header> <dest> <source>

        The header byte will differ, but it is basically 3 bytes.

        CAN is the oddball. In 11 bit CAN, it is all implied. That is, there are 8 predefined message IDs for up to 8 ECU's. Generally, you can count on some things coming from the lowest physical ID, but it isn't a rule, just a recommended practice.

        You also have to 'know' the matching ID for talking to the particular physical address. It is basically offset by 8 (though this rule doesn't hold true for make/model specific stuff).

        29 bit CAN, though rare, is closer to the older protocols. The 3 elements are just packed into one CAN ID, instead of 3 trasmitted bytes.

        -jjf

        P.S. There is a list of the headers in a table in the J1979 spec, but unfortunately I am not legally able to reproduce it. Sorry!

        Comment


        • #5
          <header> <dest> <source>

          So how do you actually parse that? Thus far I've been using sscanf. So for something like thi:
          Code:
          7E8 06 41 05 6A
          I'd parse thus:
          Code:
          unsigned long h; unsigned int ecu;
          unsigned int mode; unsigned int pid;
          unsigned int bytes[4];
          
          sscanf(buf, "%3lX %02X %02X %02X %02X", &h, &ecu, &mode, &pid, &bytes[0]);
          Would that be right in general, or am I way off?

          I have a copy of the most recent J1979 - could you tell me where in it to look? I flick through it and my eyes occasionally glaze over :-|

          Thanks,
          Gary (-;
          OBDGPSLogger, for logging OBDII and/or GPS data
          OBDSim, an OBDII/ELM327 software simulator
          mp3car forums: obdgpslogger, obdsim

          Comment


          • #6
            Originally posted by chunkyks View Post
            <header> <dest> <source>

            So how do you actually parse that? Thus far I've been using sscanf. So for something like thi:
            Code:
            7E8 06 41 05 6A
            In this case it would be

            if (proto == can_std)
            {
            ...
            }

            And the first bit (0x7E8) is the CAN ID.

            The next byte is just for the CAN protocol. All packets are 8 bytes, but this will tell you how many of the remaining 7 bytes are actually valid. There is also a bit that indicates that the response is too big for one packet, so you have to send flow control messages.

            I believe that you can setup your interface to do the handshaking automatically for you, but you'll still need to reassemble the packets.

            The next byte, 0x41, is the first byte of the actual OBD-II response data. The 0x40 means positive response, and the 0x01 means 'to a mode 1 request'.

            In a positive response, the next byte will be the PID requested (0x05).

            The remainder of a single packet response will be 1-4 data bytes. PID 5 would be ECT, so there is just a single byte of data.


            As far as 'where', I can't open the spec on this machine (there is a stupid security add-on you have to run with the Adobe Reader, and it is setup fo a different machine). But if you look at the listing of tables you should find it. It basically shows all the different basic packets, along with their headers, in one table.

            -jjf

            Comment


            • #7
              OK, so, I'm looking at the spec. [page 30 here. I bought the dead tree version because the DRM is pretty draconic]

              I see the CAN header bytes are either 11 or 29 bits, then eight bytes. It doesn't say that the byte after the address is the number of valid bytes - am I looking at the wrong thing?

              The other protocols [as I will be receiving them from the ELM327 device] all seem to be of this form:
              "%02X %02X %02X %02X %02X ...", priority/type, ELM bus address [I would ignore this], ecu, mode, pid, etc, etc [maximum seven bytes]. The first three, the actual header I would parse, seem to all be one byte each [?], except for ISO14230-4, the description for which is completely outside my comprehension.

              Is that right? The problem is that I really don't have any other systems. Would you be able to post a few simple logfiles showing the communications you have with the ELM device, for each of the protocols? Just, say, 0100 for each or something after enabling headers with ATH1. I realise it's a lot to ask, but I just don't have the hardware I need to do it myself.

              It seems that very few people spend any time looking at the headers in OBDII software

              Thanks for your help!
              Gary (-;
              OBDGPSLogger, for logging OBDII and/or GPS data
              OBDSim, an OBDII/ELM327 software simulator
              mp3car forums: obdgpslogger, obdsim

              Comment


              • #8
                Gary,

                Look in the ELM327 datasheet, there are many examples there. For instance:

                >01 00
                48 6B 10 41 00 BE 3E B8 11 FA
                48 6B 18 41 00 80 10 80 00 C0


                This is what you get if you have two ECUs, 10 and 18 (typically, ECM and TCM) on J1850 VPW and ISO 9141-2.

                For PWM, the first byte becomes 41 (=IFR required), everything else stays the same.

                KWP may seem confusing, but is actually pretty simple:

                Diagnostic Request at 10.4 kbit/s (ISO 14230-4)
                11LL LLLLb 33 F1


                So the first two bits of the first byte are "11" and the rest of the bits are message length. Destination is 33 (functional address), and F1 is of course the source address. The rest of the request ("01 00") is the same.

                Diagnostic Response at 10.4 kbit/s (ISO 14230-4)
                10LL LLLLb F1 ECU addr


                This means that the first two bits are "10", then you have length, then scan tool address as the destination, and ECU address as the source (so the response is always a physically addressed message).

                There is an example of multi-message 11-bit CAN responses on page 41 of the datasheet. The first byte after the header is the PCI byte (explained on the following page). It encodes the type of message, plus other information depending on the type of message.

                29-bit CAN follows the same format, except it has enough bits to include the source and destination addresses inside the header.

                Vitaliy
                OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
                Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!

                You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.

                Comment


                • #9
                  Thank-you!

                  Erm, for shame I hadn't looked at the datasheet - for some reason, I forgot that this information was in there.

                  Reading it again now!
                  Gary (-;
                  OBDGPSLogger, for logging OBDII and/or GPS data
                  OBDSim, an OBDII/ELM327 software simulator
                  mp3car forums: obdgpslogger, obdsim

                  Comment

                  Working...
                  X