No announcement yet.

SAE J2178 is it being used at all?

  • Filter
  • Time
  • Show
Clear All
new posts

  • SAE J2178 is it being used at all?


    I've SAE J2178 document (all four parts). Second part is listing the PID's
    diagnostic (OBD2) and extended set. They are defining the things like odometer, engine oil level, etc... in the ext. set, but once i try to get this info from the vehicle it seems, that most of the things above 0x00FF is not implemented. The vehicles i've used for the testing is MB Sprinter and Ford Focus both vehicles are built in 2009. So my question would be - are manufacturers implementing this protocol, or is there something else i should be looking for as i'm interested in more than OBD2 set. I need such PID's as Odometer, Engine coolant level, Engine oil level, etc.

    Any ideas?

  • #2
    SAE J2178 is used but for heavy trucks (Daf, Mann etc.).
    You need SAE J1979, but I doubt you will find the Odometer or the Engine coolant level there. Logically as most engines do not have a sensor that measures this.
    A brief description of what has been changed to J1979:
    Some of the pids:


    • #3
      Hi p2psmurf,

      Thanks for the answer. As far as i know SAE J1979 is the OB2 protocol spec.
      Where i am sure i wont be able to get such information as odometer or coolant level. So i should be looking for something else... You can see in the wiki OBD2 that they have an extended diagnostics (which is using 2 bytes for PID, not one as OBD2 does) is there any document then to describe those PID's? or it is strictly manufacturer specific? I had hands on Mercedes using their stardiag tool - i've hooked a can analyzer just to see the CAN traffic and surprisingly - all things were query / response based.
      So are they using their own proprietary protocol for that, or it is some kind of document which can be purchased from SEA/ISO to know those PID's? What about J1939?

      Thanks, and sorry for such long post.


      • #4
        Are you confusing mode-PID with a 2 byte PID? J1979 reserves modes 0x01-0x0A for generic definition by J1979. Theoretically each mode could have PIDs 0x00-0xFF. Any mode beyond 0x0A is left up to OEM discretion. I have seen OEM specific modes have 2 byte PIDs, but there arent any in J1979. J1939 is for heavy truck CAN. The two cars you mentioned are light duty vehicles and will use J1979 mode-PIDs. How many of those PIDs are supported is up to the manufacturer to a certain degree. OBD II is based on a request receive setup. So it makes sense that would be what your CAN analyzer showed you.

        To sum it up. If you want information pertaining to what you can gather from the two vehicles mentioned, you want J1979. The wiki does not show all of J1979 only a small portion. As you mentioned, you want additional information not laid out in J1979. You will need to get your hands on OEM specific info.


        • #5
          Valdas, officially these cars are not OBD2 compliant, but rather EOBD compliant.
          EOBD is the European version and based on ISO documents.
          However, the ISO and SAE documents are 99.99% equal and the ISO ones cost 2 to 3 times as much. That's why is said you need SAE J1979.
          The difference between OBD2 and EOBD is the allowed can baudrates.
          OBD2 only allows 500k, where EOBD allows both 250k and 500k.

          Any description of the Mercedes proprietary protocol you will have to get from Mercedes.
          I wish you all the luck in getting them. I don't think anybody will supply them.


          • #6
            Thanks for the help, i really appreciate this guys. So the only proper way for me currently to get this information would be to dig in OEM specific buses without any specifications... just a reverse engineering? Aberk - i am not confusing mode-PID with the actual PID. I got an answer for my previous question as far as i understand it correctly - you meant, that whats being defined after the mode 0x0A - there's no standard documentation for that as all the modes after it is OEM specific. Is that what you meant? In this case from my researches it would be clear that lets say Merc uses mode 21 for their proprietary diagnostics. The only thing which is still unclear - i why the diag tool is using CAN frame ID's different from OBD2. As i've seen OBD2 query's are being sent on ID 0x07DF - which is not a case in Mercedes diag tool.
            p2psmurf - you're right i'm in Europe, and they have renamed OBD2 here to EOBD, which is anyway almost identical.
            Just one more quick question: i had a looka at j2190 - which actually should be the same thing i am looking for i believe, but SAE are saying that this document has been canceled. Does that mean that i can not rely on it anymore? And will it bring any use for me at all.

            Thank you.


            • #7
              Yes, reverse engineering or becoming really good friends with some one on the inside is the only way.

              Yes, you are correct about modes above 0x0A

              0x7DF is known a as a functional address and is standardized address for OBDII CAN. It will return the data queried from all supporting modules. That is if you ask for Speed using 0x7DF you may get Speed back from the engine controller, transmission controller and/or the ESP controller. The Mercedes tool is using what is known as physical addressing which will target specific data from a specific module. In my personal experience the primary engine controller usually responds to a physical address of 0x7E0. If I send a Speed request to 0x7E0 I will only get a response from the engine controller, even if other modules support the information I requested. The engine controller does not have to have a physical address of 0x7E0.


              • #8
                Why are the Can ID's different from EOBD/OBD2?
                First answer would be that when using proprietary diagnostics you only want 1 (one) ecu to answer, not all the EOBD compliant ones (could be several for engine plus the gearbox). All EOBD compliant ecu's listen to address 0x7DF, but only the engine (or engine controller 1) listens to address 0x7E0 (assuming 0x7E0 is the actual address).
                Second answer could be that controllers listening to 0x7DF will not recognize any modes other than the EOBD modes, i.e. 01 through 0A, so a mode 21 request would result in a Negative acknowledge.

                If you want things like odometer, coolant level, etc. you will have to reverse engineer it yourself, assuming that the factory scanner has these parameters. If the factory scanner does not show the coolant level (from whatever source, probably instruments) then that's it. If the vehicle does not have a sensor that measure's it, than you can't display it.


                • #9
                  Well, the cars i am targeting to are quite new 2008-2009, so i believe i should not face problems with the absence of the sensor for one or another PID and especially that i am not looking for anything miraculous. I have a tool for Mercedes. So now i need to get one for Ford. I am currently looking at DrewTech's CarDAQ-DV maybe anyone of you guys have had experience with it ( Will it be able to do the task i need. As they are stating that they can sell additionally ford enhanced PID's:

                  or maybe you have any other suggestions.

                  Thanks once again


                  • #10
                    I have heard that J2190 was a 'recommended practices' document - not a real standard. I would also be interested in knowing if anyone else has used PID's from J2190 and gotten results for Odometer, oil pressure, etc?


                    • #11
                      Please - if anybody had experience using those tools, could it be shared? Or maybe i should create a different topic for this? As this question is totally out of the scope of this topic?