More PIDs for Torque App

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
in addition to the existing info on "tested vehicle", would be an example of an actual vehicle reply, preferably with OBD message headers previously enabled

Do you happen to have such a recorded example of that 12C5 PID response from an actual vehicle or PCM?
 

azswiss

Member
May 23, 2021
924
Tempe, AZ
I don't expect you or anyone else to change existing spreadsheet entries, but one thing that would be useful (for future entries) for those "unknown" PIDs, in addition to the existing info on "tested vehicle", would be an example of an actual vehicle reply, preferably with OBD message headers previously enabled ("ATH1" command to scantool). That makes it easy to see, for example, how big the PID reply is (in bytes), which can help someone trying to decipher possible PID meanings.
Vehicle response from '03 Suburban added in for all "Unknown" PIDs.
 

Attachments

  • PCM PIDScan2.xlsx
    45.8 KB · Views: 13
  • Like
Reactions: AmpOverload

AmpOverload

Member
Jul 10, 2023
121
USA
Do you happen to have such a recorded example of that 12C5 PID response from an actual vehicle or PCM?
Yes, indeed. (Sorry for not thinking to have included it earlier.) This is the raw traffic to/from a 2004 Buick Century (P04 PCM):
Code:
Command: 2212C5011
  Reply: 6C F1 10 62 12 C5 0A C8 65
When using "(A*256+B)/51" (essentially "(A*256+B)/(255/5)") as the formula, it decodes to 54.12%.

The same datapoint (fuel level) query, when done with functional addressing, yielded:
Code:
Command: ATSH 89 82 F1
  Reply: OK
Command: 12
  Reply: A8 83 10 12 89 ED
As you're undoubtedly already aware, that's an SAE-standard Primary/Secondary ID ($82/$12) that decodes using A*100/255. For my example above (A=$89), it's 53.73%.

I have many more examples, if needed.

BTW, thanks for the URL to Torque's equation "language". It turns out that I've downloaded it in the past, but since I don't use Torque Pro, I'm not that savvy on their formula language. But I will try my best to use it in this thread especially.
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
When using "(A*256+B)/51" (essentially "(A*256+B)/(255/5)") as the formula, it decodes to 54.12%.

Using 2 bytes for what is essentially a 0 to 5 volt range from the sensor is an absurd level of resolution I have never before seen!

Where 0xAC8 = about 54% were are looking at each bit representing less than a millivolt.

It just seems off.
 

AmpOverload

Member
Jul 10, 2023
121
USA
Using 2 bytes for what is essentially a 0 to 5 volt range from the sensor is an absurd level of resolution I have never before seen!

Where 0xAC8 = about 54% were are looking at each bit representing less than a millivolt.

It just seems off.
I agree. In fact, it's even worse than that if my other information about this vehicle is correct. The PCM (ignoring error checking) supposedly only uses a range of 0.8 volts (empty tank) to 2.5 volts (full tank) from that sensor, making the use of a 2-byte PID even more of a head-scratcher. :confused:

But I'm just reporting what the vehicle says (over the course of several years now) and it returns 2 bytes for PCM Mode $22 PID $12C5. I considered the possibility that only the upper byte ("A") is relevant, but that didn't make much sense when I looked at values and considered the formula needed to make it match the functionally addressed command's result (which should be taken as "canonical" since it's an SAE-standard query with SAE-standard formula).

For the moment, I'm mostly curious if that equation in the spreadsheet for PID $12C5 really works correctly on any GM vehicle. Can you possibly confirm (or reject) that idea from your recorded data?
 
Last edited:

AmpOverload

Member
Jul 10, 2023
121
USA
I've been looking over Rev 4A of the "GMT PIDs" spreadsheet, specifically on the "PIDs" tab...
[...]
Row 250 identifies the PID as "Fuel Tank Level% -F". (BTW, what does the "-F" suffix mean on those names in column "B"?)
Quoting myself above... Looking through some old websites for something unrelated, I stumbled across the answer to my own question, on post #6 on this thread.
GaryDoug said:
In fact, I have added a "-F" (for F-Series cars) to the end of each name in order to avoid confusion with the limited GM set provided in the app. Also added is a "6" for V6 and an "8" for V8 following the "-F".
 

AmpOverload

