rusefi.com

Hello Everybody,

We have another running car. Mike's track-oriented 1991 Miata with a built VVT engine is running on rusefi. I believe it's #88.
All the I/O are verified- just haven't gotten to letting it warm up and see if VVT works as planned. Enjoy the (brief) video! One thing that I noticed with other installs as well: Sometimes, when you turn off ignition while TunerStudio is connected via USB, the ECU does not shut off. Somehow it gets power via the USB and the main board. As near as I can tell this never happens with just the brainboard, not installed on the ECU.

I was in NJ just last week. I forgot you were down there. Blah. Some day I'll catch up with you and say hello.

That's some good news about getting another one running.

About USB power, I recall that you can removed Frankenso's D6 / Discovery's D1. This prevents the USB from powering the board at all, such that you require the Frankenso 5V to power the board.

@ Yes- next time you make it to central NJ, please stop by!

Somehting's off with closed loop (automatic) idle. It often takes its' sweet old time to kick in. Sometimes it won't kick in at all. Once it's kicked in, it works well, but many times it just says "meh- I don't wanna"

Settings: And here are some log snippets showing what's going on. Automatic just won't kick in, even though, as far as I can see, conditions for activating automatic mode are met.

The idle problem persists. Does anybody else have a similar experience?
Also: what are the conditions for the firmware to enter CL idle mode? I'm missing something here....

Can you please try latest firmware and rusEfi console with verbose info?

I've added a "state" variable which could be one of the following

I just tried the latest FW with some improvements regarding idle- running on the Jimstim. Here is the log.
It illustrates nicely what's wrong:
With the throttle closed and the engine spinning at rpms significantly higher than target (1000), the I-term of the PID is going all the way negative. This is a typical occurrence, for example coming to a stop at a light. You're off the throttle, the car is coasting in gear, the wheels are spinning the engine. Now you're reaching your stop, you hit the clutch and rpms drop. Now we're waaay below target and the P-term goes all the way positive, but it's not enough, since our I-term is far too negative. Now I-term is slowly winding up.
When you blip the throttle, the idle-mode is entered anew and the I-term is reset to 0, so now we're getting into values for output that make sense and things start working. Suggested fix: Set allowable min and max for all terms (P, I, D). When entering automatic idle, I-value should be seeded with offset value.
Also: Set threshold for rpms within target for when to enter automatic (closed loop) idle.
Explanation: There's no reason to enter CL idle when we're above target rpm and rpms are dropping slowly.

If that's not enough, we may need to define slow-dropping rpm and fast-dropping rpm and have different strategies for these cases.

I haven't really messed with closed loop idle again, so can't report if any progress was made. I'm not driving the car and making changes by phone support is always a bit tricky....
In other news: I started noticing that this car is really sluggish to start. It usually takes about 1.5s for the rusefi to pick up on the fact that we are cranking the engine. I do seem remember from last year April how quick rusefi started my NB2, using the same trigger settings. It figured out where the engine was quicker than Megasquirt and I think even quicker than the stock ECU.
In this car it's just a dog. Were there any changes in the code for crank/cam pattern recognition in the interim that could have made this worse?
I'm judging how long it takes from the log: When cranking starts, battery voltage and MAP drop. Then a little later we start seeing rpm. Typical delay right now is 1.5s. Assuming we're cranking at 180rpm, that's 4-5 full engine rotations, if I done did my mathing right.

My green NA VVT car was starting like shit until an engine rebuild. I cannot explain it - but my attempts to find better cranking parameters have failed. Once engine was replaced suddenly with zero software changes it was starting much better. I cannot explain it.

That would point to a weak signal from one of the sensors- crank or cam that got fixed by rebuilding the engine. I'll try the sniffer to see how long it takes to get something usable.

I have also noticed some “Idle valve - control” differences. I remember before my engine rebuild about 3 - 4 moths ago rusEFI was driving the idle solenoid valve slightly louder. I could hear the valve while engine was idling. I think now the valve seems to be a lot quieter on idle which is better I think.

However my cranking air settings doesn’t seem to control the valve at all. I have to press the throttle a little to start the engine. Also the bench tests don’t seem to control the idle solenoid valve.

It is a weird bug, because once you crank the engine the car keeps idleing nicely and reacts on the idle settings.

just curious: when you help start the engine with throttle, it means, rusefi measures the TPS value and enriches the fuel mixture? or during cranking, those enrichment formula doesn't work?

rusefi is capable of changing mixture during cranking based on TPS. You can program additional or less fuel under "Cranking" -> "TPS multiplier".
Most people seem to go with a slightly rich mixture as standard and then actually lean it out when throttle is pressed.

Idle valve buzz: If you use a PWM frequency lower than the valve would like to see, you get a lot of buzzing. You can also reduce buzzing by installing a flyback diode to the PWM driver.
I get idle valve opening during cranking, but since it takes almost 2s for the ECU to realize that we're cranking, it also takes 2s for the idle valve to open. But then it opens to the commanded value as set by cranking settings. I believe the "Idle warmup multiplier" also gets applied during cranking.

Here we have a perfect example of what great sensitivity rusefi has as compared to other solutions. Look at the MAP curve. For lack of a better spot we initially installed the MAP sensor hooked into an intake runner. You can see every single pressure pulse in that runner.

how about building/integrating a parser that would trigger an error message once it detects a permanent noticable difference between MAP values for different cylinders?

I think we're not getting enough temporal resolution. At 6000rpm, we should see a pulse every 200ms. But we're getting fresh data approx. every 70ms. Not enough resolution and that's why it looks so funky.

It appears that we still have an issue that we saw last year on my '03 as well. VVT target does not get interpolated when we're outside the boundaries of the table. With the top row set at 85kpa, under full throttle (MAP around 95 or so), the target values (red line in the second graph window below) changes suddenly from one commanded value to the next and no smooth interpolation in between. Amazingly the actual value is able to keep up with it quite well....

https://github.com/rusefi/rusefi/issues/604 "no interpolation outside of the table" is fixed now