Dwell time/length

[nielshy]

Hi.
Regarding Z32 TT 1990
Is the dwell lenght readings i see when i playback a log the actual dwell time for ignition coils. And if so. In the log viewer it goes from about 1.000 ms at idle to about 0.100 ms at 6500 rpm. from what i can find on the internet dwell time should be about 2.5 ms.

[Matt]

It should be about 2.5ms for Z32 all the way through. Perhaps the reporting is wrong in the software for that parameter for this ECU?

[NIVO]

it is 1.9ms - 2.10ms throughout the rpm range.
Reporting is wrong from Nistune.

[Ross]

Now I'm concerned that reporting is wrong for my BNR32 ECU as well because I was getting ~1ms down to ~.100ms as well. I increased the dwell vs voltage tables by 100% and it is reporting near 3ms but still trickling down well under 2ms at high RPM. I don't have a good oscilloscope right now to verify.. is it possible that these values are indeed incorrect?

Kind regards,

Ross

[Matt]

Will check it out:
http://www.nistune.com/mantis/view.php?id=189

[madaxgt]

I don't get this problem on my 32 ecu using FP firmware at least if I just raise the rpm in neutral.
Targeted 3ms and its pretty consistent up to 6krpm. Sometimes I get a random 1ms or 4ms (dangerous with my GM D585 coils!) in map tracing but when it goes back over that cell its around 3ms. Be interesting to know if the random values are true. The 4ms is an issue for me if its true as these coils fire regardless if the dwell time is too high.

I guess the 0.1ms is completely false as the coil wouldn't fire at the value, but also interested in and answer on my random values!

[Matt]

True test of measure is using the scope. The readings shown on display are calculated from RPM and ECU calculated dwell pulse numbers to come up with a rough indication. It does not mean that actual dwell is reading 4ms for example

[madaxgt]

I tested this with a scope as I have been getting misfires on a BNR32 with higher boost using my LS D585 coils which need 3.9-4.1ms. I get dwell limitation from about 4200rpm upwards. It drops from 4ms max to 2.6ms at 8000rpm in a linear fashion. It doesnt matter what i do with the two tables there is another dwell max with rpm table that is not addressed in nistune. Is this a ecu hardware limitation (would seem strange to me) or is it historical coil protection from nissan...?

I have ordered Audi R8 coils instead as these require a 2.5ms charge time and deliver higher energy so it should solve the problem. Just annoying I didnt know about this limitation when i ordered my LS coils.

[Matt]

There are limits in the ECU for maximum dwell charge time, so maybe you are hitting that? I've not tested high dwell RPMs with a scope on the dyno, just reving upto about 4000rpm or so in the drive way to check my estimated coil output gauge in the software with various ECUs

The way the ECU works is that it has an RPM triggered pulse processor. As the RPMs increase, the base pulse time (used to generate dwell) gets smaller, so that is what the RPM/dwell table is for - to keep the dwell time the same

Similarly with the voltage table, as the voltage drops, this table is used to increase the dwell time, but there is a limit to the maximum (hard coded in the ECU)

[Matt]

Attached is the dwell times for R35 GTR coils in a Z32 ECU running E85 20psi medium boost, 30psi high boost

[Matt]

With these numbers customer reports the dwell gauge shows 3.2ms

[madaxgt]

Be good if you could fix the reporting of dwell time in bnr32 as it almost never matches the scope reading. I dont always have a scope at hand so it would good to be able to trust the reporting to within +-0.2ms or something.

Just to clarify its not possible to get 3.2ms at high rpm on the bnr32 I was limited to around 2.4ms at 7-8k rpm.

[Matt]

I could only calibrate the approximation around 800-3000rpm during development. Around 7000rpm is not really possible

There is no hard and fast formula for calculating the pulse calculation....

The ECU has a pulse processor, and the pulses get shorter at higher RPM (so the RPM / dwell table is used to offset this) and the lower the battery voltage, the larger the pulse is required (hence the battery / dwell table)

The ECU code uses a base pulse multiplied by the RPM and battery dwell tables to work out a number to send to the pulse generator chip (for charge time)

Whilst I know the number (read from the processor) sent to the pulse processor, the calculations for 'ms' of time are only an estimate and there is not a definite way of calculating it on the fly

[Matt]

Updated dwell table based from scope measurements for R35 GTR