Monday, 28 January 2013

RPM Issue Solved!



Long time, no write! I let the project fall by the wayside for a few months until I was able to move the bike into a new workshop so I have just got back to it recently.

Since my last post, I seem to have solved the rpm signal issue which turned out to be deceptively simple as usual!
Starting at the beginning, I switched firmware on the ECU to MS/Extra which gave me access to extra diagnostics tools in order to try and solve the issue. Running the diagnostics on the trigger wheel signal showed up some interesting results. The diagnostics tool works by measuring the time gap between “events” and outputting the results as a bar graph. This allows the user to see how the ECU interprets the VR sensor signal and identify issues with noise or false signals. The ECU interprets an “event” as the when the VR voltage signal crosses 0V going positive and using the definition of the trigger wheel as set by the user, determines engine RPM and crank position. Below is a photo of the mc22 trigger wheel.
mc22 trigger wheel


An event happens any time a tooth approaches the sensor so the ECU should read 9 events followed by a gap. If the ECU is measuring the gap between events, it should see 8 gaps of relatively equal length (the length will vary due to compression effects) followed by a gap four times the length of the previous 8. However, when I ran the diagnostics tool at engine idle, it became clear why the ECU could not interpret the rpm signal. The diagnostics shows that the ECU was seeing only 7 relatively equal gaps, followed by a gap roughly twice as long and finally a gap about 3 times the length of the first 7. It was almost as if the last tooth had shifted one position later! Graph below for illustration.
Problematic TunerStudio Tooth Logger output at engine idle


I spent ages looking into the cause of this. I bought a cheap USB oscilloscope from EBay to look at the raw signal data from the VR sensor but it turned out to be useless as I misread the specifications and it only had an amplitude range of 1V! I also planned to build a VR conditioner circuit which would convert the VR signal to a square wave Hall signal before input to the Microsquirt ECU. This had been used by a few of the MS forumers to allow the Microsquirt to interpret long tooth trigger wheels. Thanks to EWflyer on the Microsquirt forum for pointing me in that direction!

A few weeks ago I discovered the Arduino board and bought one to play around with. I figured it might have some uses for this project, especially data acquisition and recording. I looked into using the Arduino as an oscilloscope but looking into it, it seemed slightly over my head for the time being. So I discovered then that I could use one of the most basic commands to have the Arduino convert an analogue voltage input to one of the Arduino pins to an integer number and send the number back to the laptop via the serial port. I could then use an auxiliary program to read the integer number stream and write the stream to a text file. The text file could then be opened in Excel and the data displayed on a graph. It is a crude and longer process than I would like but it works! The disadvantage was that it would only read the positive values of the VR signal so I could only display half the signal. For the purposes of identifying any potential issues with the signal, this was acceptable. I may be able to capture the full signal using the Arduino if I research it some more and play around with the code but that’s for another day.
Arduino board hooked up to the VR sensor


When cranking the engine, I was able to get the below plot from the Arduino. The signal looks just the way I would expect so no issues there. The acquisition rate isn’t high enough to identify noise but at the same time, the ECU has inbuilt noise filtering so as long as there is no major noise, it shouldn’t be an issue.
Plot generated from Arduino output


Armed with the confidence that there was nothing wrong with the VR signal, I went back to the microsquirt to see what could be done there. As it happened I solved the issue by accident! While cranking the ignition with the engine stop switch in “off” position, I recorded correct signals with the TunerStudio Tooth Logger.
TunerStudio Tooth Logger diagnostics output when cranking


Recording a data log of the engine cranking also showed a steady cranking rpm signal of ~360rpm without any dropouts! The ~5000rpm spike at the start can be ignored as the ECU will usually skip a certain amount of pulses when starting cranking to allow the signal to settle.
Consistent rpm signal logged at ~360rpm


So quite by accident and even though I was sure I had tried it before, I discovered the issue was simply interference with sharing the VR signal between the stock CDI and the Microsquirt. The next step is to wire up the Microsquirt to drive the coils and get the engine running with Microsquirt controlling the ignition timing and remove the stock CDI altogether. That way I will also be able to identify any issues with high rpm running, signal dropouts or misfiring, etc. Watch this space.

No comments:

Post a Comment