Member
Jul 10, 2023
121
USA
TL;DR: suggested updates to and a question about the PID spreadsheets

I've been playing around with the "PCM-PIDScan2" and "GMT_PIDS_Rev_4A" spreadsheets. I decided to use an online converter to go from '.xlsx' format to CSV format on the former, so that I could then import it into my favorite spreadsheet utility (Gnumeric). From there, I was able to create a new column with decimal equivalents to the "Mode & PID" (hexadecimal-format) column, which allowed me to finally sort the spreadsheet by that same column. This helps preserve my diminishing sanity. 🤪

This conversion and sorting also conveniently pointed out a few minor issues that I'll humbly suggest might be added to the list of spreadsheet "tweaks". IIUC, the changes are needed in both spreadsheets. IMHO, there's no reason to put out new versions of either spreadsheet right away. I just thought I'd mention these issues now while they're fresh in my brain.

For various reasons, I'm showing raw lines below from the CSV-format conversion, instead of using row numbers. Hopefully that won't "muddy the waters".

There are 11 cases that have a superfluous leading space character in the text for the "Mode & PID" cell entry. This space should be deleted because it messes up the sorting.
Code:
BCM,Fuel Tank Pressure -F, FuelTnkPr, 22114E, A/51,0,5, Volts, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,Engine Run Time -F, Run Time, 2211A1, ((A*256)+B)/60,0,999, Mins, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,HO2S1 Crossover Counts -F, HO2S1-X, 2211AF, A,0,255, Counts, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,HO2S2 Crossover Counts -F, HO2S2-X, 2211B0, A,0,255, Counts, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,EGR Closed Position Volts -F, EGR Cls, 2211BB, A/51,0,5, Volts, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,EGR Test Counts -F, EGR Test, 2211BD, A,0,255, Counts, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,EGR Position Error% -F, EGR Err%, 2211C1, A/2.55,0,100, %, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,HO2B1S1 Warm Up time -F, HO2B1S1-W, 2211CA, A,0,255, Secs, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,HO2B1S2 Warm Up time -F, HO2B1S2-W, 2211CB, A,0,255, Secs, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
PCM,HO2S3 Warm Up time -F, HO2S3-W, 2211CC, A,0,255, Secs, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs
BCM,Fuel Tank Level% -F, Fuel Lvl%, 2212C5, A/2.55,0,100, %, Auto,,All models,https://torquebhp.fandom.com/wiki/GM_Extended_PIDs

There is one case that has a superfluous colon character in the text for the "Mode & PID" cell entry. (Note that the ':' does not appear in the CSV format, but it's in the original '.xlsx' spreadsheet.) That same entry also has a superfluous "01" at the end which should be removed for consistency with all the other Mode $22 entries. (The "01" suffix on the command is needed by GM vehicles but contributes nothing to the PID value/meaning).
Code:
,AIR as Volts DC,,22154901,A/51,0,5,Volts,6C10F1,x1,2004+ 4.2 Vortec LL8,https://gmtnation.com/forums/threads/more-pids-for-torque-app.20176/page-10#post-620636

Lastly, there is one case that has just the trailing "01" which should be deleted:
Code:
,AIR pressure kPa,,22151C01,(A/255)*110+40,40,150,kPa,6C10F1,x1,2004+ 4.2 Vortec LL8,https://gmtnation.com/forums/threads/more-pids-for-torque-app.20176/page-10#post-620636

On a different note, I'm wondering who (@azswiss?) owns the "2003 Suburban 4x4 L59 4L60E" that appears in the spreadsheet? It appears that that vehicle supports PCM Mode $22 PID $12C5 because (prior to being deleted as a duplicate entry) it was listed as "System PID Scan". If so, it would be interesting to see what the PCM reply was to that command.

Lastly, I'm curious about the "System" column. I can see the usefulness of it, but its prominence and the fact that it contains entries like "PCM", "BCM", and "IPC" make it look (to me at least, until I "wised up") like an indicator of the node, which frankly is far more important, IMHO, especially if shown with the hexadecimal node address, in such a spreadsheet. Thoughts, anyone?
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
I've been playing around with the "PCM-PIDScan2" and "GMT_PIDS_Rev_4A" spreadsheets

I tried searching for "PCM-PIDScan2" and came up empty. What is the source here? It could even be myself as the source but a Google search of this site comes up empty.
 

azswiss

Member
May 23, 2021
924
Tempe, AZ
Answers to some of the questions above (in no specific order!):

Module addresses I have identified on my '03 Suburban:
10 PCM
29 Chassis/4WAL
40 BCM
58 SRS/Restraints
60 Instrument Panel
80 Radio
83 Fuel System
98 HVAC
1A TCCM
A0 Driver Door Module
A1 Passenger Door Module
A7 RearSeat Audio

Mode $22 PID $12C5 response: Did not see a valid response in the original data.

Trailing "01" on several entries: These entries were pulled from a pre-existing source so I kept them as is.

Also, the CSV tab is for creating & formatting data necessary for import into Torque. Sorting (& filtering) should be done on the PID tab.

Strongly suggest moving to an app that allows advanced filtering (e.g. text contains, ends with, begins with, etc.) as simple sorting has some inherent limitations (e.g. if the dataset may be dirty or incomplete). I would create a dummy account on Google in order to be able to access Google Sheets; LibreOffice Calc is an open source download that should also work.
 

AmpOverload

Member
Jul 10, 2023
121
USA
Maybe use AB/51.2 ??
I typically use "xxx/255*5" ("xxx/51") for 5-volt analog sensors but some people simply use "xxx/256*5" ("xxx/51.2"). The simple truth is that there's so much noise in that sensor that anything in that range is acceptable. My comment of "(or thereabout, but it's close to that)" was meant to leave some "wiggle room" for anyone who likes to use 256. 🙂
 
  • Like
