More PIDs for Torque App

[TJBaker57]

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:

View attachment 109307

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!

I was going to say much the same about that message. I have hundreds of recordings rolling down the road and I knew it was an incremental value. I 'may' have even deduced the resolution somewhere along the line but failed to properly document it!! So many files with such poor note-taking!!

 

[AmpOverload]

I had another realization and did some testing. Here's a better graph:



With apologies to any colorblind readers out there, the red line is almost certainly a "fuel consumption" value of some sort. The green line is VSS (Vehicle Speed Sensor). The blue line is an odometer of sorts.

Notice how the red line starts to level off whenever the vehicle speed drops (coasting, minimal fuel use)? That seems like clear confirmation that this data point could very well be "fuel consumption".

I 'may' have even deduced the resolution somewhere along the line but failed to properly document it!! So many files with such poor note-taking!!

I feel your pain! It's quite tough to keep track of it all.

Based on some computations from those values, I'm going to take a wild, initial guess that Prim/Sec $82/$0A is "fuel consumption" with the formula "unsigned(A*256+B)/32768" liters. At some point, I will test this against a computation of instantaneous MPG (taken from VSS and MAF values) to see if I can get a reliable correlation. But for now, in my world, I'm calling this (GM-defined) data point "fuel consumption (formula and units unknown)".

There's another story behind that blue "GM:FracOdo" (odometer) line, but I'll leave that for another day.

 

[kastein]

You should be able to grab the year from the VIN in the PCM, yes?

Well, I have good and bad news. Good news is yes I could have, and I actually found some info from when I pulled it at the junkyard. It was an 06 Escalade donor. Bad news is while packing up my hangar into a shipping pod 2 weeks ago I had a guy come by to buy a project vehicle and while he didn't want to pay my price for that, he bought my '06 LQ9 and '03 4L80e for about what I had into them. So now I don't have a spare motor but on the other hand I didn't have to load them into the pod or unload them at the other end.

If or when the buyer finishes his build (he's on the fence about going Holley Terminator or factory ECU, though I'm pushing hard for factory ECU, there's no reason he should actually need a Terminator and it'll save him 50%ish on his EFI bill of materials) I may try and buy the ECU and/or harness back for my own use.

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?

Interesting. I am going to have to check if 12C5 is 2-byte and correct on my '03 LQ4 ECU, that's what I'm using for my fuel gauge project right now. I was only using byte A. As for 0.8-2.5 volts, that is an unfortunate artifact of how they do the analog circuit for the fuel level sender. It's a 40-250 ohm variable resistor sender in a voltage divider with a fixed 250 ohm resistor (near as I can tell) pulling up to the 5V Aref rail inside the ECU. So at the lowest, you'll have 5V*40/(40+250) = 0.69V at the ECU input pin and at the highest, 5V*250/(250+250) = 2.5V. Given the fact that the ADCs for the two tank sensor inputs appear to be 8 bit... yeah my fuel tank calibration table has some very grainy points in it because some of my calibration points are only a few LSBs apart.

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.

I *want* the answer to be 256, but the correct answer is 255, because the 0-5V range of the ADC input has 256 *points*, which means it has 255 steps in between those points.

So I have been digging into this fuel level parameter a bit with my 2005 Yukon 5.3 LM7.
*snip*
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.

Very interesting... I was hoping someone would find that rear tank sensor voltage PID, I'll add that to my collection immediately and fool around with it since I hope to use it for my aux tank sender (once I add one instead of the hillbilly hose and ball valve setup that I have to pressurize to start siphoning it into the main tank.)
I'll give the other PIDs a look too and see what I think about them.

*snip*
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.

Fun fact - there are up to *five* calibration tables for this calculation! If you are fooling around with hptuners, look under System->Fuel Tank/Gauge. You'll find six single data points (capacity, capacity gauge, primary capacity, primary capacity gauge, sender max A/D, sender min A/D) as well as 5 buttons for the calibration tables. I have not received any confirmation from my post on the HPTuners forums about this, but my impression is that the capacity/primary capacity values are actual tank volumes for DTE calculation, the capacity gauge/primary capacity gauge values are the ones used for the gauge, the A/D ones are the fenceposts before the ECU trips a P0462/463. The table named "gauge output" is for calibrating the ECU's output calibration, it converts your PID $12C5 0-100% linearized fuel level into a non-linear PWM drive output needed to run whatever wonky bimetallic/etc analog gauge was in the factory gauge cluster when that vehicle was released. The 4 other calibration tables convert the fuel level ADC input(s) into absolute fuel volume currently in that tank (of both actual and gauge scales) which the ECU then combines with the tank sizes (actual and gauge scale) to calculate actual and gauge fuel remaining outputs that are fed onto the bus and/or into the fuel level output PWM table calculations.

Clear as mud?

 

[AmpOverload]

@kastein: Lots of interesting stuff in your post! Many thanks for the information!

I'm not into tuning PCMs, so I've never used HPTuners, even though I'm mostly interested in things that keep a vehicle running and tend to spend more time on engine- and transmission-related things. In fact, all this fuel-related stuff is more of an interesting diversion. But I do love a good, detailed, technical discussion, so it's all "candy" to me, even if some of it goes beyond my knowledge and/or my ability to relate it to the few GM vehicles I occasionally have access to.

Fun fact - there are up to *five* calibration tables for this calculation! [...]

Good info on the fuel cal (etc) -- lots there that I was unaware of -- thanks! A minor note I'd add, based on what I've seen, very recently in fact. There's some "smoothing" going on at some point between the PCM's source of 'fuel tank level' and what appears on the dashboard's needle gauge. I don't know if it's done in the PCM or in the IPC (Instrument Panel Cluster), but there's a definite "lag" there.

I very recently changed my display of PID $1155 to include not just "volts" but, based on that range of 0.8 to 2.5 volts, also "percent full". But if I understand your post, I think I'll remove the "percent full" display (because it might be non-linear and is not taking into account the proper calibrations in the PCM, like PID $12C5 does, IIUC) and just leave it as "volts".

 

[AmpOverload]

Testing Fuel-Tank-Level Data on P04-PCM Vehicles

I've been looking into the 'fuel tank level' data discussed earlier in this thread. On 2 vehicles, as I was adding about 2 gallons to the fuel tank, I monitored these data points:

1. PCM Mode $22 PID $1155 (fuel tank level sensor, in volts)
2. PCM Mode $22 PID $12C5 (fuel tank level, in percent)
3. functionally addressed Primary/Secondary ID $82/$12 (fuel level, in percent)

Things to note about the graphs for the 2 vehicles:

• Along the bottom edge, there's a timeline, showing "add" and "stop" to roughly mark where I was adding fuel and where I stopped.
• I show 2 different graph formats for each vehicle, 1 with individual plots for each data point and 1 with a common Y axis where all 3 data points are overlaid. The latter version makes it easier to see things like "lag" (etc).
• The fuel gauge on the 2004 Buick Century is unreliable. It's correct when the vehicle is standing still long enough but is untrustworthy while moving and for about 30 seconds after coming to a complete stop. The fuel gauge on the 2005 Buick LeSabre is more reliable.

