Drop the 01 at the end of the pid given and use
header 6C10F1 (or Auto)…

((Signed(A)*256)+B)*0.024

((Signed(A)*256)+B)*(1000/15625)
((Signed(A)*256)+B)*(1/16)

ATSH6C10F1 set header to 6C10F1.

ATSP2 set protocol 2 (VPW). Torque will
set the correct protocol when you connect
so all is needed is to create a custom pid
and snap the throttle over the threshold rpm
for value updates.

ATZ resets the adapter.

Edited.

The last byte (01) instructs the ECU to return
a single response. Not needed within Torque.
(Mode 22 addresses are two bytes from 00 00
thru FF FF). Notice the response example given
didn’t include it.

If…

AA=04 and BB=3B matches +26.0°
AA=02 and BB=71 matches +15.0°
AA=00 and BB=D0 matches +5.0°
AA=00 and BB=53 matches +2.0°
AA=00 and BB=3F matches +1.5°
AA=00 and BB=2A matches +1.0°
AA=00 and BB=00 matches 0.0°
AA=FF and BB=D6 matches -1.0°
AA=FF and BB=C1 matches -1.5°
AA=FF and BB=AD matches -2.0°
AA=FF and BB=30 matches -5.0°
AA=FD and BB=8F matches -15.0°
AA=FB and BB=C5 matches -26.0°

Then multiplier equals (1000/41667) = 0.024

If…

AA=01 and BB=96 matches +26.0°
AA=00 and BB=EA matches +15.0°
AA=00 and BB=4E matches +5.0°
AA=00 and BB=1F matches +2.0°
AA=00 and BB=17 matches +1.5°
AA=00 and BB=10 matches +1.0°
AA=00 and BB=00 matches 0.0°
AA=FF and BB=F0 matches -1.0°
AA=FF and BB=E9 matches -1.5°
AA=FF and BB=E1 matches -2.0°
AA=FF and BB=B2 matches -5.0°
AA=FF and BB=16 matches -15.0°
AA=FE and BB=6A matches -26.0°

Then multiplier equals (1000/15625) = 0.064

If…

AA=01 and BB=A0 matches +26.0°
AA=00 and BB=F0 matches +15.0°
AA=00 and BB=50 matches +5.0°
AA=00 and BB=20 matches +2.0°
AA=00 and BB=18 matches +1.5°
AA=00 and BB=10 matches +1.0°
AA=00 and BB=00 matches 0.0°
AA=FF and BB=F0 matches -1.0°
AA=FF and BB=E8 matches -1.5°
AA=FF and BB=E0 matches -2.0°
AA=FF and BB=B0 matches -5.0°
AA=FF and BB=10 matches -15.0°
AA=FE and BB=60 matches -26.0°

Then multiplier equals (1/16) = 0.0625

For VPW header 6C10F1.. the ECU address is 10
and F1 is the tester address.

While in the pid editor, test the pid for the
returned hex code response.

The torque variables used will be dependent on
the byte positions in the hex response.

If the response matches the example given then
Torque variables A and B are correct.

If a P1345 dtc is set at +/- 26 degrees for 1999 (where one
tooth is ~27.7 degrees) ? … curious what value the
hex response reports at that threshold and which
equation comes closest. Not sure how well engine
will run at those thresholds though.

Edited.

Okay, with 221301 as the Mode/PID string, 6C10F1 as the header string, and (Signed(A)*256)+B)*0.024 as the formula, we get a response of 7F22130112 and constantly updating data if you hold the RPM up a bit.

I know that the closer you get this value to zero, the closer you are to exact specifications. But I highly suspect the formula is slightly inaccurate were A=00 with low values of B, and much more so if A=FF. More on why later.

But for the moment, it doesn’t matter. While holding your phone in one hand you can adjust the distributor with the other. Set as close to zero as you can reasonably get, and you are good to go.

I have some more info regarding ranges, limits, etc, and I’ll try to get it typed up later today. But I’m still not sure if the data is a one or two complement number.

Sorry, between the holidays and having to dig up my main sewer line, I’ve just not had time to play with this much. And then it snowed, so I’ve got a muddy mess out here.

With the engine at idle I hit the test button within the PID editor. That returned the last recorded offset and the 7F23130112 response. As soon as you rev it up a bit the data begins to change but the response code does not. As I take it up over 2k RPM the data begins to stabilize roughly 0.2 deg lower than the initial value.

I have Alldata for my vehicles, and I’ve seen the excerpt from the actual GM procedure for this. Nowhere does it say anything about “snapping the throttle”. They heavily imply holding it exactly at 1000 RPM, which, using the GM Tech2 scantool, you can command the engine to do.

And that makes sense. Due to slop in the timing chain the value will change slightly at different RPMs, even on a fresh engine. So any procedure would pick a specific RPM for consistency purposes.

What I don’t know yet is how the CPU is treating this data internally, versus how it sends it you, versus how you display it. I need to confirm something that I’m pretty sure I saw, but it was getting dark and I was out of time.

From the terminal I know that A=00, and B increases as you go slightly positive. I have little doubt that A will increase to 01, 02, etc if you keep going. But I’m not so sure about the negative. I know that A will turn FF, and I have little doubt it will decrease to FE, FD, etc.

But…my admittedly fuzzy memory is telling me that when A=FF, B started out very low and -increased- as I went slightly further clockwise. If you were directly referencing bytes within a word, B would be FF when you first went negative, and decrease as you went more so.

