1.3.2a - VVT Stopped Working

[AbeFM]

Howdy!
I had 1.3.1 on my miata with VVT and everything was working well - aside from a ~1 degree offset, the VVT was all working fine.

Now I put on 1.3.2a, and I noticed (can't say for sure it wasn't happening, I haven't been logging recently) there's no VVT action after the flash. I'm using the same settings.

The first thing I noticed was the VVT_angle gauge was pegged at whatever my max angle is (28 or something on the gauge in TS) - later in the logs it was stuck at 269* dead flat (min absolute degrees, with max being 314.5)... So I turned off "range check measured angles) and the angle jumped to 346.9 and now has some small (realistic) variation to it (about 1/2 a degree)

VVT Target moves around but is in the range of 0-32 degrees.

The "VVT duty cycle" is at 0 the entire time. I feel this makes sense as it is trying to go from "346" degrees to ~10, so it needs to retard.

I tested the valve, it's moving just fine (PWM scroll valve style), and with the vvt output test I was able to get it to hold open, hold close, and buzz (though I didn't try this while the car was running).
I did set the "more duty means:" from advanced to retard, and the reported advance slowly slewed over to something in the middle of my range (say "15" degrees).

So it seems like something is messed up with the way it is figuring degrees on the VVT. Perhaps it has to do with the new 36-2 code?

Anyway, let me know what data you need. The log is pretty boring but I can send it. You can see where I turned off the coercion.

[AbeFM]

Small follow up: If I manually use test mode, <20% retards timing, more than 45% advances it. It'll come into range. I'm not quite sure why it reads such extreme values, it seems like it works till it hits the edge of my "defined" range, then falls apart (possibly substituting "actual" angles for effective-advance ones). A log would probably tell this?

[AbeFM]

oh, and I tried PID's from my current 50/17/25 to 1,1,1 and 100,100,100 and a few other random ones. I never saw %dutycycle budge from either 0% (set to more duty advances) or 100% (set to more duty retards).

[jsmcortina]

Which is the last firmware where VVT worked as you expected?

James

[AbeFM]

1.3.1, though I never ran 1.3.2

[jsmcortina]

Please try the pre-1.3.2 betas and determine when things changed. I've skimmed the ChangeLog and nothing jumps out.

EDIT: Find the betas by going to the Downloads page and clicking on "old versions"

James

[AbeFM]

Here is, what I believe to be, an msq that had VVT working. At least, it's one on either side of when I have a data log to show it working.

