More PIDs for Torque App

[TJBaker57]

But there are 2 other spreadsheet definitions that use this rather odd formula, for both PIDs $1145 and $1146:

(A*.005)-0.068 volts

This morning when I saw this it looked like something I would do. The substitution of a reciprocal is something I sometimes do, and the offset looked familiar.

So today I spent a good deal of time exploring again. Here is where the offset came from.

With a 2003 P10 PCM on the bench and no O2 sensor in place (open circuit) a Tech 2 or Autel AP200 displays 447 mv steady. The data reported by service/mode 22, PID 1145 is $67 or 103 decimal.

The commonly seen equation of A/200 yields .515 volts. The difference between 515 and 447 is 0.068.

This was likely one of my earlier equation explorations. In general I try to duplicate what a scantool reports and while I like to know the details there are times I just get as close as I can to a scantool output.

So in an attempt to get to the bottom of this today I compiled a listing of all the possible PID values and their respective scantool readings in millivolts. All 255 of them. Even with the high and low lines from the 2003 P10 PCM shorted together there was no $00 reported, the lowest attainable value being $01 which the scantool reported as 4 millivolts.

Try as I might I could deduce no clearly explainable equation to reproduce the scantool output for all values. With a little tweaking of the most logical equation I have 1 value where I am off by 1 millivolt after rounding. I miss it by 2 microvolts. 254 values report the same as a scantool, 1 value misses by 1 millivolt.

A * 4.34027 = millivolts

Edit: FWIW I just evaluated @AmpOverload equation and it also misses just 1 value. Our missed values are not the same ones though.

Anyone interested in the raw hex vs millivolts data..

PID 1145.csv

drive.google.com

 

[AmpOverload]

This morning when I saw this it looked like something I would do. The substitution of a reciprocal is something I sometimes do, and the offset looked familiar.

So today I spent a good deal of time exploring again. Here is where the offset came from.

With a 2003 P10 PCM on the bench and no O2 sensor in place (open circuit) a Tech 2 or Autel AP200 displays 447 mv steady. The data reported by service/mode 22, PID 1145 is $67 or 103 decimal.

The commonly seen equation of A/200 yields .515 volts. The difference between 515 and 447 is 0.068.

This was likely one of my earlier equation explorations. In general I try to duplicate what a scantool reports and while I like to know the details there are times I just get as close as I can to a scantool output.

So in an attempt to get to the bottom of this today I compiled a listing of all the possible PID values and their respective scantool readings in millivolts. All 255 of them. Even with the high and low lines from the 2003 P10 PCM shorted together there was no $00 reported, the lowest attainable value being $01 which the scantool reported as 4 millivolts.

Try as I might I could deduce no clearly explainable equation to reproduce the scantool output for all values. With a little tweaking of the most logical equation I have 1 value where I am off by 1 millivolt after rounding. I miss it by 2 microvolts. 254 values report the same as a scantool, 1 value misses by 1 millivolt.

A * 4.34027 = millivolts

First off, an apology. I made a simple but glaring, clumsy error in one aspect of what I wrote in my previous post! When I stated my first equation, I used "* 0.9" when it clearly should have been "/ 0.9" or alternatively (what I was probably really thinking) "A/(256*0.9) volts". The "A/230.4 volts" equation is still, I assert, correct. Fortunately, you used the shorter, correct version. (Unfortunately, I can no longer edit that post.)

Having cleared up that point, I see that your equation:

A * 4.34027 = millivolts

is effectively the same as mine:

A/256/0.9 volts

So it seems to me that, even though we've approached this from different directions (not a bad thing, BTW!), we've come to essentially the same conclusion, namely that the current equation (in 2 spots in the "GMT PIDs" spreadsheet) is not correct (by quite a bit, in fact):

(A*.005)-0.068 volts

Do you agree? If so, I think the spreadsheet should be updated to reflect that.

Edit: FWIW I just evaluated @AmpOverload equation and it also misses just 1 value. Our missed values are not the same ones though.

Oh, don't keep me in suspense! Do tell... which 2 cells?

Anyone interested in the raw hex vs millivolts data..

Just so I'm clear, is the "mV" column in your CSV file what the scantool(s) showed or a (rounded? truncated?) version of what your equation produced?

 

[TJBaker57]

Just so I'm clear, is the "mV" column in your CSV file what the scantool(s) showed or a (rounded? truncated?) version of what your equation produced?

The mV column is what a scantool returns given the $xx value of the row. Both my Autel AP200 and Tech 2 return millivolts in whole numbers only.

, don't keep me in suspense! Do tell... which 2 cells?

So for $D8 my equation as posted yields 937.49832 which rounds to 937 and the scantools return 938.

For $48 your equation yields 312.5 which rounds to 313 and the scantools return 312.

(A*.005)-0.068 volts

Do you agree? If so, I think the spreadsheet should be updated to reflect that.

Yes indeed. That early equation produces results that are on the order of 55+- millivolts low at 100mV and about the same 55 mV high at 900 mV. It is pretty close at mid-range.

It was put forth very early on in my exploring of equations before I had much of a clue about how these things worked, and before I had access to spare PCMs and a better assortment of instruments to test with.

A * 4.34027 = millivolts

is effectively the same as mine:

A/256/0.9 volts

Yes, though I truncated the equation I posted to 5 decimal places. If I use 8 decimal places we both miss at 312 millivolts as returned by scantools.

The 2 microvolt miss I stated happens at 7 decimal places, A * 4.3402777.

When I stated my first equation, I used "* 0.9" when it clearly should have been "/ 0.9" or alternatively (what I was probably really thinking) "A/(256*0.9) volts".

I think I ran straight past the actual equation as written. Instead I read the post, absorbed the concept and went straight to the correct shortened version. Actually never gave it a thought again until I had completed my own exploration. Only then did I think to compare your results to mine.

 

[AmpOverload]

The mV column is what a scantool returns given the $xx value of the row. Both my Autel AP200 and Tech 2 return millivolts in whole numbers only.

Unsurprisingly, Tech2Win also shows mV in whole numbers only, but I've found that for some parameters it rounds and for others it simply truncates, so I've grown somewhat "gun shy" about what it shows me. AFAICT, for these 2 PIDs ($1145 & $1146), Tech2Win is rounding.

