Torque

Forums

Forums

Guest  

Show or hide header
Welcome Guest, posting in this forum require registration.




Torque » Torque OBD ECU Scanner » Torque Discussion / Ideas » GM Cam Retard Offset PID Found!

Pages: 1 [2] 3
Author Topic: GM Cam Retard Offset PID Found!
lesmyer
Member
Posts: 3
Post Re: GM Cam Retard Offset PID Found!
on: July 20, 2016 (GMT)

OK you’ve given me some interesting things to do. Would be cool to get this one figured out for Torque Pro. I’ll see what I info I can obtain.

DCS
Member
Posts: 4
Post Re: GM Cam Retard Offset PID Found!
on: September 10, 2016 (GMT)

Quote from SoonerCentral on December 26, 2014
Here’s the easier way with Torque:

– Buy the app, just do it!
– Get it connected and working with your ODB2 adapter.
– Create a custom PID. The critical parts are 221301 as the Mode/PID string, a negative minimum value (-100 should be fine), and the equation is ((Signed(A)*256)+B)*0.024
– Add a real time display to show this PID along with the engine RPM.

Rev engine over 1k, adjust within +/- 2.0, slightly tighten, and retest. I say slightly, because it’s entirely true that the mere act of doing so will generally change the setting. On a 5.7, with the wiring harness in the way…

*********************************

OK, I just bought Torque Pro, and I followed (and double-checked) the steps above.

If I use the Edit Custom PID method and click Test at the bottom of that screen, the equation returns a value of 7F2213010011.

I set up a real time display for the custom PID, but it just sits at zero, no matter what I do. I edited that display to include 3 digits, so it displays 0.000, but it never changes. Revs (rpm’s) are right next to it, and they are working properly.

1996 5.7l vortec.

At this point, I I tried this with OBD Header set at blank, also set at ‘Auto’, both provide the same result.

My interface is a blue chinese Jtron ELM327 Mini that I have had for about 4 years pr so.

I’m using Torque Pro on an android phone.

I’m guessing that the 0011 trailer on the Test Response may be valid data. When I have time, I will test this theory by moving the distributor cap and doing another test to see if the two end values change.

I am not getting a code. This is more of a thing where I have done the intake gasket job many years ago, and also changed a rotor many years ago, but I have never had a scanner check of distributor cap alignment. I’d like to check it and adjust it if necessary, plus I just ordered a new cap and rotor because my rig now has 225K miles, so I want to replace those components and then set the new distributor as close to 0° as I can.

Bottom line – for me, the realtime display does not work. Maybe the Test response is a valid response.

This thread is interesting, but it does not really provide a full suite of usable data for a new reader.

This thread provides “critical parts” for the custom PID, but it leaves me wondering about Scale Factor, Unit Type, OBD Header, Diagnostic Start Command, and Diagnostic Stop Command. Are we really to just leave these blank?

Also, if one performs a test and receives the response described above, are those last two values something that one would consider valid, usable responses?

Thanks!

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: September 10, 2016 (GMT)

Did you try with header 6C10F1 as mentioned
in previous posts? (VPW?).

The 7F response is an unsuccessful
response.

Scaling x1
Units degrees
diagnostic start stop commands were not
needed by the OP. Leave blank.

Remember to hold rpm above the suggested
threshold before receiving valid data, otherwise
an error will be returned. Though OP had a
different error than yours?

DCS
Member
Posts: 4
Post Re: GM Cam Retard Offset PID Found!
on: September 11, 2016 (GMT)

Thanks Capp, I will try this.

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: September 12, 2016 (GMT)

In my feeble memory I thought I read
somewhere the 1996 used a different
spec than zero? You might want to check?

(For example P1345 sets at +/-15° on
your 1996 versus +/-26° on the 1999)?

Would you let us know if you are able to
get this working?

TIA

DCS
Member
Posts: 4
Post Re: GM Cam Retard Offset PID Found!
on: September 13, 2016 (GMT)

I don’t know what VPW means.

