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!