MSefi.com read only forum (Jan.15,2018)

This is on my racebike, a V3 board, with MSII. Code is 2.862. The tach input is a geartooth sensor looking at a single reluctor nib on the stock rotor.

Have attached a lot file and the .msq I am presently running on.

If you take a look at the attached log file, at about 382 seconds the RPM flatlines. It then drops to zero for a period before coming back.

This occurs in quit a few places further along, always after I have shut the throttle going into a corner. You can see leading up to it that the RPM drops as it should, then stays at a static number for a while before going zero. The engine is turning at this time, but as I open the throttle nothing happens until it "catches" again.

I could understand loosing signal, but it seems to think that the bike is motoring at an impossibly stable RPM before the dropout. This only seems to happen on throttle down.

I have replaced the whole ECU and will try the new setup tomorrow. I don't see how this could be affected by hardware this way tho.

Any ideas?

There are 2 possibilities here. You are losing synch when the throttle is snapped shut because the drop in rpm is so fast the processor thinks it has lost synch or you really have lost synch in the sense that the tach inputs to the processor have ceased. If it were the former, you could set (under basic ignition options) check synch only on accel and steady state and this would solve the problem. But I think you are really losing synch. If you look at rpm and deltaT, they drop when tps drops at a little past 381. But at 382 no more tach inputs arrive - shown by the fact that deltaT and rpm freeze. deltaT is the time between tach pulses - very little can go wrong with it and the fact that it is freezing indicates it is not receiving anything. In your code I believe there is about a 1 sec timeout and then it declares lost synch. )Later codes use .3 sec or less.) Why you should lose synch on decel I don't know, especially with a tooth sensor, assuming it is a Hall sensor which puts out the same level signal regardless of rpm.

I have never seen this kind of trace before. I guess that if there is absolutely no input from the sensor, then it cannot update the delta-t unless it resets. Then once it resets it thinks it is zero RPM since there is no trigger. Kinda wierd that the trigger decides to work again for a while before failing again.

So what could cause the occasional drop to zero (like at 201.682)? I can see how the spikes can occur due to false triggering, but not sure how it can go to zero so quickly.

The pickup is a Cherry GS100701, (see http://www.jameco.com/Jameco/Products/ProdDS/512401.pdf) it is a hall-effect with built-in magnet. TTL output with a pullup resistor, and it is shielded to the MS box. The MS triggers an external HEI unit, and the primary wires to the COP coil are even shielded.

I had the thing on the dyno just a few days before, and logged the signals with my virtual oscilliscope datalogger. Everything was looking great then. But things only fail at the track, never in controlled circumstances.

I have attached another datalog, this is from the same bike after I replaced the complete MS and configured it the same. Things go along swimingly for a few laps, then it starts having all kinds of problems. The RPM spikes and drops to zero over-and-over and never really recovers. But it never has the RPM level out then go to zero.

It is starting to look like the pickup has failed, or at least is failing when it gets warm?

Now that I am home, I am going to take a look at it and see if there is anything obviously amiss with the pickup. Maybe setup a trigger on the milling machine, and then hit it with a heat gun. Could just replace it, but I would like to be able to confirm before I waste another race weekend.

Any other ideas to try?