Reactions: TJBaker57

AmpOverload

Member
Jul 10, 2023
121
USA
Module addresses I have identified on my '03 Suburban: [...]
Sorry if I wasn't clear about this, but I wasn't asking which nodes (by name and/or address) are on anyone's vehicle. I'm suggesting that the spreadsheet might include a new column to show the node being queried. Without that information, one can look at the "Header" column (assuming it's not showing "Auto" and isn't blank) to discern that information. But a PID is technically useless without knowing more than Mode and PID #. Yes, in most cases it's the PCM (typically address $10), but not always. Not a big deal, just a suggestion.

Mode $22 PID $12C5 response: Did not see a valid response in the original data.
OK, thanks! So from where I sit, I'm the only one so far who has a documented response (on 2 different vehicles, in fact) to a PCM Mode $22 PID $12C5 command. And my responses are 2 bytes long. Which makes me wonder if that original page from where the formula in the spreadsheet came is truly correct. Not a big deal to me since my formula works. But if your spreadsheet is to be correct it would be nice to see someone who has a vehicle where the reply is only 1 byte and matches the formula to the real-world (dashboard) fuel gauge.

Trailing "01" on several entries: These entries were pulled from a pre-existing source so I kept them as is.
☹️ It breaks the sorting but, fair enough... It's your spreadsheet, not mine.

Also, the CSV tab is for creating & formatting data necessary for import into Torque. Sorting (& filtering) should be done on the PID tab.
Again, I apologize because it seems I wasn't clear. I wasn't referring in any way to the "CSV" tab on your spreadsheet -- I never even open it. I was referring to converting the whole "PCM PIDScan2.xlsx" spreadsheet to CSV format, which is more universal and easily imported by any capable program.

Strongly suggest moving to an app that allows advanced filtering (e.g. text contains, ends with, begins with, etc.) as simple sorting has some inherent limitations (e.g. if the dataset may be dirty or incomplete). I would create a dummy account on Google in order to be able to access Google Sheets; LibreOffice Calc is an open source download that should also work.
But, as long as the spreadsheet comes ordered by "Mode & PID", I don't need any of those features (which are available in Gnumeric too). It just strikes me as odd that there appears to be no inherent order to the content when it's first loaded. But I can work around that now, so I don't have any issue. Forgive me if it seemed I was suggesting otherwise.
 

azswiss

Member
May 23, 2021
924
Tempe, AZ
Fuel system is suspect as that range is specified for "Entertainment"
Cannot remember where/how I made that connection (incorrect data from an online search?). Redid the module scan & confirmed presence. No entertainment system in the vehicle whereas the Radio & Rear Seat Audio nodes identified separately (80 & A7, respectively). Suggestions on how to validate/reject?