2004 Buick Century
Individual Plots:

Shared Y-Axis:


2005 Buick LeSabre
Individual Plots:

Shared Y-Axis:


From the graphs above, I can see that the 2-byte PID $12C5 generally "tracks" the 1-byte PID $1155, but with some smoothing (and, presumably, some PCM-based calibrations for non-linearity). @TJBaker57 and I both question the need for a 2-byte PID here but (AFAICT) both bytes are actually used. The least-significant (lower) byte just tends to increment in large amounts for each change in the sensor's (1-byte) voltage report, as you might expect.

The functionally addressed $82/$12 data point is even more smoothed than PID $12C5 and frequently lags changes in the fuel level that are seen sooner in the other 2 data points.

As I suggested in my last post, I've stopped decoding PID $1155 with alternate units of "percent full" and now decode it only as a simple "sensor volts" value. This makes sense since these fuel tanks are probably not dimensionally uniform, necessitating PCM-based calibration factors, as mentioned by @kastein.

@azswiss, I think that the "GM PIDS" spreadsheet should probably do the same with PID $1155, but that line came from @TJBaker57 data, so I'd like to hear his opinion too. As for PID $12C5, GM clearly used 2 different implementations of that one, so it's really up to you as to whether the spreadsheet should distinguish the 1-byte and 2-byte versions/vehicles.

Although there's a lot of OBD-nerd-level detail in this post, at least now I'm convinced that I'm interpreting these data points correctly. The dual-tank vehicle owners will hopefully fill in their part of the story at some point.

My next step is to gather data to figure out the formula and units for functionally addressed data point Prim/Sec $82/$0A (total fuel consumption since reset, IIUC). There's probably a good chance that that data point behaves more consistently among the various GM vehicles being discussed in this thread, even though it's not an SAE-standardized data point (i.e. GM can define it however they want for their vehicles). Time will tell....

 

[AmpOverload]

I'm disappointed to see no comments about my last post. Did I misjudge interest in using P04-PCM PID information in the "GM PIDs" spreadsheet? If there's no enthusiasm for documenting those PIDs, I understand and will cease commenting about them.

@azswiss, do you still intend to update the spreadsheet based on recent findings (specifically, PCM Mode $22 PIDs $1155 and $12C5)?

@TJBaker57, I was specifically wondering if you think that PCM Mode $22 PID $1155 should still show units of "percent" in the spreadsheet, especially after the discussions about it earlier in this thread and especially since that spreadsheet entry shows that your data was the source. As I said in my last post, I think that the units should be "volts", with equation adjusted accordingly, but maybe it doesn't behave the same way on non-P04 PCMs.

I'm OK with whatever folks here want to do, but I certainly don't want to spend my time needlessly documenting PID behavior here either.

 

[azswiss]

@azswiss, do you still intend to update the spreadsheet based on recent findings (specifically, PCM Mode $22 PIDs $1155 and $12C5)?

An updated version is in progress and will include all inputs. In parallel, I did a full PID rescan of my truck and will incorporate the results as well (12C5 is there!). It will also be reformatted to better reflect the range of vehicles represented.

 

[AmpOverload]

An updated version is in progress and will include all inputs. In parallel, I did a full PID rescan of my truck and will incorporate the results as well (12C5 is there!). It will also be reformatted to better reflect the range of vehicles represented.

Fantastic! Many thanks for the clarification! For the record, I'm in no hurry for a revised spreadsheet. I was just worried that silence from both of the recent players (you and @TJBaker57) might have meant a loss of interest in the activity.

I wish I'd done a full PID scan of the 2005(?) Avalanche way back in the day. I doubt I'll ever get another chance.

 

[TJBaker57]

I was just worried that silence from both of the recent players (you and @TJBaker57) might have meant a loss of interest in the activity.

I have noticed that at times these things take a good deal of time. Thoughts need time to settle and digest. Other related events occur and bring forth new questions. "Squirrel" syndrome occurs and I hop from this task to that thought to something unrelated entirely.

So in the past week or so I have rescanned my Yukon for the full count of 65535 possible PIDs. Also scanned the common PID areas of my TrailBlazer and 3 other P10 PCMs plus a P12 PCM. I had previously lost a lot of data files due to a phone self-reset where I had not backed it up! So I now have backed up copies of my re-scans. I still need to re-scan one block where my scan ran too fast and a message stepped on the preceding message(s) reply on 3 or 4 occasions.

Worked on my own spreadsheets a bit adding abilities here and there. There still remains much work to be done.

Recorded a couple of driving sessions to investigate that fuel usage message a bit. Also recorded some data at idle. For example my 4.2 TrailBlazer accrues about 27000 units (bits) per hour (extrapolated) at no load idle for that 83..0A parameter. About 73000/hr at roughly 2000 no-load rpm, and about 125000/hr rolling down the highway at 65 mph. All are extrapolated measures. Also saw that when I rapidly query that data directly in an app rolling down the highway it appears to intefere with my DIC value for instant fuel economy (in MPG). What all this adds up to I cannot yet say.

That 1155 PID I feel safe saying that a Tech2 uses that to display the fuel senders return voltage. At least on my TrailBlazer it does.

 

[AmpOverload]

So in the past week or so I have rescanned my Yukon [...]

Wow, you guys have been far more productive on OBD2 stuff than I have! My limited access to GM vehicles (especially when road-testing is required) is hindering progress. Apologies to all parties here if I appear to have been impatient. I know all too well how long these things can take!

Recorded a couple of driving sessions to investigate that fuel usage message a bit. Also recorded some data at idle. For example my 4.2 TrailBlazer accrues about 27000 units (bits) per hour (extrapolated) at no load idle for that 83..0A parameter. About 73000/hr at roughly 2000 no-load rpm, and about 125000/hr rolling down the highway at 65 mph. All are extrapolated measures. Also saw that when I rapidly query that data directly in an app rolling down the highway it appears to intefere with my DIC value for instant fuel economy (in MPG). What all this adds up to I cannot yet say.

I have not had a chance to record anything new on that suspected 'fuel use' ($82/$83+$0A) data point. My wild estimate on the formula was based on how far (in miles) that 'n' "units" of "fuel used" moved the vehicle and a rough estimate of 30 MPG for that vehicle. Initial calculations with my "WAG" formula on your data don't seem to be anywhere close to your "units per hour" figures, but I want to check everything more closely once again (and then yet again after I collect some new, more-complete data). Hopefully, GM isn't using 2 different formulas here!

Thanks for the update!

 

[TJBaker57]

@AmpOverload

So today I had the opportunity to do some more data gathering regarding fuel tank level. I still need to analyze the data though.

