Permanent DTCs are stored in mode 10 (ten) - MYTH
I have been hearing and reading this a lot lately. So much so I decided to make a myth post about it. The source is aftermarket training. I see it in books, online and in youtube training videos. Here's something I wrote to address the issue and explain hex and why we use it. But first, sing the alphabet song to yourself and then answer the question; did you start singing "A B C D E F G..." or did you start singing "Ten B C D E F G...." I thought so.:)
OBD language, HEX, Decimal, ASCII, Binary.
1 bit has two possible states, on/off, high/low or written as 0/1.
A group of 4 bits (nibble) represents 16 possible combinations:
The order is as written, left to right then top to bottom. Think of it like an odometer where the LSB increments from 0 to 1 then 0 but pushes the next bit to 1 etc.
As more bits are strung together it gets too complicated to write so we group 8 bits together to form a byte and that can be written in a hexadecimal format. 2 nibbles (1 byte) can now be written as 2 hex digits.
Hex represents 16 possible states starting with 0. Since we must use a single digit to represent those 16 states we can’t use “10” after “9”. In hex, we use “A” after “9” and continue to “F” so the 16 states are: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F which represent the 16 digits.
The next group is a byte that is 2 nibbles or 16 X 16 = 256 bits. How do we write 256 possible combinations?
After “F” we then can go to 2 digits by putting a “1” in front of each of the 16 digits so it becomes 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F and then repeats with a 2 in front etc, etc, etc. The right digit is bits 0 – 3 and the left digit is bits 4 – 7 of an 8 bit byte.
For OBD we use 8 bits (1 byte) and represent that with a 2 digit hex number. To denote that as hex a “$” is generally used preceding the hex, for example; $0A or $10.
$0A and $10 represent 2 totally different bytes. Can you see that?
$0A = …
$10 = …
We could convert hex to decimal and $0A is decimal 10 but $10 is decimal 16. Why not convert to ASCII?
I don’t think that makes much sense and neither does calling $0A “10” or the word “ten”.
In OBD we have what are called service modes. ISO/SAE reserves $00 - $0F for the generic side of the scan tool and service mode $0A is for permanent DTCs. $10 and up is used for Unified Diagnostic System (UDS) which is now used by all manufactures and since $10 is within the UDS structure, it too is defined within UDS so saying service mode 10 and associating that with permanent DTCs just doesn’t work. An engineer will associate service mode 10 to UDS. For more UDS information, see ISO 14229-1.
Finally, how do you say the J2012 DTC "P0AEF"? I hope no one said "P zero ten fourteen fifteen" :)
Good Morning Randy,
Could you please post more info on the UDS? ISO 14229-1.?
I don’t have the background to do UDS justice. It’s much more complex than the legislative side of OBD Which is what I primarily work with. For instance, I could simply state mode $03 if for stored DTCs and mode $04 is for DTC clear on the legislated side (generic) whereas $19 is for DTCs and $14 is for DTC clear on the enhanced or UDS side. However, that leaves out a lot and when you get deeper into UDS you see how much more complex it is.
I am sure there are more qualified individuals on here that can answer UDS questions better than me.
From a programming standpoint you are absolutely right. The whole reason for calling it mode 10 is because we as humans have been extensively trained to think in decimal, not hex. From a scientific standpoint it is logical and correct to call it mode $0A, but from a human, common person standpoint it more familiar to call it mode 10, just as mode $10 would likewise be commonly referred to as mode 16, or mode $16 would be referred to as mode 22.
Right, where does it start and stop? That's what confuses me when I have a technician call me up and in the course of the conversation he starts talking mode "ten".
UDS is coming to the legislated side of OBD. What will the training industry do when that happens? The real mode $10 is an important service mode.
J1979 Service modes are all invoked using a one-byte identifier. That identifier is a hex value so $0A comes after $09. When we had to create a Service ID in J1979 for permanent DTCs, $0A was simply the next available number. If we have to add another service mode to J1979, it will be $0B which is the next number after $0A. I agree that most people don't think in hex and we worried about that when we expanded J2012 DTC definitions to include hex values (per your P0AEF example). Hopefully people will be exposed to that info over time.
Also, the CAN messages with the actual Service ID is not normally visible to the service technician. The scan tool handles all of that. The service tech usually sees some text that describes the service, not the actual SID. You would know about SIDs if you looked at SAE standards, but most service techs don't (and don't need to). It's easy to understand why there is a lot of misunderstanding about SIDs and what they mean.
Here is a list of services that Ford gasoline PCMs normally support. I'm not sure how a scan tool labels them.
Service, Message Description $01 Request Current Powertrain Diagnostic Data $02 Request Powertrain Freeze Frame Data $03 Request Emission Related Confirmed DTCs $04 Clear/Reset Emission Related Diagnostic Information $06 Request On-Board monitoring Test Results $07 Request Emission Related Pending DTCs $08 Request Control of On-Board System $09 Request Vehicle Information $0A Request Emission Related Permanent DTCs $10 DiagnosticSessionControl $11 ECUReset $14 ClearDiagnosticInformation $19 ReadDTCInformation $22 ReadDataByIdentifier $23 ReadMemoryByAddress $24 ReadScalingDataByIdentifer $27 SecurityAccess $2A ReadDataByPeriodicIdentifier $2C DynamicallyDefineDataIdentifier $2E WriteDataByIdentifier $2F InputOutputControlByIdentifier $31 RoutineControl $34 RequestDownload $35 RequestUpload $36 TransferData $37 TransferExit$3D WriteMemoryByAddress $3E TesterPresent $85 ControlDTCSetting
The issue with not understanding all this is the confusion it can create in I M programs. We already have issues with manufactures storing DTCs in the wrong mode, not clearing correctly, or even MIL commands set to on with no DTCs. Technicians don’t seem to understand how all this is supposed to work let alone when it doesn’t. Changing terminology doesn’t help, it hurts. I remember the conversations you, Mike and I had many years ago about what to do with J2012 and if you remember, I totally supported using the hex values. I still think that was the correct decision.
Sticking with DTCs, it is important to know what mode the DTCs came from or more accurately, what service mode the scan tool requested. We have 4 main possibilities; $03, $07, $0A and $19. Typically (soon to change in some states) only mode $03 will command the MiL and cause an I M failure but technicians will not always distinguish between the modes and attempt repairs that don’t address the failure. Most common is the $19 option which, as you know, can have sub functions And as I understand the direction of legislated OBD, $19 will be involved in emissions DTCs but that has not been decided. Some manufactures have DTCs in mode $19 that suspend monitors but don’t command the MIL.
If (when) UDS does come to legislated OBD, UDS sid hex value will play a part in how we both fail vehicles and diagnose them.
Thanks again for your input.
Sir, this is a rather useless gripe, that you have called a "myth" here. How do YOU pronounce Hexidecimal A, if not "ten" ? I have been familiar with the idea of hex since the 80's, but have never heard of new names for the numbers.
When the concept of different base numbers is taught in schools we still use the same English language. So it is, and will be pronounced "ten" and is certainly not a myth.
Having sat in training when the "Mode $10" was first being showed as coming soon, the rumor mill was flying as it was being discussed, it was often referred to as mode $10, so many refer to it as such. As John Bridgewater stated: it is human nature to follow thru in decimal format mentally when the reality is hexadecimal. Since the final rulings and specifications came after many people 1st heard about it and were even prematurely taught about permanent codes, I suspect that is why the mode$10 has really stuck as the accepted term. In my mind this is similar to the difference in terminology when referring to tools in the industry. Example: Amp probe, Current Probe, Amp clamp.... etc..etc.. I definitely see you point of view from a technical accuracy stand point as far as it being $0A, but let us all be glad that more guys are aware of what permanent codes are and how they work, vs using the correct terminology. Good information and well written and I appreciate you wanting to get techs on the same page, and not have the incorrect terminology later in the technology shift. Later in life it will definitely cause U1000 issues between folks in the industry. Hope my POV maybe helps, but I firmly believe the incorrect $10 originates from the early learning of the service mode $0A that was officially named so. Carry On Randy
I went back and dug up an old presentation and class from my hard drive dated 9/2008 and 12/2008 respectively that Jim and I did on mode $0A. I read the handout and I wouldn’t change a word 10 years later. Permanent DTCs were first required in the 2010 model year (phase in) and we used a 2009 Toyota Venza for screen shots because that was the first Toyota that supported mode $0A.
My point, why is it being taught wrong and why is there so much confusion on what it is? It is not difficult at all unless you confuse the subject with random ideas not based on regulations and standards which many have done. Technicians need to understand how it is supposed to work and then they will be able to deal with those few manufactures that did not implement $0A correctly (yes, they exist).
Don‘t even get me started on the difference between a monitor and a readiness flag, that really gets me going. 😀
So, a little background may be in order. OBD-related Electronic Control Units (ECUs) are what are called “embedded controllers” which have no human usable interface method (keyboard/mouse/display). They use a more dedicated microcontroller as opposed to those used in Personal Computers. Embedded controllers have traditionally been designed and implemented by specialized hardware/software engineers. For many years, these microcontrollers were programmed in “assembly language” or “machine code” instructions in the interest of memory space-savings and speed of operation. These early systems and microcontrollers were (and still are) based on the binary number system as Randy pointed out. This was cumbersome and microcontroller designs were based on an 8-bit register set, which then lent itself to use of the base 16 or hexadecimal (hex) number system as Randy described. At that time there were a number of different ways to indicate a hex number as opposed to a decimal number. SAE and ISO settled on a mix of two different styles – one using the dollar sign ($) prefix and the other using “0x” prefix (i.e. $1A, 0x1A). ISO has since, especially in 14229, moved to the “base 16 post subscript” (i.e. 1A16). So, any time you see a “Service $A” or a “Service 0x10” or a “Service 1916” then you know that these are hex values. We tend to leave the decimal values alone. Sorry that the 16 subscript did not transfer well to this medium.
Now, to the question of what to call them. Since I was around in the early days of microcontrollers (long before the ‘80’s) and embedded systems, it just seemed natural to go ahead and call them by the normal nomenclature. So, we make no distinction between “10” and $10” as we knew by the prefix (or lack thereof) that it was decimal or hex “ten.” Therefore, to Geoff’s question, we called it “Aye” because it is denoted by the letter “A.” Otherwise, what would you call $1A, as Randy asked – “one-ten” – I think not? We call it “one-Aye” because that’s what it looks like. Unfortunately, in the brave new world, embedded controls still live in “hexadecimal land” and technicians are not naturally taught this language. I agree with Justin that the misidentification of Mode $10 as Mode $0A is a big part of the problem. There are two reasons behind this:
First – Again, the use of the “$.” This indicates to the embedded world that those both are hex values and are different, just like the decimal values 10 and 5 are different. If there was no $ in front of the 10, then I might see where these could be construed as the same. If one indiscriminately is using the “$” because that’s how they see all of the documentation written, this just exacerbates the problem, leading to:
Second – Since the whole system is now predicated on the base 16 numbering system, no one should use decimal numbers in their communication of such information.
Lastly, Paul makes a good point, scan tools are generally designed to make the conversion for us so that we do not worry about such items. SAE J1978 provides guidance to scan tool manufacturers in this regard. I could go on about how P,B,C,U do not exist inside of an ECU’s DTC land, but that would be another complete discussion.
So, originally, Bob Augustine asked that I add some about UDS Services here, as a member of ISO WG2. However, I felt the need to preface this discussion with the above background. So, onward…
Unified Diagnostic Services (UDS) are defined in the ISO 14229-1 document the same way that Legislated OBD Services are in J1979. In an agreement between ISO and SAE, the Legislated OBD Services were given a reserved space of 15 (decimal) or $0F (hex) Services. Always remember, we are living in a hexadecimal world here. As Paul mentioned, when we got to Service $09, and needed to open another, $0A was next, just as decimal 3 comes next after decimal 2. When we need to open more, we’ll go to $0B, then $0C and so on.
UDS is also known as Enhanced Diagnostics. Not all OEMs currently use UDS, but the trend is for all to be on board by the time CARB decides to pull UDS into the Legislated OBD realm. It consists of the rest of the one-byte space available for Services, that is from $10 to $FF (maximum value for a byte). I will say up front that just as J1979 is the intellectual property of SAE and cannot be reproduced, ISO 14229-1 is the intellectual property of ISO. Therefore, I can only provide a rough overview of what is available.
UDS Services are divided into functional units:
Diagnostic and communication management
Stored Data transmission
There are roughly two dozen services available in UDS. Just a final note, Service $10 is the start of the UDS service space and is the diagnostic session controller for the rest of the services. I hope this helps some.
Awesome, enjoying this thread.
Bob, when you say " as a member of ISO WG2. " is this International Standards Organisation Work Group 2"?
yes - the "longname" is - TC22/SC31/WG2, Technical Committee 22/Steering Committee 31/Working Group 2 Road Vehicles - Vehicle Diagnostic Protocols. If anyone is interested, the ISO document can be purchased in the US through ANSI.
Nothing like having the big guns in here to support me. 😀
The only item I will bring to your and Paul’s attention is that scan tools do not label modes and pids the same and sometimes they label them incorrectly. So much so I just use the hex to describe what I need from someone. Mode $01 PID $41 is one, Mode $01 PID $1C is another and I use those quite often. So relying on the scan tool to tell me what it is doing is not a good thing. I prefer the hex and not the descriptors.
I do have a K-line issue I am dealing with, I have been meaning to contact you. Just made your day, didn’t I.😀 I have some ecu’s sitting behind immobilizer modules that take to long to communicate but only with a certain interface and even though I have read all your publications on K-line and the J document on known k-line issues, I can’t see what is different between tools other than the order of the protocol request. One requests fast init first and waits the required 2.6 seconds before requesting 9141-2 and it works every time. The one that doesn’t requests 9141-2 first and the only way to see the ecu is to wait several minutes with the engine running and then request it. But, that’s not the issue, something else is. I will send you an email unless you have seen this before and can give me a clue on where to look.
Thanks for posting!
So not a "useless gripe" then. Thanks for the info Randy, I shall go forth and educate the masses.....
Yes, unfortunately, scan tools have not been as well regulated as vehicles, as CARB has always stuck to their guns about only regulating the "point of emissions." SAE does have documents to "help" scan tool manufacturers do a better job:
J1978 - roughly equivalent to J1979 and J1699-2 - equivalent to J1699-3.
As you know, some of my I/M investigations have uncovered several tool anomalies, some of which are listed in J1699-4 and my Clearinghouse White Paper that you noted. At the SAE E/E Diagnostic Committee yesterday, I appointed a new chair for J1978 and will open the document for revision in the first quarter of 2019 for updates related to the new data requirements given in J1979.
Regarding your K-line issue, yah - go ahead and email me or call me when you get a chance.
G'day Bob, how can I obtain copies of these SAE documents:
J1978 - roughly equivalent to J1979 and J1699-2 - equivalent to J1699-3. ?
Thanks in advance
Oh, and the ISO doc: