Porsche 911 3.3 Turbo

Problem solved

After finding that some cars get similar problems with powerflyback and Delphi 1000cc injectors (this car has Delphi 750cc) series resistors was fitted to the injectors. The car now run the injectors in saturated mode with series resistors and the ECU also has the flyback set up for highZ injectors.

The missfire disappeared immediately after this, I suspect that the strong pulsed currents caused a problem with the ground reference for the ignition control chip (I259). I hope to get find this problem on a car again to be able to diagnose it properly.


This car came to a friend of mine for mapping as he knows the specifics of these cars. But it was soon clear that the car needed more then mapping, it showed signs of trigger problems.


The spec is VEMS v3.2, 1.0.36 firmware, MSD DIS-4, proper waste spark coils, copy of original 911 turbo triggerwheel from a late model car. BMW VR sensor. The problem is that the triggerwheel is badly positioned, the missing teeth is around #1 TDC. More to come.


At high loads it banged and shot very violently, when going through the register at lower loads it just showed some hesitation. This is pretty common.

Tests and results

Full indexing (Strobe light)

When strobing the car on each coil it seem to fire at least one of the coils 120 degrees off now and then at idle. It's impossible to see how often but it happens.

Wheel error counter

The wheel error counts up to 1-2 during initial cranking and can count up when the cars idle is let down low enough for it to almost stall (3-500rpm). When the bang and cutout problem occur the wheel error counter _does not_ count up. Is the wheel error counter a reliable way to make sure that there are no false triggs or can some types of errors sneak through?

Scoping triggersignal

Redundant as the wheel error counter said everything was ok but as this is the only chance I have to scope the car I did it. The trigger signal was marginal in the missing tooth area, this is what made me doubt the wheel error diagnostics. It looks like it could almost arm the trigger for doing a false trigg in the missing tooth area.

check my_make, if it has MY_CONF += -D ALLOW_SLOPPY_TOOTHWHEEL (uncommented), than it tolerates 1 less toothcount (eg. 34 instead of 35). This is because it assumes that the tooth after the missing tooth was not sensed and everything was delayed 1 tooth (10 degree for a 36-1). There is no reason to completely cut power in this case (someone in Estonia claimed his engine needs ALLOW_SLOPPY_TOOTHWHEEL to run).



Around 2k:


Around 3k:




This wheel is useless, at least with VR sensor. Do you have a drawing, or picture of the missing tooth area to educate the future generation ?

I know the flywheel trigger is badly designed and that the triggersignals is dangerously close to a false trigg but the wheelerror counter does NOT count up when the missfire problem occur! Does this mean that the wheelerror counter can't be trusted?

The bad triggerwheel design:


The signs of communication corruption in the config.txt file makes me suspect that the communication with the ecu is not reliable and that corruption might have occured when the end user upgraded the firmware and uploaded config and tables.

This highlights the potential hazzard caused by us not having a properly defined release proceedure.

But is the problem in the bad missing tooth location? If not, maybe using Honeywell 1GT101 Hall sensor could cure the false trigger signal problem? PeepPaadam?

We have tested the Honeywell sensor a bit with multitooth triggerhweels lately and it will not read a wheel that is similar to this. It self calibrates until it doesn't see the wheel, then it calibrate until it see the wheel again. This continues in 1-4 second intervals. I can't say for this particular wheel but it is pretty similar to the ford sheetmetal triggerwheeel we tested. On the wheel we tested it worked after we removed half of the teeth to make it a 18-1 triggerwheel.