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.
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.