Interestingly, that log shows (only when motor not running) timing of 269.0 degrees (capped, I'm assuming). It goes to a reasonable value as soon as there

2014-10-14_18_TrimmedVVTStarting.msl

Here's starting with new code.


Note the cursor is where I switched it from "duty advances" to "duty retards" so perhaps it IS trying to control it?

Starting with old code. (file on next post)





Uhg, flashing and all that is going to take some time. Is there anything else which might help you decode all that?

[AbeFM]

More attachments.

[AbeFM]

That's 13 firmwares - if you could give me a clue where to start I could try a couple of them.... Perhaps if you think the VVT code was tweaked for the Flyin Miata wheel or something I could start there.


Here's another thought: I did replace the timing belt. Could I be flirting with the "limit" in a way it's not behaving? Perhaps with the old belt, I never dropped below 269.5, but now I'm at 269.2 and that's throwing it off? Would it make sense to try to bump my limits around?
I don't have any logs since I did the belt, and, it's felt a little lacking in bottom end. I don't drive the car much lately since it's not "sorted", this is all an attempt to get it so.

[AbeFM]

Sorry to keep piling it on, just looking for a chink in the armor so we know where to look.
Checking the logs, under 1.3.1:

VVT-angle
269
269
269
0.3
0.3
0.3
0.9
0.9
0.9
0.9
0.9
-4.5
0.9
0.9
0.8
0.8
0.7
0.7
-0.1
-0.1
0.5
0.1
0.2
0.3
-0.4
0.7
0
-0.7
0.6
-0.2
-0.1
-0.2
1.3
1.2
6.9
6.9
23.2
23.2
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6

In same file:
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6
32.6
1.3
1.3
0.6
0.6
-4.9
-4.9
-3.7
-3.7
-0.5
0.7
0.5
-0.1
-1
0.2
0.6
2.8
7.7
11.6
17.6
17.6
16.9
16.4
16.3
16.7
19.6
18.9
19.2
21.1
20.8
19.7
20.5
22
20.9
20.7
21.2
21.8



And in 1.3.2a:
269
269
269
269
269
269
260.1
260.1
260.1
260.1
260.1
260.1
349.1
349.1
349.1
349.1
349.1
348.3
348.3

AND
346.6
346.7
347
347
347
347
346.6
347
346.6
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
269
311.4
311.4
311.4
311.4
348.2
348.2
348.2
347.6
347.6
347.3
347.3
347.1
348.1
352.2
3.5
3.6
8.8
15.5
22.8
29.9
32.2
32.4
31.7
31.8
32.6
31.3
32
31.5
31.9


Note that there are no negative numbers. Now, the issue is that in the 1.3.1 stuff, the largest negative number is -4.9, and it's hard to say if that's the coercion taking place or not... But perhaps the code sees "340 degrees" and tries to retard the timing instead of trying to advance it like it should.

Is there any easy way to see how it records numbers like -2 degrees in the new code?

[AbeFM]

Ok - I think I fixed it.

Something was going on with the limits. Here's what I did - first I moved them to the numbers it was showing (er, like the high and low from the log) and then I'd get more wonky numbers.

So I set the minimum and maximum (absolute degrees) under Cam Settings to 0.0 both. That way the recorded numbers were absolute numbers.

THEN I used "TEST" to fully advance and retard cam, and grabbed new numbers (255 and 302).

After that, my VVTangle and VVTtarget made perfect sense, tracking nicely (could be tighter, but it's working).


So - I would suggest some tweaks - probably working in absolute numbers, only displaying the "corrected" ones?
For TS, perhaps a wizard to help you set these numbers - i.e. like TPS have a "grab current value" (though for VVT with it's fluctuations, it should average over a second or two) button for max advance and retard while letting you play with the valve manually. Actually, you probably don't need MAX and MIN, since it's good to check them but really everything is off one extreme (for miatas, "advance").

The other thing which is weird, though, I don't get why my old numbers have moved so far from the current ones. (269 and 315)

(checks something) the difference is 14 degrees base, 13 degrees advances which means ~14 degrees total. With 46 teeth per gear that would be 2 teeth off plus 1-3 degrees more from my old numbers. It's hard to imagine I'm off by that much, is there any way stuff could have changed on your end? I'll review installation pictures to make sure I was in the right spot both times, I could be off by one tooth, but I doubt 2! Are the degrees "cam" degrees? If they are crank, then I could see being off by 1 - but then "365 degrees" should really be just that, not wrapping around to 5.

[jsmcortina]

The code works in crank degrees.

Could you explain your "tweaks" suggestion some more, I don't understand them.

James

[AbeFM]

Insofar as my tweaks are WORTH explaining....

I guess the first thing is, instead of going from (what looks like) -5 to +355 degrees, perhaps it would be more useful to look at the numbers like so:

MAX (max absolute degrees of cam position you already have defined)
MIN (minimum absolute....)

DEFINE MID = (MAX - MIN)/2

And have the range instead of (-5,355) be (-180 + MID, +180 + MID)
longhand: Max-Relative-Advance = 180 + (MAX - MIN)/2
Min-Relative-Degrees = -180 + (MAX - MIN)/2

This should let you have the most error and still recover. I'm pretty sure what was going on was as soon as the routine saw 350 degrees (which was really -10), it tried to retard because PID's don't know we're working in a looping numbering system. I think that would fix the logic so the cams will always try to go to the right spot. Obviously you could still light up the VVT_ERROR when we're outside of the expected range.

I was thinking of getting rid of the MAX value (since all we need is MIN and Relative-Advance) but it seems useful now. Also, if the code works in Crank Degrees, then it REALLY shouldn't loop at 355, it should loop at 720.



The other suggestions were geared towards Tuner Studio: To calibrate the TPS, there's a little function where you let off the gas, hit "get current value" which takes the current ADC counts and stuffs them into the "MIN" for TPS, similarly for max where you floor the gas then press the button while held down.
A similar thing could be done for getting the MAX and MIN numbers. Instead of TEST being a section (with CAM and DUTY%) in the VVT screen, it would be under calibrate, output test, or just be a button in the current VVT Settings dialog. Then it'd pop up a window with CAM(number/OFF), Duty% (which, by the way, I'm not sure 0% works. I type 1 (and get 1.2 after it corrects) then it works. 100% works fine), and the Minimum and Maximum from the Cam Settings section, each of which would have a "grab" button.

When you click the button for "Minimum" (for instance), it would look at a stream of ~1 second of absolute-advance values and average them to get a reasonable bottom value, and then fill that number into the Minimum (abs. deg.) blank. Similarly for Maximum, which I assume the user would get the Duty% to full though this could be automated.

I'd be happy to explain what I was thinking more, does that make sense?

For those who are curious, yes, my cams are both off a tooth. By the way, I'm available to work on anyone's car should they need it mucked up.

[jsmcortina]

The code currently uses +/- 5 degrees for out of range detection. It will loop at 360 degrees in your case because you have a cam tooth every 360 degrees.

There's already an open TODO suggestion to make the angles auto-detect. Handling it totally reliably is my concern.

James

[Niklas Falk]

Thanks to Abe for point me to this thread (this might however be is a TODO suggestion, nothing really "broken" for me),

I have another beef with the VVT settings, the unnatural relative numbers shown in TS and logs.
If this would affect Abe's problems I don't know, but it would look different at least.

I might have a bit special case with decked block and a custom cam, making the locked/min cam location to -13 degrees (as I would like to refer to it).

Setting the min and max absolute values is not a problem and it works well enough (once you get hold of a walk trough), but the logic of using the min location as a realative "zero" is daft IMHO.
Keeping it manual would be an advantage for me, since the max value means dangerously close to valve-piston contact (testing it worked, bot others might want to enter the range, or reduced range instead).

I would be very happy with the option to enter a value between min and max absolute as the relative "zero", this way I would see understandable values in tables and logs.
Default value should of course be the min value.

In my case, 257 min 304 max, and I'd like relative "zero" (in logs and tables) at 270, not 257.
It's much easier to talk cam phasing with a tuner/builder when the tables/logs says "0" for the default cam grind phase, not "13".

I don't have a clue about other VVT systems but there must be systems that have cam advance and retard, with a relative "zero" that is nowhere near the min in the range.
So I imagine that adding a custom "zero" would make the function more user friendly and less nerdy.

Shoot me if this is available in the newer FW's, I have not updated mine in over a year.

[jsmcortina]

I haven't (hadn't) heard of any VVT systems that move it both directions.

James

[Peter Florance]

^I think of cams as installed at their rest position. Zero at rest makes sense to me.

I hope you have mechanical stops in your phaser hardware and you are not depending on the VVT system to keep clearance safe.

[Niklas Falk]

I haven't (hadn't) heard of any VVT systems that move it both directions.

James

It only advances from the stop position, true, but if the stop position isn't "zero" relative for whatever reason (by design, decked head/block, ...) I'd like to be able to set an offset so the data in logs/tables make sense without doing math every time. When my cam is zeroed the data shows 13, an offset I need to remember, all the time. I'll learn eventually, but need to explain the math every time someone else helps me with the tuning.

The same argument could be placed for ignition timing, but there it's very clear that there is an advantage to set things up so 28 in logs/tables really means 28 BTDC, and not 24 or 32 depending on the placement of the pickup.

[Peter Florance]

If that's the case, maybe set limits so position reads in actual lobe center values

[Niklas Falk]

If that's the case, maybe set limits so position reads in actual lobe center values

5 degrees outside min-max throws error, so think again ;)