Talk:OBD-II PIDs

PID $23

PID $23 is not limited to diesel engines, any engine where the fuel rail pressure is greater than that allowed by PID $22 may use it, gasoline direct injection for instance. Manufactures are required to report on one of the 3 fuel rail pressure PIDs PIDs $0A $22 or $23 if a fuel rail pressure sensor is fitted to their vehicles.

Rich and Lean fuel trims were switched. A negative fuel trim means the initially calculated fuel amount is too much (Rich) to achieve the desired Air/Fuel Ratio (14.7:1 under most driving conditions), and the ecm has to remove (hence the negative) a percentage from the calculated fuel amount. 68.84.176.20 06:15, 5 May 2007 (UTC)

Doubts

I also have some doubts on the PID=0x23 line that is marked with "?". Some sources state that the return will be packed in 2 bytes. Some sources sugest a convertion factor of 10 to achieve a result in kPa.

• http://groups.yahoo.com/group/opendiag/message/4888?viscount=100

• http://www.obd-2.de/tech_prog.html

Merger proposal

The Table of OBD-II Codes seems that it should merged into this article because there is more information here. — CZmarlin (talk) 04:21, 2 January 2008 (UTC)

-- Agreed! Davide Andrea (talk) —Preceding comment was added at 17:59, 6 January 2008 (UTC)

-- Comment The OBD-II codes themselves are property of the Society of Automotive Engineers. 64.26.98.90 (talk) 17:09, 19 January 2008 (UTC)

-- Done. Davide Andrea (talk) 20:53, 29 February 2008 (UTC)

Adding more PIDs, and Mode 22 PIDs?

This article is great, and I just added two new PIDs from the range 0x50-0x60. I'll go through my notes and add more mode 1 PIDs over the next few days.

However, I also would like to add mode 22 PIds from SAE J/2190. Those are vendor specific; and there's issues about addressing those and prioritizing those messages on the OBD bus. What is the right answer for these? I'll put the PIDs in as they are, but presumably more information on this addressing belongs in a separate article on PWM/CAN modulation etc...?

63.107.91.99 (talk) 14:58, 7 November 2008 (UTC)

PIDs Copyright

• Looks like the table of PID codes has been deleted. Is this information not accessible publicly? I'm really interested in the legality of having such information on Wikipedia. And shouldn't there be some sort of discussion before it's just up and removed? --Tripzero (talk) 19:59, 27 July 2009 (UTC)

• This was already discussed back in 2008, and it was decided to keep the page rather than remove it. Why was this decision ignored and the page deleted anyway?64.9.88.210 (talk) 20:05, 27 July 2009 (UTC)

• I'm reverting the page back to before the table was deleted pending further discussion on it's removal. --Tripzero (talk) 20:17, 27 July 2009 (UTC)

• This information is not publicly available, and if it is, then its in violation of international copyright law. Have you read the ISO documents on the SAE and ISO websites, they are fully complete and accurate. What you are posting here is bits and pieces from those documents in an incomplete and copied fashion. Incomplete and inaccurate information will result in an increase of the cost of Vehicle ownership to society as a whole. Scantools are already very cheap, as low as $10USD, and free software are available, that already used the FULL SAE and ISO documents to develop the free software. What is the purpose of this wiki? so that home hobbyists can do something that can already be done by 1000s of aftermarket companies using the FULL SAE and ISO documentation? Perhaps you need to find some backyard hobbyiest forum to post your so-called new found information. —Preceding unsigned comment added by 60.234.226.126 (talk) 07:53, 28 July 2009 (UTC)

• Wouldn't this fall under "fair-use"? The copywritten materials are not being copied here - only the knowledge, which can't be copywritten. The remark about "increase cost of Vehicle ownership" is absurd. That's like saying we should charge for the instructions to newly purchased electronics because if the consumer wants them they should have to pay. I am a "backyard hobbyist" trying to develop something that would actually add significant value to vehicles by using this information which is quite contrary to what you are imagining. —Preceding unsigned comment added by 71.59.106.104 (talk) 18:12, 28 July 2009 (UTC)

• It is clear that the information here is not in copyright violation. It exists in the SAE and ISO documents in completely different form. I suggest putting a note in there that describes that this information may not be correct and then refer by direct link to the SAE/ISO documents (not just link to their homepage). --Tripzero (talk) 19:09, 4 August 2009 (UTC)

• I am an automotive engineer AND a "backyard hobbyist" [sic]. I also have all the SAE documents and, if you have ever seen them, this format is much easier to follow. The guy above is quite simply wrong...this information may not be as full as that found in the the SAE docs, but it is correct and much more well explained than most documents you can locate easily. Finally, you're accessing information that *your* vehicle is making available to you to aid in diagnosis and, for the most part, emissions monitoring...the more people that monitor this and keep their car's pollution levels minimized the better. Anyway, monitoring scan codes via software is no different than the old method of turning the key on and off a few times with shorted pins and counting the flashing MIL. For what it's worth, if you're smart enough to build a J1850 compliant interface and build a scanner using this information, you're smarter than most of the automotive professionals I deal with. Information like this is a valuable addition to Wikipedia. —Preceding unsigned comment added by Quiller69 (talk • contribs) 13:29, 13 September 2010 (UTC)

Adding non-standard/Vendor-specific PIDs?

• Would adding vendor-specific codes to this page pose a copyright problem (Obtained by deciphering and relating messages by hand, without any official vendor-material)? --ND90 (talk) 10:15, 21 May 2011 (UTC)

kb, bits, Kilobits, baud and Baudot