That early equation produces results that are on the order of 55+- millivolts low at 100mV and about the same 55 mV high at 900 mV. It is pretty close at mid-range.

It was put forth very early on in my exploring of equations before I had much of a clue about how these things worked, and before I had access to spare PCMs and a better assortment of instruments to test with.

Early on, I was also (erroneously, as it turned out) using "A/200 volts" (but without any offset) as the formula for $1145 and $1146, simply because I had no guidance to follow and used the Mode $01 PIDs $14 to $1D$1B equation to guide me, wrongly assuming that it would be close. Real-world data collection showed otherwise, though, so I'd been using A/230 (better, but still not exactly right, as it turns out) in recent years.

Every formula I apply to a vehicle data point (PID, etc) has to have both a "forward" and a "reverse" function, the former to decode it (raw value -> human-readable) and the latter to come up with a raw value (for vehicle simulation) from a real-world value. So I tend to scrutinize equations that don't "look right" more than most folks would. There have been very few equations that don't have a form that is "eye pleasing", when written "correctly". That's partly why I assert that the equation "A/256/0.9" ("A/230.4" in the "ugly" [but still precise!] form) is truly the correct variant.

So for $D8 my equation as posted yields 937.49832 which rounds to 937 and the scantools return 938.

For $48 your equation yields 312.5 which rounds to 313 and the scantools return 312.

I just ran a test with Tech2Win, configured as a 2004 Buick Century ("W" body, "J" engine [3.1L LG8]). I'm sending it $48 (72) for PID $1145.

However, get this... Unlike your Tech2, Tech2Win shows this as "313 mV", not 312! So, if the formula is A/230.4*1000, making the O2 sensor voltage result exactly 312.500 mV, then I would say that Tech2Win is rounding it correctly.

When I send Tech2Win $D8 (216) for PID $1145, it shows "938 mV", which is also a correct rounding of 216/230.4*1000 = 937.500 exactly.

For fun, I re-configured Tech2Win with a vehicle like your 2002 TrailBlazer (4.2 LL8 ["S"] engine) in Tech2Win, which should have the P10 PCM, IIUC. When I send $48, I again see "313 mV", so the discrepancy in "mV" display doesn't seem to be vehicle-related. When I send $D8, I again see "938 mV".

So it seems like a Tech2 (clone?) and Tech2Win have ever-so-slightly different processing, either in the formula itself, in the precision of the formula's operands, in the rounding of the result, or maybe even in the underlying hardware.

All-in-all, not a big deal, since we agree that the formula needs to be changed for those 2 spreadsheet entries. I'm using "A/256/0.9 volts" in my calculations. What's put in the spreadsheet is up to @azswiss.

EDIT #1: Minor tweaks so that my hexadecimal notation format is consistent!

EDIT #2: PID $1B, not $1D!

 

[TJBaker57]

It's certainly possible that the formula for those 2 PIDs is dependent on the vehicle or, probably more precisely stated, on the PCM family (P01/P59, P04, P10, P12, etc)

Jumping back a page where the P12 was mentioned I thought I would note that the 2006 P12 I have does not provide service/mode $22 PIDs $1145 or $1146.

Instead they seem to have implemented the SAE standard service/mode $01 PIDs $14 and $15 but placed them in service/mode $22.

When I was scanning for PIDs with no O2 sensors present (open circuit) on this 2006 P12 PCM PIDs $0014 and $0015 returned $58 for the "A" byte. Using the A/200 equation yields 0.44 mV.

Since I have my O2 sensor mock-up at the ready maybe I will explore these PIDs tomorrow on the '06 P12 PCM.

My test input is a AA battery across a 10k, 10 turn linear potentiometer, with the center tap as the output to the O2 sensor high signal and the battery negative as the sensor lo signal input.

 

[AmpOverload]

Jumping back a page where the P12 was mentioned I thought I would note that the 2006 P12 I have does not provide service/mode $22 PIDs $1145 or $1146.

Very interesting!

Instead they seem to have implemented the SAE standard service/mode $01 PIDs $14 and $15 but placed them in service/mode $22.

Based on that, coupled with the info from that link to a list of PCM families used on various vehicles that I gave at the end of my post #592, I made an attempt to validate a method of testing with Tech2Win on what I hoped would be a P12-equipped vehicle. I selected:

1. 2006
2. LD Trk, MPV, Incomplete
3. Chevrolet Truck
4. "T" platform
5. TrailBlazer
6. Powertrain
7. "S" ("4.2L L6 LL8") engine

And I see exactly what you saw: PCM Mode $22 PIDs $1145 and $1146 are not being queried. PIDs $0014 and $0015 are. And their values are displayed using the SAE-standard equation "A/200*1000 mV".

This is useful for me to know because your experience essentially authenticates my setup for a P12-equipped vehicle now, so thanks for reporting this!

 

[TJBaker57]

Since I have my O2 sensor mock-up at the ready maybe I will explore these PIDs tomorrow on the '06 P12 PCM.

Well that was a quick experiment. Verified that a 2006 P12 supports service/mode $22 PIDs $0014 & $0015 apparently in place of $1145 & $1146. And they do indeed employ the same scaling as specified for the service/mode $01 standard PIDs of the same name. 5 mV per bit. The range reported is from $00 to $DB inclusive with a resulting reported mV range of 0 mV to 1095 mV.

Also confirmed that service/mode $22 PIDs $1145 and $1146 are not supported by a 2006 P12 PCM.

While I had the P12 PCM on the bench I loaded the misfire data and noted the apparent reversal of service/mode $22 misfire current PIDs $1205 & $ 1206 much the same as @AmpOverload spoke of for a P12 PCM. I have no way to simulate a misfire though so I can not definitively state they are reversed even though the evidence is strong.

Looking closely I see cylinder 6 current and history PIDs are tacked on the end of the data packet configuration, as if the 5 cylinder code was written first. So I then loaded up the misfire DPIDs for the 5 and 4 cylinder versions of the Atlas engine. Sure enough these show the same apparent swapping of cylinders 1 and 2 current misfire PIDs. And they are identical, that is to say the 4 cylinder version loads the misfire PIDs for cylinder 5 which it doesn't have. The display does only show 4 cylinders.

I am coming to the conclusion that as happens with many things, the closer you look the more errata you will find.

 

