More PIDs for Torque App

[TJBaker57]

I have found the following to be INCORRECT.

Having gathered more data logs and observations I believe PID 1120 Bit 0 to be related to fuel status, as are other bits of PID 1120, but not a true indicator of Loop status as it does not follow true with pid 0103 which is defined as the standard for Fuel Status in SAE Standard J1979.

Name = Loop Status
PID = 221120
Scale = x1
Units =
Equation = Lookup(Bit(A:0)::0='Open':1='Closed')
Header = Auto

 

[TJBaker57]

A little more on that Loop Status PID...

I did a couple test drives with the Tech2. Also checked and verified that the Tech2 does not load the fuel status "standard pid" of 0103 at all. So it is using something else, maybe the bit I am questioning. What I discovered yesterday is that the Tech2 reports closed loop operation even when in power enrichment or full decel with injector shutoff! This is the same behaviour my previously reported PID with Lookup(Bit) does. The standard fuel status pid of 0103 (that's what Torque displays as fuel status) indicates open loop at these times.

Anyone have ideas why this would be this way??

I plan to have another look at the data I recorded to check Fuel Trim Cell and Fuel Trim Index at the time of power enrichment and decel with injector cutoff to see if there are clues there.




Edit: just found this...

ScanGauge and Open Loop

On my truck the ScanGauge displays Loop Status as OPEN during extended deceleration on the highway. Today I hooked up my Tech2 and it only displayed OPEN during the first five minutes after a cold start. Tech2 displays Closed during extended deceleration and extended WOT. So the ScanGauge and...

www.bobistheoilguy.com

So others have seen this also.

 

[Mektek]

the error is "pid is too long, can be 3 bytes (6hex characters only) but it only appears after I click OK.
So when I enter 22114401 and OK in the obd2 mode line that is the message that pops up.
Without the 01 appended it works fine.
I have an 02 like you. The torque scan and track recorder add on installed.
One thing I'm thinking is that I have the "faster communication" option ticked in the adapter settings. Maybe that sends the 01 automatically?

 

[TJBaker57]

Been quiet here for a while...

I've been noodling about getting PIDs from modules that don't support the service that Torque uses for calling up PIDs. Modules like the TCCM (node 1A) and the HVAC (node 98). At least in 2002 these modules do not support service 22 requests so Torque can not access these PIDs.

I also got sort of mired down with just too many PIDs, bits, equations, spreadsheets, and so on that I needed a break and a regrouping. Still working on that..

But here is something that came up in another thread.....Crank Request. It is another bitmapped value of PID 1131 where I also found one of several 'Park/Neutral' indicators. When the key is turned to the start position I observe 4 bits from the return byte of this PID go high, #0,#1,#3,#4. If I shift to a drive gear and turn to start position only bit 4 goes high. I believe this to be the signal voltage from the ignition switch through the crank fuse to the PCM and further look at this as 'Crank Request' input to the PCM. That's my current (no pun intended) theory at least.

Name = ~Crank Request
PID= 221131
Scale= x1
Units =
Equation =Lookup(Bit(A:4)::0='OFF':1='CRANK_REQ')
Header = Auto

In .csv format:
"~Crank Request (1131 bit 4)","Crank_Req","0x221131","Lookup(Bit(A:4)::0='OFF':1='CRANK_REQ')",0,1,"","Auto","","1",1

 

[mrrsm]

FWIW...

Without knowing whether or not PID Developments will help with creating Bi-Directional Tests (Such as Speedometer Sweeps and Dash Panel Lights) ...or if it can even can be achieved using the Torque APP... The Linked Video below and the related Screen Still Shots and Diagrams demonstrate how to Make and Wire up a Simple OBD2 Connector Harness to work in conjunction with any Blue Tooth ODB2 Scanner.

For those WITH Bi-Directional Testing capabilities... This will work for the purposes of Pulling, Repairing and then Bench Testing the IPCs (Instrument Panel Cluster)s for GM and GMC Trucks and SUVs WITHOUT having to run back and forth to the Vehicle(s) and Test the Repairs and Functionality:

 

[TJBaker57]

So in another recent thread here the possibility of a bad steering wheel position sensor was mentioned. My 02 TrailBlazer has no stabilitrak or such and thus has no steering sensor that I know of but my 05 Yukon does. I isolated this PID for the sensor.

Can someone try this out on a TrailBlazer to see if it is the same as my Yukon?

Name = Steering Wheel Sensor
PID = 222121
Scale = x1
Units = Volts
Header = Auto
Equation = A/255 * 5

 

[YUKON87]

TFP Switch A/B/C. (Post #17, top left gauge) A couple of days ago I had little idea of what this was. Transmission Fluid Pressure manual valve position switch. Do what now??

I googled the term and came up with a diagram and an understanding of the switch and its output and in working these data streams I managed to match the switch output to PID 1951, bits 5, 6, and 7, in the order A, B, and C. (Thank goodness for spreadsheets) For a display I match the decimal equivalent of these 3 bits and substitute text indicating the positions as we would see them such as Park/Neutral, Drive, Reverse and so on.
This switch cannot distinguish between Park or Neutral as the valve body pressures are the same in these 2 positions. (Or so I've read)
Could this be useful somehow? I have no idea, but I found it and it works to display the switch position, if not the individual channels of A, B, or C. This switch will not indicate changes in transmission selection without the presence of fluid pressure so if one shifts through the selections with the engine off no change is seen of course.

Name = Transmission Fluid Pressure Switch A/B/C
PID = 221951(append 01 for faster response in Torque)
Scale = x1
Units =Bit Mapped
Equation = Lookup(A>5::5='P/N':4='Reverse':1='Drive':3='3rd':7='2nd':6='1st')
Header = Auto

Previously I have posted a PID for Park/Neutral as 221131, bit 2. That PID/bit does indeed indicate Park/Neutral as a value of 1 and all else as 0. That PID 221131 also contains things like crank request, starter relay command and a couple of other items I have yet to even hazard a guess. I have to remind myself that we are not in fact seeing the actual switch data. The PCM is seeing that information and outputting these PIDs that we then call up. I can only make logical guesses at where the PCM is getting its information based on testing and watching the data streams. I see that P/N as displayed by PID 221131 bit 2 changes without the engine running so it is not a derivative of the TFP switch. So where does it come from?

Transmission Range Switch A/B/C/P ?? (Post #17, center left gauge) Again I say "Do what now?" More tests, more googling, more noodling around and I find this switch is also represented in PID 1951 as bits 0,1,2, and 3. It has 4 switch outputs and through combinations represent all positions including separate park and neutral indications. I believe this to be a switch on the drivers side of the transmission. Since this has separate park and neutral indications it doesn't look like a candidate for the source of the 221131 bit 2 P/N indicator. I may never know what is that source so I will move on knowing only that it does appear to indicate P/N, if not an actual switch position. To further muddy the waters there is also a previously unmentioned PID 221920 (seen in post #17, bottom left gauge) that also displays a Transmission Selection with a single bit (#1 thru 7) each representing one of 7 positions, P,R,N,D,3,2,1. Confused yet?? I can tell you I am! I am currently wondering if this PID 221920 is for use by the Instrument Cluster for the display there.

Back to that Transmission Range Switch A/B/C/P.
PID = 221951( yes, this is the same PID# used above but we will be using different bits from it. And again I say "append 01 for faster response in Torque)
Scale = x1
Units = Bit Mapped
Equation = Lookup(A-(A>5)*32::6='Park':3='Reverse':10='Neutral':9='Drive':0='3rd':5='2nd':12='1st')
Header = Auto

And just for completions sake here is what I am currently using for PID 221920. I did not alter the value of A here and there exists a possibility that this will be erroneous if ever a value appears in bit #0. I have a solution for that if it comes up.

Name = Trans Select
PID = 22192001 (I have already appended the 01)
Scale = x1
Units = Bit Mapped
Equation = LOOKUP(A: :128='Park':64='Reverse':32='Nuetral':16='Drive':8='3rd':4='2nd':2='1st')
Header = Auto

Whew!!

TFP Switch A/B/C. (Post #17, top left gauge) A couple of days ago I had little idea of what this was. Transmission Fluid Pressure manual valve position switch. Do what now??

I googled the term and came up with a diagram and an understanding of the switch and its output and in working these data streams I managed to match the switch output to PID 1951, bits 5, 6, and 7, in the order A, B, and C. (Thank goodness for spreadsheets) For a display I match the decimal equivalent of these 3 bits and substitute text indicating the positions as we would see them such as Park/Neutral, Drive, Reverse and so on.
This switch cannot distinguish between Park or Neutral as the valve body pressures are the same in these 2 positions. (Or so I've read)
Could this be useful somehow? I have no idea, but I found it and it works to display the switch position, if not the individual channels of A, B, or C. This switch will not indicate changes in transmission selection without the presence of fluid pressure so if one shifts through the selections with the engine off no change is seen of course.

Name = Transmission Fluid Pressure Switch A/B/C
PID = 221951(append 01 for faster response in Torque)
Scale = x1
Units =Bit Mapped
Equation = Lookup(A>5::5='P/N':4='Reverse':1='Drive':3='3rd':7='2nd':6='1st')
Header = Auto

Previously I have posted a PID for Park/Neutral as 221131, bit 2. That PID/bit does indeed indicate Park/Neutral as a value of 1 and all else as 0. That PID 221131 also contains things like crank request, starter relay command and a couple of other items I have yet to even hazard a guess. I have to remind myself that we are not in fact seeing the actual switch data. The PCM is seeing that information and outputting these PIDs that we then call up. I can only make logical guesses at where the PCM is getting its information based on testing and watching the data streams. I see that P/N as displayed by PID 221131 bit 2 changes without the engine running so it is not a derivative of the TFP switch. So where does it come from?

Transmission Range Switch A/B/C/P ?? (Post #17, center left gauge) Again I say "Do what now?" More tests, more googling, more noodling around and I find this switch is also represented in PID 1951 as bits 0,1,2, and 3. It has 4 switch outputs and through combinations represent all positions including separate park and neutral indications. I believe this to be a switch on the drivers side of the transmission. Since this has separate park and neutral indications it doesn't look like a candidate for the source of the 221131 bit 2 P/N indicator. I may never know what is that source so I will move on knowing only that it does appear to indicate P/N, if not an actual switch position. To further muddy the waters there is also a previously unmentioned PID 221920 (seen in post #17, bottom left gauge) that also displays a Transmission Selection with a single bit (#1 thru 7) each representing one of 7 positions, P,R,N,D,3,2,1. Confused yet?? I can tell you I am! I am currently wondering if this PID 221920 is for use by the Instrument Cluster for the display there.

Back to that Transmission Range Switch A/B/C/P.
PID = 221951( yes, this is the same PID# used above but we will be using different bits from it. And again I say "append 01 for faster response in Torque)
Scale = x1
Units = Bit Mapped
Equation = Lookup(A-(A>5)*32::6='Park':3='Reverse':10='Neutral':9='Drive':0='3rd':5='2nd':12='1st')
Header = Auto

And just for completions sake here is what I am currently using for PID 221920. I did not alter the value of A here and there exists a possibility that this will be erroneous if ever a value appears in bit #0. I have a solution for that if it comes up.

Name = Trans Select
PID = 22192001 (I have already appended the 01)
Scale = x1
Units = Bit Mapped
Equation = LOOKUP(A: :128='Park':64='Reverse':32='Nuetral':16='Drive':8='3rd':4='2nd':2='1st')
Header = Auto

Whew!!

On my 2003 Yukon 4L 60e trans I'm using pid 221921 with the bit values reversed for the trans shifter selection as follows: LOOKUP(A: :128='Park':32='Reverse':64='Nuetral':8='Drive':4='3rd':2='2nd':16='1st')

By the way mine is a flex fuel with a sensor but all I ever get is a value of 0 was wondering if you've managed to come across any info to read this been trying PID 220052. And 22 1177. The ladder PID 1177 is labeled as ethanol/m/r and gives me a value of 10 and nothing else.

 

[TJBaker57]

ladder PID 1177 is labeled as ethanol/m/r

Labelled by who? What is the source ?

So except where expressly stated all of this thread to date has been worked out and tested solely on my 2002 4.2 LL8 TrailBlazer. I also own a 2005 5.3 LM7 Yukon and am going to be seeing what we can get there.

Glad to see someone making use of this and Thanks for the contribution! I'm traveling in my Yukon right now and just added your pid and equation to my Yukon profile.

 

[YUKON87]

Labelled by who? What is the source ?

So except where expressly stated all of this thread to date has been worked out and tested solely on my 2002 4.2 LL8 TrailBlazer. I also own a 2005 5.3 LM7 Yukon and am going to be seeing what we can get there.

Glad to see someone making use of this and Thanks for the contribution! I'm traveling in my Yukon right now and just added your pid and equation to my Yukon profile.

1177 was acquired on another forum from a huge PID list. The only clue I have is the list is labeled as SS. Hopefully the rearranged equation will work in your Yukon.

 

[TJBaker57]

Hopefully the rearranged equation will work in your Yukon.

Well not quite. I just experimented and confirmed this PID 1921 in my 2005 5.3 LM7 appears to be the TFT switch. Transmission Fluid Pressure Switch. I say this because it does not reflect shifting through the gears unless the engine is running. Also, the TFT switch cannot differentiate between Park and Nuetral because the pressures acting on these switches are the same in both of those selections. The PIDs I mentioned earlier as "Range Select" (or maybe "Trans Select"?) reflect shifts with the engine off.

What DOES work for my 2005 Yukon for TFT switch ,PID 1921, is this...

Lookup(A::64='P/N':32='Reverse':8='Drive 4':4='Drive 3':2='Drive 2':1='Drive 1')

 

[YUKON87]

Well not quite. I just experimented and confirmed this PID 1921 in my 2005 5.3 LM7 appears to be the TFT switch. Transmission Fluid Pressure Switch. I say this because it does not reflect shifting through the gears unless the engine is running. Also, the TFT switch cannot differentiate between Park and Nuetral because the pressures acting on these switches are the same in both of those selections. The PIDs I mentioned earlier as "Range Select" (or maybe "Trans Select"?) reflect shifts with the engine off.

What DOES work for my 2005 Yukon for TFT switch ,PID 1921, is this...

Lookup(A::64='P/N':32='Reverse':8='Drive 4':4='Drive 3':2='Drive 2':1='Drive 1')

I agree as I noticed this as well there was no way to get it to actually differentiate between Park and neutral as these are both seen as neutral positions according to the Transmission Fluid Pressure. You would be correct as the vehicle needs to be running in order to reflect this although it can be used as an alternative with engine running. At the very least it partially defines another potential PID.

 

[YUKON87]

By the way, hats off to you sir for teaching me how to utilize a look up equation type. This should help me in further decoding and understanding more pids. Was unaware of the "Lookup" method.

 

[YUKON87]

Heres one you may have.
"A/C PRESSURE OUT OF RANGE"
Pid: 221103
Type: Bit
Range: 0.0 - 1.0
Scale:1x
Header: Auto
Equation: (A&4)/4

Question: How would you do a "Lookup" Equation for this?? I believe Out of range shows "1" for me.

"lookup(bit(A:4)::0='No':1='Yes')??"..

 

[TJBaker57]

Heres one you may have.
"A/C PRESSURE OUT OF RANGE"
Pid: 221103
Type: Bit
Range: 0.0 - 1.0
Scale:1x
Header: Auto
Equation: (A&4)/4

Question: How would you do a "Lookup" Equation for this?? I believe Out of range shows "1" for me.

"lookup(bit(A:4)::0='No':1='Yes')??"..

You are very close...

Lookup(Bit(A:2)::0='No':1='Yes')

It literally took me hours to discover what that ampersand does! I am not a programmer. After much Googling I did however find out what the purpose of that equation is.
I suspect the author may have used this equation before other functions became available in Torque to do the same thing, that is isolate a single bit from a byte. That equation is the equivalent of "Bit(A:2)"

I also monitored that Pid 1103 in my 2005 5.3 Yukon. The equation for me yields a zero, as the the pid for me returns a value of 0x01. Only the zero bit is high for me and did not change. It appears the origin of this pid is from GaryDoug in FirebirdForums back in 2012. I suspect many if not most of these pids vary from vehicle to vehicle and we may actually be seeing something entirely unrelated to A/C pressures here.

 

[YUKON87]

You are very close...

Lookup(Bit(A:2)::0='No':1='Yes')

It literally took me hours to discover what that ampersand does! I am not a programmer. After much Googling I did however find out what the purpose of that equation is.
I suspect the author may have used this equation before other functions became available in Torque to do the same thing, that is isolate a single bit from a byte. That equation is the equivalent of "Bit(A:2)"

I also monitored that Pid 1103 in my 2005 5.3 Yukon. The equation for me yields a zero, as the the pid for me returns a value of 0x01. Only the zero bit is high for me and did not change. It appears the origin of this pid is from GaryDoug in FirebirdForums back in 2012. I suspect many if not most of these pids vary from vehicle to vehicle and we may actually be seeing something entirely unrelated to A/C pressures here.

I agree. Unfortunately some of these parameters are extremely vehicle specific. Still knowledge is inexhaustible. Anytime I discover a new PID, I take the time to label it for the vehicle I know it works for. Thank you for your assistance. Keep up the good work. I will try to help and contribute as I can. I have witnessed new data from your post that I have not been able to figure out from years worth of essential research from many. Usually the moment proprietary knowledge becomes available, it gets hidden away. I feel like once we own these vehicles, the data should be ours to understand interpret, and to read. Specifically the data within any given software that is owned by you or me.

 

[TJBaker57]

For evaluation of new unidentified pids I employ the data logging of Torque Pro. The resulting file is synchronized to my Google Drive. I then have a Google spreadsheet that imports that data file and applies a color scale to the values. This helps me recognize patterns in the pid data stream that may help identify it. I find it also useful for troubleshooting purposes. Here's a screenshot showing fuel trim stuff....STFT, LTFT, Fuel Trim Index, Fuel Trim Cell, Engine RPM, ECT, MAP, IAT, and so on...

 

[YUKON87]

For evaluation of new unidentified pids I employ the data logging of Torque Pro. The resulting file is synchronized to my Google Drive. I then have a Google spreadsheet that imports that data file and applies a color scale to the values. This helps me recognize patterns in the pid data stream that may help identify it. I find it also useful for troubleshooting purposes. Here's a screenshot showing fuel trim stuff....STFT, LTFT, Fuel Trim Index, Fuel Trim Cell, Engine RPM, ECT, MAP, IAT, and so on...

View attachment 91825

Haven't played around with the logging feature yet. Definitely something I knew I needed to learn. Ive heard Torque is an excellent option for logging data. I like the way this is set up. Will definitely take your example for logging. Ty for this information.

 

[YUKON87]

Would like to comment that the above revised equation and information for the bit look up method would seem to be a higher resolution equation. This can apply to all bit encoded pids. This is very valuable information for those who may be confused when reading bit encoded pids. Wikipedia explains much of this information in relative detail.

 

[YUKON87]

Anyone know circumstances where one O2 sensor heater would be on and the other off? Tech 2 displays two distinct HO2S commands.

I have identified 2 bits, #1 & #2 in PID 1112 that toggle with the O2 heater commands but I don't know which is which. Not sure it even matters generally. So this equation will admittedly be a little 'different'. I cannot tell which heater is which so I will configure my equation to tell if both heaters are commanded off, or both commanded on, or if any single heater is commanded on.

HO2S Heaters #1&#2
PID = 221112
Scale = x1
Units =
Equation = Lookup(Bit(A:1)+Bit(A:2)::0='O2Htrs_OFF':1='O2Htr_ON':2='O2Htrs_ON')
Header = Auto


Additionally I have candidate "Power Enrichment" and "Loop Status" bits.

Name = Power Enrichment
PID = 221120
Scale = x1
Units =
Equation = Lookup(Bit(A:7)::0='Inactive':1='Active')
Header = Auto


Name = Loop Status
PID = 221120
Scale = x1
Units =
Equation = Lookup(Bit(A:0)::0='Open':1='Closed')
Header = Auto

Here is a screenshot just after engine shutdown...

View attachment 90743

I have observed that on the heated 02 s when it is registering non plural heated O2 active, that would in theory be Downstream attached are some images on an hour and a half drive cycle of observation with notes of observation. So therefore my theory is that bit one maybe Downstream as the Upstream would in theory have a lower priority for needing to be heated as it is closer to the engine and should heat up quickly enough on its own it would seem this logic May apply to the vehicle as only one O2 heater is on during run position engine off. Thoughts? Another interesting Behavior I observed is as I was driving it would cycle one or both on and off this did not seem random but seemed to have a pattern as a normal functional Behavior as this vehicle was driven on a cooler day with a bad fan clutch so the vehicle had trouble maintaining full operating temperature at times.

 

[YUKON87]

Included are some additional screenshots on a known PID for commanded AFR. I'm sure many have figured this out but thought I'd share anyway as I have not read anywhere that would indicate anyone for sure knew the entire process of how this works. Also included is a custom equation that I created on my own that luckily worked out pretty simple to convert the AFR read out into a Lambda Stoich read out. Because I have a flex fuel my commanded changes mostly in reference to my ethanol percentage.

 

[YUKON87]

Another PID is as follows:

Pid: 22FC30

Long Name: (Gm) Aspark (Flex Fuel Spark)

Short Name: Adv.Spark

Min.: 0

Max. 200

Unit: Degrees

Equation: "(A)/40.96?" Or "(A+20)/0.35?"

Header: 6C10F1 Or Auto

This works on my 2003 Yukon l59.

 

[YUKON87]

For evaluation of new unidentified pids I employ the data logging of Torque Pro. The resulting file is synchronized to my Google Drive. I then have a Google spreadsheet that imports that data file and applies a color scale to the values. This helps me recognize patterns in the pid data stream that may help identify it. I find it also useful for troubleshooting purposes. Here's a screenshot showing fuel trim stuff....STFT, LTFT, Fuel Trim Index, Fuel Trim Cell, Engine RPM, ECT, MAP, IAT, and so on...

View attachment 91825

On this note I have successfully ran my first misfire log and followed your example and interestingly enough I have observed misfires in the log that were unable to display in the user interface. So as stated logging is a must for things like this. Theory is when logging it does not have to register the display with the UI therefore in the log file it gets the data more quickly and or cuts out the extra step to register the data with the UI. This was done on my 4.2 Atlas Envoy.

 

[YUKON87]

So ive been trying to determine a new Bit encoded PID for my 03 Yukon. The PID in question is as follows:

PID: 221107

NAME: Ign.Mode.Fp.Fcut.Stat.

UNIT: Bit (Byte)

HEADER: Auto

EQUATION:
Lookup(A::75='Acc.On.?':74='Key.To.Acc.On?':67='F.P.Rly/Start.Req?':66='Ign.Run/FP.Run?':64='Ign.Run?':3='Decel':
2='Open.Loop/FuelCut?':1='Fuel.Cut':0='Standby')

:::::::::::::::::::::::::::::::::::::::;::::::::::::::::::::::::::

(Every label you see in the equation, was given in relation to the order of turning key to accessory & Beyond. "Fuel cut" and "decel" may need to be swapped NS, however, im confident in those as they read during what I know to be fuel cut and decel mode. Dec."2"=Open.Loop/FuelCut?? At idle, for me, this constantly changes from 2 to 0. Maybe heated 02s??).

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Instead of specifying a specific bit, I'm experimenting with using the entire Byte to display multiple pieces of information. This would seem to be an efficient way to read multiple pieces of information from one PID, without cluttering the display with multiple guages (under the right circumstances at least), instead of polling multiple PID displays for the same information. The PID in question appears to provide not only Ignition stats, but crank request and Fuel Pump request. During each the ignition cycle. I have monitored the binary (bit) changes. What I have came up with, is a generalization of what each decimal number means of the entire byte of byte "A", by monitoring binary changes. This is a work in progress. For example: what I have defined as "crank request", or "fuel pump request", specifically, may actually be the relay or something else entirely. This may have already been defined. However, I have not witnessed it.

 

[YUKON87]

Ok, I'll try to be brief. I recently received an MX+. Yet, occasionally, I would continue to get errors in torque. Long story short I figured out removing faster Communications and going back through my pids and specifying the proper return byte, (which most seem to be 01), as well as sending a command from torque specifying protocol 2A (ATSP2A) rather than (ATSP2) VPW protocol, has eliminated connection errors within torque as well as dramatically increased data speed. Also the vehicle seems to run a little smoother this way. Instead of a "7F22XXXX12" response with valid data behind it, (with an error message "12"). I now get 62XXXX"01"XX, which is my ECU saying I understand this request, request accepted. It Seemed to make sense this way. Obviously It's a good habit to have because you learn how data bytes are expected. And this is a native and proper way of using diagnostic software. Rather than using a hack workaround and obviously letting torque do this for you, which in my mind, torque simply make multiple requests per PID per read out cycling through the options, whereas this, specifies it properly the first request, reducing load on the ECU and torque from having to respond to multiple invalid requests per PID per pole. Therefore, data flows naturally through the app and ECU. Also, I would like to share a new translation of PID 1107 for my 2003 Yukon Slt.

PID: 22110701 (Without Faster Communications ticked)

NAME: Dec/FC/Loop Stat/ IGN. Stat

EQUATION: Lookup(A::0='Standby':2='Idle':1='Fuel Cut
/Decel':3='Fuel Cut
/OL':75='KeyAcc.':74='Acc. On':67='Eng. Off':66='Open Loop':64='Closed Loop')

HEADER: Auto or 4C10F1

TJBaker57? Try this on your 05 Yukon. For my 03 Yukon the loop status lines up exact with the generic pre-programmed in torque. Technically, there's two behaviors of fuel cut decel. During fuel cut/decel In closed-loop, my injectors go around 2.0 milliseconds. During full fuel cut and decel. Inj. go "0.05 ms." and loop goes "open".

 

[gmcman]

Just a small sidestep, but is there a fix for the displays to keep from getting scrambled up and shifted to one side on Torque Pro?

The layout is correct being on top of each other...just pushed to one side.

The top pic should not have the square gages on the right .....they should be on the left of the bottom pic.

Happens on occasion.

 

[YUKON87]

Just a small sidestep, but is there a fix for the displays to keep from getting scrambled up and shifted to one side on Torque Pro?

The layout is correct being on top of each other...just pushed to one side.

The top pic should not have the square gages on the right .....they should be on the left of the bottom pic.

Happens on occasion.

View attachment 93173

View attachment 93174

Have you checked align to grid when adding gauges if so Are you running fine Grids or coarse grids. Also, what are your full screen settings on your phone? Somewhere in your settings. You can choose font sizes and screen zoom. There is a setting for each app on my S8 Plus that allows you to choose which apps can go full screen. Edit: Also, you may have to go with a smaller size when adding a gauge. Try making sure snap to grid is checked in torque. And Try to disable Torque Pro from going full screen. And choose"fine grids" instead of "coarse", see if that helps.

 

[YUKON87]

gmcman

 

[TJBaker57]

specifying protocol 2A

What is this protocol 2A ? The ELM327 datasheet on page 26 lists 13 options, all represented by a single character 0 through C.

 

[gmcman]

Have you checked align to grid when adding gauges if so Are you running fine Grids or coarse grids. Also, what are your full screen settings on your phone? Somewhere in your settings. You can choose font sizes and screen zoom. There is a setting for each app on my S8 Plus that allows you to choose which apps can go full screen. Edit: Also, you may have to go with a smaller size when adding a gauge. Try making sure snap to grid is checked in torque. And Try to disable Torque Pro from going full screen. And choose"fine grids" instead of "coarse", see if that helps.

Thanks for the info...I tried and checked what you suggested but no change.

To clarify, the screen stays the way I set it up for weeks/months...then gets mixed up on it's own, I don't change any settings.

 

[YUKON87]

This will be my last update on the aforementioned PID. Not going to wear this post out with just this. But I could not leave My interpretations as is. I believe this is the closest match to what each output should mean. Anyone else has better knowledge can chime in but I think that most of this should be generally, correct. My biggest issue has been I have no Other info to go by other than what I've accumulated. Despite this dilemma. I was finally able to monitor the data appropriately as I took a longer trip.


PID: 22110701

Lookup(A::0='Standby':
75='KeyAcc.':
74='Acc.On':
67='IgnitionReq.':
66='OpenLoop':
64='ClosedLoop':
10='?Power.Enrich?':
8='Enrich.Accel.':
3='FC/Decel':
2='?O2H?':
1='Lean.Decel')


The attached photo was a quick read on how Our vehicles could work. If I have interpreted everything right.

 

[YUKON87]

Thanks for the info...I tried and checked what you suggested but no change.

To clarify, the screen stays the way I set it up for weeks/months...then gets mixed up on it's own, I don't change any settings.

The only thing I can guess at is maybe the app is still running in the background and when you carry out any specific tasks it could cause torque to bug out when you reopen torque. There are options to clear cache with torque. Maybe try that Ive had similar issues after an update on my S8 Plus. Basically, I disabled full screen. And after another update it did not seem to cause any issues. Every program or software runs on RAM. Software also accumulates cache. This cached data can get full and can cause issues at times. You can try clearing this data cache. And rebooting as well, which are just basics. May or may not work. But it's worth a try. Maybe someone else can chime in on this. Edit: another option you can give a shot is the option to allow torque to appear on top.

 

[YUKON87]

What is this protocol 2A ? The ELM327 datasheet on page 26 lists 13 options, all represented by a single character 0 through C.

Included is An example I believe on a Volvo forum.

Honestly I shared this bit of information Based on a theory in hopes that someone would chime in and better explain this. On some of the apps I have. In order to scan C codes And ABS codes. It generically shows the message ("VPW" / VPW TYPE 2") I also remembered reading from various sources expressing a different flavor of speed with vpw protocol. May not mean anything but the elm command to set the protocol accepts setting protocol 2 and 2A respectively (VPW).

">SP 2
">OK" and
">SP 2A"
">OK."


Also Here is a link to one of many. Website explaining the base protocol is in a little more detail. Some of this information may be bad information. And some of it might be missing other bits of information.

OBD-II Protocol -- SAE J1850 VPW PWM - ImProgrammer - 博客园

http://www.auto-diagnostics.info/j1850j1850The SAE J1850 bus bus is used for diagnostics and data sh

www.cnblogs.com

 

[TJBaker57]

May not mean anything but the elm command to set the protocol accepts setting protocol 2 and 2A respectively (VPW).

">SP 2
">OK" and
">SP 2A"
">OK."

I have the same results when issuing those commands as well.. However when I follow that up with "AT DP" (define protocol) the elm reports back the very same protocol leading me to think that only the first character is being accepted when setting the protocol.

Edit: just for a test I tried ATSP2B and it was rejected so it would appear there is at least some verification of the 2A command there.

We are moving away from the subject matter of this thread though and perhaps this would be best addressed elsewhere.

 

[YUKON87]

I have the same results when issuing those commands as well.. However when I follow that up with "AT DP" (define protocol) the elm reports back the very same protocol leading me to think that only the first character is being accepted when setting the protocol.

Edit: just for a test I tried ATSP2B and it was rejected so it would appear there is at least some verification of the 2A command there.

We are moving away from the subject matter of this thread though and perhaps this would be best addressed elsewhere.

Agreed! And i got the same results ty for your input.

 

[YUKON87]

Probably not the best place to post this information but decided to include a link as it directly relates to the PID 1107. I am posting this to help others as this also helped to confirm what I got right and what I did not potentially.

ECM MODES OF OPERATION

 

[YUKON87]

Been a while no activity I could not help but share this information. Specifically to TJ Baker. Here's a fun one for you when testing a suspect PID. Try entering this header 8CFEF8 and hit test. This is better done with bytes A through F specified. What this is is a broadcast to all nodes (FE) & this requests the PID to every module in the vehicle while testing it with each byte. This is an extremely efficient way of testing new pids. Questions comments or concerns interested in hearing anyone's opinion been using this for months now. I have also learned much since then.


On this note I have gathered that if a PID number starts with "21, 23, 24" this is usually BCM. Respectively "11, 00, 19" etc. is PCM. "41, 43, 44" is usually associated with header 8C & "A0-A9" & F8 (or F0). So the PID format would be formatted as follows:22____"2152"_______01
::::::::::::::|||||::::::::::||||||||:::::::::::::::||||:::::::::::::::::::::_____"Mode:"___"PID"____"ByteReturn"
Which would use a header of "XC40FX"

 

[mrrsm]

@TJBaker57 … Has the “Tire Size versus Speedometer Behavior” controversy ever been solved beyond being manipulated using a Tech 2 to make any such narrow adjustments within the PCM Calibration? I was wondering if the information and calculations posted in the Linked Thread would be of any use to you; perhaps when delving into obtaining more flexible and precise “Cell Phone Speedometer” Read-Outs on Vehicles fitted with Non-Standard Wheel & Tire combinations.

https://www.ls1lt1.com/threads/speedometer-calibration-tuner-pro-rt.54939/

 

[YUKON87]

Managed to discover additional Pids after half a day of driving. Wasn't Easy. I have many other things that have not been fully defined yet that I may share later if someone sees this information as useful. Decided to go ahead and share this.

"(Gmc) Door Lock Status (Envoy)","Door_Lock_Stat","22410601","Lookup(Bit(A:2)::0='Unlocked':1='Locked')",0,100,"","6CA2F1","","",1

=============================

"(Gmc) Multi_Stat_Mode_(Yukon)","Mult/Stat/M","22110701","Lookup(A::0='Standby': 75='KeyAcc.': 74='Acc.On': 73='A/C,RelayOff': 72='A/C,RelayOn': 67='IgnitionReq.': 66='OpenLoop': 64='ClosedLoop': 11='FcRapidDecel': 10='IgnitionRet': 9='ClosedThrottle': 8='OpenThrottle': 3='FC/Decel': 2='SemiOL': 1='Lean.Decel')",0,128,"","Auto","","",1

=============================

"(Gmc) Right & Left Rear Window (Envoy)","RR&LR_Window","22210F01","Lookup(A::131='RR/Up':67='RR/Down':11='R/L_Up':3='Set')",0,100,"","8C40F8","","",1

=============================

"(Gmc) TransRangeSwitchSel (Yukon)","TransSel (Yukon)","22111301","Lookup(A: :1='P':2='R':4='N':8='D':16='3':32='2':64='1')",0,100,"","8C10F8","","",1

=============================


P.S. for the left rear window. The "down function" is read out by a different PID, but I have not yet figured out how to add a different PID readout in the equation to read two different pids in 1 gauge. Specifically for a "bit encoded Pid". Can someone help me out? If someone can show me i'll share the "left rear window down function" pid.

 

[TJBaker57]

Well here goes.....this is not technically a "PID" but I am going to post it here nonetheless.

A true PID is usually requested from a module by use of service $22, request data by PID. You send a properly formatted request to the module, the module takes the PID number and looks up that PIDs details in an internal table where it gets the memory address where the PID data is stored as well as other details needed to retrieve and process the PID data. This is the general method used by Torque and others. Works great for the majority of interests.

But what about the Transfer case and HVAC modules?? I discovered sometime last year that our TCCM and HVAC modules do not support service $22 so we cannot request live data from these using the normal methods. Most unfortunate since the 4WD system seems to generate so much grief for owners.

I set about finding a way to get at this data last year then tabled it for a time after making some progress in identifying PIDs, even though I could not directly use the PID number. Spent the last 3 days poring over documents found on chinese websites and tinkering with my bluetooth elm clone adapter and a serial terminal app that has support for saved macros as well as being able to log the session, the latter being crucial to the task.

OK, lets get to it. I am using service $23 instead of service $22 so the ~pid~ info typed into Torque will begin with 23, not 22. Next comes a 3 byte memory address followed by a single byte memory size. My tests indicate the memory size request can only be 01 which returns 4 bytes beginning at the memory address in the request. Here is the string for the 4WD mode switch on the dashboard of my 2002 TrailBlazer. "2300009001". This will return 4 bytes but we are only using the first byte here, which Torque will label as "A" in the equation. The value returned by the TCCM is a single hex byte which Torque converts to decimal and passes to the equation editor as 'A'.





The header is important here. It must be as shown so that the message packet is sent to right module. The message priority and type is "6C", the TCCM is node address 1A, and our sending address is "F1" so the full 3 byte header is "6C1AF1".


------------------------------

For the encoder motor return voltage the only change besides the names of your choosing is the memory address of $000091. So the 'mode and pid' string is thus "2300009101"

-------------------------------


So again I say, I have no way to know if this will work on anything other than what it has been developed on, my 2002 TrailBlazer.

Someone here once posted they could not enter more than 6 characters in the "mode and pid" field of Torque. I never came up with any reason for this as I can enter almost anything there without any error message. If this is the case for you then this method of retrieving data cannot be made to work for you as the service $23 requires the string as I have shown it here.

Please do post here if you try this method and works for you. I fully expect this to ONLY work for trucks with the very same 4WD system as mine, same TCCM etc. It is quite possible that even other year TCCMs will be different and this will not yield correct data.

 

[TJBaker57]

I had a look at Torque Lite yesterday to refresh my memory of the offering. I saw no means of specifying a header for a custom PID. Additionally I see no means of importing PIDs from a csv. My conclusion is that Torque Pro is required for most all of what has been discussed in this thread.