Outstanding! I was successfully able to create a macro based on lines 1-15 and got data. Very, very cool. Thanks!Anyone who has read through this thread will surely not be surprised that I have a spreadsheet or two for the purpose of scanning for PIDs.
Also mentioned in the thread somewhere is likely my recommendation of this app for the terminal of choice, especially since my spreadsheet(s) are built for the logfiles of the app.
Serial Bluetooth Terminal - Apps on Google Play
Terminal for serial devices connected with Bluetooth Classic / LEplay.google.com
In general, I am readying a Google spreadsheet that I use which given a starting value for PID generates a column which can be copied and pasted into the Serial Bluetooth Terminal app as a macro to be executed on your vehicles PCM, ECM, TCM, BCM or whatever.
The Serial Bluetooth Terminal app can save a logfile of the session. That logfile is simple text that can be selected, copied, and pasted into another tab on the same Google spreadsheet, and that tab will filter out the chaff and give a listing of the PIDs which the vehicle supports.
This process can not identify what data is being reported by each PID, it merely returns a list of PIDs available from the range that was scanned and the number of bytes returned by each PID.
I have also developed in a spreadsheet the ability to create the text of a .csv file in a format that can be imported by Torque Pro. Since at that stage the data each PID returns has not been idetified the equation will simply be either "A" or "(A<8)+B", the decimal equivalent of the modules response for further examination in Torque Pro. This I have not yet assembled in the one Google Spreadsheet mentioned, but it is currently in use in another spreadsheet and I just need to find it and copy the required functions over to the spreadsheet I am preparing as a one-stop solution for PID scanning.
Here are the beginnings, the scan generator, and the start of the logfile processing...
View attachment 101507
View attachment 101508
Here is a link to what I am working on. Currently shared as view only.
GMTN_PID+DTC_Scanning
docs.google.com
More PIDs for Torque App
- Thread starter TJBaker57
- Start date
We haven't gotten into the interpretation yet. I imagine a majority of the data you received to be what I call a "7F" response where the second to last byte of the line is "31" . This response indicates that the PCM does not support this PID, the "31" condition of a "7F" response means "out of range".
I just took a short walk here at 86°F and the sun is strong at 8200 feet elevation but I managed to think about this a bit and thought as a jump start I would upload a configuration file for the serial terminal app. A feature of the app is the ability to both export and import a configuration file (as text) that includes things like between character time delay, between line time delay, timestamp format and various other selections as well as any current macros. In this manner we would be working with the same settings which should guarantee compatibility with the spreadsheet.
I think I'm back up and running. The fans status with the original equation are not working. I'm not sure why I thought they were. They do show up green in the PID list and when the car is on shows 0.0, it does not change when the fans come on?
That is actually not surprising considering that the PID list they came from was for earlier vehicles.
I have found the range of PIDs from say 1100 to maybe 1139ish are what I refer to as "bit-mapped" PIDs where each bit represents a different parameter.
These PIDs seem to change from vehicle to vehicle.
Establishing a standard config baseline is a good idea. Working from your prior posts I have gone into the Terminal settings and set character time delay, between line time delay, timestamp format accordingly. In light of potential vehicle-to-vehicle PID variation vehicle details should be documented (e.g. 2003 Suburban 1500 L59 4L60E).
Question: Referring to the screen grab below from the DTC Scan Generator tab, what info is being requested from lines 8 - 11 (6A = Display??)? Lines 12 & beyond appear to looking for PCM DTC data.
Sorry for the slow response, been hammering at some of the spreadsheet.
As you noted it is wise to document vehicle specifics. After I had amassed a pile of scan data I found it was becoming difficult to identify which scan came from which vehicle. So I added lines 8 to 11 to do just that.
Line 8 is an ELM327 configuration command that sets the header to "68 6A F1". This is the header needed for the next three lines which are functionally addressed Mode 09 requests.
Line 9 is a Mode 09, PID 02 request which returns the VIN. It will come in 5 replies with 4 bytes per reply.
Line 10 is a Mode 09, Pid 04 request for the calibration numbers. For my 02 TrailBlazer I get 25 lines of reply. You can see where the between line delay is needed here as we are blindly running a macro that would interrupt the response stream and result in lost data.
Line 11 is a Mode 09, Pid 06 request for the calibration verification numbers. I get 6 lines for the 02 TrailBlazer here.
Adding these lines gives the vehicle details to some degree right there in the logfile.
We can entertain different ways of not exposing ones VIN of course. There are many options. One option is to make a copy of the spreadsheet for your own use and do your exploring there as an option. If using a public document it is not necessary to past in the entire logfile, you can selectively copy beginning below the VIN section.
Got it re: Lines 8-11. Looking at the Serial Terminal config file I found that individual command lines of each macro are concatenated into a single line. For instance: "pref_m3_value": "atz\natspa2\nath1\nats1\natal\natsh6cfef1\n19c2ff00",
How many command lines do you incorporate into a single macro before it gets unwieldy?
8000+ PIDS and/or DTC's makes for a massive file (ran to 20 pages in WORD!).
How many command lines do you incorporate into a single macro before it gets unwieldy?
8000+ PIDS and/or DTC's makes for a massive file (ran to 20 pages in WORD!).
Oh indeed I have some massive config files!! In this thread here we are concerned with PIDs. I also have scanned for possible DTCs and memory locations as well!!
I generally break down the scans to I think 8191 lines per macro. But I don't expect anyone to take this to the silly level I have! My full scans of a PCM have taken days.
Fortunately, as far as the PCM goes the vast majority of PIDs seem concentrated in certain ranges. For example, I have scanned my P10 PCMs (I have 3) from 0x0000 to 0xFFFF and found nothing between 0x1A88 and 0xFC00. Other modules use those ranges, the TCCM has PIDs in the 0x31xx range, the BCM seems to be in the 0x21xx range, the LiftGate Module shows up in the 0x41xx range and so on.
Somewhere squirreled away I have a spreadsheet formula that creates a text blob for pasting directly into the serial terminal apps config file so I can skip the manual creation of a macro in the app!
That's really interesting... So it may still work if I can get the bitmaps corrected somehow. Thanks!
Very likely it can be made to work. The real issue is locating the correct PID number and bit, and that is no trivial matter. For example, in my 2002 TrailBlazer P10 PCM, in the PID range of 1100 to 1139 I have 27 supported PIDs. At 8 bits per PID that's 216 possible locations!
When I am trying to locate something like this I make a dashboard screen in Torque Pro that contains the likely PIDs. Not for each bit but just the PID numbers. Then I try to trigger the action manually somehow. The easiest things are control buttons like the cruise control. You just press the button and see what changes on the Torque Dashboard. For bit-mapped PIDs the value in the Torque dashboard wil increase or decrease by the decimal value of the bit that changes. 1,2,4,8,16,32,64, or 128.
In the folder linked below is a config file for Serial Bluetooth Terminal which contains 8 macro buttons that cover the range of 0x000 to 0x7FFF. [Ooops, that should read "to 0xFFFF".]
Additional actions by the user would be to grant access in Android to your chosen location for logfiles and to remember to turn on data logging before running a scan.
The between line timing is set at 500 ms which means each macro would require about an hour and quarter to complete. If the timing were set faster there is a likelihood that data would be missed when the macro would run over responses from the PCM. There are requests that get an initial negative response from the PCM, not because the PID is not supported but because the data isn't quite ready yet. So the PCM responds with a "7F" & reason code 23 and then responds again moments later with the data.
Once triggered there is no way to interrupt the execution other than to disconnect from the bluetooth device.
When I scan a PCM in a vehicle I use a charger and only turn the key enough to get the PCM active. On my TrailBlazer that means I dont even go as far as the ACC. position, just until the battery charge indicator light turns on.
GMTNation - Google Drive
drive.google.com
Last edited:
Got it. Heading out shortly to tackle the first round (~400 lines).
Update 1: 426 lines (1100 - 12A9) took 7 minutes. 120 valid PIDs, 306 "7F"
Update 2: 2529 lines (12AA - 1C8A) took 2 hours 55 minutes. 96 valid PIDs, 2433 "7F"
Update 3: 2004 lines (1C8B - 245F) took 1 hour 20 minutes. 0 valid PIDs, 2004 "7F" @#$%^
Update 1: 426 lines (1100 - 12A9) took 7 minutes. 120 valid PIDs, 306 "7F"
Update 2: 2529 lines (12AA - 1C8A) took 2 hours 55 minutes. 96 valid PIDs, 2433 "7F"
Update 3: 2004 lines (1C8B - 245F) took 1 hour 20 minutes. 0 valid PIDs, 2004 "7F" @#$%^
Last edited:
I am still fiddling with the spreadsheet. Just totally revamped the PID generation tab. I think it is a good improvement. Now you enter a starting and ending PID as hex values and copy from a single cell, no need to drag.
Also have allowed user access to selected cells now.
Last edited:
As observed on your PCM, there appears to be a "dead zone" above 0x1A88 (no valid PIDs found in the range of 0x1A89 - 0x245F. Will finish the PCM scans tomorrow and then determine next steps.
Next steps could be pasting logfiles to the spreadsheet previously linked in post #358, and again here below. Public access is granted where it is needed. Any troubles, question, suggestions are most welcome.
The logfile should be posted to the "PIDScan Processing" tab, cell A5. Clear out previous logfile on Android using the menu item "named ranges" then tap the highlighted selection and clear. Desktop users with Chrome will see a "Custom" menubar selection with a function to clear the existing logfile. These are done simply to avoid having to select the range manually as sometimes the logfile can be quite large.
At the far right, starting at column Q, cell 4 is the text needed to create a csv file for import to Torque Pro. Beginning with Q4 select the cells down as far as you need then copy and paste into your text editor of choice, then save as a .csv filetype and place in the Android folder ".torque/extendedpids". This will make it accesible for import from inside the Torque Pro app.
GMTN_PID+DTC_Scanning
On my TrailBlazer I found there was a block of PIDs in the 0xFC00 to 0xFCFF range. I have about 230 something up there. What they may be for I have no ideas.
I was going to ask if you had a target range for me to check; will try these next. Will now move on to the spreadsheet.
Ran the scan for the 0xFC00 to 0xFCFF range; found an additional 16 valid PIDs (for a total of 232). I am attaching the valid PIDS & response findings (Mode+PID+01, Response) in a .TXT file.
Actually 231, you have 0x110E01 in there twice
153 at 1 byte
76 at 2 bytes
2 at 4 bytes
Excellent summary; appreciate all the work that went into these updates!Next steps could be pasting logfiles to the spreadsheet previously linked in post #358, and again here below. Public access is granted where it is needed. Any troubles, question, suggestions are most welcome.
The logfile should be posted to the "PIDScan Processing" tab, cell A5. Clear out previous logfile on Android using the menu item "named ranges" then tap the highlighted selection and clear. Desktop users with Chrome will see a "Custom" menubar selection with a function to clear the existing logfile. These are done simply to avoid having to select the range manually as sometimes the logfile can be quite large.
At the far right, starting at column Q, cell 4 is the text needed to create a csv file for import to Torque Pro. Beginning with Q4 select the cells down as far as you need then copy and paste into your text editor of choice, then save as a .csv filetype and place in the Android folder ".torque/extendedpids". This will make it accesible for import from inside the Torque Pro app.
GMTN_PID+DTC_Scanning
Update: Defintely going to have to read up on Excel formulas!!
Last edited:
Well such as it is I have put together a downloadable file of PIDs for import to Torque Pro. Once again I will state that not all of these will work for varying years and engines. I can only say which ones work for my 2002 4.2. Also, any PID with a question mark in the name or shortname is not verified. Some of those are just a guess! There's only a handful of these.
The headers used in this file are intended for vehicles on the SAE J1850 VPW protocol. These headers will not work for CANBUS vehicles. Some of the PIDs with a header of 6C10F1 might work if the headers were changed to Auto instead. Those with headers other than 6C10F1 simply won't work on CANBUS.
For anyone who has a decent working setup in Torque I would advise only loading these into a new vehicle profile created for the prupose of testing these out. Set that new profile properties to use its own dashboards and PIDs. It's too much trouble to get your gauges all set up as you want them to risk having something go haywire and having to start all over again. BTDT.
drive.google.com
The headers used in this file are intended for vehicles on the SAE J1850 VPW protocol. These headers will not work for CANBUS vehicles. Some of the PIDs with a header of 6C10F1 might work if the headers were changed to Auto instead. Those with headers other than 6C10F1 simply won't work on CANBUS.
For anyone who has a decent working setup in Torque I would advise only loading these into a new vehicle profile created for the prupose of testing these out. Set that new profile properties to use its own dashboards and PIDs. It's too much trouble to get your gauges all set up as you want them to risk having something go haywire and having to start all over again. BTDT.
GMTN_TorquePro~PIDs.csv
drive.google.com
Last edited:
So I have been at it again of late.
Previously I dug into the TCCM memory to uncover some parameters I decided would be useful. I found 2 that time around, the return voltages of the selector switch and the shift motor position sensor.
This time I had a look at the HVAC module. I have two vehicles with the automatic controls, RPO code CJ2, a 2002 TrailBlazer and a 2005 Yukon.
I have found a byte of memory that contains several status that may prove useful when diagnosing non functioning AC systems and at the very least one of the bits is the same between TrailBlazer and the Yukon. This bit reports the status of whether or not the PCM will engage the compressor based on various parameters like the lo pressure switch or ambient temperature or engine temperature etc.
The memory location is 0x0020F8 and the bit is #5. So the Torque Pro fields would be:
mode and PID:230020F801
Name:A/C Permission
Short Name: A/C Perm
Min value:0
Max Value:1
Scale:x1
Unit Type:
Equation:Lookup(Bit(A:5)::0='NO':1='YES')
Header:6C98F1
This has only been tested on the aforementioned vehicles with automatic controls. I have no idea if this will work elsewhere though I suspect it will since it works on my vehicles that are 3 years apart.
Other items in this same byte are the lo pressure switch status, the compressor feedback signal and something that engages when both left and right temp settings are at the lowest setting. Whatever this third mentioned item is it seems to coincide with the automatic operation of a recirc mode.
Previously I dug into the TCCM memory to uncover some parameters I decided would be useful. I found 2 that time around, the return voltages of the selector switch and the shift motor position sensor.
This time I had a look at the HVAC module. I have two vehicles with the automatic controls, RPO code CJ2, a 2002 TrailBlazer and a 2005 Yukon.
I have found a byte of memory that contains several status that may prove useful when diagnosing non functioning AC systems and at the very least one of the bits is the same between TrailBlazer and the Yukon. This bit reports the status of whether or not the PCM will engage the compressor based on various parameters like the lo pressure switch or ambient temperature or engine temperature etc.
The memory location is 0x0020F8 and the bit is #5. So the Torque Pro fields would be:
mode and PID:230020F801
Name:A/C Permission
Short Name: A/C Perm
Min value:0
Max Value:1
Scale:x1
Unit Type:
Equation:Lookup(Bit(A:5)::0='NO':1='YES')
Header:6C98F1
This has only been tested on the aforementioned vehicles with automatic controls. I have no idea if this will work elsewhere though I suspect it will since it works on my vehicles that are 3 years apart.
Other items in this same byte are the lo pressure switch status, the compressor feedback signal and something that engages when both left and right temp settings are at the lowest setting. Whatever this third mentioned item is it seems to coincide with the automatic operation of a recirc mode.
Several days ago I posted about reading the status "A/C Permission" on my two GM vehicles with CJ2 automatic controls. At the time I thought I was expanding on what I had previously posted about various A/C data parameters. Looking back through the thread now it appears I have not previously posted much of anything for A/C parameters beyond the high pressure. Fell through the cracks I guess.
Perhaps I was unsure about what I had. I have recently done more research and am more confident of what I am seeing.
The first one here frequently appears first before the A/C relay is commanded on. The technical details of what it is I do not know, I just see its' behaviour.
Name:~A/C Request (Pid 1100 Bit 1)
ShortName:A/C Request
ModeAndPID:0x22110001
Equation:Lookup(bit(A:1)::1='ON':0='OFF')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
These next two seem to be the same thing just appearing in two different PIDs, one in the range where transmission PIDs are generally seen. They both indicate that the PCM has activated the A/C relay which should send power to the compressor clutch. These both go high even if the relay is removed so it clearly is not proof that power has actually been sent to the clutch, just an indication that the PCM believes it has grounded the control circuit of the A/C relay.
Name:~A/C Relay Command (PID 1110 Bit 2)
ShortName:A/C Relay
ModeAndPID:0x22111001
Equation:Lookup(Bit(A:2)::0='OFF':1='ON')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
Name:~A/C Clutch Request (PID 1954 Bit 4)
ShortName:A/C Clutch
ModeAndPID:0x22195401
Equation:Lookup(Bit(A:4)::0='OFF':1='ON')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
The foregoing PIDs are mode 22 requests, the type normally used for acquiring data. The next ones use a mode 23 direct memory read to get data otherwise unavailable at least without onerous methods. As such I again must say I can only state that these work on my 2002 with factory calibrations. Eventually I will grab HVAC modules of varying years from the Upull for the purpose of nailing down these data points.
This one is the status line coming back to the PCM from the clutch. I believe it carries the 12 volts that is sent to the clutch back to the PCM as a feedback signal confirming the relay has indeed closed. In the wiring diagrams it looks to be connected after the compressor thermal protection switch as well so if that opens this signal should drop out.
Name:~A/C Clutch Feedback Signal
ShortName:A/C FDBK
ModeAndPID:0x230020F801
Equation:Lookup(bit(A:3)::0='Off':1='On')
Min Value:0
Max Value:1
Unit:
Header:6C98F1
Scale:x1
This should need no explanation, it is the status of the lo pressure switch.
Name:~A/C Low Pressure Switch
ShortName:A/C Lo Pres
ModeAndPID:0x230020F801
Equation:Lookup(bit(A:4)::0='Closed':1='Open')
Min Value:0
Max Value:1
Unit:
Header:6C98F1
Scale:x1
This too is self explanatory. This address works for my 2002 CJ2 but the address is slightly different for my 2005 Yukon. One other thing worth a mention. This is the first time I have come across a data parameter that reports in degrees Fahrenheit instead of Celsius. The TrailBlazer gives me Fahrenheit but the Yukon gives me Celcius. The Yukon address btw is 0x2475 instead of 0x24BA.
Name:~Cabin Inside Air Temp °F (2002 CJ2)
ShortName:Cabin Air °F
ModeAndPID:0x230024BA01
Equation:A-40
Min Value:-40
Max Value:215
Unit:°F
Header:6C98F1
Scale:x1
All of this is contained in my spreadsheet seen here...
docs.google.com
Perhaps I was unsure about what I had. I have recently done more research and am more confident of what I am seeing.
The first one here frequently appears first before the A/C relay is commanded on. The technical details of what it is I do not know, I just see its' behaviour.
Name:~A/C Request (Pid 1100 Bit 1)
ShortName:A/C Request
ModeAndPID:0x22110001
Equation:Lookup(bit(A:1)::1='ON':0='OFF')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
These next two seem to be the same thing just appearing in two different PIDs, one in the range where transmission PIDs are generally seen. They both indicate that the PCM has activated the A/C relay which should send power to the compressor clutch. These both go high even if the relay is removed so it clearly is not proof that power has actually been sent to the clutch, just an indication that the PCM believes it has grounded the control circuit of the A/C relay.
Name:~A/C Relay Command (PID 1110 Bit 2)
ShortName:A/C Relay
ModeAndPID:0x22111001
Equation:Lookup(Bit(A:2)::0='OFF':1='ON')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
Name:~A/C Clutch Request (PID 1954 Bit 4)
ShortName:A/C Clutch
ModeAndPID:0x22195401
Equation:Lookup(Bit(A:4)::0='OFF':1='ON')
Min Value:0
Max Value:1
Unit:
Header:6C10F1
Scale:x1
The foregoing PIDs are mode 22 requests, the type normally used for acquiring data. The next ones use a mode 23 direct memory read to get data otherwise unavailable at least without onerous methods. As such I again must say I can only state that these work on my 2002 with factory calibrations. Eventually I will grab HVAC modules of varying years from the Upull for the purpose of nailing down these data points.
This one is the status line coming back to the PCM from the clutch. I believe it carries the 12 volts that is sent to the clutch back to the PCM as a feedback signal confirming the relay has indeed closed. In the wiring diagrams it looks to be connected after the compressor thermal protection switch as well so if that opens this signal should drop out.
Name:~A/C Clutch Feedback Signal
ShortName:A/C FDBK
ModeAndPID:0x230020F801
Equation:Lookup(bit(A:3)::0='Off':1='On')
Min Value:0
Max Value:1
Unit:
Header:6C98F1
Scale:x1
This should need no explanation, it is the status of the lo pressure switch.
Name:~A/C Low Pressure Switch
ShortName:A/C Lo Pres
ModeAndPID:0x230020F801
Equation:Lookup(bit(A:4)::0='Closed':1='Open')
Min Value:0
Max Value:1
Unit:
Header:6C98F1
Scale:x1
This too is self explanatory. This address works for my 2002 CJ2 but the address is slightly different for my 2005 Yukon. One other thing worth a mention. This is the first time I have come across a data parameter that reports in degrees Fahrenheit instead of Celsius. The TrailBlazer gives me Fahrenheit but the Yukon gives me Celcius. The Yukon address btw is 0x2475 instead of 0x24BA.
Name:~Cabin Inside Air Temp °F (2002 CJ2)
ShortName:Cabin Air °F
ModeAndPID:0x230024BA01
Equation:A-40
Min Value:-40
Max Value:215
Unit:°F
Header:6C98F1
Scale:x1
All of this is contained in my spreadsheet seen here...
GMTN_Torque
A lot of great information here. I have found some of these PIDs and have seen others on other sites, but this is a great resource for those interested in developing interfaces with their vehicle.
I have a 2005 Chevy Tahoe that I built an Android tablet into the console and run Torque on. I use it for a variety of things including navigation, backup camera, music, weather and an alternative dashboard that gives me some things that the instrument cluster does, but also many things that it doesn't. It's also convenient to be able run an OBD diagnostic right there on the dash.
I've spent a great deal of time working out PIDs for things that I was interested in, so I thought I would contribute some that I have found that I didn't see in this thread. Here are the parameters for monitoring the TPMS. This allowed me to show all the tires at once on a graphical display instead of scrolling through them one at a time on the DIC.
I don't know how far beyond the 2005 Tahoe these will work. I do know that they don't work on my 2021 Escalade, but I haven't tried them on other GM vehicles.
I have a 2005 Chevy Tahoe that I built an Android tablet into the console and run Torque on. I use it for a variety of things including navigation, backup camera, music, weather and an alternative dashboard that gives me some things that the instrument cluster does, but also many things that it doesn't. It's also convenient to be able run an OBD diagnostic right there on the dash.
I've spent a great deal of time working out PIDs for things that I was interested in, so I thought I would contribute some that I have found that I didn't see in this thread. Here are the parameters for monitoring the TPMS. This allowed me to show all the tires at once on a graphical display instead of scrolling through them one at a time on the DIC.
| Long Name | Short Name | PID | Equation | Min | Max | Units | Header |
| Left Front Tire Pressure | TPMS LF | 22248e | A | 0 | 100 | psi | 6CA1F1 |
| Right Front Tire Pressure | TPMS RF | 22248f | A | 0 | 100 | psi | 6CA1F1 |
| Right Rear Tire Pressure | TPMS RR | 222490 | A | 0 | 100 | psi | 6CA1F1 |
| Left Rear Tire Pressure | TPMS LR | 222491 | A | 0 | 100 | psi | 6CA1F1 |
I don't know how far beyond the 2005 Tahoe these will work. I do know that they don't work on my 2021 Escalade, but I haven't tried them on other GM vehicles.
BTW thanks for working out the Selected Gear PID, I had been looking for that one for a while now.
Has anyone tried to read the odometer from the instrument cluster? That is another PID that I have been trying to find for a while now. I've figured out how to read and change it with an in-circuit programmer, but the PID still eludes me.
Has anyone tried to read the odometer from the instrument cluster? That is another PID that I have been trying to find for a while now. I've figured out how to read and change it with an in-circuit programmer, but the PID still eludes me.
A familiar name! Welcome aboard!
I have another thread here that deals with the normal serial data traffic and some things that I cannot get from a PID I can read through requests there. I have several of those types of things mixed in here as well. I assume you are looking for the odometer on your Tahoe. I will look at my Yukon and see what I have for odometer.
A familiar name?? I just joined this forum to respond to this thread. Do you know me from somewhere else? I have posted a bit on the TahoeYukon forums. Anyway, thanks for the warm welcome.
As for the odometer PID, I'll eventually figure it out, but it would be great if you have already found it.
Well I had a look and reminded myself what the issue here is. Even with the PID number we cannot request it from the cluster as it does not support mode 22 PID requests. For other modules like the TCCM and HVAC modules I locate the data I want in memory and use a mode 23 request for the data. However, the cluster does not allow unsecured memory reads either. So there's two walls we run into. I can make it return the odometer value in Torque Pro but the method is so outside the design intent of Torque Pro that it fouls up other PIDs that otherwise work fine. See the tire pressure of 5 psi in the screenshot as an example...
When I try entering a PID in Torque Pro that uses a functional address for the odometer Torque Pro does not recognize the response, maybe because it is 4 bytes long...
Here the response data value is 0x0142E10A. The equation takes the decimal value, divides by 64 for kilometers which I multiply by 0.621371 for mileage, in this case 205,443 miles.
Bingo! I added a bit of information some time ago to your post there of the tire pressure system PIDs. I added PIDs for reading the sensor ID numbers and may have talked about how to write those values to the proper memory locations when rotating wheels/tires.
Had someone elswhere on the web seeking PID details for the AIR system as used in the 2004 and onward 4.2 Vortec LL8. I don't have that system being an 02 but I grabbed an 06 PCM at the yard yesterday and hooked up a ten turn wirewound variable pot in place of the air pressure sensor. Some scanning and experimenting etc and have what I believe is the desired data.
Name: AIR pressure kPa
Mode&PID: 22151C01
Min:40
Max:150
Equation: (A/255)*110+40
Header 6C10F1
Name: AIR as Volts DC
Mode&PID:22154901
Min:0
Max:5
Equation:A/51
Header:6C10F1
Will add to the spreadsheet directly.
Name: AIR pressure kPa
Mode&PID: 22151C01
Min:40
Max:150
Equation: (A/255)*110+40
Header 6C10F1
Name: AIR as Volts DC
Mode&PID:22154901
Min:0
Max:5
Equation:A/51
Header:6C10F1
Will add to the spreadsheet directly.
Last edited:
Interesting. Didn't realize there were so many issues with getting it. Torque has a GM PID for odometer (22121E) in their extended set, but I haven't had any luck with that. However, I question its authenticity since the equation included returns a 16 bit value which is then multiplied by 16. While this allows values up to 1,000,000 which is what the memory space in the cluster is configured to hold, it doesn't have 0.1 or even 1 mile resolution. Instead it would jump 16 miles at a time.
Neither my 05 Yukon or my 02 Trailblazer support that PID number "121E". They respond with a 7F general response that the PID is "out of range". It is my suspicion that some of these PIDs that come with Torque Pro were user submissions and not ready for prime time shall we say. Take example the 4 that are purported to be for the 4 wheel speeds with a header of "ABS". Those 4 are totally bogus. Yes, they will return a speed value, updated very slowly and mostly show the same speed. That's because they aren't actually a response to the request from Torque Pro at all. The EBCM is yet another module does not support mode 22 so you cannot request doodleysquat from it the way Torque is trying to. What is really happening is the EBCM regularly broadcasts the vehicle speed over the class 2 serial data bus for use by any other modules that need that information. Given enough time the broadcast happens at the time Torque is expecting a reply and it uses that to update whatever wheel it was looking for at that time.
Is there a PID for the fan engagement? I mean the percentage of the duty cycle of fan clutch solenoid control?
I am not aware of such for the P10 PCM. I wouldn't be surprised if there were one buried in there but I have not come across one. There is a desired fan rpm and I suppose one could use that in conjunction with engine rpm to get an idea of what might be a duty cycle of the fan control module.
I have a 2006 P12 on the bench and see that the desired fan rpm PID 0x163F is not supported. However, there is a mode 22 PID that seems to appear only on the 2006, 0x1641 and this I believe to be a cooling fan duty cycle. Having just the PCM I cannot confirm this, that would require a running 2006 LL8. But if anyone with an 06 desires to try it I would try the mode&pid of 22164101 and the equation A/2.55 and a header of 6C10F1.