[TJBaker57]

PCM Mode $22 PIDs $1145 and $1146 are not being queried. PIDs $0014 and $0015 are.

With P10 and P12 PCMs at least, I have the upper hand as I can just ask these PCMs for all possible PIDs one at a time and confirm their existance or absence based on the PCM response. I have 4 P10 and 1 P12 at my disposal.

I have many PIDs confirmed by scanning that a scantool never asks for but they are there. Like the 2002 model year TrailBlazer P10 PCM. There is a PID for engine oil temperature but a Tech 2 does not display that anywhere.

 

[AmpOverload]

I have many PIDs confirmed by scanning that a scantool never asks for but they are there. Like the 2002 model year TrailBlazer P10 PCM. There is a PID for engine oil temperature but a Tech 2 does not display that anywhere.

Funny you mention that. Just yesterday, looking for the meaning of PCM Mode $22 PID $199C (discovered long ago to be "supported" by a PID scan on various Buicks), I could see no Tech2Win queries of that PID, on any of the "Powertrain" displays. I suspect that I'll encounter a few more like that.

Having said that, Tech2Win has come in very handy in discovering the meaning of other "mystery" vehicle data points (PIDs, etc). For example, I also now have all the transmission TAP-related values identified and supported in my human-readable output files. In fact, I just collected some data today on a 2004 Century that showed the TAP data changing "in flight".

 

[TJBaker57]

PCM Mode $22 PID $199C (discovered long ago to be "supported" by a PID scan on various Buicks), I could see no Tech2Win queries of that PID, on any of the "Powertrain" displays.

This particular PID is queried on my 2005 Yukon 4WD 5.3 LM7 when trans adapt data is requested. However, there doesn't appear to any candidate display fields. It returns a single byte (Key On Engine Off) ($00).

It is supported on a 2006 P12 PCM where it returns 2 bytes. ($00 $80) Apparently not queried by scantool.

Supported on my 2002, 2003 and 2005 P10 PCMs where on the bench it returns 1 byte ($80). Also another 2002 P10 in vehicle still returns $80. Also apparently not queried by scantool.

now have all the transmission TAP-related values identified

Seems like my TAP values are in Data Blocks accesible with service/mode $3C. Oddly however my 2002 TrailBlazer LL8 P10 does not seem to utilize the TAP system. All values remain at $00. "Current TAP cell" PID value does vary when driving though.

 

[AmpOverload]

This particular PID is queried on my 2005 Yukon 4WD 5.3 LM7 when trans adapt data is requested. However, there doesn't appear to any candidate display fields. It returns a single byte (Key On Engine Off) ($00).

It is supported on a 2006 P12 PCM where it returns 2 bytes. ($00 $80) Apparently not queried by scantool.

Supported on my 2002, 2003 and 2005 P10 PCMs where on the bench it returns 1 byte ($80). Also another 2002 P10 in vehicle still returns $80. Also apparently not queried by scantool.

PCM Mode $22 PID $199C has a 1-byte reply on 2005 Avalanche, 2004 Century, and 2003 & 2005 LeSabres, and 2001 Pontiac Bonneville. It's typically (always?) $00 at KOEO.

For a long time now, I've assumed that it has something to do with TAP (Transmission Adaptive Pressure) or the transmission because of the numeric ID's proximity to other transmission-related PIDs. But I can't quite figure out what its meaning/purpose is.

On a recent test on the 2004 Century, over a 38-minute recording, the PID $199C value (2nd line from the top, in green) varied from 0 to 111 ($00 to $6F):



I think PID $199C will have to remain a mystery for a while longer yet!

Seems like my TAP values are in Data Blocks accesible with service/mode $3C. Oddly however my 2002 TrailBlazer LL8 P10 does not seem to utilize the TAP system. All values remain at $00. "Current TAP cell" PID value does vary when driving though.

The TAP values on the 2004 Century are all retrieved using Mode $3C queries too. I was surprised to see so many changes as the vehicle was driven. (In the graph above, I've eliminated the TAP values that didn't change.)

One other thing that strikes me as odd. TAP cells run from #4 to #16 (for all 3 shifts) on this 2004 Century. But the TAP Cell reported by the actual vehicle (PCM Mode $22 PID $199B, top line, in red) ranged from 0 to 8 in the graph. And Tech2Win shows "Current TAP Cell" with whatever value I simulate (0 to 255) for PID $199B, i.e. not offset by 4. So maybe the value reported by $199B is really a "TAP Cell Offset" of sorts as opposed to the actual 'TAP Cell Number'?

 

[TJBaker57]

Well I haven't posted anything new here for some time. Here is a sneak peak at a recent discovery of mine....

Here (upper right gauge in the video) is a display of a custom PID I just created to report the current operational "Power Mode" of my 2002 4.2 LL8 TrailBlazer in the Torque Pro Android App.

The other gauges on this screen have nothing to do with this video, I just didn't have a blank dashboard to use for this video.

The "Power Mode" for this platform is determined by the BCM (Body Control Module) using several factors including the key position, sequence of inputs from the ignition switch, some serial data from others systems of the truck and so on. There are 7 "Power Modes" with this platform.

Some things to note here:

(1) The "UNLOCK" power mode exists between the OFF and ACC key positions. This is when only the ignition switch terminal E gets power. When turning the switch towards OFF this very same key/ location becomes "RAP UNLOCK" because the RAP (Retained Accessory Power) Power Mode is enabled to keep certain subsystems active for a time (like the radio, power windows,.etc.) The status of the ignition switch outputs are the same but the power mode is different until the RAP timer runs out.

(2) The RUN power mode is the same whether or not the engine is actually running. Same power mode.

(3) The "OFF/AWAKE" power mode happens when the key is OFF but the network is at least partially awake. Hitting a keyfob button or opening a door will do this before you ever put the key into the ignition lock cylinder.

(4) The "OFF/AWAKE" key position becomes the "RAP" power mode when the key is turned to OFF after having been on. Same reasons as with the RAP/UNLOCK power mode. The status of the ignition switch outputs are the same but the power mode is different until the RAP timer runs out.



The same message that reports the Power Mode also reports the status of inputs to the BCM from ignition switch terminals E (white), A (brown), G (orange), and C (pink). My next step will be to display this additional data but I am starting with just the Power Mode here.

