MembersPage/FPhil/SomeOddFireConcerns

I shall report here some of the problems I had while configuring the parameters (odd-fire, low toothcount maserati VR / VR trigger engine).

(Chronological order is bottom to top)


Missing primtrig pulse in the case of the coil type trig setup


(fphil) To further my remark the Vems support kindly told me that they would make the fw version 1.2.31 more strict in the special low-tooth count triggers when trigger noise is present.

I checked this point on the bench running fw 1.2.32. For the purpose, I built a trigger signal where one prim trig is missing: see below on the picture the last one before the coming sec. trig.

trigMissTooth.jpg

The triggerlog which results gives

trigErIgnStopOk.png

As on can see,

- the missing prim trig is indeed estimated, so the ignition fire quite on right time,

- the ignition stops afterwards.

However there is an extra last firing which is not on the good spot, it should have occurred about 60 before

- the vemslog (not shown) does not show that the injection is stopped as wheel.

In any case the behaviour of the genboard in case of missing low count tooth seems much better and quite safe now.

Thanks for taking care.


(fphil)It is not so the matter to stay in sync when one pulse is missing that the fw does not go out of sync and securely stops the engine (for the less) if this happens. Cannot any missing pulse be simply detected through a time window built from the last pulse period?

This issue may also concern coil type trig set up. For 60-2 setup this is indeed less a concern, but there how is this error detected and managed?

My VR pulse and grounds are quite good for what I can scope, This is the first time this happens after 2 years. It had occurred after I set the PS/2 speed cable from car dashboard, - which lights up when I switch on the car lights. I need to scope the signals. The Maserati case and its electric gimmicks are very special, however I hope that the time we have spent had allowed Vems to built their solution and offer for the odd-fire engine.


(vems) For a reasonable setup like a 60-2 a missing or an extra primtrig pulse does not cause serious out of sync usually. For a low toothcount setup (which is a bad idea in general, and especially bad idea if it's not HALL but VR), the trigger pattern should be high quality signal (it would be interesting to see why the lights effect it, maybe grounding can be improved ?).

So the options are:

Switching on lights influencing trigger is almost certainly a grounding problem somewhere. Getting out of sync with a lost primtrig pulse (especially for a low toothcount setup) is not a firmware problem. The install wiring (and perhaps VR sensor bias pullup resistor?) should be reviewed and fixed so that the VR signal is sufficient quality and turning on lights should not cause lost pulses or noise pulses: than the engine will stay in sync.


I was steadily driving at 60km/h entering a tunnel in a busy trafic. At the time I switched on the lights the engine shakened badly, made big noise, big smoke behind the car, seemed to have no more power.The engine stopped when clutching off. Then the engine restarted ok when clutching on by the car still moving on.

At my parking slot, I was able to record the trigger log of what may has happened the night before.

Switching on and off the car lights, I noticed that sometimes the engine was accelerating or slowing or eventually may stop.

Here is trigger log when the engine stops. (prim trigs are 30, 90, 30 apart, there are 3x2 pulses on the crank wheel). One can see that Vems came out of sync but was still firing.

outofsync.jpg

Here is the same log without the fire events.

config2trigmissing.jpg

It shows that one prim trig is missing (@ first complete revolution).

Indeed, to further what the Vems support has told me, with a reasonable setup like a 60-2 an extra trigger pulse or a missing pulse does not cause serious out of sync. However for a low tooth count setup such as coil type, the trigger pattern can have a high quality signal, (I scoped mine several times before), but comes to get a default, per ex. because a ground problem occurs (one does not install a non oem ecu on a new car).

I believe that an operational software should detect those trig errors and takes proper action: This does not seem to be a big fw update to check if the incoming pulse is in a good window or not, and, if it is not the case, do re-sync (per example)

At least, Vems should let people know that there is no trig error management with the coil type set up and that there is some risk of engine damage or car crash in a tunnel incoming Paris ;p)