I did try the 6C10F1 header. I made sure that the engine was stuck at 1100 rpms before starting Torque. I tried the test function, but got the same invalid response as before.

I get a lot of valid functions from my kit. It will read correct rpms, scan codes, erase codes, etc, etc.
It just won’t work for CMPRET with the formulas and methods discussed here.

I’m open to other ideas or suggestions, because I would love to get this simple capability of properly aligning the distributor, whether it be with Torque or some other app.

All of my reading suggests that a 96 vortec in a Yukon is the same 0+2° spec as other years.

Thanks.

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: September 13, 2016 (GMT)

VPW protocol was typically used in
older GMs to communicate with the
vehicle.

You can verify which protocol is in use
by looking under adapter status icon
functions while connected to the vehicle.

DCS
Member
Posts: 4
Post Re: GM Cam Retard Offset PID Found!
on: September 16, 2016 (GMT)

I got it to work with DashCommand.

.95 for the app. .95 for the special GM PID’s.

It works fine with my 5yr old chinese ELM327 Mini bluetooth interface.

I found an old thread on the palmerperfomance.com forum. It tells how to use the free evaluation version of DashCommand to see whether the app will support the Camshaft Retard Offset PID (aka CMP, aka Cam Retard) for your specific vehicle.

That’s how I started. I installed the free DC app, then entered the basic details for my vehicle, then the following steps:
1.) Go to the Data Grid View.
2.) Tap PIDs.
3.) Tap Add PIDs
4.) Tap the little 3-dot menu button at the bottom right.
5.) Tap Sort PIDs.
6.) Sort by Manufacurer.
7.) Tap GM.
8.) Look for the GM.ENGINE.CR pid. If it is present in the list of available PID’s under the GM heading, then supposedly DashCommand will display that value after you buy the app and the extended code set. If this particular PID is not present in the list, then there is no reason for you to buy the app, because the app doesn’t support that code for your vehicle.

For me – it was the 3rd item in the list. So I bought the app, then I bought the extended GM code set.

Then I clicked the Gauges item in the home menu, and repeated a similar “sort by manufacturer” process to add the PID from the extended set to the main app. Then I set up a CR dial gauge with digital window, right next to a similar gauge for RPM. Then I started my Yukon and tapped the Connect button. Holy shit! There it was! -4.8°.

I tapped the back button and then the disconnect button.

Then I changed all my plugs, wires, my distributor cap, and rotor. While the cap was off, I loosened the distributor hold-down bolt, to where the distributor was free to turn, but snug, not sloppy. Then I put everything back together and set the distributor close to where it was before I started the job (based on a cell-phone pic). Then I started the engine (air intake assy still off the vehicle). I opened the throttle slightly by hand and stuck a thin piece of cardboard between the throttle-stop screw and its related contact arm on the throttle pulley assy and then let it shut on the cardboard, pinching it in place. This caused the motor to run at 1500rpm. Then I tapped the Connect button on the DC app, and pulled up my gauge screen. -9.4°

What I learned at this point was that the motor will start if your distributor is 7.4° out of spec, and also that it won’t necessarily throw a code right away, because the only codes I got were MAF codes related to the fact that the MAF sensor was unplugged and laying on the floor across the garage.

Anyway, I twisted the distributor CCW, and sure enough, the CR reading came around to with the 4° spec window. So I kind of eyeballed the position of the distributor that was close to 0°, then I shut off the motor, bellied up on some folded towels on the fan shroud, turned the distributor to where I thought it should go, and then commenced the battle of tightening that damn hold-down bolt while laying on the motor and holding the distributor in the position I thought it should be. I tightened the bolt just past snug, then fired up the motor and restarted DashCommand.

I got 0.1°. LOL. I never get lucky like that, but I did today.

That’s it. I tightened the hold-down bolt to 25ft lbs, buttoned everything up and went for a spin. On the hwy, it was cruising at 55mph at ~1500 rpms, and I tapped the connect button on DC, and presto, I was holding a fluctuating CR value of between 0 and 0.1°. Job done.

It was weird in a way. I had to do a lot of reading to try to find something that might work, and then all of a sudden, there it was.

Motor sounds smooth. No more tiny stumble here and there. Maybe it was the new spark plug wires and cap and rotor. Maybe it was the CR. maybe it’s both.

Thanks for the feedback here.

Funny to chase a code this hard for a 20yr old vehicle.

Oh, one more thing: Dash Command is pretty good, but it is not an intuitive interface. I’m do some webdev work. Intuitive processes are elemental to good design. DC is pretty powerful, but it’s damn clunky. If I hadn’t found that old thread about sorting by manufacturer to see a code that is otherwise not displayed anywhere, and if I hadn’t figured out that you have to tap a little obscure menu button before you can do the search, then DC would have been a bust for me. It has lot’s of bells and whistles, but it has no intuitive flow. Torque is a better design, but it ain’t got no CMP.

Good luck!

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: September 18, 2016 (GMT)

I am glad you found a solution to your problem
but I’m a little curious if…

Running Torque scan until it reaches the
suggested pid would yield working results?

and

Would using tester present command (3F?) in the
diagnostics start command field or using a diagnostics
enable command yield working results?

or it could just be a different pid :-(

Would be great if someone with a known offset and
hex response could post so this equation can be
calibrated to yield closer results away from zero.

Edited.

Interesting reading:

ht tp://www.fullsizechevy.com/forum/forum/general-discussion/technical-maintenance/487877-custom-pid-cmpret-cam-retard-offset-torque

ht tp://www.gmt400.com/threads/cmpret-pid-something-new.35694/

Does anyone know if Torque supports 2A requests
with 6A responses mentioned in the above forums/threads?

Has anyone tried this yet and willing to post their
raw hex responses?

Edited again 08/19/2017.

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: August 22, 2017 (GMT)

Bump hoping for some answers…

Will Torque parse the 2A request correctly?

Assuming the given hex response example…

6C F1 10 6A 09 00 00 37 76 FF CE 4F

is typical and can be parsed correctly…

I would test:

((Signed(E)*256)+F)*(1000/15625)
((Signed(N4)*256)+N5)*(1000/15625)
((Signed(R9)*256)+R10)*(1000/15625)

((Signed(E)*256)+F)*(1/16)
((Signed(N4)*256)+N5)*(1/16)
((Signed(R9)*256)+R10)*(1/16)

(I drive an OBDI Jeep and can’t test this
further without your help).

Header: 6C10F1
Mode/Pid: See interesting reading links above (2A…)
Long Name: Camshaft Retard Offset (Test)
Short Name: Cmpret?
Equation: See test equations above.
Units: Degrees (°)
Scaling: x1
Min: -24.0
Max: 24.0
Diagnostic Stop/Start: Leave blank.

Rx addressing may work if Torque cannot
parse the other addressing types correctly.

I am also wondering if…

37 76 is engine rpm?

((C*256)+D)*0.125 = 1775 ?
((N2*256)+N3)*0.125 = 1775 ?
((R7*256)+R8)*0.125 = 1775 ?

4F is engine coolant temperature?

G*(9/5)-40 = 102 °F ?
N6*(9/5)-40 = 102 °F ?
R11*(9/5)-40 = 102 °F ?

Edited.

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: September 27, 2017 (GMT)

Still hoping for answers.

Davkenrem
Member
Posts: 1
Post Re: GM Cam Retard Offset PID Found!
on: November 17, 2018 (GMT)

Quote from DCS on September 16, 2016
I got it to work with DashCommand.

.95 for the app. .95 for the special GM PID’s.

It works fine with my 5yr old chinese ELM327 Mini bluetooth interface.

I found an old thread on the palmerperfomance.com forum. It tells how to use the free evaluation version of DashCommand to see whether the app will support the Camshaft Retard Offset PID (aka CMP, aka Cam Retard) for your specific vehicle.

That’s how I started. I installed the free DC app, then entered the basic details for my vehicle, then the following steps:
1.) Go to the Data Grid View.
2.) Tap PIDs.
3.) Tap Add PIDs
4.) Tap the little 3-dot menu button at the bottom right.
5.) Tap Sort PIDs.
6.) Sort by Manufacurer.
7.) Tap GM.
8.) Look for the GM.ENGINE.CR pid. If it is present in the list of available PID’s under the GM heading, then supposedly DashCommand will display that value after you buy the app and the extended code set. If this particular PID is not present in the list, then there is no reason for you to buy the app, because the app doesn’t support that code for your vehicle.

