Programmable Delco Ignition Module

[VL400]

Unless your PCM logic is inverted to ours the high to low transition is the reference edge sent to the PCM, page 4-7. This appears to happen at 6* BTDC. I can easily software invert the ref signal output so that is a simple if it is inverted. Can you check the bin to confirm the ref angle?

Can also get the toggle of the ref signal happening differently to what it is now and match your LT-5 module. Will take a bit to do and test but its possible.

[VL400]

1,322.3RPM(22.038 revs/second) increase per second, looking at 2000RPM(33.333 revs/second), the crank should go from one revolution in 30mSec(2,000RPM) to one revolution in 29.4mSec(2,039.7RPM), so .6mSec faster per revolution. being an 8 cylinder engine, that is .15mSec faster per firing event.

The issue is actually at low revs and gets better as RPM increases (the time between teeth is a non-linear relationship to RPM), above about 2000 RPM dwell control independent of the ECU is no longer an issue.

Generally spark retards as RPM quickly increases to suppress knock so not so much of a problem, and I predict engine acceleration based on previous tooth times but you need some change to be able to predict the next! But it can still cause a problem at very low dwell times.

[Xfirez51]

Unless your PCM logic is inverted to ours the high to low transition is the reference edge sent to the PCM, page 4-7. This appears to happen at 6* BTDC. I can easily software invert the ref signal output so that is a simple if it is inverted. Can you check the bin to confirm the ref angle?

Can also get the toggle of the ref signal happening differently to what it is now and match your LT-5 module. Will take a bit to do and test but its possible.

I will check altho I do not recall seeing a constant in the.xdf I have. I will send you a copy of the .xdf to verify also. Is it possible this may be hard-coded in the IM firmware?

[antus]

Post a bin and xdf to this thread. After helping vl400 test the nissan optical cas support i have seen first hand that the issues happen at low rpm or idle. Thats where the biggest timing differences for spark happen. On the VG30det we have this running on the numbers at idle are a lot less smooth than you would think.

[VL400]

I think the dwell control is finally working how I like it. Have a predictive term to try and just track RPM and dynamic dwell term to add a little for fast engine changes to give some more energy. Both are configurable to suit the coil type, both are currently pretty low for testing.

Around a 50% throttle stab (zoomed in) while using a 1.5ms dwell that some COPs use. Surprisingly the LS1 coils have no problem WOT revving out to 6800RPM like this and noticed no difference in how the car drove...

COP Dwell.png (31.32 KiB) Viewed 7331 times

At idle an instant WOT with the LS1 dwell table results in this (zoomed in again)....

Idle and Rev 2.png (30.63 KiB) Viewed 7331 times

Still get a small amount of initial dwell drop (not bad in this one) as I can only predict what the RPM is doing after the initial RPM changes and still dont know what the ECU spark advance will be. The ECU uses TPS AE to know that the RPM is going to rise and adds a large amount of dwell (the green bottom monitor). My dwell correction in ms is light blue, different scale so looks like heaps but is around 2ms (dynamic and predictive terms added).

Now this WOT is zoomed in so does not look like a fast change, but right at the initial rev it goes from 929RPM to 1179RPM in 32ms. This is 7812 RPM/sec!

And a bit higher revs to show how dwell smooths out as the accel rate and engine smooths out a bit....

Idle and Rev.png (27.71 KiB) Viewed 7331 times

[Xfirez51]

VL,

So if I understand correctly, changes in throttle transients are tougher to predict for dwell calcs than when you simply stomp the throttle. Also, the LS-1 coils appeared to operate happily even using a 1.5ms dwell? Perhaps you may have already noted this, but is there any dwell overlap and are we looking at individual cylinder instead of waste spark?

[VL400]

Because the module does not have a TPS input its harder to predict, I can only predict after getting the change what will happen on the next trigger pulse whereas the ECU/PCM knows there will be an RPM change when the TPS shows a fast movement. In the first picture with the 1.5ms dwell it shows the green EST dwell leading my modules light blue correction, that is how long it takes for things to move from mashing the pedal to the engine RPM changing - its about 35ms or so. I had initially considered using EST dwell as another way to detect it but needs some more coding to make that happen, it would not help in your case with no EST though.

Yeah the LS1 coils certainly are good, not problem at low dwell times but I am not really pushing it that hard either (NA, 10.4 comp and standard plug gaps). A boosted setup would likely be different, but could upgrade to LS2 or later coils for more punch.

There is dwell overlap, any setup with more than one coil can use it so not limited to sequential spark. I run two LS1 coils (its a twin dizzy V8) with overlap, picture of that here with the bottom monitor showing light blue EST dropping to 1.6ms (max you could get with a single coil, or even a factory DIS like we have in the commodore) while the module maintains 3.67ms (orange target overlay with dark blue what was delivered) .. http://pcmhacking.net/forums/viewtopic. ... 120#p49028

[Xfirez51]

In the case of the LT-5, the module is controlling dwell, so like your module, it has no TPS input to use as a predictor? Correct?

[VL400]

Correct, can only react to the engine RPM change after the fact. I suspect its not trying to command 1.5ms of dwell either, its easy with 4+ ms as you can lose a millisecond for one event and not notice or get a misfire. Lose 1ms with a 1.5ms target and its a different story!

[Xfirez51]

And as stated in the DIS documentation, the dwell time is set for 2-4msec. Since the dwell criteria is set for Waste Spark, would I be correct in saying that w a COP or CNP setup, the 2-4msec. is more than adequate given that the coils would be firing half the number of times?
So the use of your module would really represent no real change when it comes to accurately predicting rpm? If current module handles the issue adequately, so should yours in other words.