What I did was record all the serial data traffic during a fill-up from as near empty as I dared get. I had the Car Scanner ELM OBD2 app running and requesting the fuel tank level as PID 1155 and also the fuel tank level as functional address 82/12. Simultaneously I recorded a video of the dashboard fuel gauge.

As an aside, the Car Scanner app can not currently display the response for functionally addressed messages but that doesn't stop it from doing the requests and the simultaneously recorded data logfile dutifully captured the requests and responses. I have recently been in contact with the apps author and the ability to read these functionally addressed queries may be forthcoming in a future release.

The engine was left idling and so I should also expect to see fuel consumption in the serial data though I expect no surprises there. (quick sample just now shows 25200 bits/hr at idle)

During the fill the functionally addressed fuel tank level (82:83/12) ranged from $00 to $F4.

PID 1155 during the fill ranged from $08 to $E8. Prior to arriving at the filling station the value was seen to drop as low as $05 due to slosh.

The amount of fuel added was 17.26 gallons. It was not "topped off" but was ceased when the pumps auto shutoff activated. At the peril of my EVAP system I could have added more.

The fuel tank capacity as reported by the PCM is 70.02 liters or 18.497 US Gallons.

The video includes me calling out gallons 8 thru 17 as it progressed. Anyone nearby must have thought me daft. This should enable me to get a timestamp of sorts for the passage of gallons using the start time on the video plus the elapsed time. I would expect the pumps flow rate to be fairly linear throughout. Seen here in graph from Car Scanner App. As evident in the graph I have not yet altered the PID setup to display volts. Of course that change would not alter the graphic itself but just the legend or so I would think.

 

[AmpOverload]

So today I had the opportunity to do some more data gathering regarding fuel tank level.

Great info, @TJBaker57 -- thank you!

I feel like I'm not holding up my end of this "PID investigation" stuff because I still haven't had a chance to do more testing. But, whether it takes another week or a month, I will do it and report about it here.

Looking at your graph for PID $1155, one thing that catches my eye is how smooth the rise is compared to my 2 graphs with that PID. My graphs show distinct "stair-stepping" where the reported tank level sensor voltage rises in discrete amounts. At higher flow rates, this effect would undoubtedly tend to disappear, but it still caught my eye. If I get the chance, I'll try to record some tank-fill data from a pump at a gas station. Also, my graphs seem to show more noise in the $1155 replies. I wonder if the Car Scanner app is doing any filtering/smoothing for that graph. Probably not, but it just looks so darn "clean".

For the record, the tests I reported on above were done using a 2.5-gallon jerry can, so the flow rate is both inconsistent and (intentionally) low. But the marked points on my graphs do at least demarcate the start/stop of flow.

The video includes me calling out gallons 8 thru 17 as it progressed. Anyone nearby must have thought me daft.

Ha! I took special pleasure in reading that -- literally a LOL moment. I'm sure people have seen and/or heard me doing weird things over the many years I've been investigating various vehicles' OBD2 behavior, e.g. going back and forth down the driveway, over and over, monitoring transmission-related data points. I consider it just "par for the course". Innate curiosity is both a blessing and a curse.

Hoping I'll have something useful to add soon....

 

[TJBaker57]

wonder if the Car Scanner app is doing any filtering/smoothing for that graph. Probably not, but it just looks so darn "clean".

So with that in mind I used the raw OBD2 serial data in a spreadsheet, filtered for the PID 1155 responses and produced a graph. Equally clean.

 

[azswiss]

An update on the PID rescan I did on my 2003 Suburban (L59, 4x4); file attached below.

Notes:
1) The following range of PIDs was scanned: 221100 thru 2230FF. A 300ms delay was established between inputs. Responses were captured for each entry; in most cases there was just a single response. A number of entries resulted in 2 responses (1 Valid, 1 Invalid; see Need Further Study section below).

2) Responses were captured and categorized as follows:
- Valid: a single response was received with the following format:
6C F1 10 62 PIDbyte1 PIDbyte2 + data bytes + error check byte
(e.g. for PID 1100: 6C F1 10 62 11 00 + data bytes + error check byte)
- Invalid: a single response was received with the following format:
6C F1 10 7F 22 PIDbyte1 PIDbyte2 + data bytes + error check byte
- Need Further Study: two responses (1 Valid & 1 Invalid) were received

3) The file contains 5 tabs as follows: Full List, Valid, Need Further Study, Invalid, Rev 4 PID List

4) PID description, reference vehicle & data source are listed based on comparison with the Rev 4 PID list. In the event that multiple entries exist for that specific PID then "Multiple" is entered in the appropriate field(s).

This is a work in progress. One particular challenge; need to work out how best to capture & present PIDs/response variations across multiple platforms (by model? engine? PCM? other?).

Comments & suggestions welcome!

 

[AmpOverload]

An update on the PID rescan I did on my 2003 Suburban (L59, 4x4); file attached below.

@azswiss: Lots of potentially interesting stuff in that spreadsheet -- thanks for posting it!

Some quick thoughts off the top of my head...

I was very glad to see that you include the "Invalid" tab, showing all the PIDs that returned a Mode $7F response code of $31 ("Request Out Of Range"). To me, knowing which PIDs were queried and are not supported by a vehicle is almost as important as knowing which PIDs are supported.

Including the full vehicle response (especially with OBD message headers enabled) is also very nice because it can be very useful when deciphering vehicle and/or PID behavior!

The "Need Further Study" tab showing 2 vehicle responses for each PID listed there is consistently showing a Mode $7F response code of $23. I suspect that @azswiss and @TJBaker57 are already aware of this, but I'll mention it in case anyone else following along hasn't encountered it and/or for future readers of this excellent thread: Response code $23 means "Routine Not Complete" and is further explained in SAE J2190:

This response code is used to indicate that the message was properly received and the routine is in process, but not yet completed.

I've seen Mode $7F replies with response code $23 many times in the past on GM Buicks (P04 PCMs) but I really need to delve into it more at some point because it's been on my "to do" list for years now!

This is a work in progress. One particular challenge; need to work out how best to capture & present PIDs/response variations across multiple platforms (by model? engine? PCM? other?).

From my experience, the list of supported "data points" is almost impossible to categorize based on any single criterion. IMHO, you probably need to include every bit of information you list (model, engine, PCM) and maybe even more. I'm thinking of a list like this:

