[Diy_efi] Re: Diy_efi Digest, Vol 7, Issue 11

[Bruce Bowling]

At 12:00 PM 7/7/2003 -0700, you wrote:
>Matthew Richard Friesen wrote:
> > This is exactly the idea that i am going for. Have "stupid" modules 
> that each
> > do their little part, and have the pc telling them when they need to 
> change. I
> > must admit though that i am beginning think maybe it would be easier to 
> start
> > with the megasquirt, (probably the AVR, i'm not too fond of assembly, 
> and i do
> > have some experience in c ) and "adjust" it to my needs(wants). (Ahh.. the
> > burdens of facing hard reality). Can the megasquirt handle sequetial
> > injection?

For the current implementation of MS, it does not handle sequential.

Can MS be modified to handle sequential firing? Yes, - but - there is a 
correct way to implement this and a half-assed method which is reality is 
no better than sequential.

Method 1: just pulse the injectors in a sequence after receiving a cam sync 
pulse - inject always at the same instant based on a spark fire pulse input.

Method 2: Monitor the crankshaft position (using a crankwheel or similar 
crankshaft-positiong device with sufficient accuracy) and fire the injector 
at a precise crankshaft position - i.e. phase is independent of ignition 
event. Most importantly, this crankshaft angle value must be a 
user-adjusted variable, and it may also be a function of RPM and/or load.

Not widely known (or not well advertised) is that Al Grippo's code 
implemeted on the EFI332 handle direct sequential injection, and he has 
been running this for about three years now, and many tens of thousands of 
miles.  The code implements the TPU in the '332 to fire based on crankshaft 
angle. The injector firing phase is a user-adjusted input.

Also not widely known is the large amount of time Al has spent on making 
the sequential mode, and more importantly the transition from batch to 
sequential and back (during a lost cam sync) if needed.

A while back, after we were doing some warmup enrichment tuning on his 
EFI332 setup, we started playing with the injection phase value at idle as 
an experiment. With the engine at idle, we incremented the phase value in 
one degree increments totally around the entire 720 degree crankshaft 
injection range, while monitoring values like MAP and RPM. What we observed 
is that the RPM and MAP was pretty much unchanged, except for a very small 
angle range, where the RPM increased slightly. We were able to reproduce 
this again and again. I do not remember the exact phase value off of my 
head, but I do recall that the degree range of this "sweet spot" was very 
small - something like 10-15 degrees crank or so. Now, Al's cam setup in 
his engine produces a lot of valve overlap, so the idle is not silky-smooth 
(even with EFI), but this sweet spot was noticeable via. the RPM increase - 
but, the engine ran pretty much the same.

We only tested this at idle, but a further experiment would be to try to 
determine this spot at different RPM and under load, to see if this phase 
angle is indeed a constant value or does it move around. Also, AFR 
measurements need to be done as well.

But, the point I am making here is that, in my mind, to implement 
sequential *correctly* you need to have accurate crankshaft position. 
Getting a pulse every 90 or 180 degrees (i.e. ignition fire events) may not 
be enough resolution, especially if the target "sweet spot" lies within a 
few degrees of a given crankshaft angle. I do not know what the acceptance 
range of crankshaft degrees for optimum sequential. But, if one has an EFI 
setup which maintains accurate instantaneous crankshaft position 
information *and* the ability for the user to vary the firing phase - and - 
the user takes the time to map out his engine to find the sweet spot as a 
function of RPM, load, etc, then sequential is worth it. Otherwise, what 
you really have is a system that is no better than a batch injection setup. 
And you will never know the difference, because a batch-injected engine 
will run very well, as will a non-synchronized sequential injection setup.

So, to answer the question, if you want "cruddy" sequential injection, then 
simply run a cam sync signal into one of the unused I/O lines, and then use 
the other I/O lines to drive the injectors. In the software, it would take 
about an hour to write the code for "cruddy" sequential - simply fire the 
outputs in a sequential order. Right now, MS fires two channels, so the 
logic is already there  - simply extend this to fire more outputs. Its that 
simple. Next, wire up the injectors to what you think is the best 
sequential timing relative to the cam sync pulse. Fire up the engine and 
run it - it will run well. Sit back and bask in the "sequential" afterglow. 
But realize that this may or may not be the best injection timing. And, the 
fact that the MS triggers off of an ignition tach pulse source, which has 
advance/retard, the injection point will move around. In my mind, this is 
crummy.

Now, to implement this correctly, a crank wheel should be used. And to 
digest the input from the crank wheel you can add software to the MS to 
keep track of the crankshaft position in real-time. This is not impossible 
- in fact, the Tomtek ignition does exactly this. And, contrary to what has 
been posted in the past, the processor in the MS is quite underloaded - in 
fact the value is somewhere around 22 - 23% CPU utilization - the other 75% 
is just wasted. The real question would be at what crankshaft RPM point 
does the processor fall behind simply due to the teeth input rate.

Now, if I was going to implement something like this, I would take 
advantage of programmable logic (CPLD or FPGA) to maintain the crankshaft 
position in real-time and to perform the output compares to fire the 
injectors at the desired points in time. Time functions can be handled very 
nicely in a FPGA, including ignition output and PWM. The processor on the 
MS would run the same code as it does right now for the fuel calculations, 
and the FPGA would handle the time-related events.

Or, you could just get Al's EFI332 code and run it on an EFI332 board -:) 
But, his code is hard-wired for his application (SBC) so you would have to 
change the number of cylinders, etc in the code. And, he has over 600 
adjustable variables, so if you want things to tweak here you go.

- Bruce



_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi