P0016 on a 60k mile car

[TheStig85]

Originally Posted by Icecreamtruk

Dont know if we are talking about the same thing, but when my car had that same code and I went to get it diagnosed as soon as the CEL showed (2nd drive cycle, always), all of the target AND measured values dropped to 0. I think the ECU just stops trying to adjust the VTT angles when this code is present. Btw, my car didnt go into limp mode, I could rev it up to redline fine (in fact I did a time attack event with it on), but it was down on power significantly. Based on times I would say at the very least 30-40hp. (2 full seconds slower on a 1min power track).

Edit: I think this doesnt help you much. but what I wanted to get across is that all gauges stopping the reading might not be an error, but that they are indeed reading "0".

Same thing. Can redline but definite decrease in power.

[TheStig85]

Originally Posted by Ultramaroon

I was concerned about exactly this. The manual has a step-by-step flow chart that requires only techstream. Note the enabling conditions. Also, the Subie TSB does not mention shimming. There are different fault codes for that.

There is one other possibility that hasn't been discussed here. The manual does mention the VVT filters possibly being clogged. I doubt that is your issue but it's worth considering. When everything is working, (codes cleared) does your bank-1 intake seem to respond more slowly than the others?

Graphs of the logs like @ermax suggested would show this.

I was referring to the shimming of the sensors in this TSB: http://www.ft86club.com/forums/attac...1&d=1375302652

I've heard from others that it's used with those Camshaft sensor CELs

[Ultramaroon]

Originally Posted by TheStig85

I was referring to the shimming of the sensors in this TSB: http://www.ft86club.com/forums/attac...1&d=1375302652

I've heard from others that it's used with those Camshaft sensor CELs

Yeah. I dunno about that. It's a total crap shoot without an o-scope. Even if you could get your hands on one, using it properly is a whole other ballgame.

The DTCs are different too. P0016-19 are crank-to-cam position correlation. The ones in that TSB are for issues with cam position signal drops. Different animal.

Should we completely trust the TSBs? Hell, it's tough. I hate spending stupid money.

[Ultramaroon]

Originally Posted by Icecreamtruk

Edit: I think this doesnt help you much. but what I wanted to get across is that all gauges stopping the reading might not be an error, but that they are indeed reading "0".

^^^this^^^ Limp mode = fixed valve timing

[TheStig85]

Originally Posted by Ultramaroon

^^^this^^^ Limp mode = fixed valve timing

I hear what you two are saying but how could there be a 0 degree VVT angle, etc etc. The angles keep changing and matching the target angle, then the CEL pops up mid drive and every gauge goes to 0. Doesn't make sense to me.

I'm trying to get my TechStream working to get some more solid data but couldn't get the logs working without it crashing. I was informed it was because the program was cracked. Got a different version with a proper key but it's not liking me when I try to connect to the VIM. Once I get this figured out, hopefully the data will show something more conclusive. Because at this point... I dunno wtf to do.

Sent from my Pixel 2 XL using Tapatalk

[TheStig85]

Does this help at all?

[Ultramaroon]

Originally Posted by TheStig85

Does this help at all?

Yes. Can you upload a CSV to datazap?

What were you doing at the time? Can you log using the driving profile in test-b?

I already see some weirdness but I would like to take a log of the same.

[kinghurl]

Earlier in this thread, I posted that the way the ecu works in this condition, 2nd drive cycle, is to realize the cam gear settings don't line up with the ECU's target value, so it throws a CEL and sets the cam value to center of its range, or 0. This was my exact issue AFTER the mechanical changes and BEFORE the ecu change. The old ECU will SLOWLY change its target value over time, A LONG TIME, measured in thousands of miles, to catch up with the new cam values. Changing the ecu speeds up the time. New ECU with no stored vvt values, instantly(over a lot less miles) assumes your new cam range is the norm.

Sent from my SM-G930V using Tapatalk

[ermax]

Techstream logs in a proprietary format but it does have an export function that will generate a CSV file. To problem is the header and time code isn’t compatible with datazap. I wrote a little app that will take a CSV that was exported from Techstream and clean it up so it will work with datazap. I will dig it up when I get a chance.

[Ultramaroon]

Originally Posted by kinghurl

The old ECU will SLOWLY change its target value over time, A LONG TIME, measured in thousands of miles, to catch up with the new cam values. Changing the ecu speeds up the time. New ECU with no stored vvt values, instantly(over a lot less miles) assumes your new cam range is the norm.

Did the stig first replace his ecu, or was it the sprocket?

[TheStig85]

Originally Posted by Ultramaroon

Yes. Can you upload a CSV to datazap?

What were you doing at the time? Can you log using the driving profile in test-b?

I already see some weirdness but I would like to take a log of the same.

Just Revving the engine slowly up to 3-3.5k RPM or so 2-3 times.

Originally Posted by Ultramaroon

Did the stig first replace his ecu, or was it the sprocket?

I've replaced both. ECU and Sprockets/Chains. CEL went away with the first ECU replacement, but came back months later. Just did the Sprockets recently.

[Ultramaroon]

Originally Posted by TheStig85

I've replaced both. ECU and Sprockets/Chains. CEL went away with the first ECU replacement, but came back months later. Just did the Sprockets recently.

Kinghurl is trying to explain that your new ECU learned the offset from the bad sprocket that needed changed. Now with the new sprocket, the ECU is going to throw codes until it relearns itself over thousands of miles.


I don't know if it's true because, according to the last section on this page of the manual, if the ECU never sees the normal, it won't ever overwrite the previously-stored value. I don't know what it takes before the ECU decides what normal is.


Maybe record the values of that test every so many miles to see if the values ever change. That could be interesting.

[steve99]

Originally Posted by Ultramaroon

Kinghurl is trying to explain that your new ECU learned the offset from the bad sprocket that needed changed. Now with the new sprocket, the ECU is going to throw codes until it relearns itself over thousands of miles.


I don't know if it's true because, according to the last section on this page of the manual, if the ECU never sees the normal, it won't ever overwrite the previously-stored value. I don't know what it takes before the ECU decides what normal is.


Maybe record the values of that test every so many miles to see if the values ever change. That could be interesting.

Certian
Y would be good to see those lelarned values on a car thats throwing codes and then from a car thats ok. Also to see how fast it re learns and if those values go to default on a reflash\reset of ecu or their stored in some other area in ecu.

Be good to understand how the "normal" range is determined. Maybe if the ecu has some fault it never determines cams in normal range hence never updateds the values

[Ultramaroon]

Originally Posted by steve99

Certian
Y would be good to see those lelarned values on a car thats throwing codes and then from a car thats ok. Also to see how fast it re learns and if those values go to default on a reflash\reset of ecu or their stored in some other area in ecu.

Be good to understand how the "normal" range is determined. Maybe if the ecu has some fault it never determines cams in normal range hence never updateds the values

Indeed. All of the above.




Here is mine.








Here is The Stig's.