RomRaider

Actually,it is a good candidate. Standalone systems use coil dwell with an rpm based scale. And alot of newer factory ecu's are using InjectorDeadTime in 3D. Some are rpm and manifold pressure based as well with secondary voltage 2d table like we are all use to.

InjectorDeadTime is definately ManifoldPressure & BatteryVoltage dependant for returnless fuel system.

InjectorDwellTime is definately EngineSpeed & BatteryVoltage dependant. I do not see any idea behind making exactly the same corrections...

Maybe you guys have seen this before, I just ran across it. It appears to be a test of the grey and black coil packs.

Just to confirm for me, in the electronic ignition world, is this dwell time table the amount of time the primary coil circuit is de-energized to release the flux into the secondary coil?

If I did my calculation correctly on a 4 cylinder engine a single spark plug is sparking every 'x' msec at these RPM.

Injector dead time(Latency) has already been defined for all ecus supported with battery voltage has it not?

Andy

2 dschultz:

The first coil should be "energized" for about 5 ms, the second - for about 3 ms (longer for lower battery voltage, shorter for greater voltage) formarly regardless of RPM.

2 elevenpoint7five:

Injector dead time depends on battery voltage. For returnless fuel systems it also depends on intake air pressure. But corrections may done as additive values from a couple 2D tables instead of 3D one.

Cool PDF!

Dwell time is the time it takes the coil to "charge". Ideally you would know the exact dwell times needed and setup the table that way. Any extra dwell time will just cause additional heat. If it took 5ms to fully "charge" you would want the dwell set to 5ms before firing. That way the coil is not sitting there all charged up creating heat waiting to fire, rather it is fired at the exact point that it reaches full charge. If you think of it as a wave it helps. The little plateau in my first rudimentary drawing is the time you want to eliminate. The second drawing is the ideal settings assuming that "/" is equivalent to the exact amount of time it takes to fully charge. Ignore the "..." it was just to attempt to get spacing right.
... __
__/ |__ __/|___

Andy

Do not forget to add some "heating time" for the reason that your engine may accelerate.
You are starting "coil charge in advance" but have to break electronic current switch at required crank angle. Due to the engine acceration you may need to limit "coil charging time".

Those 3D "IgnitionDwellCorrections" found may be due to this reason.

Okay so now my dumb question.

If it takes 5ms to charge @14V, that remains a constant regardless of RPM.

...then what is this dwell table doing with respect to RPM? If this defines the "charge" time then we are getting less spark potential as the RPM increases.

I have not looked in the ROM code to see how these values are being used. I still have to go find those routines and learn the opcodes more.

Could this table be the "advance" time needed to stop the charge; in advance of the spark event expectation?
I would make sense, longer values at lower RPM.

"Break time" is fixed and regardless of any thing is about 50-70 microseconds.
I stiil think that engine acceleration is the main problem. In my homebrew ecu calculated time correction is applied to ignition dwell time. Otherwise I completely loose the ability to ignite mixture under 1-2 gear full throttle run due to fast engine acceleration that shorten "coil precharge time".

Let me see if I got what you are saying.

The times in the table are added to the nominal charge time to account for 1) changing engine speeds, and 2) a variation in battery voltage. Is that right?

Exactly.

But "changing engine speed" should be substituted by "possible engine speed acceleration".

That info about the tables is good stuff, can I ask where you got it? I knew that the 32bit ROMs had the multipliers included, but I hadn't figured out how yet. This is different for the 16bit ROMs, as it is not included anywhere. We assumed that the value would be in milliseconds because when I tested dwell with an o-scope(in ms) I got the same values as we had defined as ms in the table. However, there is still a chance that the values could be in degrees of crank rotation, or something completely different as well. While I see it as quite strange that there would be such a coincidence of the ms from the o-scope matching what we had defined and not being correct, it is possible. I can only assume that it is being measured the same from 16bit and 32bit.

Andy

I found it here.

So what I've found so far about table structure in the 32bit ECU is:

- X & Y axis values are always FLOAT (IEEE754) values and seem to describe directly the axis field quantity (no conversion needed)

- the data unit type MSB will be either 0, 4, or 8. If 4 or 8 then the multiplier and additive (values in IEEE754 format) are provided to be applied to the data values. If the data unit type is 0 then no x or + is provided and it seems that the data is provided as a uint16 value, the units maybe unknown without knowing how the values are used in the calculations

For example:


That's the hard part to figure out. For the supposed Dwell table I posted, there is no x or +, so I interpreted the uint16 values as raw data. Then multiplied them by 0.001 to get something close to a msec value. If the coil packs are the same on the a 16bit and 32bit ECU equipped cars then there's no reason the values should be different. RPM is RPM and charge time of the coil pack will be the same between cars. Therefore the tables should be nearly identical (I assume).
In the end, unit measure should not be an issue as your read out and convert the data value with the same formula constants as you would convert and write back the data value into the ROM file.
Dale

in addition to "timing" (ie * of advance) issues, also keep in mind the coils can TOLERATE less dwell as rpms increase. that's because there are simply more conduction events per unit time. the thermal conductivity of the coil to the rest of the world will dictate the rate at which heat energy can be safely dissipated from the core. the thermal capacity of the coil/core will allow some excursions beyond that steady state limit, but that is treading on thinner ice.