For me – it was the 3rd item in the list. So I bought the app, then I bought the extended GM code set.

Then I clicked the Gauges item in the home menu, and repeated a similar “sort by manufacturer” process to add the PID from the extended set to the main app. Then I set up a CR dial gauge with digital window, right next to a similar gauge for RPM. Then I started my Yukon and tapped the Connect button. Holy shit! There it was! -4.8°.

I tapped the back button and then the disconnect button.

Then I changed all my plugs, wires, my distributor cap, and rotor. While the cap was off, I loosened the distributor hold-down bolt, to where the distributor was free to turn, but snug, not sloppy. Then I put everything back together and set the distributor close to where it was before I started the job (based on a cell-phone pic). Then I started the engine (air intake assy still off the vehicle). I opened the throttle slightly by hand and stuck a thin piece of cardboard between the throttle-stop screw and its related contact arm on the throttle pulley assy and then let it shut on the cardboard, pinching it in place. This caused the motor to run at 1500rpm. Then I tapped the Connect button on the DC app, and pulled up my gauge screen. -9.4°

What I learned at this point was that the motor will start if your distributor is 7.4° out of spec, and also that it won’t necessarily throw a code right away, because the only codes I got were MAF codes related to the fact that the MAF sensor was unplugged and laying on the floor across the garage.

Anyway, I twisted the distributor CCW, and sure enough, the CR reading came around to with the 4° spec window. So I kind of eyeballed the position of the distributor that was close to 0°, then I shut off the motor, bellied up on some folded towels on the fan shroud, turned the distributor to where I thought it should go, and then commenced the battle of tightening that damn hold-down bolt while laying on the motor and holding the distributor in the position I thought it should be. I tightened the bolt just past snug, then fired up the motor and restarted DashCommand.

I got 0.1°. LOL. I never get lucky like that, but I did today.

That’s it. I tightened the hold-down bolt to 25ft lbs, buttoned everything up and went for a spin. On the hwy, it was cruising at 55mph at ~1500 rpms, and I tapped the connect button on DC, and presto, I was holding a fluctuating CR value of between 0 and 0.1°. Job done.

It was weird in a way. I had to do a lot of reading to try to find something that might work, and then all of a sudden, there it was.

Motor sounds smooth. No more tiny stumble here and there. Maybe it was the new spark plug wires and cap and rotor. Maybe it was the CR. maybe it’s both.

Thanks for the feedback here.

Funny to chase a code this hard for a 20yr old vehicle.

Oh, one more thing: Dash Command is pretty good, but it is not an intuitive interface. I’m do some webdev work. Intuitive processes are elemental to good design. DC is pretty powerful, but it’s damn clunky. If I hadn’t found that old thread about sorting by manufacturer to see a code that is otherwise not displayed anywhere, and if I hadn’t figured out that you have to tap a little obscure menu button before you can do the search, then DC would have been a bust for me. It has lot’s of bells and whistles, but it has no intuitive flow. Torque is a better design, but it ain’t got no CMP.

Good luck!

This worked for me thanks!!

F-150Torqued
Member
Posts: 382
Post Re: GM Cam Retard Offset PID Found!
on: November 19, 2018 (GMT)