I think this data might be useful when diagnosing possible ignition switch faults.

I have read that there may a code set when the stated Power Mode does not match the expected Power Mode. I have not yet researched that further.

 

[AmpOverload]

I have read that there may a code set when the stated Power Mode does not match the expected Power Mode. I have not yet researched that further.

In case it saves you a minute or two if/when you do look into it, DTC B1440 is supposed to be "Power Mode Master Input Circuits Mismatch" and is supposedly supported by a 2005 Chevy Avalanche. This is based on a list I had from an online source, not from the actual vehicle.

It probably does not apply, but both the 2004 Century and 2005 LeSabre support DTC B1422 ("Device Power Moding Error"), which comes from actual Mode $19 queries on those vehicles.

 

[TJBaker57]

I may have brought this up before but memory fails me. I am fairly sure that even if I did mention it there was no discussion or conclusion arrived at. So here it is...

I am reviewing PIDs with an eye towards updating or clarifying equations.. I have come to the TCC Slip PID as presented in Torque Pro. It is essentially given as the following:

((SIGNED(A)*256)+B)/8

I have a suspicion it should be something like this instead:

SIGNED(A*256+B)/8

But not knowing how the "SIGNED" function is written I am uncertain.

Anyone have any thoughts on this?

I think I am going to create a second PID with my proposed equation and compare the reults in a road test.

I will of course post the results.

 

[AmpOverload]

Anyone have any thoughts on this?

Of course, as you imply, your results depend on how the Torque Pro author has coded it. He may have made an error. But it's a worthy experiment, IMHO, regardless.

If he has coded it correctly, I think you'll find that the 2 equations will yield identical results. I'm tempted to fire up my vehicle simulator and feed Torque some choice values, effectively duplicating your test from a different angle, but Torque Lite (all I have) doesn't allow custom PIDs, so I cannot do so.

Personally, assuming that the equations yield identical results, I lean toward the "SIGNED(A*256+B)/8" form of the equation, simply because it seems more intuitive to me, but intelligent minds are known to differ.

 

[TJBaker57]

assuming that the equations yield identical results, I lean toward the "SIGNED(A*256+B)/8" form of the equation, simply because it seems more intuitive

Well I will still do the test, but I just visited the Torque BHP Wiki where I discovered they added a "SIGNED16()" function which likely renders the question moot.

 

[AmpOverload]

Well I will still do the test, but I just visited the Torque BHP Wiki where I discovered they added a "SIGNED16()" function which likely renders the question moot.

Odd that Torque breaks out so many variants: "SIGNED8()", "SIGNED16()", "SIGNED24()", and "SIGNED32()". I'm struggling to think of a case where I wouldn't just want to use "SIGNED(anything)" and just have it treat it as the "signed" version of the computed value, whatever size the value might occupy (i.e. in computer memory). Maybe such control is useful in some script and my imagination is just lacking.

 

[TJBaker57]

I will of course post the results.

Well it turns out that the equation in Torque Pro works OK as it is.

My alternate does not work correctly and for some really weird reason it sometimes reported over 8000 rpm slip when the actual slip was no greater than 1. Like it forgot the "divide by 8" part of the equation momentarily!!

The SIGNED function must be coded in a way to accomodate the second byte that appears to be outside the function.

The "SIGNED16" function also works. The wiki could benefit by adding some examples as they gave no indication of the syntax. I eventually found that "SIGNED16(A*256+B)/8" works and matches the original equation supplied with Torque Pro.

I did not check the elimination of what looks like an extraneous level of parentheses in the original equation. "(Signed(A)*256+B)/8" should work.


Next up is to see how it works in Car Scanner ELM OBD2.

 

[AmpOverload]

Well it turns out that the equation in Torque Pro works OK as it is.

My alternate does not work correctly and for some really weird reason it sometimes reported over 8000 rpm slip when the actual slip was no greater than 1. Like it forgot the "divide by 8" part of the equation momentarily!!

The SIGNED function must be coded in a way to accomodate the second byte that appears to be outside the function.

The "SIGNED16" function also works. The wiki could benefit by adding some examples as they gave no indication of the syntax. I eventually found that "SIGNED16(A*256+B)/8" works and matches the original equation supplied with Torque Pro.

I did not check the elimination of what looks like an extraneous level of parentheses in the original equation. "(Signed(A)*256+B)/8" should work.


Next up is to see how it works in Car Scanner ELM OBD2.

I didn't mention it specifically in my previous post because I assumed you read the same Torque wiki page that I did, but the Torque author treats "SIGNED()" the same as "SIGNED8()". That's a design flaw, IMHO. I understand why he did it -- for backwards compatibility. But he really never should have made a "SIGNED()" function that only worked on an 8-bit operand. I looked at my (almost 6 years) old saved Torque wiki page on equations and his "SIGNED()" function was like that even that long ago, i.e. before he added the 16-, 24-, and 32-bit versions of that function

So it makes sense to me that the "((SIGNED(A)*256)+B)/8" equation worked and still works.

IIUC, you used "SIGNED(A*256+B)/8" as your 1st alternative (a plan which made perfect sense to me in my 1st response, before I realized that Torque treats "SIGNED()" as "SIGNED8()"). But that was destined to fail because Torque will be using 8-bit signed math on a 16-bit operand and "all bets are off". Sorry for not mentioning that in my 2nd post, once I understood how Torque really works. I assumed you were going to use "SIGNED16()", not "SIGNED()".

The fact that "SIGNED16(A*256+B)/8" output matches "((SIGNED(A)*256)+B)/8" output is the "nature of the beast", however unintuitive. Which is why I'd humbly advocate use of the former equation.

Ideally, Torque would deprecate the "SIGNED()" notation and eventually eliminate it because continuing to allow it will only confuse the issue for Torque users, IMHO.

 

[TJBaker57]

The fact that "SIGNED16(A*256+B)/8" output matches "((SIGNED(A)*256)+B)/8" output is the "nature of the beast", however unintuitive. Which is why I'd humbly advocate use of the former equation.

I agree it's best to leave the original Torque Pro equation as it is since it works.

I am not a math person.