Edit: 83 is not present.
 
Last edited:

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
I typically use "xxx/255*5" ("xxx/51") for 5-volt analog sensors but some people simply use "xxx/256*5" ("xxx/51.2"). The simple truth is that there's so much noise in that sensor that anything in that range is acceptable. My comment of "(or thereabout, but it's close to that)" was meant to leave some "wiggle room" for anyone who likes to use 256. 🙂

In 5th grade one of the nuns was watching me do some task and stated "Whatever you do in life you are going to do it with precision". She was not wrong!
 
  • Like
Reactions: AmpOverload

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
Cannot remember where/how I made that connection (incorrect data from an online search?). Redid the module scan & confirmed presence. No entertainment system in the vehicle whereas the Radio & Rear Seat Audio nodes identified separately (80 & A7, respectively). Suggestions on how to validate/reject?

Edit: 83 is not present.


I will go ahead and reply anyway! One method would be to query data block 08 for the part number.

6C 83 F1 3C 08 is the query. The answer will look like: 6C F1 83 7C 08 xx xx xx xx CS. Convert the hexadecimal xxxxxxxx to decimal for the part number.
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
from where I sit, I'm the only one so far who has a documented response (on 2 different vehicles, in fact) to a PCM Mode $22 PID $12C5 command. And my responses are 2 bytes long


I can confirm that for a 2004 Buick a Tech2 does in fact request that $12C5 PID under EVAP data and identifies it with a 2 byte return value. So there is that much.
 
  • Like
Reactions: AmpOverload

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
Mode 22 PID 1996 is not supported by the P10 PCM, tested on 2 2002s, 1 2003 and 1 2005 in my arsenal.

It is supported by the 2006 P12 PCM I have.

Well crap! I will have to edit this here as upon further study the PID is NOT present on my 2006 P12 PCM.

It is present on my 2005 Yukon 5.3 as well as @azswiss 2003 Suburban, both with single byte responses.
 

azswiss

Member
May 23, 2021
924
Tempe, AZ
I think a clear takeaway from today's discussions in this thread is that vehicle-specific details need to be incorporated into these datasets.

Also re: Post #504 above, note-to-self: Check twice, post once!
 
  • Like
Reactions: TJBaker57

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
So I have been digging into this fuel level parameter a bit with my 2005 Yukon 5.3 LM7.

First I verified that PID 12C5 is supported by the PCM. It returns a 1 byte value. I see in @azswiss data record that his 2003 Suburban also returns a 1 byte value for this 12C5 PID. It appears to be a percentage value.

Next I took a look with the Tech 2 and found fuel tank level reported in the EVAP data selection. Also present were fuel tank capacity, fuel remaining, and sensor voltages for both the primary and optional rear tank.

I expected to see the 12C5 PID in there but although it is supported in this vehicle that PID is not called up when displaying EVAP data which contains fuel tank values. Hmmm.

So I set about seeking the source of the fuel tank data. I have deduced the following:

For the optional rear tank (if equipped) the sensor voltage PID is 1338.

Fuel tank capacity for this vehicle is reported by PID 131D. It is a 2 byte value, the resolution is 1 bit = 1/64th of a liter.

Remaining fuel in this vehicle is reported by PID 132A. Like the previous stated PID it is a 2 byte value with the same resolution, 1 bit = 1/64th liter.
 

AmpOverload

Member
Jul 10, 2023
121
USA
I can confirm that for a 2004 Buick a Tech2 does in fact request that $12C5 PID under EVAP data and identifies it with a 2 byte return value. So there is that much.
Good to know. Thanks for the confirmation!

Just curious, do you happen to have access to a 2004 Buick (or the PCM), do you have a way to simulate it, or can the Tech2 accept a user-specified vehicle as the input? (I haven't seen a Tech2 in well over 20 years, so I can't recall how it works.)

I see in @azswiss data record that his 2003 Suburban also returns a 1 byte value for this 12C5 PID. It appears to be a percentage value.
Mode $22 PID $12C5 response: Did not see a valid response in the original data.
OK, well I'm officially and thoroughly confused! :confused: Something isn't quite right here, folks. Which is it?

@TJBaker57, it would be quite interesting to know if the 1-byte value from a PID $12C5 query on your 2005 Yukon, after applying the spreadsheet formula of "A/2.55", yields a "tank fill percentage" value that matches your dashboard fuel gauge.

