Starting algorithms

AbeFM · Post by **AbeFM** » Fri Jan 25, 2008 1:15 pm

Well, I have a feeling I should read the source code before posting this, but I'm curious for the insights of those with a lot more experience than I.

A few nights back, playing with my JimStim, I noticed three full sets of cam signals before the MS "started". That seems a long time to me. I'm sure it wants to see a "double pulse" on the cam signal (i.e. to uniquely identify cam position) before committing to start.

Playing the other side of the fence for a moment (I'll use the 99+ Miata as an example, I feel it's representative and I'm familiar with it) which works like so:
The crank has four teeth, two marks some distance before TDC, and two are just somewhere in between.
The cam had three teeth, a single at TDC cyl1 firing, and a doublet at TDC cyl 2 firing. Not exactly, but this is close enough.

To my simplistic view, two things will tell you where you are. Either
1) You see a signal on the cam sensor. You know you are near TDC on cyl 1 or 4
2) You see three pulses on the crank. You know you are a few degrees before TDC.

On a bank fired motor you can fire the ignition on coil pack A shortly after condition 2. You will have passed TDC, and even if you are a little retarded, the extra kick will get the motor going faster. For condition one, you likely can fire coil A by the same logic.

You could make the argument that you need to let that opportunity go by (though I don't think I would agree), but at most, two crank teeth later, you could fire the coil.

This should work for any bank fired motor. A missing tooth could be fired after only a few teeth to establish a time base and then a miss.

My only guess is that this is a noise rejection scheme, or to maintain compatibility for non-bank fire cars. Of course, nothing would keep you from firing pairs of coils until you achieve sync on a dedicated coil motor.

So, now that I've laid out the simple version, someone explain to me why it's a bad idea. The theory, while simplistic, seems workable to me.

Post by **jsmcortina** » Fri Jan 25, 2008 3:54 pm

The sync code is specific to the wheel mode chosen.

On your wheel the code waits until it sees a crank pulse then counts the number of cam pulses that happen before the next crank pulse. Then it can sync. The angular delay you are seeing may well be a function of the way the wheel pattern is coded in the stim - it will always start at the same point in the sequence where a real engine will stop in a fairly random location.

James

AbeFM · Post by **AbeFM** » Fri Jan 25, 2008 4:32 pm

Either way (and I could put this on the scope and check) it shouldn't need three full sets of cam teeth to sync. With the worst case assumptions, by that logic it should start syncing on the second cam tooth set.

I should be getting a new jimstim chip in tonight and will be able to check it better.

When does the engine start to fire?

Anyway, my real question is why not fire first, sync later? Is there a hole in my earlier logic? It would still be "cranking" and "unsynchronized", only it would fire the plugs.

This isn't even a feature request but I am curious about the rational.

Post by **jsmcortina** » Fri Jan 25, 2008 4:37 pm

That may be possible on some wheels, but in general (e.g. a 36-1 wheel) just randomly starting to fire spark plugs when you feel like it and unsynced is a very bad idea.

The core of the code is general a supports all of the wheels including distributor. The sync code and wheel pattern definitions are the specific portions. Allowing early sync would require special casing of particular wheel types, so it isn't something were are likely to do as a priority.

James

AbeFM · Post by **AbeFM** » Mon Jan 28, 2008 11:15 am

Last comment on this till I dig into the code and get a bit more grounded in the topic, but it seems a "partial sync" state is what I'm talking about. Something that says I know where TDC is, and that's all I know. Then, how you generate that would depend on the wheel.

In the case of a single 36-1 wheel, your full sync and partial sync happen at the same time, as soon as you've seen enough teeth to get a stable measure of the expected rate, then you see a missing tooth. How you get a "full sync" on that I don't know...

Anyway, in the case of a two-whee system, you would flip a bit for "TDC knowledge", and if it's wasted spark, your other module would fire. If it's not a wasted spark system, you have a choice between running in wasted spark till full sync, or just waiting until that comes along.

If the logic is at least reasonable, I might try to get my feet wet in this whole thing with it. Do you think that's a good idea at all?