I was about to write a post explaining why I thought it was wrong. However, while composing said post I needed to go back to the wikipedia explanation of the two's complement method used in expressing negative values in hexadecimal. Briefly trying get a grasp of how it works I discovered that I really had no idea how it works!! I still don't understand it but I gained enough to see why the equation given by Torque Pro is actually correct.

We can leave it at that

 

[YUKON87]

Header 8CFEF8 DIAGNOSTIC START CMD'= - 'ATH1' & 'ATS1 & ATL1' is good for test PIDs on all headers.

 

[AmpOverload]

I agree it's best to leave the original Torque Pro equation as it is since it works.

Actually, I was advocating for updating the equation to use the newer, unambiguous "SIGNED16(A*256+B)/8" notation.

But since I really don't use Torque, I have no dog in this "fight". That's what I meant in my 1st post on this topic when I said "intelligent minds are known to differ". We both clearly have keen minds (and ample curiosity) and will obviously see things differently at times. All good by me.

[...] while composing said post I needed to go back to the wikipedia explanation of the two's complement method [...]

Funny you mention the Wikipedia article on "two's complement". I almost included a link to that exact article in my previous post, before settling on the cop-out phrase "the nature of the beast". I just felt that nobody really cared about the details enough to ever read that article! I was wrong, yet again in life!

Thanks for publishing the results of your testing!

 

[buraan]

Hello All,
I'm new and I've already learnt a lot reading over this topic, I'm glad you Guys are so enthusiasts. I own an 2012 Opel/Vauxhall Astra J 1.4T (A14NET, LUJ) engine that was used in Chevy Cruze at the same time. I use Torque Pro, I added the GM pids for misfire but they work strange. The values are altering between 0, 147 and 37631. I guess these are not the pins I'm looking for...
I have a coil bridge above all my 4 cylinders so I can't just unplug one spark plug and see where I can see the numbers increasing.

Could you please advise an approach how to find / test the pids for my engine? Also I'm not sure how it should work in practice... in case of a misfire the counter turns from 0 to 1 and a couple of seconds later back to zero?
Thank you.

 

[AmpOverload]

Could you please advise an approach how to find / test the pids for my engine? Also I'm not sure how it should work in practice... in case of a misfire the counter turns from 0 to 1 and a couple of seconds later back to zero?

Welcome!

I don't know much about 2012-era GM engines. Since it's a 2012 model year, I would expect that it uses CAN protocol, not the SAE J1850 VPW protocol that's typical on older GM vehicles often discussed here. Do you know for sure which protocol the PCM uses?

It might also help for you to tell us what PCM Mode $22 PIDs you're monitoring now and what you expect their meanings to be.

As for the behavior of the misfire PIDs, I can't say that all GM engines work this way, but on a 2004 Buick Century (6-cylinder engine) and similar vehicles, there is a "misfire data cycles" value (PCM Mode $22 PID $122A on such engines) that increments continuously between 0 and 100 (with some periods of no-change, typically while the RPM is decreasing, in my experience). When the value "wraps" from 100, jumping back to 0, that defines a new "cycle".

If your engine works similarly and if that value is reported by your PCM, it would be a lot easier to find than the "misfire count" PIDs. And once you find that PID, it might be easier to find the others.

Have you done a "PID scan" on that PCM to get the list of all available Mode $22 PIDs? Torque had a plug-in to do that, but I also recall many people having problems with it.

The "current misfire counter" PIDs (1 for each cylinder, of course) will change from 0 to non-zero rather briefly, assuming the misfire is intermittent. But even on a normal, well-functioning engine, I've seen it jump from 0 to 2 often -- it's not always 0 to 1. Then, at the start of the next cycle (as defined by the "misfire data cycles" PID explained above), the "historic misfire counter" PID (1 for each cylinder) will reflect the count from the "current misfire counter" PID and the "current misfire counter" PID will drop to zero until a new misfire is detected. At the end of that cycle, the "historic misfire counter" PID will also drop to zero (again, assuming that the misfires are intermittent and not continuous).

Finding those "current" and "historic" misfire PIDs might be tricky without being able to induce an intentional misfire. That's why I'd start with trying to find the "misfire data cycles" PID first. Actually, I'd expect that by now someone has found and published these PIDs, even for a CAN-protocol PCM, assuming that they're not the same as the PIDs on a VPW-protocol PCM.

Local expert @TJBaker57 could easily have more to say about this.

Let us know if you have any more questions and please keep us posted on your test results. There's a reasonable chance that we might be able to help you find the data you seek.

EDIT: Minor spelling fix.

 

[buraan]

Welcome!

I don't know much about 2012-era GM engines. Since it's a 2012 model year, I would expect that it uses CAN protocol

Hi, thanks indeed for the fast reply. Yes, these cars are CAN-based, the engine control module is on 500kbps high-speed CAN bus. Most parts of the protocol is the same, though; the GM extended modes are
$21: Request data by address offset, parameter is one byte value
$22: Request data by parameter ID, parameter is a two-bytes value (16 bit)
$23: Request data by memory address, parameter is 3 bytes (24 bit) + $01, you can get back 4 bytes always from the memory

I only tried $22 query for PIDs. I used Torque's pid scan, exactly as you said; then my usual method is to observe, guess, observe, fail and sometimes I can figure something. What I've found so far
221154 Engine Oil temperature (A-40) [Celsius]
22115E Camshaft Position Sensor (A)
2211A1 Engine run time ((A*256)+B)/60 [min]
2211AC Calculated Air Flow ((A*256) + B) / 128
2212B4 Accelerate pedal position (A) [%]
221315 - 22131C History of cruise control events
22131E RPM (A*256+B)

I lack the diagnostic tools otherwise I could've got farther. You can see most of the pids above by a simple standard J1979 $01 mode query as well, but my goal now is merely to get some experience.

As for the behavior of the misfire PIDs, I can't say that all GM engines work this way, but on a 2004 Buick Century (6-cylinder engine) and similar vehicles, there is a "misfire data cycles" value (PCM Mode $22 PID $122A on such engines) that increments continuously between 0 and 100 (with some periods of no-change, typically while the RPM is decreasing, in my experience). When the value "wraps" from 100, jumping back to 0, that defines a new "cycle".

If your engine works similarly and if that value is reported by your PCM, it would be a lot easier to find than the "misfire count" PIDs. And once you find that PID, it might be easier to find the others.