I've done some more testing too, but I'm not ready to comment just yet.

P.S. Funny that you mention PCM Mode $22 PID $1338. That appeared once in a PID scan I did years ago but not since then! It's a "ghost" PID as far as the 2004 Buick is concerned! I think I even tested it with the PCM unlocked but never saw it report again.

P.P.S. If you haven't already tried it, you might try functional addressing with Pri/Sec IDs of $82/$16 ('fuel system'/'fuel capacity'). That's an SAE-standard ID pair with SAE-standard decoding -- PRN 6007, I think you speak that lingo, right? If not, it's "(A*256+B)/100" liters. That worked on at least one GM vehicle (2005 LeSabre) that I've tested in the past.
 

AmpOverload

Member
Jul 10, 2023
121
USA
Fuel tank capacity for this vehicle is reported by PID 131D. It is a 2 byte value, the resolution is 1 bit = 1/64th of a liter.

Remaining fuel in this vehicle is reported by PID 132A. Like the previous stated PID it is a 2 byte value with the same resolution, 1 bit = 1/64th liter.
Forgot to mention... For the record, I've never seen a valid response to either of those Mode $22 PIDs on any GM vehicle.
 

azswiss

Member
May 23, 2021
924
Tempe, AZ
I need to do a full reverification PID scan and then do a deep dive review of my spreadsheets for errors/omissions/duplicates. In case of any conflicting data, I would defer to @TJBaker57.
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
Just curious, do you happen to have access to a 2004 Buick (or the PCM), do you have a way to simulate it, or can the Tech2 accept a user-specified vehicle as the input?

I do not have access to either vehicle or PCM. The Tech 2 walks you through a selection menu for vehicle specifics. It does no comms with the vehicle during this process. It only initiates comms when one selects menu option to request data such as scanning for DTCs or pulling in live data. If you are not connected to the type of vehicle you specified it will likely toss an error of the sort "possible incorrect vehicle selected". However, the PID requests for DPID setup have already been transmitted before the error interrupts the process. :wink:




well I'm officially and thoroughly confused! :confused: Something isn't quite right here, folks. Which is it?

I have a copy of the results of a PIDscan @azswiss shared years ago. In that log I see this...

2212B001 6C F1 10 62 12 B0 00 8E
2212B101 6C F1 10 62 12 B1 03 27 34
2212C501 6C F1 10 62 12 C5 B6 E6
2212E201 6C F1 10 62 12 E2 5A 44
2212E301 6C F1 10 62 12 E3 4B D8


Looks like a single byte response there.
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
@TJBaker57, it would be quite interesting to know if the 1-byte value from a PID $12C5 query on your 2005 Yukon, after applying the spreadsheet formula of "A/2.55", yields a "tank fill percentage" value that matches your dashboard fuel gauge

I likely have this on file as I record most all of my experimentations and scannings. This record is of all serial data traffic including the functionally addressed messages between PCM and IPC. So that will include fuel gauge messages. I have discovered that A/2.55 used in some PIDs may need some adjustment as the remaining fuel quantities reported by a Tech 2 can run higher than 100%.

20230806_175523~2.jpg



you mention PCM Mode $22 PID $1338. That appeared once in a PID scan I did years ago but not since then!

I would be surprised to see it on a vehicle that cannot accept a second fuel tank. Here is data from the Yukon

Screenshot_20230807-223533_aGrep.jpg
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
For the record, I've never seen a valid response to either of those Mode $22 PIDs on any GM vehicle.

A quick scan of my recorded data tosses up 2 different PCM responses to 132A.

Screenshot_20230807-224708_aGrep.jpg

The first back in 2021 is from a 2006 P12 which supports 132A but not 131D. That bears looking into. It reports a zero value because it was being bench scanned with no sensors attached.

The next 2 are both from the 2005 Yukon. For whatever reason I seem to have had that PID entered in Torque Pro. Likely for evaluation purposes.
 

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
P.P.S. If you haven't already tried it, you might try functional addressing with Pri/Sec IDs of $82/$16 ('fuel system'/'fuel capacity'). That's an SAE-standard ID pair with SAE-standard decoding -- PRN 6007, I think you speak that lingo, right?