• VIN (with at least the first 11 characters provided, possibly "anonymized" with "x" in the last several characters)
• model year (e.g. 2005)
• manufacturer (e.g. GM)
• model (e.g. Chevy Avalanche, Buick Century, etc)
• engine configuration (displacement, cylinder count, and "family")
• other configuration/options (e.g. "Limited" versus "Custom" on some Buicks)
• PCM family (e.g. "P01", "P04", "P10", "P12", "P59")
• PCM OSID (when/where it's known)

I need to pore over this spreadsheet and the others some more when I get a chance.

 

[azswiss]

@AmpOverload, all $7F responses were $22, no $23 responses were observed.

 

[AmpOverload]

@AmpOverload, all $7F responses were $22, no $23 responses were observed.

I beg to differ, good sir.

The Mode $7F response code is not the 1st byte after the "7F". A Mode $7F reply to a Mode $22 command is echoing the command first ($22 $PID-HI $PID-LO $01). The response code is the penultimate byte in the reply (when OBD message headers are enabled), i.e. the one right before the checksum byte.

The response codes on your "Need Further Study" tab (for the ones that were a Mode $7F reply) are all indeed $23. Just like the response codes on your "Invalid" tab are all $31 ("Request Out Of Range").

 

[azswiss]

Ah . . . .!

 

[TJBaker57]

@azswiss: Lots of potentially interesting stuff in that spreadsheet -- thanks for posting it!

Some quick thoughts off the top of my head...

I was very glad to see that you include the "Invalid" tab, showing all the PIDs that returned a Mode $7F response code of $31 ("Request Out Of Range"). To me, knowing which PIDs were queried and are not supported by a vehicle is almost as important as knowing which PIDs are supported.

Including the full vehicle response (especially with OBD message headers enabled) is also very nice because it can be very useful when deciphering vehicle and/or PID behavior!

The "Need Further Study" tab showing 2 vehicle responses for each PID listed there is consistently showing a Mode $7F response code of $23. I suspect that @azswiss and @TJBaker57 are already aware of this, but I'll mention it in case anyone else following along hasn't encountered it and/or for future readers of this excellent thread: Response code $23 means "Routine Not Complete" and is further explained in SAE J2190:

I've seen Mode $7F replies with response code $23 many times in the past on GM Buicks (P04 PCMs) but I really need to delve into it more at some point because it's been on my "to do" list for years now!


From my experience, the list of supported "data points" is almost impossible to categorize based on any single criterion. IMHO, you probably need to include every bit of information you list (model, engine, PCM) and maybe even more. I'm thinking of a list like this:

• VIN (with at least the first 11 characters provided, possibly "anonymized" with "x" in the last several characters)
• model year (e.g. 2005)
• manufacturer (e.g. GM)
• model (e.g. Chevy Avalanche, Buick Century, etc)
• engine configuration (displacement, cylinder count, and "family")
• other configuration/options (e.g. "Limited" versus "Custom" on some Buicks)
• PCM family (e.g. "P01", "P04", "P10", "P12", "P59")
• PCM OSID (when/where it's known)

I need to pore over this spreadsheet and the others some more when I get a chance.

My standard Pidscan logfiles generate this sort of data and maybe more. At present I do not anonymize the VIN. And the VIN itself provides much of the specifics like engine code, year, etc.

I use some mode $09 requests to provide such information to include the calibrations as well.

With regard to $7F responses here is a peek at my a recent scan of my Yukon and in particular some conditional formatting that highlights where there are $7F responses that are NOT reason code $31. It is seen here that on some occasions the $7F response is followed immediately by a positive response. I see bith $7F:22 and $7F:23 responses.



Other columns list the positive responses with highlighted cells for PIDs already defined in the Torque Pro extended PID set.
There is even a feature that generates a csv file for import into Torque Pro of all PIDs that gave a positive response.
Somewhere on this site that Google spreadsheet is linked and discussed but I cannot at the moment remember which of my discussions that is. Here it is again...

GMTN_PID+DTC_Scanning

PID Scan Generator PLEASE NOTE: This will NOT work for modules using CANBUS This is written for modules using single wire serial data J1850 VPW. Enter starting PID as hex in cell A2, ending PID as hex in A3,copy A5 to serial terminal macro. NOTES: There is a maximum of 0x15AA PIDs. If a larger v...

docs.google.com

 

[AmpOverload]

My standard Pidscan logfiles generate this sort of data and maybe more. At present I do not anonymize the VIN. And the VIN itself provides much of the specifics like engine code, year, etc.

To be clear, my "bullet" list above is essentially the data that I'd want to see, ideally, for each "PID" listed in a spreadsheet, to more easily help people determine other vehicles to which that "PID" might apply. Indeed, some of that data overlaps (like the VIN giving model year and possibly things like engine code and model/trim info), but it's probably better to have overlapping, redundant data than missing data.

With regard to $7F responses here is a peek at my a recent scan of my Yukon and in particular some conditional formatting that highlights where there are $7F responses that are NOT reason code $31. It is seen here that on some occasions the $7F response is followed immediately by a positive response. I see bith $7F:22 and $7F:23 responses.

Very interesting...

I don't recall if I've ever seen a Mode $7F reply with response code $22. I'll have to see if I can automate a log search. (The varying position of the response code makes that job trickier.)

Looking at your purple and green lines, I'm wondering: Whatever it is that's querying the vehicle (Torque Pro?), is it re-issuing the Mode $22 command after a Mode $7F reply or are those green lines that follow a purple line a case of the vehicle somehow replying without having seen a 2nd Mode $22 command?!?

 

[AmpOverload]

I don't recall if I've ever seen a Mode $7F reply with response code $22. I'll have to see if I can automate a log search.

It turns out that years ago for a 2004 Buick Century, I'd already generated a list of cases where I got a non-$31 response code in a Mode $7F reply to a Mode $22 command on the PCM. I'd just never taken the time to look into it any deeper!

Interestingly, the list has some overlap with the @azswiss PID scan spreadsheet and some in the $FCxx range that look like they could be part of the @TJBaker57 PID scan:

PID $12B4   Reply: 7F 22 12 B4 01 23
PID $12B5   Reply: 7F 22 12 B5 01 23
PID $12B6   Reply: 7F 22 12 B6 01 23
PID $12B7   Reply: 7F 22 12 B7 01 23
PID $12B8   Reply: 7F 22 12 B8 01 23
PID $12B9   Reply: 7F 22 12 B9 01 23
PID $12BA   Reply: 7F 22 12 BA 01 23
PID $12BB   Reply: 7F 22 12 BB 01 23
PID $12BC   Reply: 7F 22 12 BC 01 23
PID $12BD   Reply: 7F 22 12 BD 01 23

PID $1321   Reply: 7F 22 13 21 01 23
PID $1322   Reply: 7F 22 13 22 01 23
PID $1323   Reply: 7F 22 13 23 01 23
PID $1324   Reply: 7F 22 13 24 01 23

PID $1428   Reply: 7F 22 14 28 01 23
PID $1429   Reply: 7F 22 14 29 01 23

PID $FC00   Reply: 7F 22 FC 00 01 23
PID $FC01   Reply: 7F 22 FC 01 01 23
PID $FC02   Reply: 7F 22 FC 02 01 23
PID $FC03   Reply: 7F 22 FC 03 01 23
PID $FC04   Reply: 7F 22 FC 04 01 23
PID $FC05   Reply: 7F 22 FC 05 01 23
PID $FC06   Reply: 7F 22 FC 06 01 23
PID $FC07   Reply: 7F 22 FC 07 01 23
PID $FC08   Reply: 7F 22 FC 08 01 23
PID $FC09   Reply: 7F 22 FC 09 01 23
PID $FC0A   Reply: 7F 22 FC 0A 01 23
PID $FC0B   Reply: 7F 22 FC 0B 01 23
PID $FC0C   Reply: 7F 22 FC 0C 01 23
PID $FC0D   Reply: 7F 22 FC 0D 01 23
PID $FC0E   Reply: 7F 22 FC 0E 01 23
PID $FC0F   Reply: 7F 22 FC 0F 01 23
PID $FC10   Reply: 7F 22 FC 10 01 23
PID $FC11   Reply: 7F 22 FC 11 01 23
PID $FC12   Reply: 7F 22 FC 12 01 23
PID $FC13   Reply: 7F 22 FC 13 01 23
PID $FC14   Reply: 7F 22 FC 14 01 23
PID $FC15   Reply: 7F 22 FC 15 01 23
PID $FC16   Reply: 7F 22 FC 16 01 23

I suspect that some of these PIDs might only generate a proper reply based on having just run some sort of diagnostic routine.

And the only response codes I saw in that whole PID query session were $31 and $23. So the $22 response code cases you're seeing are novel and intriguing to me.

 

[TJBaker57]

Looking at your purple and green lines, I'm wondering: Whatever it is that's querying the vehicle (Torque Pro?), is it re-issuing the Mode $22 command after a Mode $7F reply or are those green lines that follow a purple line a case of the vehicle somehow replying without having seen a 2nd Mode $22 command?!?

Precisely, the vehicle PCM is responding to the single request message. That column with the green and purple lines is the source logfile as recorded by a serial terminal app which is running a simple multiline text macro of messages with a preconfigured line delay given in milliseconds.

The spreadsheet I linked to just recently does the generation of the macro (text) for me to then copy/paste into the serial terminals macro editor.

The spreadsheet also has tabs for generating a DTC scan and tabs for processing both the PID Scan and the DTC scan.

Going even further the spreadsheet has a tab for dealing with the HVAC module which does NOT provide mode $22!

 

[AmpOverload]

Precisely, the vehicle PCM is responding to the single request message. That column with the green and purple lines is the source logfile as recorded by a serial terminal app which is running a simple multiline text macro of messages with a preconfigured line delay given in milliseconds.

That multi-reply behavior is really strange! As seen in @azswiss' #536 comment above, SAE J2190 does say this about response code $22: "This request may elicit an affirmative response at another time." but it really should add ", uncommanded" to the end of that to make it clearer. In fact, the use of the words "affirmative response" to me means Mode $7F response code $00 (literally, "Affirmative Response"), not a response which is now "normal", i.e. with the Mode $22 offset command echo of $62! I think either GM is mis-interpreting SAE J2190 or I am! I don't think I've ever seen a second, uncommanded response to a physically addressed command before!

Going even further the spreadsheet has a tab for dealing with the HVAC module which does NOT provide mode $22!

I've never seen a GM node other than the PCM which supports Mode $22. They probably exist (they exist on some Ford vehicles), but I've yet to see one.

 

[TJBaker57]

I've never seen a GM node other than the PCM which supports Mode $22. They probably exist

The GMT360/370 BCM and LGM are two that support mode $22. I have working PIDs for both. Here is a request and response to/from a BCM (node $40) for the Passlock code value.



While we are at it, here are a flock of security related PIDs from a TrailBlazer BCM as seen in Torque Pro. Much of this I have yet to identify...

 

[Enroute]

Hi guys. Had to leave the forum for a couple of years due to health issue and just got well enough to get back involved. So impressed with the incredible amount of work completed. Phone got wet during my treatments so I lost all of my custom PIDS for my LM7 5.3l (did not back up my stuff, my bad). I have reinstalled all but my injector information and can not seem to find where I got it before. I know from years past that TJ has a LM7 PCM so I hope ou can help me. Thanks and it is good to be back.

 

[Enroute]

Anybody else ever get a resolution to the issue addressed in post #121 & #125 on the GM PID for misfire current and history for cylinder 1 & 2 or is it just my LM7 that has this? So good to be back.

 

[TJBaker57]

Hi guys. Had to leave the forum for a couple of years due to health issue and just got well enough to get back involved. So impressed with the incredible amount of work completed. Phone got wet during my treatments so I lost all of my custom PIDS for my LM7 5.3l (did not back up my stuff, my bad). I have reinstalled all but my injector information and can not seem to find where I got it before. I know from years past that TJ has a LM7 PCM so I hope ou can help me. Thanks and it is good to be back.

Somehow this post and your next got past me entirely. I have no recollection of having seen them?

I do indeed still have my LM7 in the Yukon and I am fairly certain I have additional PIDs which I never have posted about. I need to get better organized.

 

[TJBaker57]

So the recent talk of PID 1155 peaked my interest. I decided to get back into this and took a 2003 P10 PCM and read out the memory that is exposed to service 23.

After doing a few low resolution scans to isolate the target memory blocks I created a macro to do a full scan on the exposed memory. At 200 ms per line the scan takes about 90 minutes.

I ran 3 of these scans, the first was just a baseline with the key at ACC. The second scan was with the key in RUN. Then for the third scan I set the fuel level gauge at the midpoint using a 10 turn potentiometer. The key was at RUN.

The data was loaded into a spreadsheet for analysis. I will spare the details unless someone really wants to know but in the end I have isolated 7 memory locations where the fuel level sensor data is homed and manipulated.

I compared the data in these 7 memory locations with the output of PID 1155. It leaves no doubt that for this PCM and Calibration PID 1155 is not the raw sensor signal.

I did locate a memory address with what appears to be the raw voltage from the sensor. It matches a simultaneous DMM reading and has no evident lag which is clearly seen in PID 1155 as well as a handful of other memory locations.

The graph seems to show that PID 1155 is the final result of the manipulation of the sensor data. It is a little difficult to see the Y axis labels with the legend placement but that is out of my control.



Mem FF95CE is the raw sensor signal in this particular PCM. It is the only memory location I found the raw signal voltage. It is seen that this memory location responds instantly to a change in sensor signal to the PCM.

There are 3 memory locations that appear to be interim points as the signal is transformed towards the output value of PID 1155.

PID 1155 is joined by 3 memory locations. I suspect one of these is the actual memory address of PID 1155. It takes around 30 seconds for these data values to arrive at the endpoint.

Fairly useless information here but I like seeing more of what goes on behind the scenes.

 

[kastein]

I'm disappointed to see no comments about my last post. Did I misjudge interest in using P04-PCM PID information in the "GM PIDs" spreadsheet? If there's no enthusiasm for documenting those PIDs, I understand and will cease commenting about them.

@azswiss, do you still intend to update the spreadsheet based on recent findings (specifically, PCM Mode $22 PIDs $1155 and $12C5)?

@TJBaker57, I was specifically wondering if you think that PCM Mode $22 PID $1155 should still show units of "percent" in the spreadsheet, especially after the discussions about it earlier in this thread and especially since that spreadsheet entry shows that your data was the source. As I said in my last post, I think that the units should be "volts", with equation adjusted accordingly, but maybe it doesn't behave the same way on non-P04 PCMs.

I'm OK with whatever folks here want to do, but I certainly don't want to spend my time needlessly documenting PID behavior here either.

My apologies, I just was working on various other projects and not checking my email or forums. I come bearing news of PID 1338 - at least on a '03 LQ4 ECU from a Savana 3500, it is exactly as expected. I just got around to digging out my spare ECU connectors, stole a few pigtails off them and inserted them into the correct positions (C2/green, pin 73 and its appropriate ground reference pin, C1/blue pin 23 or C2/green pin 80 depending on which is free in your particular harness) and I see 252ish (so near 0xFF fullscale) LSB counts with the pin floating at 5V Vref, as expected, and 0 LSB counts with them connected together to produce a 0V signal input.

I also got my secondary/transfer fuel pump from the junkyard (it's off a '87 Ford E250, lol) and now all I have to do is plumb and wire it all and calibrate my secondary tank level sensor tables in the ECU with hptuners and I should have access to my full 34 gallons of fuel without pulling over and screwing around with it to start the siphon from one to the other. But that's not really exactly relevant to the thread, it was just my motivation to embark on this research project.

 

[AmpOverload]

So the recent talk of PID 1155 peaked my interest. I decided to get back into this and took a 2003 P10 PCM and read out the memory that is exposed to service 23.

Very interesting... It's bizarre how much PCM manipulation is being done for such a simple concept. I'm starting to appreciate the simplicity of fuel indicators where the level is ascertained simply by looking at the side of a translucent tank!

I've used Mode $23 to successfully query memory within various GM (and Ford) nodes. But on GM nodes, I have no actual "purposeful" assignments to any memory address. Frankly, I was always concerned that memory address assignments would vary far more (by vehicle model and maybe even by OSID among otherwise-identical models) than, say Mode $22 PID assignments, Mode $2A DPID assignments, and Mode $3C block assignments, so I've focused more on those 3 modes than I have on Mode $23. But I may eventually find some time to play around with Mode $23 more, so I appreciate you posting about your investigations, even if there are only a handful of people who are this deeply into it.

I don't have a bench setup for testing ECUs, even though I've been thinking about it for many years. I hope to someday remedy that, which will greatly expand my ability to investigate.

Of course, although I can read that memory address on a 2004 Buick Century...

Command: 23 ff95ce 01
  Reply: 6C F1 10 63 95 CE 00 00 00 00 AC

... it's virtually impossible that it would have the same meaning on this P04 PCM.

Functional Query $82+$0A (Fuel Use):

I've gathered some more data on this topic but haven't posted yet because:

• I'd like to get some better data (specifically from a longer trip).
• I haven't had time to compose a coherent analysis of my current data.

But I hope this will happen soon.

 

[AmpOverload]

Re: Functional Query $82+$0A (Fuel Use)

Recorded a couple of driving sessions to investigate that fuel usage message a bit. Also recorded some data at idle. For example my 4.2 TrailBlazer accrues about 27000 units (bits) per hour (extrapolated) at no load idle for that 83..0A parameter.

I'll mention results from some of my testing, despite my inability to show any data from a longer on-road test...

Data from 2 different recordings of a warmed-up, idling 2004 Buick Century (3.1-liter, V6) engine gives anywhere from 8.14 to 8.93 units/second. Extrapolating, that's 29304 to 32148 units per hour. Determining the proper formula might be a bit tricky.

 

[TJBaker57]

Data from 2 different recordings of a warmed-up, idling 2004 Buick Century (3.1-liter, V6) engine gives anywhere from 8.14 to 8.93 units/second. Extrapolating, that's 29304 to 32148 units per hour. Determining the proper formula might be a bit tricky.

Indeed, this one has been in my list for a couple of years now. Every so often I take another look.

Frankly, I was always concerned that memory address assignments would vary far more (by vehicle model and maybe even by OSID among otherwise-identical models) than, say Mode $22 PID assignments, Mode $2A DPID assignments, and Mode $3C block assignments, so I've focused more on those 3 modes than I have on Mode $23. But I may eventually find some time to play around with Mode $23 more, so I appreciate you posting about your investigations, even if there are only a handful of people who are this deeply into it.

.......................

Of course, although I can read that memory address on a 2004 Buick Century...

Command: 23 ff95ce 01
Reply: 6C F1 10 63 95 CE 00 00 00 00 AC

... it's virtually impossible that it would have the same meaning on this P04 PCM

True enough. As with my explorations of TCCMs I have now scanned three different P10 PCMs and have located the presumed ADC locations in each of them. A 2002, a 2003, and a 2005 model year. Have not looked at which calibrations and OS are in use though that data is in the logfiles. Two of the ADC locations are just a few bytes apart and the third is further away. $FF9FCE, $FF95CA, & $FF9668.

The number of fuel level related locations I found on successive P10 PCMs were less than the first PCM I scanned (a 2003), though I will say that perhaps I didn't explore the additional PCMs as thoroughly as the first.

And that 1155 PID,,,, based on TrailBlazer PCMs I have plus data otherwise gathered it is supported in P10 PCMs in 2002, 2003 but NOT in 2004 or 2005. In 2004 & 05 they sort of copied a mode $01 PID, $2F. So we have a $22002F there in 04 and 05 which behaves like the $1155 does in 02 and 03.

Then in 2006 they went to a P12 PCM and reinstated the $1155 PID dropping the $2F PID.

I am currently away from home for the day and I don't have a data recording to look at but if memory serves this 2006 P12 $1155 behaves differently than the earlier $1155 in 02 and 03. But having looked at so much in recent days the grey matter is getting a little scrambled!

2007 looks like they go back to that $22002F PID and again dropped the $221155. I might confirm that today as there is a 2007 here where I am at today.

I chuckled at your comment about writing a cohesive post. If I waited for that I wouldn't get anything posted.

The vast bulk of this is pretty useless information. One takeaway may be to know that PIDs $221155 and $22002F are manipulated values, not the actual sensor return signal.

Thus far I have only scanned benchtop PCMs. If I scan my own 2002 P10 and locate the requisite data perhaps I can come up with a better equation to use for $221155.

 

[AmpOverload]

Indeed, this one has been in my list for a couple of years now. Every so often I take another look.

As always, good info, TJ... thanks!

The whole issue of determining 'fuel tank fill level' really is a mess, isn't it? It's unfathomable that these psychotic auto manufacturers won't just use Mode $01 PID $2F ("Fuel Level Input", 0-100%), which has been defined by SAE J1979 since at least April 2002, and probably long before then. Of the GM vehicles I've tested, none support that PID, including a 2005 Avalanche (which was weird in its own way -- supporting a Mode $22 PID $21 ["Distance Travelled While MIL is Activated"] command but rejecting a Mode $01 PID $21 command -- WTH, GM???).

As for the Functional $82+$0A ("Fuel Use") formula, I'm thinking of a couple of ways to try to determine it. One would be to assume stoichiometric air-to-fuel ratio and just use MAF to compute fuel burn. The other way would involve monitoring fuel injector pulse width. I suspect that GM's calculation must be using one method or the other, since there's no fuel flow sensor on the GM vehicles on which I typically test but they do respond to $82+$0A. The problem I have at the moment, besides lack of enough test data, is that while I can collect the necessary data, I'd like to somehow automate calculations made on that data. But I'm not sure how much time I want to spend on this particular data value because it's really more of a curiosity and doesn't help me repair a broken vehicle. Time will tell....

 

[TJBaker57]

But I'm not sure how much time I want to spend on this particular data value because it's really more of a curiosity and doesn't help me repair a broken vehicle. Time will tell..

I know the feeling..

Some things I pursue out of curiosity and the notion that I may learn something that is useful elsewhere in diagnostics. That has always been my intended focus, diagnostics with an eye towards frugality/economy.

I'd like to somehow automate calculations made on that data.

Elsewhere in the forum is my first Arduino project which decodes J1850 VPW traffic and can also send messages. My intention was to add sensors here and there simply for monitoring stuff the vehicles don't. I use a phone app with custom PID to read the added sensor(s).

Lately I have toying with the idea of adding an SD card to the project and then I could code stuff to monitor various messages, perform calculations and whatnot and write the results to the card.

supporting a Mode $22 PID $21 ["Distance Travelled While MIL is Activated"] command but rejecting a Mode $01 PID $21 command -- WTH, GM???).

Speaking of weird GM stuff. Here is an unrelated item I forgot to mention earlier. Scanned a P12 PCM the other day using service/mode 23. Remember that talk of $7F:23 messages that were immediately followed by a valid response to the ONE query message?? Well I get 481 consecutive such messages in a particular P12 PCM memory range. How is "routine not complete" appropriate for a direct memory read query!? My queries were sent at 300 ms timings so both responses fit in that timeframe.

 

[AmpOverload]

Some things I pursue out of curiosity and the notion that I may learn something that is useful elsewhere in diagnostics. That has always been my intended focus, diagnostics with an eye towards frugality/economy.

We are "cut from the same cloth".

Elsewhere in the forum is my first Arduino project which decodes J1850 VPW traffic and can also send messages. My intention was to add sensors here and there simply for monitoring stuff the vehicles don't. I use a phone app with custom PID to read the added sensor(s).

Lately I have toying with the idea of adding an SD card to the project and then I could code stuff to monitor various messages, perform calculations and whatnot and write the results to the card.

Very cool! I don't know how, but I somehow missed that. (I have too many hobbies/projects and read too many websites, so I probably miss/forget a lot!)

(Time passes as I search for and read info about your cool Arduino project...)

Wow! We've been treading a lot of the same ground in parallel universes, it seems! And in more ways than one -- OBD2 VPW vehicle diagnostics & VPW hardware designs.

So much to say about all this, but I will keep it short here to avoid boring everyone who isn't an OBD2 VPW nerd like us.

Actually, I think I'll post in your "Arduino Chat" thread about things related to VPW circuitry, once I compose something sane.

As for doing the data computations, I really like your Arduino + SD card idea and might one day pursue a hardware route like that myself (more to say about that in the Arduino thread). I think that could work nicely for your testing. In my case, however, I already have years of development into a program that runs under Linux. So my diagnoses and recordings are typically done on a laptop and I've developed a very efficient method of making that work, including a remote control that I can use in-vehicle to control the laptop. So, for now, I'm thinking of ways to improve my post-recording, post-processing software (the same software that generated the fuel-related graphs that I posted earlier) to do the computations, but in a generic way so as to be useful for more than just this "experiment" with Fx $82+$0A. But, of course, there is only so much time in the day, so we'll see where that goes....

Speaking of weird GM stuff. Here is an unrelated item I forgot to mention earlier. Scanned a P12 PCM the other day using service/mode 23. Remember that talk of $7F:23 messages that were immediately followed by a valid response to the ONE query message?? Well I get 481 consecutive such messages in a particular P12 PCM memory range. How is "routine not complete" appropriate for a direct memory read query!? My queries were sent at 300 ms timings so both responses fit in that timeframe.

Although my logs of Mode $23 commands on GM vehicles are very limited, I just took a look through them and saw no such behavior. That is indeed very strange! Glad you posted it! I wish I had kept a list of all the GM weirdness and outright specification/standards violations I've seen over the years.

 

[AmpOverload]

Ongoing Search For Equation For "Fuel Use" Data

I still lack a long-running data collection to better understand the "fuel use" data point (Functionally Addressed Prim+Sec $82+$0A) on GM vehicles.

However, I recently collected data on a short (2.9-mile) trip on a 2005 Buick LeSabre (3.8-liter, 6-cylinder engine).

I crudely extracted the data and imported it into a spreadsheet to try to determine a formula for the vehicle-reported fuel use versus real-world fuel use. My first attempt took the Mass Air Flow (MAF) data points from the recording and, using the stoichiometric air-to-fuel ratio (by mass) for gasoline engines, computed the expected fuel burn at each successive point where MAF was reported by the vehicle (517 total points).

Basically, I take the MAF (in grams/second) divide by 14.7 (the "stoich" air:fuel ratio, to convert air mass to gasoline mass), divide by 454 (to convert grams to pounds), divide by 6.17 (to convert pounds of gasoline to US gallons), and multiply by the time difference (in seconds) between this MAF reading and the last one. This gives me fuel use in US gallons between successive MAF reports:

increm fuel use (USgal) = MAF (g/s) / 14.7 / 454 / 6.17 * deltaT

The sum of the 517 computations for fuel use is 0.12985653 US gallons (0.49156042 liters). That's under ideal conditions; real-world usage would be higher, of course.

Over that time, $82+$0A ("fuel use") increases by 9698 units.

9698 / 0.12985653 = 74682.42

Unsurprisingly, that's not a very "neat" value for a formula. But it's close enough to a typical, nice-round-binary divisor of 65535 (2^16 - 1) that I wonder if the formula might be "USgal/65535". In other words, if that formula is accurate, the vehicle thinks I burned 9698/65535 (0.14798) USgal of fuel on that 2.9-mile trip. That would be about 19.6 MPG -- not unreasonable.

I began to investigate fuel use from a different angle, using a recording of fuel injector pulse widths on the same vehicle. But that quickly became too involved (trying to determine fuel use from injector PW) and I decided that I can't justify the time spent on researching that, at least for now, since this formula is mostly a curiosity.

The bottom line is that this analysis lacks enough data to come to any real conclusion about a formula for this data point. Over time, I hope to collect more data and possibly re-visit this.

 

[AmpOverload]

@TJBaker57: Late yesterday, I saw some interesting online information (thanks @Mooseman!) about GM ABS nodes and I was thinking about posting about it in this thread. But I'm not sure if this thread is the appropriate place to post about non-PID vehicle data points (e.g. Mode $2A DPIDs), given the title of the thread and the fact that Torque Pro (IIUC) doesn't support Mode $2A commands/replies. Since it's your thread, I'll defer to you. If you'd prefer not to taint this thread with non-Torque-relevant info, I'll gladly post elsewhere (suggestions welcome). Thanks!

P.S. Great job helping cope1980 with his BCM issue!

 

[TJBaker57]

@TJBaker57: Late yesterday, I saw some interesting online information (thanks @Mooseman!) about GM ABS nodes and I was thinking about posting about it in this thread. But I'm not sure if this thread is the appropriate place to post about non-PID vehicle data points (e.g. Mode $2A DPIDs), given the title of the thread and the fact that Torque Pro (IIUC) doesn't support Mode $2A commands/replies. Since it's your thread, I'll defer to you. If you'd prefer not to taint this thread with non-Torque-relevant info, I'll gladly post elsewhere (suggestions welcome). Thanks!

P.S. Great job helping cope1980 with his BCM issue!

If one reads this whole thread it can be seen that I have sometimes strayed myself, such as including functionally addressed queries which as you know are not true "PIDs". I even started another thread I thought would more specifically target that arena, ELM327 & Class 2 Serial Data.

This service $2A data can be useful. I have used $2A for checking individual wheel speed data from an EBCM. And just yesterday I learned how to use $2A and $3B to correct a BCM/SDM issue I reset an SDM key in a BCM with only my little bluetooth OBD2 adapter and a serial data terminal No fancy scantool required.

But as you say, where does such discussion belong? Should we consider opening a more wide ranging thread for general discussion of such endeavors/experiments?

As for Torque Pro I actually did come up with a back door way to make some use of a DPID in Torque Pro. At least for my HVAC module. In doing service $23 scans of the HVAC module memory I came upon a location that holds what appears to be the most recent DPID configured with service $2C. In Torque Pro we can do service $23 reads. Plus Torque Pro has a "Push Button" display type where one or more messages can be sent from a dashboard. So I load up some service $2C DPID configuration messages with a Push Button on the Torque Pro dashboard and read the PID data out with service $23 memory reads. What a hack! But this lets me read out things like the HVAC actuator counts and such.

And here I am straying again. I think we do need to open another thread with a more wide ranging arena.

 

[AmpOverload]

I think we do need to open another thread with a more wide ranging arena.

I agree that a new thread is probably appropriate. Should I start one or would you prefer to be the thread "owner"? (I'm fine with either choice.)

I guess the same "Scan Tools" sub-forum is the appropriate place for such a thread, even though it seems to not really clearly match the "rules" for that sub-forum.

I even started another thread I thought would more specifically target that arena, ELM327 & Class 2 Serial Data.

Based on the title ("ELM327 & Class 2 Serial Data"), I would probably have posted more of my observations there instead of in the "More PIDs for Torque App" thread, but this comment from that 1st thread did/does dissuade me:

The focus of this thread will be the general communications across the serial bus that is not the result of a data request by a tool (though that is also possible) but the normal operational messaging needed for the system to function as a whole.

To me, this says that the thread subject is functionally (not physically) addressed message traffic.

So I guess it makes sense to figure out a name for the new thread. I'm thinking something like "VPW-Bus Message Traffic & Vehicle Data Points". Or is that too broad? Is "VPW" too restrictive, i.e. should we include non-VPW (CAN, etc)? Suggestions welcomed.

This service $2A data can be useful. I have used $2A for checking individual wheel speed data from an EBCM.

I use WSS (Wheel Speed Sensor) data from the ABS all the time, including just a couple weeks ago to fix a WSS-related DTC that seems to have been triggered by a poor connection at the wheel end.

And just yesterday I learned how to use $2A and $3B to correct a BCM/SDM issue I reset an SDM key in a BCM with only my little bluetooth OBD2 adapter and a serial data terminal No fancy scantool required.

I've never used Mode $3B ("Write Data Block" for those following along) -- too chicken to do it on an actual vehicle, especially one that's not mine. Maybe one day when I finally go junkyard shopping for a spare PCM to bench test!

It's a shame how many people seem to think that a fancy/expensive scantool is needed to do even simple things like reading ABS DTCs. I've given up trying to convince people that, ignoring certain "edge" cases, it's almost all in the software.

As for Torque Pro I actually did come up with a back door way to make some use of a DPID in Torque Pro. At least for my HVAC module. In doing service $23 scans of the HVAC module memory I came upon a location that holds what appears to be the most recent DPID configured with service $2C. In Torque Pro we can do service $23 reads. Plus Torque Pro has a "Push Button" display type where one or more messages can be sent from a dashboard. So I load up some service $2C DPID configuration messages with a Push Button on the Torque Pro dashboard and read the PID data out with service $23 memory reads. What a hack! But this lets me read out things like the HVAC actuator counts and such.

You continue to amaze and astound me, TJ! I thought I was a dedicated investigator, but you're putting me to shame!

 

[TJBaker57]

agree that a new thread is probably appropriate. Should I start one or would you prefer to be the thread "owner"? (I'm fine with either choice.)

I guess the same "Scan Tools" sub-forum is the appropriate place for such a thread, even though it seems to not really clearly match the "rules" for that sub-forum.

I would think it doen't matter much who gets the ball rolling here.

And unless an admin or moderator has a better thought about where the discussion best belongs then Scan Tools seems most appropriate I would think. I am fairly certain that when creating a site such as this no one ever imagined doing or even discussing the sort of things we are getting into here.

Is "VPW" too restrictive, i.e. should we include non-VPW (CAN, etc)? Suggestions welcomed.

Speaking for myself I try to steer clear of CAN (ISO 15765-4 specifically). I felt that CAN is covered widely elsewhere and my niche is clearly SAE J1850-VPW.

makes sense to figure out a name for the new thread. I'm thinking something like "VPW-Bus Message Traffic & Vehicle Data Points

What's in a name?? A lot actually. I find I totally disregard some threads based solely on the name. Likely not a good policy but there it is.

Perhaps it is possible to not fret about it too much and as we go along we could have a moderator change the thread title for us if it seems appropriate??

It's a shame how many people seem to think that a fancy/expensive scantool is needed to do even simple things like reading ABS DTCs. I've given up trying to convince people that, ignoring certain "edge" cases, it's almost all in the software.

A big AMEN to that!