More PIDs for Torque App

OP
OP
T

TJBaker57

Well-Known Member
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
 
OP
OP
T

TJBaker57

Well-Known Member
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.

Screenshot_20190911-204927.pngScreenshot_20190911-204624.png


Edit: just found this...

So others have seen this also.
 
Last edited:

Mektek

Well-Known Member
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?
 
OP
OP
T

TJBaker57

Well-Known Member
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

Lifetime VIP Supporter
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:


IPCLUSTERLAYOUT1.jpgIPCLUSTERLAYOUT2.jpgIPCLUSTERLAYOUT3.jpgIPCLUSTERLAYOUT4.jpgIPCLUSTERLAYOUT5.jpgIPCLUSTERLAYOUT6.jpgIPCLUSTERLAYOUT7.jpgIPCLUSTERLAYOUT8.jpgIPCLUSTERLAYOUT9.jpgIPCLUSTERLAYOUT10.jpg
 
OP
OP
T

TJBaker57

Well-Known Member
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

Active Member
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.
 
Last edited:
OP
OP
T

TJBaker57

Well-Known Member
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

Active Member
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.
 
OP
OP
T

TJBaker57

Well-Known Member
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

Active Member
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

Active Member
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

Active Member
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')??"..
 
OP
OP
T

TJBaker57

Well-Known Member
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

Active Member
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.
 
Last edited:
OP
OP
T

TJBaker57

Well-Known Member
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...

Screenshot_20191119-094835.png
 

YUKON87

Active Member
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

Active Member
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

Active Member
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. 20191220_152904.jpgScreenshot_20191220-153038_Torque.jpgScreenshot_20191220-153202_Torque.jpg
 
Last edited:

YUKON87

Active Member
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 Screenshot_20191221-135618_Gallery.jpgread out. Because I have a flex fuel my commanded changes mostly in reference to my ethanol percentage.
 

Attachments

YUKON87

Active Member
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.
 
Last edited:

YUKON87

Active Member
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.
 

Attachments

YUKON87

Active Member
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.
 
Last edited:

YUKON87

Active Member
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".
 
Last edited:

gmcman

Well-Known Member
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.

Screenshot_20200214-171238_Gallery.jpg

Screenshot_20200214-171419_Gallery.jpg
 
Last edited:

YUKON87

Active Member
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.
 
Last edited:

gmcman

Well-Known Member
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

Active Member
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.
 

Attachments

Last edited:

YUKON87

Active Member
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

Active Member
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.

 

Attachments

Last edited:
OP
OP
T

TJBaker57

Well-Known Member
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.
 
Last edited:

YUKON87

Active Member
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.
 

Online statistics

Members online
9
Guests online
191
Total visitors
200

Forum statistics

Threads
20,161
Messages
590,682
Unanswered questions
1
Answered questions
2
Members
13,070
Latest member
jtd573
Top Bottom