Yes I do. Rather than chase the capacity I just pulled up fuel remaining in both PID 132A and functional addressing 83/13. Different resolutions that resolve to pretty much the same value.

Screenshot_20230807-230726_aGrep.jpg

$030F = 783
783/64 = 12.23 liters

$04C9 = 1225
1225/100 = 12.25 liters

I will see about checking a higher percentage fill next.

Followup edit: it also matched at 65 liters in another file record.
 
Last edited:

AmpOverload

Member
Jul 10, 2023
121
USA
[...] The Tech 2 walks you through a selection menu for vehicle specifics. [...] If you are not connected to the type of vehicle you specified it will likely toss an error of the sort "possible incorrect vehicle selected". However, the PID requests for DPID setup have already been transmitted before the error interrupts the process. :wink:
😄 Fantastic! Thanks for that explanation! I simulate various vehicles (and to a lesser extent, various scantools) with software (and, more recently, with hardware). Of course, it's never 100% accurate, but the software is good enough these days to fool every OBD program I throw at it. I really should buy a Tech2 (probably a clone, these days) and join in on the fun. I've thought about it for years but don't own any GM vehicles.

I have a copy of the results of a PIDscan @azswiss shared years ago. [...]
Excellent! I guess that, depending on what @azswiss wants his spreadsheet to represent, it might make sense for me to forget about P04-specific PIDs (including PIDs with P04-specific reply lengths). This was my concern when I joined this thread. That is, I don't want to "pollute" your guys' data with what is (to you) irrelevant (however correct it might be) data.

I would be surprised to see it [PID $1338] on a vehicle that cannot accept a second fuel tank.
Me too, but here it is:
Code:
Locked PCM:
2020-10-31 19:04:06.100 Try  1: PID 10:1338 success   Reply: { 6C F1 10 } 62 13 38 00 [92]
Unlocked PCM:
2020-10-31 20:21:44.068 Try  1: PID 10:1338 success   Reply: { 6C F1 10 } 62 13 38 00 [92]
(As you can see, to aid in interpreting the data, my software puts OBD message headers in braces and checksums in brackets. Much easier for my aging brain to properly interpret!)

BTW, as you can see above, I was wrong earlier about only seeing this PID once. I did see a 2nd successful reply to that PID, but it was on the same day, with the PCM unlocked. Curiously, subsequent attempts before I finally disabled queries for that PID in my "OBD snapshots" (about a year later) all yielded the same reply:
Code:
ATSH: 6C 10 F1   Node: 0x10   Mode: 0x22   PID: 0x1338   Reply #1: { 6C F1 10 } 7F 22 13 38 01 31 [10]
In other words, Mode $7F, Response Code $31 ("Request Out Of Range"), which is what I'd have expected all the time.

But GM PCMs sometimes do crazy things! This is not the only example of such that I've encountered, unfortunately.

