Talk:On-board diagnostics

Clarification Needed

(I hope this is the correct procedure and place to put this.)

In the "Mode of operation" section these two statements are somewhat contradictory:

• Mode $04 is used to clear emission-related diagnostic information. This includes clearing the stored pending/confirmed DTCs and Freeze Frame data.

• Mode $0A lists emission-related "permanent" diagnostic trouble codes stored. As per CARB, any diagnostic trouble codes that is commanding MIL on and stored into non-volatile memory shall be logged as a permanent fault code.

"Permanent" needs clarification: Are Mode $0A fault codes permanent "permanent" or only temporary "permanent" until erased by Mode $04 commands? If permanent "permanent", what is their purpose and who is the target audience?

BTW - I tried to insert a Wikipedia link to the section using the "link" tool and pasting the original URL but kept getting "Page does not exist" ArtKocsis (talk) 04:32, 4 October 2012 (UTC)

Permanent DTCs cannot be manually cleared, and the NVRAM protects it from power (battery) loss. The DTC can only be cleared by the computer as it reevaluates drive cycles. Primarily, it prevents cheating on emissions tests, but it also benefits the (honest) consumer by providing positive confirmation when the problem is fixed, as the MIL will only turn off when the computer is satisfied. Without permanence, the code will usually be lost during repairs when the battery is disconnected so the consumer has no way to confirm that the problem is fixed; they can only drive enough to feel confident that it is. Ham Pastrami (talk) 01:00, 22 October 2022 (UTC)

ALDL History

Hi- I am having a difficult time identifying the problems with a recent edit of this page. I have tried to correct errors and improve the accuracy of the history shown. Please advise. W9kfb (talk) 17:00, 19 September 2022 (UTC)

The basic data you added looks fine (only gave it a quick glance, I used to do ECU development a few years back but ALDL is before my time). But the referencing format you used was totally messed up. Do you have online versions of those references that we double check or just paper copies?  Stepho  talk  22:22, 19 September 2022 (UTC)

Yes I have digital copies and paper copies of everything except the Project center XDE. If anyone can find a copy of that document, they will see that I signed it. I was a member of the Prject center back then as a digital systems engineer. I am 79 years old now so it was a long time ago, I retired from Delphi Automotive in 2001. I spent my last 11 years with GM as the executive responsible for the systems and software design groups at Delco Electronics in Kokomo, IN. I now reside in Denver CO area. ALDL was created at the prject center late in the 1981 program. Cadillac did not have it at the start of their 1980 program. It was even a late add to the GM corporate program for 1981.

more later...

2601:280:C600:7C30:D4F1:1598:B234:7ADD (talk) 12:13, 20 September 2022 (UTC)

I should clarify what I can send you to document my revisions, My biography, "Deco Electronics", I can send the entire book (digitally as. a PDF file) as published on Amazon/Kindle. This documents my eole as being responsible for the GM corporate ECM functions and features in 1981 and the ECM functions and features for the "Iron Duke" 4 cylinder, abd "Corvette Cross Fire" engines in 1982.I have a paper copy of the GM today magazine (8 pages) of which I can scan in and send. I have paper copies of my IEEE paper which I can also scan in. It is available from the IEEE on line. Also Have some document from the project center not previously referenced. I can scan and send.

W9kfb (talk) 12:37, 20 September 2022 (UTC)

I should also add that I wrote the first specifications for the 1884 GM corporate sequential fuel injection programs, in the middle of that program I was transferred to assist in the definition of the 1986 E/K body electronics programs (Cadillac, Buick, and Oldsmobile).

W9kfb (talk) 12:55, 20 September 2022 (UTC)

Please let me know if you reviewed and can read the three items I sent via email.

Thanks, W9kfb (talk) 13:11, 21 September 2022 (UTC)

Sounds like you're a man after my own heart (although higher up in the food chain than me). WP has had some problems with pretenders and bogus information, so we tend to overreact if we can't see sources/references for ourselves. We also disallow personal anecdotes because there are hard to verify. Which is why references that can be checked are such a big thing here. I'd love to read your biography. I'll send a PM to you and we'll work something out.  Stepho  talk 

Received your scans and placed them here: http://members.iinet.net.au/~stepho/RonaldCox/

Also bought your book but haven't read it yet: Amazon