@capp777 and @DCS and @SoonerCentral – I don’t mean to stick my nose in your business. But reading through this thread sounds reminiscent of what I went through for about a year trying to figure out bizzar results from the Intake Manifold Runner Control (IMRC) on my F150 5.4L 3 valve. I see you guys talking about ‘Tangents’ and about 100 other possible formulas – including -32768 to +32762 – doing everything imaginable with Bytes “A” and “B” – none of which seem to work. That’s the same thing I went through – described in detail in this thread: https://torque-bhp.com/forums/?wpforumaction=viewtopic&t=9617.0

I notice @SoonerCentral commented – quoting as follows:

“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.”

THIS is all vaguely similar to what Bytes “A” and “B” were reporting on my IMRC. In developing formulas, I have learned that usually I end up trying to make them too complicated. The PCM generally outputs something much more sensible – if I can figure out what it is.

Like @SoonerCentral, I have an assembly background (of old), and I was aware one of the fastest operations in a processor is two’s complement addition. So I decided to simply treat the two bytes ‘signed’ 7 bit twos compliment bytes and add them together —- and instantly the readings from the device produce -127 to 128. VERY EASY TO FACTOR to ‘degrees’ open or ‘percent’ open or whatever.

I believe your two byte CMP reading in Torque might produce a clean “+” or “-” reading by simply Signed(A)+Signed(B) and see what you get. You might need to factor the result to 360 degrees or something to get the accurate plus/minus gauge reading.

I don’t have a compatible vehicle to try it on, but JUST A THOUGHT.

———–
54371019

Capp777
Member
Posts: 2560
Post Re: GM Cam Retard Offset PID Found!
on: November 19, 2018 (GMT)

I believe the form of the equation given is
correct but the slope of 0.024 is not. Since
zero is ideal it still works with any slope…
just can’t believe the degrees reading away
from zero without the correct slope.

A two byte signed equation produces a result
from -32768 to 32767. Not sure treating each
byte as a signed value to itself would work
properly. For instance…

In the case of Signed(A)+Signed(B)

FF FF would result in -1 and -1 which when
added together becomes -2.

In our case… ((Signed(A)*256)+B)

FF FF would result in (-1*256)) and 255 which when
added together becomes -1.

So far there are two possible pids for this parameter
but only one has been tested to date.

F-150Torqued
Member
Posts: 382
Post Re: GM Cam Retard Offset PID Found!
on: November 20, 2018 (GMT)

As I mentioned, it was “just a thought” based on reading through the long thread describing numerous efforts. Drawing upon my ‘somewhat fading’ career experience in writing assembly code for process control environments – an efficient way to represent the relationship between two events in a microprocessor would be to set up two counters (“A” and “B”), one counting negatively before an event (TDC or PIP) and the other counting positively after the event.

I didn’t see any actual sample data to experiment with and wasn’t sure if the table in your post of 12/2/14 was actual data results from a log or hypothetical.

Certainly the response has to be treated appropriately depending on how the ECU stored it. Treating a signed word consisting of byte “A” and “B” as two signed bytes would obviously produce erroneous results – in the same fashion as treating two independent twos compliment signed bytes as a signed word would do.

I would point out that the FIRST sample you provided –

FF FF would result in -1 and -1 which when
added together becomes -2.

– fails to properly apply rules of twos complement addition where the answer would actually be Zero. Thus correcting a problem that occurs in addition of signed binary numbers that results from the system actually having two ZERO values (a Positive Zero and a negative Zero) at the boundary between positive / negative.

I wondered if this could have anything to do with @SoonerCentral was having difficulty obtaining a reading of absolute ZERO.

I know I was speaking out of school – so to speak – not having real world data to check against. But it makes lots of sense to me that a twos complement representation would be very fast & efficient for the ECU to use for representing the positive /and/or/ negative reading you are analyzing. It would even be super easy for the processor to internally handle the twos complement offset of 1 for negative numbers so you could just ADD the two bytes together as is the case with my IMRC valve.

———–

54371019

Pages: 1 [2] 3
WP-Forum by: Fredrik Fahlstad, Version: 2.4
Page loaded in: 0.198 seconds.

  Follow me on twitter