As for fuel-related "PIDs", I suspect that GM is really only using 2 pieces of information: fuel tank capacity (however it's queried/attained) and the reading from a 5-volt fuel tank level sensor. Everything else is probably just computed from those 2 elements and some of it, depending on the vehicle, is made available via Mode $22 PIDs and/or functional addressing. In general, I need to do some more fuel-related tests, but I hope to be able to report some results within a few days, time permitting.

As for the "higher than 100% fuel remaining", I saw "102.2%" ("104.4%" if I jostle the car a bit) just the other day on a 2005 Buick that I was playing with and knew had just been re-fueled. EDIT: That was PCM Mode $22 PID $12C5.

All great info, @TJBaker57 -- thanks! Your posts are frequently dense (in the good sense!) with high-quality information. It's very nice to be able to communicate with another person who can clearly speak "OBD", down to the nitty-gritty in fact. I haven't found many who have delved into it the way that you (and I) have. My data logs go back to 2012, having bought my first scantool back in 2010 (and even then feeling that I was way "late to the game").
 
Last edited:

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
I simulate various vehicles (and to a lesser extent, various scantools) with software [...] I really should buy a Tech2 (probably a clone, these days) and join in on the fun. I've thought about it for years but don't own any GM vehicles.

Interesting. I am limited to doing these experiments on Android phones as I do not own a desktop computer. Also have no formal education in programming or the like. Most everything I post here is done on a phone or two.

So not owning any GM vehicles, I have to ask: What got you into this arena we are discussing here? I have owned GM vehicles since 1982 but only dove into this stuff when low cost OBD2 dongles became available.

For access to some of the traffic behind a Tech 2 there is at least one more inexpensive option but it does require a smartphone. The Autel AP200 (the original model, not the later AP200 derivatives) seems to use the same structure of DPIDs. It lacks the programming services and some of the "special functions" and such but data retrieval is there for as low as $35.10 at JB Tools online store. The software(s) for the tool does require a good deal of storage space.




@azswiss wants his spreadsheet to represent, it might make sense for me to forget about P04-specific PIDs (including PIDs with P04-specific reply lengths). This was my concern when I joined this thread. That is, I don't want to "pollute" your guys' data with what is (to you) irrelevant (however, correct it might be) data.

I would encourage you to continue adding whatever data you feel may be useful to others. Although this website is largely devoted to the GMT360/370 platform you can see there is room provided for other platforms. I have added a little Yukon data and @azswiss delves into the similar Suburban. My efforts have largely been towards my TrailBlazer but I intend to dig deeper into my Yukon.

Perhaps we can create a more wide ranging repository for our findings and directly include informations like the subject vehicle (year, make, model and more)?


In my early scans I neglected to include that in the logfile which leaves me now having to examine those logs to determine what vehicle they were from. In my later logfiles I include some service $09 requests to include VIN number and calibration informations.

As you have noted there are not many of us who dig into this arena and if we can come together here and bring more traffic to our website all the better.



Me too, but here it is:
Code:
Locked PCM:
2020-10-31 19:04:06.100 Try 1: PID 10:1338 success Reply: { 6C F1 10 } 62 13 38 00 [92]
Unlocked PCM:
2020-10-31 20:21:44.068 Try 1: PID 10:1338 success Reply: { 6C F1 10 } 62 13 38 00 [92]

Perhaps GM re-uses blocks of coding here and there and some orphaned PIDs slip by?

Curious that it reports a data value of zero. Apparantly on my Yukon it is still reading the nearly 5 volt output while there is no level sensor to pull that down.

Accidental message post happened here, continuing below!!
================================
 
Last edited:

TJBaker57

Original poster
Member
Aug 16, 2015
2,907
Colorado
I suspect that GM is really only using 2 pieces of information: fuel tank capacity (however it's queried/attained) and the reading from a 5-volt fuel tank level sensor.

I wondered the same. I do see functionally addressed messaging about fuel usage using 83/0A but haven't quite concluded what that is being used for.


I saw "102.2%" ("104.4%" if I jostle the car a bit)

To achieve the greater than 100%, and to gather data for analysis in tracking down the capacity and remaining fuel value PIDs, I parked the vehicle on a steepish incline first facing uphill and then repeated facing down. Also gathered a near-level data set then looked over the readings to isolate what PID(s) were possible fuel tank level PIDs. Under normal near-level conditions the tank was maybe 92% filled.


My data logs go back to 2012, having bought my first scantool back in 2010 (and even then feeling that I was way "late to the game").

If you have trudged through this thread you may have seen me talk about concentrating my efforts on this older SAE J1850 VPW protocol. Yes we were late to the game and most moved on to ISO 15765-4 CANBUS but I feel this is a good niche that still needs attention. Much attention is devoted to reprogramming/tuning and so on. Much good information can be harvested from those exploits. But my focus has always been towards diagnostics for the purpose of repair. No interest in modifications of the calibrations.
 

AmpOverload

Member
Jul 10, 2023
121
USA
I am limited to doing these experiments on Android phones as I do not own a desktop computer. Also have no formal education in programming or the like. Most everything I post here is done on a phone or two.
Your work is impressive and admirable, even more so given those (formidable, IMHO) limitations! I tip my hat to you!

I usually collect data with a nice, small laptop PC, running Linux. For anything involved, I process it on a desktop PC, also running Linux. I have played with Android devices for data collection, but I really hate the ecosystem (development, etc). "Different strokes", eh?

So not owning any GM vehicles, I have to ask: What got you into this arena we are discussing here?
My interest in GM (VPW) comes from having people I know who benefit from my automotive advice/repairs and own (older) GM vehicles. Don't anyone "light the torches and warm up the pitchforks" but I also mess around with Ford (PWM) vehicles 😱 when appropriate and available. Maybe one day I'll have broader access to some other manufacturers. For now, I learn what I can, where I can.

For access to some of the traffic behind a Tech 2 there is at least one more inexpensive option but it does require a smartphone. The Autel AP200 [...]
Thanks for the tip. I took a quick look into it and it doesn't seem to really fit my "M.O.", but I'm always open to suggestions and will look into it a bit more deeply. Who knows? Maybe I'll develop a fondness for smartphones and such someday. 🤔

I would encourage you to continue adding whatever data you feel may be useful to others. Although this website is largely devoted to the GMT360/370 platform you can see there is room provided for other platforms. I have added a little Yukon data and @azswiss delves into the similar Suburban. My efforts have largely been towards my TrailBlazer but I intend to dig deeper into my Yukon.
I'm not familiar with the GM line of trucks at all. In the past, I've had brief "OBD peeks" at a 2005 (IIRC) Avalanche, but that was long ago and I don't have a lot of data on it.

Perhaps we can create a more wide ranging repository for our findings and directly include informations like the subject vehicle (year, make, model and more)?
It might be tough to make a good spreadsheet, frankly. At a minimum, it probably has to be broken down (new tab or at least a new column) by PCM family (P01, P04, P10, etc). That's a daunting task to keep organized and I wish it upon nobody.

In my early scans I neglected to include that in the logfile which leaves me now having to examine those logs to determine what vehicle they were from. In my later logfiles I include some service $09 requests to include VIN number and calibration informations.
Yeah, my earliest logs are rather pathetic. As I learned more, my logs became more useful. 😊 I was logging VIN from early on, but the odometer had me stumped for an embarrassingly long time, I have to admit! Nowadays, I log everything that a vehicle is known to report, even if I don't understand what some "PIDs" (in quotes because it's not really all just Mode $01/$02/$22 PIDs) actually mean.

Perhaps GM re-uses blocks of coding here and there and some orphaned PIDs slip by?

Curious that it reports a data value of zero. Apparantly on my Yukon it is still reading the nearly 5 volt output while there is no level sensor to pull that down.
I think the report of $1338 is/was just a fluke, probably a bug in the PCM hardware or firmware. I see some crazy stuff on a very predictable basis, especially with functional addressing.

I wondered the same. I do see functionally addressed messaging about fuel usage using 83/0A but haven't quite concluded what that is being used for.
Looking at my data, I also see Pri/Sec $82/$0A (forgive me, I've developed the habit of using the "command" Primary ID, not the "reply") on "my" 2 Buicks, but I've never figured out the meaning either.

If you have trudged through this thread you may have seen me talk about concentrating my efforts on this older SAE J1850 VPW protocol. Yes we were late to the game and most moved on to ISO 15765-4 CANBUS but I feel this is a good niche that still needs attention. Much attention is devoted to reprogramming/tuning and so on. Much good information can be harvested from those exploits. But my focus has always been towards diagnostics for the purpose of repair. No interest in modifications of the calibrations.
I think we must have been separated at birth! 😂 I'm the same way. I have no interest whatsoever in "tuning" (other than that their investigations and knowledge often overlap mine and I have learned important things from those forums). I really care only about diagnostics and repair, to help save people money, avoid the too-often-abusive dealerships, and to keep old vehicles running reliably and safely.
 
  • Like
Reactions: TJBaker57

AmpOverload

Member
Jul 10, 2023
121
USA
Looking at my data, I also see Pri/Sec $82/$0A [...] on "my" 2 Buicks, but I've never figured out the meaning either.
I stumbled across a note which led me to some data that I forgot about. A few months ago, I collected various data points on a 2004 Buick Century as it was driven. It included the value above. Here's a graph:

2004-Century-FxAddr-82-08-driving.png

Since I don't know the purpose, this 2-byte value is simply being decoded for now as "unsigned(A*256+B)".

Given that it's incrementing the whole time, my note speculated that it might be some sort of "fuel consumed" value, but I'd need to do a lot more testing to know. (...deep sigh...) So many "PIDs", so little time! 🤪
 

Forum Statistics

Threads
23,400
Posts
638,838
Members
18,614
Latest member
dakis

Members Online