At least now I have a clue what are "current" amd "historic" counters. Maybe I'll ask someone in the local forum who has a faulty coil bridge (e.g., cylinder 3 does not work) if I can borrow it. Then I can compare the results.

Let us know if you have any more questions and please keep us posted on your test results. There's a reasonable chance that we might be able to help you find the data you seek.

Thank you very much, I'll definitely post if I can get to somewhere.

 

[AmpOverload]

I only tried $22 query for PIDs. I used Torque's pid scan, exactly as you said; then my usual method is to observe, guess, observe, fail and sometimes I can figure something. What I've found so far
221154 Engine Oil temperature (A-40) [Celsius]
22115E Camshaft Position Sensor (A)
2211A1 Engine run time ((A*256)+B)/60 [min]
2211AC Calculated Air Flow ((A*256) + B) / 128
2212B4 Accelerate pedal position (A) [%]
221315 - 22131C History of cruise control events
22131E RPM (A*256+B)

Of those PIDs, only one matches the set that I know about and support on GM Buicks: PID $11A1 ("Engine Run Time"). All the others are either non-existent or do not report the same data. Having said that, I'll list, in numeric order, the PCM Mode $22 "misfire"-related PIDs that I use, but I doubt that they'll be the same on your PCM:

$11EA = Current Misfire Count Cylinder #5 ('CMFC-5') [A] counts
$11EB = Current Misfire Count Cylinder #6 ('CMFC-6') [A] counts
$11F8 = Historic Misfire Count Cylinder #5 ('HMFC-5') [AB] counts
$11F9 = Historic Misfire Count Cylinder #6 ('HMFC-6') [AB] counts
$1200 = Current Misfire Count All Cylinders ('CMFC-ALL') [A] counts
$1201 = Historic Misfire Count Cylinder #1 ('HMFC-1') [AB] counts
$1202 = Historic Misfire Count Cylinder #2 ('HMFC-2') [AB] counts
$1203 = Historic Misfire Count Cylinder #3 ('HMFC-3') [AB] counts
$1204 = Historic Misfire Count Cylinder #4 ('HMFC-4') [AB] counts
$1205 = Current Misfire Count Cylinder #2 ('CMFC-2') [A] counts
$1206 = Current Misfire Count Cylinder #1 ('CMFC-1') [A] counts
$1207 = Current Misfire Count Cylinder #3 ('CMFC-3') [A] counts
$1208 = Current Misfire Count Cylinder #4 ('CMFC-4') [A] counts
$122A = Misfire Data Cycles ('MF-DataCyc') [A] counts

The "formula" is in brackets. My "AB" is "A*256+B" in Torque "language".

Notice the seemingly "backwards" order of PIDs $1205 and $1206. That's not a mistake -- they really do report like that on some GM PCMs, as discussed earlier in this thread.

At least now I have a clue what are "current" amd "historic" counters. Maybe I'll ask someone in the local forum who has a faulty coil bridge (e.g., cylinder 3 does not work) if I can borrow it. Then I can compare the results.

I tried to run a test with Tech2Win, to simulate your vehicle, but my hardware vehicle simulator only does VPW, not CAN, so there was no communication seen by my simulator when I selected your 2012 Opel vehicle in Tech2Win.

In case it helps, here's a set of plots from some misfire data I collected on a 2004 Buick Century, taken over a period of 2m43s, where there happened to be intermittent misfires on cylinder #1, #4, and #5:



Notice the bottom (orange/brown) line. That's the "misfire data cycles" PID I was talking about. The points where that plot "flatlines" are where the RPM (not shown in this graph) is decreasing, which seems to effectively "pause" the misfire event detector, if my understanding is correct.

I disabled graphs for all the PIDs that showed no changes during the run.

"CMFC" PIDs are "Current Misfire Count". "HMFC" PIDs are "Historic Misfire Count".

If you study those plots, you'll see how the various PIDs change with brief, intermittent misfires. I suspect that your PCM might record things similarly, but I can't be certain.

Good luck in your search and analysis!

 

[AmpOverload]

I own an 2012 Opel/Vauxhall Astra J 1.4T (A14NET, LUJ) engine that was used in Chevy Cruze at the same time. I use Torque Pro, I added the GM pids for misfire but they work strange.

I only tried $22 query for PIDs. I used Torque's pid scan, exactly as you said; then my usual method is to observe, guess, observe, fail

and sometimes I can figure something. What I've found so far
221154 Engine Oil temperature (A-40) [Celsius]
22115E Camshaft Position Sensor (A)
2211A1 Engine run time ((A*256)+B)/60 [min]
2211AC Calculated Air Flow ((A*256) + B) / 128
2212B4 Accelerate pedal position (A) [%]
221315 - 22131C History of cruise control events
22131E RPM (A*256+B)

I lack the diagnostic tools otherwise I could've got farther. You can see most of the pids above by a simple standard J1979 $01 mode query as well, but my goal now is merely to get some experience.

At least now I have a clue what are "current" amd "historic" counters.

Maybe I'll ask someone in the local forum who has a faulty coil bridge (e.g., cylinder 3 does not work) if I can borrow it. Then I can compare the results.

Thank you very much, I'll definitely post if I can get to somewhere.

Just curious... Did you ever make any progress on this?

Since I last posted, I've come up with a vehicle simulator that handles CAN-protocol vehicle nodes.

This means that I can now simulate vehicles like your (CAN-protocol) 2012 Opel 'Astra J'.

I've been testing a bit and can see that there is a lot of information available for that vehicle, using the 'GDS2' software that came with my VXDIAG VCX Nano hardware.

So if you're still looking for information, let me know and I'll try to get you some useful PIDs which might be usable in Torque Pro.

 

[lsxautumn]

I been trying to use some PIDs that will work on my PC based logger trying to get myself a logger that I can take with me since I don't have a laptop. Mostly trying to get PIDs 1617(desired IAC airflow) 119e(desired AFR) 114b(egr analog where my wideband is connected) to work. From what I've scoured on the web mode 22 should be the correct mode but I get nothing. I've tried it with leaving the header blank tried it with it on Auto no dice. Appending a 01 doesn't seem to make a difference. I'm using a p59 from an express van as my ECU it was widely used from 03-06 and uses class 2(j1850vpw). Is there possibly something I'm missing here that I can do to get this working?

 

