Thread: Rev Limiter Discussion

From a user interface point of view, if I set a flag to enable fuel cut and enable spark cut I want them both to "cut" and I want to be able to set when they will happen (at what rpm). Independently if possible.

Is that not what you're asking?

If you don't enable a fuel cut and don't enable a spark cut I would expect to have no rev limiter at all (although I would still expect to be able to set a launch control separately if possible).

The default (if there is such a thing) should be to enable a rev limiter of some kind.

Why would someone want to cut spark at one limit and cut fuel at another?



This might get a little too complex, to have separate cut flags for launch vs. rev limits. The launch is the same as a rev limit. The only difference is when they are active.



This is really my question. Which kind (2-4) should be the default?

Thanks,
Dave

I've been doing some testing with a friends S13 w/SR20DET, and the results so far, are mixed. I can control spark cut and fuel cut independently (they are synced), and have been testing with the launch rev limit set at 2500rpm. This mode cuts 1 injector/plug at 2350rpm, 2 injectors/plugs at 2400rpm, 3 injectors/plugs at 2450rpm, and all 4 injectors/plugs at 2500 rpm. I haven't played around with timing retard yet, but I wanted to let you guys know what I've found so far.

With fuel cut only, the RPM holds very steady at 2500rpm up to about 1/2 throttle. Beyond that, the RPM is not as steady, but doesn't vary too wildly. I have some other cut schemes in mind to try and smooth this out at high throttle settings.

With spark cut enabled, the tach signal skips a pulse whenever a plug is cut, so the tach needle jumps around so bad, it's hard to read.

With spark cut only, there is a fair amount of popping and backfiring as raw fuel dumps into the exhaust header, however it will build about 2 psi of boost above 3/4 throttle (without timing retard).

With both spark and fuel cut enabled, the engine behaves much like fuel cut only, but the tach needle jumps around.

Thoughts? Suggestions?

Thanks,
Dave

Honestly I have no idea. I've just seen the capability in AEM and other stand-alones. For some reason I get the feeling some people use the first limit as like a rev limit and the second one maybe 200 rpm later for some silly "OMG, no really, stop building revs!" rev limit.

I don't know. Never made any sense to me either.


I mean if you can only come up with one rev limit, then I guess people will have to decide if they want it for a launch control (set at low rpm with speed sensor data to disable) or for a valve train saver (set at high rpm).


Why is the tach signal bouncing around with spark cut? That makes no sense at all. The tach signal comes from the CAS, not the ignition system. Do we think the coil charges and discharges uncontrollably causing erratic electrical behavior?


It's hard to choose which to use because that depends on what the user wants. Do they want a launch control limit with or without anti-lag capabilities?

There are multiple rev limits. What I meant was the complexity of configuring each of the different rev limits for spark vs. fuel cut independently. ie: spark cut only for rev limit, fuel cut only for launch, etc. It can be done, just not sure if the complexity of configuring it justifies the benefit.



That's just it, the tach signal isn't generated separately by the CAS.



Anti-lag is in the plan, just not yet implemented. I want to get the launch and rev limit issues better understood first.

Thanks,
Dave

Dave the complexity of configuring each different rev limit sounds like a UI issue, no?

The tach signal isn't generated by the CAS? Hogwash. The ECU reads the CAS input and calculates rpm, then sends that to the tach. Yes?
How would cutting spark have anything to do with that? Unless your code or hacking is the cause, I don't see it.

Yes, that's part of it. The other is weather the user takes the time and effort to try all of the possible combinations.



No. You're right about the ECU reading the CAS and calculating rpm, but the tach signal is generated in the ECU from the ignition signal from the CPU. That's what I'm seeing on the oscilloscope. What makes you so sure the tach signal is generated directly from the CAS signals, outside of the CPU operation?



I wouldn't call it hacking. Some of my background is in embedded systems engineering. I'm editing source code, assembling, and linking to build a bin. Don't get me wrong. I appreciate your input.

Thanks,
Dave

That's a much simpler way to do it than I imagined. The thought never even crossed my mind, but I'm inclined to believe you on that. Damn, that's pretty annoying.

Nothing. I'm not sure at all. I just figured it had to work that way. Anyway else of doing it doesn't even pop into my programmer's brain. Robustness and non-duplication of functionality makes me think it must be done one way, when obviously they took the easy way out and did it all wacky in my opinion...



Dave I meant "hacking" in the best, most favorable way.
Definition of a hacker
That's the way we use it in the software and hardware community, and I thought you'd have caught the well-intentioned meaning. =]

You don't have to defend your abilities or position to me. Your reputation precedes you. Trust me.

At this point, I wish they had done it directly via the CAS, but I'm still investigating. I hope some others chime in on these issues. Thanks, Ben.

Dave

Sorry for the terrible thread hi-jacking, but since rpm calculation came out... my calum RT v0 is not sending signal to the stock tach, does it mean my CPU is fried? Some other way of fixing this? I got my rpm signal for VVL from the distributor negative coil wire, but the switch is not responding accurately when activating the solenoids.