Crank VR signal quality

[GustavH]

Hardware:
MegaSquirt V3 with the MegaSquirt-II processor modified for dual spark as described here.
Running with code version 2.883j and configured as a microsquirt. The MSQ file can be found here here.

Currently we are trying to get reliable RPM reading using a 12-1 crank wheel. (thus not using the cam wheel/sensor)

Using the 'Crank Wheel Pulser software' the RPM is accurate and reliable in megatune.



The figure shows the measured 'VR' signal from the software and the shaped signal to the processor (measured at PIN 14 on the CPU board). The missing teeth does not look perfect, but the RPM is calculated correctly.

When connecting the real VR sensor the signal looks like this:

The missing teeth is clearly 'missing' in the signal. The signal looks perfect ??!


The figure show the signals measured at PIN2 and PIN3 on U7a. The threshold and hysteresis looks ok (and different values has been tried). But the RPM measurement in megatune are highly unreliable. From time to time, the correct RPM is shown. The fuel pump does not start either so it's not a communication problem. We have not seen any problems with the VR signal on the scope.

To simulate the noise generated by the starter / generator. The engine were cracked while feeding the EFI with the VR signal from the the Crank Wheel Pulser software. Still no problem with the RPM

We have tried different values in pmask, tmask. The alpha-beta-gamma predictor with default values did not work either.

Any ideas on what could be wrong or how to troubleshoot it ?

[Tobisen]

It is nice to se Im not the only Danish guy her
I can´t open your msq!
Try to send it in a email to me!

Torben, Odense
Tobisen7@hotmail.com

[grippo]

What the processor sees are the times between the rising edges or the falling edges, whichever you specify. If I look ate these, you definitely want falling edge, but the V3 board is different from the microsquirt and the polarity you sepcify for the tach input mauy get reversed in the circuitry. So try just changing this polarity to see if it makes a difference.

Another thing is that your trigger offset is +3. It needs to be a large negative number. Try -63, but adjust the delay teeth either +2 or -2 to retain the same timing. This isn't the cause of the rpm problem, but it will affect ignition output when you start looking at that.

[GustavH]

Thanks for the reply.

Changing the trigger input capture from falling to rising did help. The RPM is now correct.

A zoom of the previously figure:


But looking at the figure where the square signal is measured at pin 14 on the CPU daughter board (the signal going directly to the CPU)
It is clear that the falling edge is the correct option. I really don't understand why it only works with rising edge trigger.

The signal is as specified on http://www.megamanual.com/ms2/wheel.htm.

@Torben
The server and network hosting the msq file and pictures are being reconfigured, so this might cause short interruptions of the service.
If you still experience problems with the file, I'll forward it to you.

[grippo]

I agree you want to always use falling edge if that is what is truly going in to the processor, and it looks like it is true in your case.However there is some jitter in the teeth in the sense that on the left of the missing tooth are longer than those on the right and the tooth before missing measures 2.55 mm with a ruler, but the missing gap is 3.9 mm with rising edge and 3.7 mm with falling edge, It should be 5 mm for the falling edge. But we need to know what the processor is seeing, scopes can sometimes introduce timing errors. Try a datalog and look at the deltaT column. It records the times between No_Skip_Teeth and see how consistent these are when using falling and rising edge. Also look at the trigger+/- column and see what they do when you set falling polarity and it starts missing inputs. Also try it at higher rpm like 1000 or 2000. You can also set falling edge and use larger pulse tolerances - make all 3 about 75%. You can't hurt anything on the stim.