Extending the high rpm dwell limits of the VX / VY flash PCM

[Chr0m3]

Hey All,

For the last week or so I've been playing with the flash VX / VY PCM on bench, I've managed to get a PCM running on bench thanks to some help from some of the guys here (pman92). I've been doing some testing with a scope to see what the capabilities are of the factory ecu and see how they handle high rpm.

I've managed to discover that at around 6600 RPM you would lose control of spark quite badly with the factory code, I've been experimenting with a patch and have some interesting results, yes you keep "better" spark control up to 8000 RPM however I feel the dwell might be too small the and the burn too big in the mid range. With some more testing maybe this can be rectified, will just have to keep trying.

First lets show what happens at 6600 RPM in the factory code:

As you can see every 2nd / 3rd reference there is a really long burn time.

From my understanding the ECU uses a hard coded min burn and min dwell time, basically if the min dwell + min burn =< calculated 3x ref period then you end up losing control of the spark, I'm not 100% sure how it works but that seems to be how it is from my testing, 6600 puts it just under the limit so it's possible the references that have long burn time are the frequency from the Arduino I'm using to simulate the 3x ref slightly changing causing the overall sum to overflow and thus the issue you can see in the picture.

I've done the math and patched these values and ended up being able to take the ecu to 8000 RPM with "better" results, however as you can see there is the unwanted effect of less dwell overall and more burn overall, it's possible with a lot of trial and error (or someone who understands exactly how this works) that you could offset these issues.

Here's the data from my testing:

Screenshot-2024-07-06-000359.png (85.48 KiB) Viewed 7638 times

The (burn error) column just shows the error on only some references at "6600" RPM.

If anyone has anything to add, please do, also worth noting that the PCM is in EST not bypass and I haven't simulated TPS, MAF etc so the PCM is running at 10 G/S and 20 MG/S so it's quite low and not under any "load", however I can't see anything directly related to the load dynamically besides there's a check if above a certain MG/S the ECU seems to set dwell to something directly (max / min, unsure). It's possible the EST refresh logic might need to be coded to be more "dynamic", that's another possible solution to the issue.

[kur4o]

First you need to calculate the time that is needed for engine to take one fire event, usually the time between cylinders TDC for a given rpm.


If you use single coil you can`t go past that limit. WIth dizzy setup and more that 1 coil, you can pass that limit, but charging the coils should overlap at higher rpms if you want more dwell than the time between 2 firing events.

It is very likely there is TPU on board that handles the hardware side of dwell time.

[antus]

This is a reasonably well known late 90s / early 00s ipcm6 variant. I believe there is a hardware spark controller but the main OS is programming it for each upcoming event. Its running 3 coil packs with wasted spark, with the ignition module handling which one is charging and firing, not the PCM, but only a single signal wire for spark control between the PCM and module, which I think is what the scope trace above is showing. Because there is only 1 signal wire, I think overlapping dwell is not possible.

I do not know what is the minimum possible burn time, but I know 0.5ms is very very quick. The results look like the best that would be possible with this interface to a coil pack. It'd be interesting to put an 808 or 424 on the bench and compare what they do at the same RPM. I believe they are considered good for higher RPM, and there are probably people mentioning how high they were able to run an engine somewhere, though I cant find it at the moment. If you can reproduce the test on the bench and see timings that someone has said are good, you might get an idea of what is acceptable here, without putting it on a car capable of that RPM to test.

[Gareth]

I’m running a 424 controlling a VL400 ignition module and individual ls coils on a V6 that has seen 8500 on the dyno with no issue.

[Chr0m3]

I’m running a 424 controlling a VL400 ignition module and individual ls coils on a V6 that has seen 8500 on the dyno with no issue.

Good to know, 424 has completely different hardware for spark if I'm correct so wouldn't be the same in this case.

8500 is insane haha.

[antus]

I’m running a 424 controlling a VL400 ignition module and individual ls coils on a V6 that has seen 8500 on the dyno with no issue.

Good to know, but that aftermarket module has individual coils and VL400 put predictive dwell logic in the module so that it can start charging the next coil before it gets the signal to do so from the PCM. Even if the PCM delivers something slightly different than what it was expecting it'll take that in to account for the next coil, but it'll still be close enough it'll fire correctly. You cant put that logic in the factory ignition module, and you cant send it down the line with only 1 signal. The factory module can only map the one signal to one coil at a time.

[antus]

A bit more about it here, likely more in the threads.

viewtopic.php?p=92210#p92210
viewtopic.php?p=49028#p49028
viewtopic.php?p=50428#p50428

That was a hardware solution, with direct coil connection and that hardware had 2 CPUs between 2 boards, and each of them were more powerful than the CPU. 1 was an analog signal processor, and one had the main spark logic, and you could program it and log it directly. But its sadly no longer made or available.

[Chr0m3]

A bit more about it here, likely more in the threads.

viewtopic.php?p=92210#p92210
viewtopic.php?p=49028#p49028
viewtopic.php?p=50428#p50428

That was a hardware solution, with direct coil connection and that hardware had 2 CPUs between 2 boards, and each of them were more powerful than the CPU. 1 was an analog signal processor, and one had the main spark logic, and you could program it and log it directly. But its sadly no longer made or available.

Cheers, some good info, it's worth mentioning that the lower you keep the rpm limit (closest to factory code) the better the overall would be, like say if you were to only patch it to go 7200 RPM, you'd probably find the dwell in other rpm ranges will align closer with factory code results.

[The1]

The factory code monitors Cylair flow every 25ms, if it doesn't change it's goes to max dwell, if it does then it switch's to dynamic dwell.

The issue is as you found min burn and min dwell will be greater than 3x time, hence why factory set the limit to 6375.

From nutting out EST logic code i found these 2 in VX Enhanced bin which should be the hard coded values. If you still have your bench setup give it a go.

I have a ruff routine coded that uses 1Bit per RPM So i could update the Fuel Cut code to 16bit if changing those did work.

Location 14735 Hex 144A (Minimum dwell)
Location 1473B Hex 1448 (EST Low time or min burn)

[Chr0m3]

The factory code monitors Cylair flow every 25ms, if it doesn't change it's goes to max dwell, if it does then it switch's to dynamic dwell.

The issue is as you found min burn and min dwell will be greater than 3x time, hence why factory set the limit to 6375.

From nutting out EST logic code i found these 2 in VX Enhanced bin which should be the hard coded values. If you still have your bench setup give it a go.

I have a ruff routine coded that uses 1Bit per RPM So i could update the Fuel Cut code to 16bit if changing those did work.

Location 14735 Hex 144A (Minimum dwell)
Location 1473B Hex 1448 (EST Low time or min burn)

I patched those values to achieve exactly that in the original post, I showed the differences it does work but it changes more than I'd like.