While I’ve little experience with the current crop of vehicle CPU’s, I started with assembly on a IBM 370 mainframe, punch cards, and have done a bit of embedded CPU work. This kind of data structure might be uncommon now, but it didn’t used to be.

I can easily confirm this part, and will when I get a chance later this week. Figuring out if it’s one or two’s complement will take a bit more work. I’m sure I can rig a wedge up to hold the throttle at a fixed RPM 1k or better. And find somewhere that I can lay something to make a fixed reference spot on the distributor.

Now I just got a really dirty look because I eyeballed my wife’s seamstress tape, with millimeter marks on one side. She won’t let me use it to measure circumference, said I get it dirty, and I don’t have calipers that big. So, feeling froggy, I said, well, how about letting me cut just a little tiny bit off of one end, so I can silicon to the distributor?

Whistles to self…

Fire up the vehicle, set it zero offset, and now you can record data versus distance traveled. And that’s easily convertible to degrees for comparison.

Give me some time and I’ll get some more info. Grandpa is too busy getting in trouble at the moment

Quote from Capp777 on December 28, 2014
Thank you for your efforts… a lot of people
have requested this function for Torque.

I can’t take credit for the most important part…finding and publishing the darn codes

We are okay on the positive side right now, it’s the negative that has to be dealt with. That means I have to go loosen a distributor and slowly adjust to negative while watching the data. Just find out whether B resets to 00 or FF when I first go negative (A=FF), which will be easy enough as you slowly turn it with the engine RPM held relatively stable (even a helper will do). I’ll try to get that done in the next couple of days. I’m just really busy right now, and everything seems to be breaking at once, literally

Snapping the throttle, while it will work to bring it well within spec, is “not the optimum procedure”. Because of slop in the timing chain as the engine revs up and down, it’s not going to be as consistent. From what I saw driving the other day you can probably tell just how stretched that chain is based on the difference between 1k and 4k RPM.

But it would let you do it “close enough” with one hand, no wedge, no helper, get ‘er done.

The hex data you asked about is coming from the Elm Basic terminal app when I query it manually. As to the 7F response within the editor, I have no idea. Never researched ODBII or Elm327 adapters (yet). But whether in the PID editor test mode, or as a real time display, you -are- getting the data back. It constantly updates as long as the RPM’s are up, and as I mentioned above, varies slightly with it.

I probably need to play with Torque, even there other than add tranny temp and play with this PID, I’ve literally not had the time to do anything. Because of your questions about the 7F response, I’m using the terminal for raw data.

What I really need to see is two separate displays, one showing calculated, another (or two, depending on what you can do in the PID editor), A and B separately either as hex or binary. No signed vs unsigned decimal, strictly raw data.

That would make it go a bit faster.

Simple test using elm terminal…

Issue pid without the 01 to compare
response at idle.

If Torque receives the 62… response then
your equations will return data correctly
which you described as working.

The 01 tells elm327 to expect one line of
response. (adapter won’t have to timeout
waiting for a response before returning).

Also you might try adding the pids to
Torque’s file data logging to capture the
values as you slowly move the distributor.

Good luck with your other projects!

Happy New Year

Edited.

If I am interpreting Sooner’s comments
correctly… in the pid editor, without the
01, he is getting a 62… response with data
and 7F22… response following. Torque is
assigning variables to the 62… response
correctly and Torque display is showing
updating data (green light).

In terminal, with the 01 added, the 7F22…
is ignored and not displayed after the
62… response.

Just trying to build a mental picture of what
Sooner is seeing.

Based upon byte BB’s questionable response to changes, I
would create separate pids using the following
equations:

1. Signed(A)*256

2. B

Edited.

Tahoe 96 with vortec not support this method?

Les, I thought I’d respond here instead of over on the Blazer forum because this is a little “techy” and app specific to this app and this forum.

Did you specify a negative minimum value? Are you getting any data for PID 221301? Have you tried 22130101?

Also, check to see if you’re getting any data at all, without the scaling factor. Use the formula “(signed(A)*256) + B”. That will display the binary integer the ECM is sending, without scaling. It should range from -32768 to 32767. And make sure with this formula that you set the minimum to a high negative number (-32000 is good).

If that returns a constant zero, I suspect there are two (or more) PIDs used by GM for this data. That would also be consistent with your description of getting this data with another app, where I thought you said there were two (or more) PID choices for “CMP Ret” and one had an asterisk on it.

I’ve been away from my “Oldsmo-Blazer” for a few weeks, and I won’t be back to it for another week or two. I’ll check more on this when I get back to it.

You might want to test the pid while in
the pid editor (with the rpm above the
threshold for a proper response) to see
if a valid hex response is received.

The formula above is good enough to get
one within spec but is not exact to a calibrated
source. You will notice I suggested other equations
that may be closer but were never checked to
my knowledge.

The questions I have are what are your
test response bytes received and what
module is responding?

If your response is valid then we can calculate
a formula from the raw hex bytes and your
known current setting. (0.3 to 0.7°).

If its not valid you could try to run torquescan
to see if a pid can be found with a hex value
that’s close to what you seek.

Edit:

If you created a custom pid did you try…

Dropping the last 01 in the pid number. Torque
doesn’t require it but terminal mode commands
do.

Assuming your protocol is VPW… try
header 6C10F1.

To get a zero result your hex data would be
00 00. Since your stated value is positive your
hex data would have to be greater than 00 00,
e.g., 00 14.