So now the points mentioned can reference the scans or the book.  Stepho  talk  05:04, 22 September 2022 (UTC)

Please aslo see may edits to Vehicle emissions control... W9kfb (talk) 22:18, 29 September 2022 (UTC)

Standards: protocols, services, and readers

I feel that there is not enough clarity regarding what standards exist and how this affects consumer products for OBD. I am not a mechanic so my experiences are limited to my own vehicle and the research I've managed to do online, but I am not confident enough to try communicating these points in the article:

• Standard communication protocols. (CAN, KWP, GMLAN, etc.) These are widely supported, but don't specify how to actually request diagnostic information, only how to connect to the system. It's the "alphabet" of the system with no language attached to it.
• Services (PIDs). This is the actual "language" of the OBD and, as the article states, while (de facto) standards exist, conforming to them isn't required. While many, if not most OBDs adhere a great deal to the standard, there are also some that do not - GM seems to be particularly egregious with this as they reportedly ask for a princely sum of $50,000 to obtain their OBD specifications, compared to other manufacturers who charge between a few hundred and a few thousand (for mostly standards-compliant specs). While some basic GM functions like DTC handling meet the standard or are otherwise known, other functions such as sensor reading seem to be completely proprietary.
• Readers. Due to non-standard OBD specifications, many readers make a misleading claim that they are compatible with all modern vehicles (from 1996 or such). While they may be compatible on some level, i.e. protocol and some basic services, they rarely bother to support any non-standard functions. While the cost of the system may reflect the completeness of its implementation, it seems that only professional shop equipment actually supports a full range of functions across all manufacturers. These professional systems are far too costly for the average DIY mechanic to utilize at home. Even premium consumer devices cost hundreds of dollars do not seem to understand how to retrieve GM sensor data, for example. Some app-based devices have programmable interfaces so an expert user could try sending manual commands to the OBD, but even with a successful return, it still amounts to guesswork as there is no way to positively confirm that the data received is what the user expects it to represent, without having access to proprietary documentation. The devices themselves typically have proprietary interfaces and may or may not have sufficient documentation to guide user programming.

Ham Pastrami (talk) 00:07, 22 October 2022 (UTC)

For newish cars, they all use the OBD-II protocol across CAN. CAN is standardised but only specifies how to send a packet across the wire - the contents of the packet is not covered by CAN. OBD-II covers the contents of the packet.

OBD-II covers a wide range of functions. But manufacturers often extend them beyond this. Eg, GM might include many more error codes than the standard. A cheap tool will display each and every one of the messages but will only decode the standard ones into nice human readable text (eg injector line #2 shorted to ground)- the custom codes are displayed simply as a code and you have to do web searching to understand it. The expensive tools (which paid a massive fee to the manufacturers) can also decode the custom codes and display them in nice human readable format. It's the nature of commerce - users and the government want standardised information freely available while manufacturers want trade secrets.  Stepho  talk  00:58, 22 October 2022 (UTC)

Contradiction

> To use OBD2 software, one needs to have a Bluetooth or WIFI OBD2 adapter plugged in the OBD2 port...

USB adapters are widely avaiable, as the very next paragraph mentions.

John G Hasler (talk) 00:05, 25 December 2022 (UTC)

Fair point. I changed this to "To use OBD2 software, one needs to have an OBD2 adapter (commonly using Bluetooth, Wi-Fi or USB)". Personally, I make heavy use USB-CAN adaptors (for use with a PC) and/or embedded microcontrollers with built-in CAN support (for monitoring devices).  Stepho  talk  01:25, 25 December 2022 (UTC)

Links to similar systems

is there a similar system in airplanes or farming or construction vehicles? Which standards? Can somebody please link? — Preceding unsigned comment added by 160.46.252.70 (talk • contribs)

I can't speak about planes but a lot of heavy machinery from the US uses SAE J1939, which is about 90% identical to ODB-II. The manufactureres often extend it in proprietary ways (see below).

Machinery from European companies tends to use CANopen.

For older and/or specialised machinery there are proprietary protocols. The manufacturers tend to hold these as close guarded intellectual property, charge a huge amount of money for the documentation and crack down hard on reverse engineering.  Stepho  talk  09:22, 27 July 2023 (UTC)