Do you happen to have such a recorded example of that 12C5 PID response from an actual vehicle or PCM?
More PIDs for Torque App
- Thread starter TJBaker57
- Start date
Do you happen to have such a recorded example of that 12C5 PID response from an actual vehicle or PCM?
For such things Torque Pro does accept INT32(A:B:C
) according to the Torque Wiki here... 
Vehicle response from '03 Suburban added in for all "Unknown" PIDs.
AmpOverload
Member
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 65The 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 EDI 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.
AmpOverload
Member
Fantastic! Many thanks!
That's a great addition and will help me and any others trying to decipher PID meanings. This is a great forum with some great people!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
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.
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
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:
AmpOverload
Member
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.
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).
Lastly, there is one case that has just the trailing "01" which should be deleted:
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?
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_PIDsThere 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-620636Lastly, 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-620636On 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?
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.
AmpOverload
Member
By
AmpOverload
Member
Odd that Google didn't locate it. DuckDuckGo found it easily:
https://html.duckduckgo.com/html?q="pcm_pidscan2"
https://html.duckduckgo.com/html?q="pcm_pidscan2"
I agree. Search is not what it used to be. And searching here in GMTNation did not find it either, other than in our two posts.
AmpOverload
Member
If you still have the data that you used to put PCM replies into the "PCM-PIDScan2" spreadsheet, I'd love to know the PCM's reply to Mode $22 PID $12C5!
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.
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
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.
AmpOverload
Member
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.
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.
It breaks the sorting but, fair enough... It's your spreadsheet, not mine.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.
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.
Cannot remember where/how I made that connection (incorrect data from an online search?).
Edit: 83 is not present.
Last edited:
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!
@AmpOverload, no worries! As with anything you find online, trust but verify!
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.
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.
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.
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.
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
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.)
OK, well I'm officially and thoroughly 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
Forgot to mention... For the record, I've never seen a valid response to either of those Mode $22 PIDs on any GM vehicle.
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.
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.
well I'm officially and thoroughly confused!
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.
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%.
I would be surprised to see it on a vehicle that cannot accept a second fuel tank. Here is data from the Yukon
A quick scan of my recorded data tosses up 2 different PCM responses to 132A.
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.
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.
$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
[...] 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.
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.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.
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]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]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:
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.
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.
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:
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.
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.
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
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?
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.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'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.
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.
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.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.
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.
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.
AmpOverload
Member
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:
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!