The article needs standardization on data rates and abbreviations for such;

b/sec is bit rate per second. kb or kb/sec is bit rate in thousands of bits per second. B and kB are symbols for Bytes and KiloBytes. These Bytes typically contain 8 or 9 bits each and are used often when discussing "storage" of data, not serial transport as we discuss here.

"baud" is a way of expressing the speed of serial data in symbols per second. The term gives credit to a pioneer in serial data, Emiel Baudot, but the baud term is all lower case. In a given serial data line, bit rate is always higher than baud rate. For example, in a 64QAM modem, M=64, and so the bit rate is N=6 times the baud rate. It is common for authors who are unfamiliar with "baud" to mistakenly substitute the term in place of "bits per second". — Preceding unsigned comment added by 71.252.233.46 (talk) 23:53, 23 November 2011 (UTC)

Mode 3 Description

The description of Mode 3 DTC parameter data seems to be specific to CAN-bus OBD-II ECUs. Older, pre-2003 OBD-II ECUs (i.e., J1850 VPW/PWM, ISO 9142-2 and Keyword 2000) pack DTC data into multiple OBD-II response packets somewhat differently. --Bruce D. Lightner (talk) 17:00, 14 December 2011 (UTC)

PID $32

It's strange that this is the only magnitude signed, if it is, I guess formula shoud be a "(AB)/4 (being AB a 16bit signed value)" which is not the same than "((A*256)+B)/4 (A is signed)" J VEP (talk) 19:13, 27 August 2012 (UTC)

Actually, when you add an unsigned 8-bit value of the second half to the signed first half multiplied by 256, you get the correct 16-bit 2's complement value. Therefore given a function—signed(a)—that tells a calculator to take these 8-bits as 2's complement, the following expression results in a signed 16-bit value: signed(A)×256 + B

It would be easier, I agree, if OBD software makers were more widely able to take in two bytes directly as a 16-bit number. Vickas54 (talk) 00:52, 17 March 2016 (UTC)

Beware that you are answering a question from 8 years ago.

The standards are expressed in terms of bytes because there is no universal standard on how to send 16-bits across a serial link. Some vendors send the upper 8-bits first and some send the lower 8-bits first - see byte order. By expressing it in terms of bytes A and B they can specify that A represents always the higher order byte, even on CPUs that use the opposite convention. This is a common problem for computer data communications and also a common solution.  Stepho  talk  03:49, 3 January 2021 (UTC)

There must be a better way than writing (256*A+B)/4 (AB is two's complement signed). What exactly is A and B if AB is signed? I would like to reference the page to people who are not "versed in programming", but know how to use an online unsigned←→signed calculator. As I understand, the intention of 256*A+B is to specify the byte order without using big words like Big Endian. How about signed16(256*A+B)/4 where signed16(n) is two's complement signed of 16-bit integer n? Levchenca (talk) 17:54, 6 September 2021 (UTC)

The typical way is to calculate 256*A+B as though it was unsigned and then assign it into a signed 16-bit variable. 2's complement arithmetic will do the unsigned to signed conversion automatically - both forms have the same bit-pattern in memory. If you can't declare the number of bits or signed/unsigned (typical of many scripting languages) then you do (256*A)+B as unsigned, then subtract 65536 (2¹⁶) if the answer is greater than 32767 (2¹⁵-1). Do the final divide by 4 after the unsigned/signed conversion.  Stepho  talk  13:45, 8 September 2021 (UTC)

References

"Modes"

ISO 15031-5:2006 refers to "services" rather than modes. — Preceding unsigned comment added by 116.90.136.74 (talk) 02:59, 19 December 2012 (UTC)

PID A6/166 Odometer

The calculation leads to 252645135 when I assume 15 (max) for all values and not 526 385 151.9 hm (km/10) — Preceding unsigned comment added by Ride4sun (talk • contribs) 17:03, 29 December 2020 (UTC)

4 bytes representing an unsigned 32-bit number goes from 0 to 4294967295. Since each value counts 0.1 metres, that means the max distance is 429496729.5 metres. I have no idea where that old value came from but it is clearly wrong. I have fixed the article.  Stepho  talk  03:42, 3 January 2021 (UTC)

S-01 PID-02

Service 1 PID 2 needs clarifying. The description of "Freeze DTC" with no units or formula leaves me confused about it's meaning. Is it a count of the number of DTCs for which there is a 'freeze frame' of associated data? DiscreetParrot (talk) 00:47, 21 March 2023 (UTC)

When a DTC is raised by the ECU it stores a freeze frame of data (eg rpm). This is often helpful when trying to figure out what caused the problem (eg maybe it raises a DTC for misfire but only when rpm is higher than 5000, which indicates maybe a weak coil). "Freeze DTC" merely indicates which DTC triggered the freeze frame data to be stored. This is explained in OBD-II_PIDs#Service_02_-_Show_freeze_frame_data. Maybe we can change the terse "Freeze DTC" to "DTC that triggered the freeze frame".  Stepho  talk  03:13, 21 March 2023 (UTC)

Ah, that makes perfect sense, thank you so much for explaining it. --DiscreetParrot (talk) 19:56, 21 March 2023 (UTC)

S-01 PID-5F

Service 1 PID 5F is described as bit encoded, but we're lacking an explanation of what the bits map to. DiscreetParrot (talk) 00:52, 21 March 2023 (UTC)

S-01 PID-7C

This is listed as being 9 bytes, yet it's described as a single temperature value and the formula only uses two bytes, which seems odd. DiscreetParrot (talk) 00:55, 21 March 2023 (UTC)