[AmpOverload]

I been trying to use some PIDs that will work on my PC based logger trying to get myself a logger that I can take with me since I don't have a laptop. Mostly trying to get PIDs 1617(desired IAC airflow) 119e(desired AFR) 114b(egr analog where my wideband is connected) to work. From what I've scoured on the web mode 22 should be the correct mode but I get nothing. I've tried it with leaving the header blank tried it with it on Auto no dice. Appending a 01 doesn't seem to make a difference. I'm using a p59 from an express van as my ECU it was widely used from 03-06 and uses class 2(j1850vpw). Is there possibly something I'm missing here that I can do to get this working?

This should be relatively easy to remedy. You certainly should be able to use Mode $22 to get the data. One or more of your PIDs may not be supported, but even that can be remedied with a bit of investigation.

A couple of preliminary, pertinent questions...

What scantool and app are you using to communicate with the (P59) PCM?

What sort of reply are you getting from the scantool? Is it "NO DATA" or a non-Mode-$22 reply (e.g. "7F 22 {...}"). The answer to that will help us know how to proceed.

Basically, you should be able to do this (done on a P04 PCM, not a P59, but the principle and the commands are the same), for Mode $22 PID $119E ("AFR"):

ATZ
ATL1
ATTP 2
ATH1
ATSH 6C 10 F1
22 119E 01

Then you should see a reply something like this:

6C F1 10 62 11 9E 6A DE

If you can get that working for any PID, but some/all of your PIDs are not supported, then I can assist with finding supported PIDs. More on that later.

 

[TJBaker57]

I been trying to use some PIDs that will work on my PC based logger trying to get myself a logger that I can take with me since I don't have a laptop. Mostly trying to get PIDs 1617(desired IAC airflow) 119e(desired AFR) 114b(egr analog where my wideband is connected) to work. From what I've scoured on the web mode 22 should be the correct mode but I get nothing. I've tried it with leaving the header blank tried it with it on Auto no dice. Appending a 01 doesn't seem to make a difference. I'm using a p59 from an express van as my ECU it was widely used from 03-06 and uses class 2(j1850vpw). Is there possibly something I'm missing here that I can do to get this working?

I have a 2005 Yukon with what I believe is a P59 PCM. What year is your P59? Maybe we can start from a common point?

My 2005 P59 definitely supports PID 119E. I use a header of "6C 10 F1" and I do use the "01" appended after the PID.

Sounds like you are using Torque Pro for this?

Maybe try using the built-in serial terminal in "TorqueScan" in "direct control" mode. That would provide instant feedback and allow you to see any response from the PCM as you try different possible messages.

Alternatively get the Android App "Serial Bluetooth Terminal" by Kai Morich. That app makes it easier to see what is going on behind the scenes.

 

[jdubb]

Hey all,
Looks like I'm late to the party with this, Ive looked through the previous pages thinking I might find a file that has the documented PIDs values and definitions with no luck. Its also possible that I missed it, Ive looked all over for something like this including the service manuals and found one or two lists but thats it. Might there be something like this floating around here? I'm running an 02 Avalanche and 07 Impala if thats pertinent info. I saw someone mention TJ's PID list as a stickie but Ive failed in finding it.

 

[azswiss]

List attached in Excel format.

 

[TJBaker57]

I'm running an 02 Avalanche

Which engine in that Avalanche?? I have an 05 Yukon with the LM7 (engine code "T"). We may have similar PIDs

 

[jdubb]

My Man! I appreciate that greatly, I have been looking all over for any and no dice. I even went to tunerpro and rifled through all of his links and couldnt find anything. Yeah, I have engine code "T" as well. I dont think you could kill one of those if you tried. Do you have a 3d printer by any chance? I'll put you some custom parts files together to say thanks.

 

[jdubb]

List attached in Excel format.

Thanks a million my friend, you saved me so much time and aggravation. I've got bad A-D-D I guess because I have to have 5 projects going at once and I wasnt going to get anywhere on this one unless I sat down and worked on it until it was finished. I got my graphics, logo, guages, and everything else done in Torque-Pro and then realized I needed Extended PIDs. I downloaded the GM pack but none are showing up as good for some reason. Torque-scan isnt even really picking anything up, maybe 35 total.

 

[azswiss]

You are welcome!

 

[buraan]

Just curious... Did you ever make any progress on this?

Since I last posted, I've come up with a vehicle simulator that handles CAN-protocol vehicle nodes.
This means that I can now simulate vehicles like your (CAN-protocol) 2012 Opel 'Astra J'.

I've been testing a bit and can see that there is a lot of information available for that vehicle, using the 'GDS2' software that came with my VXDIAG VCX Nano hardware.

So if you're still looking for information, let me know and I'll try to get you some useful PIDs which might be usable in Torque Pro.

Hello AmpOverload,
thanks a million times for your kindness. I did not make too much progress with the misfire counter, tbh. I tried to borrow or get a faulty coil pack but as soon people understood I need that for a project they want me to pay for it, so at the end I abandoned to find those pids. Maybe if my own coil pack goes faulty, I'll continue.

Regards to other pids; thank you much! I don't know what is even possible for the A14NET/B14NET engine? I'm having the standard pids + oil temp and I'm fine with that. Maybe the turbo boost & related data would be useful. The transmission is manual, so there is not much to see. One of my friend has a Z16LET (1.6 turbo, 180hp) engine with automatic gears (I think it's an AF40-6T40 or -6T45), if you could find the transmission oil temperature, I'm sure he would be grateful.

I know I'm not a frequent writer so if you sold your GDS2 in the meantime or if you do something more useful instead of looking for these pids, I understand.

 

[AmpOverload]

I did not make too much progress with the misfire counter, tbh.

