Dwell time/length

Nistune topics related specifically to the 6303 cpu

Moderator: Matt

Post Reply
nielshy
Posts: 3
Joined: Tue Aug 11, 2015 4:29 pm

Dwell time/length

Post by nielshy » Sat May 06, 2017 5:02 am

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Sun May 07, 2017 3:03 pm

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
Posts: 2
Joined: Fri Apr 13, 2007 3:13 pm
Location: Massachusetts
Contact:

Re: Dwell time/length

Post by NIVO » Fri Jul 07, 2017 5:42 am

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

Ross
Posts: 7
Joined: Thu Jan 10, 2013 2:21 pm

Re: Dwell time/length

Post by Ross » Thu Jan 04, 2018 11:24 am

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Tue Jan 09, 2018 6:17 pm


madaxgt
Posts: 14
Joined: Mon Feb 06, 2017 7:16 pm
Location: Goteborg, Sweden

Re: Dwell time/length

Post by madaxgt » Tue May 08, 2018 4:34 pm

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Fri May 11, 2018 10:18 am

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
Posts: 14
Joined: Mon Feb 06, 2017 7:16 pm
Location: Goteborg, Sweden

Re: Dwell time/length

Post by madaxgt » Mon Aug 31, 2020 11:11 pm

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Sat Sep 12, 2020 6:54 pm

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Sun Sep 13, 2020 11:03 am

Attached is the dwell times for R35 GTR coils in a Z32 ECU running E85 20psi medium boost, 30psi high boost
Attachments
2020-09-13 09_27_40-Dwell Time.png
2020-09-13 09_27_40-Dwell Time.png (298.64 KiB) Viewed 1207 times

Matt
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Sun Sep 13, 2020 11:03 am

With these numbers customer reports the dwell gauge shows 3.2ms

madaxgt
Posts: 14
Joined: Mon Feb 06, 2017 7:16 pm
Location: Goteborg, Sweden

Re: Dwell time/length

Post by madaxgt » Thu Nov 26, 2020 1:26 am

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
Site Admin
Posts: 8633
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Dwell time/length

Post by Matt » Thu Nov 26, 2020 10:37 pm

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

Post Reply