Welcome back! Sorry to hear that. For the record, my testing shows that your 2012 Astra J does appear to use the standard GM misfire PIDs (Mode $22, PIDs $1201 to $1208) as documented in many places, including earlier in this very thread (see my post #626).

Regards to other pids; thank you much! I don't know what is even possible for the A14NET/B14NET engine? I'm having the standard pids + oil temp and I'm fine with that. Maybe the turbo boost & related data would be useful.

I ran GDS2 and selected the following: 2012, Opel Astra J, with "LUJ" engine

Here is a screenshot of the GDS2-supported PIDs from the "Engine Data" group:


If you can pick out a few PIDs from that list that you're most interested in monitoring, I will make an effort to decipher the PID number and formula for each one. Since it usually takes a bit of time to determine each PID's meaning and formula, please pick no more than 10 PIDs (by the "Parameter Name" column) from that list for now, ordered to start with the ones that are most important to you.

Here is a raw list of the 51 Mode $22 PID numbers that GDS2 is querying for that list of "Engine Data" for your 2012 Opel Astra J with LUJ engine, in case it's useful for some "exploring" of your own:

$0004, $0005, $0006, $0007, $000B, $000C, $000D, $000E, $000F, $0010,
$0014, $0015, $001F, $002E, $002F, $0030, $0031, $0033, $0042, $0044,
$0046, $1123, $1124, $1127, $1128, $1130, $1131, $1190, $11C9, $1232,
$1233, $12B1, $12C3, $131F, $136C, $148D, $150C, $1523, $2006, $2020,
$203F, $205A, $2070, $207E, $20D0, $20D4, $2301, $3201, $328B, $328D,
$3298

Mode $22 PIDs $0004 through $0046 are defined (as equivalents to Mode $01 PIDs) by SAE J1979. The ones from $1123 to $3298 are defined by the manufacturer.

Note that when I select a vehicle, GDS2 wants a VIN. So if you can provide me with your VIN, it might give better results in some cases. Feel free to use zero for the last 3 digits of the VIN if you'd like to remain anonymous.

Another thing that is often useful when deciphering a specific vehicle's PIDs is a photo of the sticker with the list of RPO ("Regular Production Options") codes. It's often found in the "glove compartment" or on the inside lid of the trunk. It probably won't matter for the PCM, but it you ever want to probe other nodes on a vehicle, knowing the RPO list can be helpful, so it's good to have that list ready.

Another thing to mention is that both Tech2/Tech2Win and GDS2 sometimes issue initial queries (for a specific vehicle) to which my simulator does not know how to respond. Typically this is not a problem, but it might cause Tech2/GDS2 to think a vehicle has a different feature or module than it really does. I don't know if this is a factor with your vehicle, but I do see GDS2 making some of these types of queries early on. For now though, I won't worry about this.

One of my friend has a Z16LET (1.6 turbo, 180hp) engine with automatic gears (I think it's an AF40-6T40 or -6T45), if you could find the transmission oil temperature, I'm sure he would be grateful.

As for your friend's vehicle, I'll need more details. What model year? Is this also an Opel Astra J? A VIN would help here too. I guessed that his vehicle was a 2012 Opel Astra J. Here is a screenshot of the "Engine Identifier" options in GDS2:


I selected "1.6L (LLU)" because that seemed to be the closest match for a "Z16LET" engine, but you should confirm this with him if possible and let me know.

Anyway, when I ran with those assumptions, it looks like your friend's "Transmission Fluid Temperature" (TFT) PID is one of the standard ones used by GM: Mode $22, PID $1940, formula "A - 40" in degC. I had my simulator reply to queries for that PID with a controlled value and GDS2 showed it correctly, so it should work for him. Have him try that if you can and please let us know if that works. If not, I'll try again once you report the details of his vehicle.

 

[buraan]

Welcome back! Sorry to hear that. For the record, my testing shows that your 2012 Astra J does appear to use the standard GM misfire PIDs (Mode $22, PIDs $1201 to $1208) as documented in many places

Sounds good - I'll set them up in my Torque and I'll see if I can see any interesting thing.

I ran GDS2 and selected the following: 2012, Opel Astra J, with "LUJ" engine
Here is a screenshot of the GDS2-supported PIDs from the "Engine Data" group:

Wow, thanks! I'd especially interested in

- Boost Pressure Sensor [kPa]
- Turbocharger Bypass Solenoid Valve Command [%]
- Turbocharger Wastegate Solenoid Valve Command [%]
- Fuel economy [L/h] -> Sounds interesting, together with speed I can calculate L/km and ultimately, [L/100km], not sure if Torque can do this thing

If you don't mind looking for more, these are my good-to-have

- BARO (I guess it's barometric pressure) [kPa]
- EVAP Purge Solenoid Valve Command [%]

Thank you indeed. The VIN is W0LPD8EC8D8063xxx. At the moment I can't look for the RPO code but my car doesn't have anything fancy (no xenon, no roof window, no trailer hook...). The model year is 2013, as the VIN number shows.

As for your friend's vehicle, I'll need more details. What model year? Is this also an Opel Astra J? A VIN would help here too. I guessed that his vehicle was a 2012 Opel Astra J.

A perfect shoot! It's a 2012 Astra J Sport Tourer, with the LLU engine. Unfortunately I don't know the VIN and my friend don't want to tell it. Note to self, I need to be more sneaky instead of direct questions to people.

Anyway, when I ran with those assumptions, it looks like your friend's "Transmission Fluid Temperature" (TFT) PID is one of the standard ones used by GM: Mode $22, PID $1940, formula "A - 40" in degC. I had my simulator reply to queries for that PID with a controlled value and GDS2 showed it correctly, so it should work for him.

A big thanks to you! I'll come back with the results once I'll met him.

 

[AmpOverload]

Wow, thanks! I'd especially interested in

- Boost Pressure Sensor [kPa]
- Turbocharger Bypass Solenoid Valve Command [%]
- Turbocharger Wastegate Solenoid Valve Command [%]
- Fuel economy [L/h] -> Sounds interesting, together with speed I can calculate L/km and ultimately, [L/100km], not sure if Torque can do this thing

If you don't mind looking for more, these are my good-to-have

- BARO (I guess it's barometric pressure) [kPa]
- EVAP Purge Solenoid Valve Command [%]

OK, sounds good! I might not have the answer today, but I will figure things out soon. Give me a day or two because things are a bit hectic here at the moment.

It's a 2012 Astra J Sport Tourer, with the LLU engine. Unfortunately I don't know the VIN and my friend don't want to tell it. Note to self, I need to be more sneaky instead of direct questions to people.

That's OK if your friend won't give you his VIN. I ask only because it might give better information in some cases, but I can proceed without it, if needed.