Thursday 18 August 2016

Back To Basics

I realise it is close to a year since I updated this but better late than never. Not much has happened in the way of real engine calibration since the last update but still some reasonable progress in terms of fine tuning settings. The bike got MOT’d right after the last blog entry and had a few outings afterwards but hasn’t really moved since Christmas.

I wanted to check a few things that were bothering me about the Microsquirt control and so ended up carrying out quite a lot of bench testing on the ignition side of things over several months.

I actually don’t remember where it all started but at some point during the last year I started to question the accuracy of ignition timing provided by the Microsquirt ECU. I carried out some tests using a crude trigger wheel simulator on the bench & then on a running engine which confirmed my suspicions; ignition timing appeared to drift as much as 5 degrees at 18,000rpm. On top of this I noticed two further uncertainties while testing.

  1. Battery voltage as read by the ECU did not track actual battery voltage. There appeared to be some hysteresis in the measurement as the ECU recorded a different offset depending on whether the battery voltage was rising or falling. This was obviously an issue as it would result in incorrect coil dwell times & injector dead times.
  2. During ignition coil testing using the ECU’s output test mode, coil dwell times measured did not match what was demanded by the ECU even with battery voltage compensation disabled.

When I first noticed the timing accuracy issue I figured I could simply get a new, higher resolution trigger wheel made to replace the standard 12-3 wheel. However I hadn’t reckoned with the fact that the Microsquirt doesn’t have the processing power to cope with a higher resolution wheel at the kind of engine speeds seen on the CBR250. The Megasquirt developers have stated that even with the low resolution wheel on the CBR250, 18,000rpm is pushing the boundaries of the Microsquirt hardware capability and that an MS3Pro ECU would do a far better job at controlling the engine at these speeds. Coming out of this, I will most likely be upgrading to an MS3Pro ECU sometime in the future but given the expense and the fact the wiring harness would need to be redesigned to work with the new ECU I tried to find a way to make the Microsquirt work acceptably until I was ready for the upgrade and so I continued with reasonably extensive bench testing in order to measure and understand how the ECU controlled the ignition side of things.

Ignition Timing Accuracy
Firstly I wanted to spend some more time bench testing the ignition control both to understand the issues better and to be able to present the issue properly to the Megasquirt developers which would help find out if the MS3Pro would actually fix the issues. That meant making sure that all other variables were as accurate as I could make them. The most important of these was the trigger wheel offset relative to TDC. I had determined this value early in the project using a timing light so it was potentially not as accurate as it could be.

To determine this properly with the oscilloscope, I needed to compare it directly with the output of the standard MC22 ECU at a known engine speed and spark advance. I wanted to have a way of accurately simulating the crank trigger signal as would be seen by the ECU in a running engine. There are lots of ways available to simulate hall effect trigger signals but I specifically wanted to simulate the VR type of signal that creates a zero crossing. After some research & trial & error I settled on using an Arduino board to create the signals using a modified version of the Ardustim code.

The Ardustim code normally generates a hall type signal by asking a single pin to go high at specific times. With some modification to the Ardustim code I ended up creating a VR type signal by switching two separate pins & merging them into a single channel. The voltage output from the merged channel would depend on the combined state of the two Arduino pins.

Both pins high = 5V; Both pins low = 0V; 1 pin high + 1 pin low = 2.5V.

The output is fed through a transformer to create the needed zero voltage crossing. The simulated VR signal could then be used to determine the 1st tooth angle offset to TDC from the standard MC22 ECU.

As I had a CBR250RR(R) ECU, the benchmark from the manual is spark demand at 20°BTDC at 1,500rpm. Measuring the time delay on the oscilloscope between the 1st tooth trigger & coil firing signal and converting to degrees at 1,500rpm gave me a 1st tooth angle of 70.5°BTDC. 0.5° closer than I had measured with the timing light.

1st Tooth Offset Determination. Note The Simulated VR Signal
With the foundation settings correct in the Microsquirt I then proceeded to map the ignition angle error across the engine speed range to build up some data and understand what the exact nature of the error was. It was only when I actually wrote the error values down that I discovered that the errors were consistent in terms of time throughout the engine speed range. This led me to wonder if this was something that could simply be corrected for in the calibration by adjusting the spark hardware latency offset setting. I had not used this previously as I had understood that it was to be used to correct for any delays which might exist within external hardware and since the errors I had been seeing were from within the Microsquirt itself, I ignored this feature.

I made some small adjustments to the latency offset and rechecked ignition timing across the speed range each time until I was happy that the measured ignition timing was consistent with what was being demanded.

Voltage Reading
It was actually quite straightforward to fix the battery voltage reading error within the calibration. I used a digital benchtop power supply to vary the voltage supply to the ECU & noted the voltage readings within the ECU. I quickly found that the different voltage readings depending on if the voltage was increasing or decreasing was being caused by the smoothing function which I had set quite high initially. Once the smoothing was removed, the ECU voltage readings tracked consistently all the time but were offset slightly from the supplied voltage.
I used the measured error to determine new values for voltage at max & min ADC to change the voltage reading calibration which brought the voltage readings in line with the supplied voltage.

Coil Dwell Time
While testing and characterising the ignition coils using the controller’s output test mode to drive the coils, I found that the measured coil dwell tended to be longer than what was being demanded from the ECU by a factor of c.1.14. This did became a little worry at the time but I have since noticed that the error appears only when controlling the coils in the output test mode. When the engine is running (or simulated) the measured dwell time matches what is being demanded by the controller and so this became a non-issue.

Ignition Coil Characterisation
A major unknown in the ignition system was the dwell time required for the ignition coils.

First, the standard MC22 RR(R) ECU was mapped in order to determine what dwell times it was requesting at different engine speeds and then compared against how the Microsquirt code handles dwell.
Looking at the dwell times that were being requested by the standard ECU and how they changed as engine speed increases gave the impression that the coils may be performance limited at high speed as the dwell time at 17,000rpm is significantly shorter than at 5,000rpm for example and if the dwell being provided at lower engine speeds is necessary for good coil performance then it would mean that the coil is not getting fully charged at higher engine speeds and ignition performance may be compromised.

This observation prompted an investigation into trying to fit some higher performing pencil coils from a more modern machine to try and get consistent ignition performance throughout the speed range. The biggest issue was and still is finding coils which will physically fit in the MC22 plug bores.

All TCI coils found are too high and protrude quite a lot above the cam cover and foul the radiator fan.

CDI coils such as installed in ’97-‘99 Suzuki GSXR600/750s & 2009 Yamaha YZF250 seem to be the smallest coils physically and could be made work but even these are c.10mm longer than ideal for the MC22. The issue with the CDI coils then is that while they can be made work with a TCI ignition system, the charging current is far higher and the dwell times are far shorter than a normal TCI coil and the ECU and coil drivers would need to be capable of controlling them very accurately.
The charging current can be dealt with using an appropriate ignition IGBT specced for the high current & fly-back voltage. I did purchase a number of appropriate transistors which were capable of driving the CDI coils successfully during bench testing.

However it was found during testing that the Microsquirt firmware did not have the dwell demand resolution needed to accurately control the GSXR CDI coils. The Megasquirt firmware can only control dwell to the nearest 0.1ms but the GSXR coil nominal dwell is c.0.3ms so accurate control of the dwell is impossible with the Microsquirt controller. Due to this control limitation, the coil upgrade idea has been parked for the foreseeable future.

Given no alternative ignition coil solution was on the horizon, the standard MC22 wasted spark coils were tested to characterise them and ensure they were being driven properly by the ECU. The coils are nothing special for the MC22 as one might expect for an engine that was being asked to rev higher than most other engines at the time. They are TEC MP08 coils which seem to have been the standard Honda wasted spark coil of choice during the 1990s.

A current clamp was connected to the oscilloscope to observe how the charging current increased with dwell time & determine the optimum dwell time for a range of battery voltages to provide consistent performance. Observing the way that current draw increased with time it was decided to limit the charging current to 2.75A. The standard ECU does not correct for battery voltage and dwells the coils for 6ms at idle and up to 4,000rpm. As can be seen in the current trace below, this level of dwell overcharges the coil and dwell times could be significantly reduced without too much of an effect on ignition performance. Reducing dwell times would also ensure the coils are performing consistently across as wide an engine speed range as possible. At 12V, the dwell time to 2.75A is 2.5ms and even at 10V there is no sense in dwelling the coils for more than 4ms although it does not reach 2.75A.

TEC MP08 Primary Current at 12V Supply, 6ms dwell
This investigation showed that as long as battery voltage is kept above 12V there would be no reduction in ignition performance across the full engine speed range. Another benefit is that by keeping the dwell as low as possible at lower engine speeds, this would reduce the load on the charging system compared to the standard settings. Also the old adage, “leave well enough alone” holds true as there is no point in chasing the COP coils option when there is nothing suitable on the market at the moment for reasonable money. For a bigger engine it would be worth it purely to free up some space and provide the option for sequential ignition at a later date.

While getting all this information took a lot of time and investment in new equipment, it is worth it to ensure that the basics of the system are working correctly otherwise it would make future calibration more difficult.


H.Amiri said...

Perfect project!
I'm working on mc17 series.
8 teeth 7 + 1, and now I'm trying to run the engine with a fork of and open source rusefi ecu.
My engine has 2 crank shaft sensors, It is hard to me running correctly.

motthomas said...

Hi & thanks for your comment.
I'd be interested to hear how you are getting on with the rusefi ecu. Are you trying to use both crank sensors? Are both sensors connected to the ECU? If I were you I would only use one crank position sensor. The MC17 is an even fire engine with a very standard firing order. Any aftermarket ECU will have no problem running it with only one sensor. You most likely do not need the 2nd sensor and it may have only been installed by Honda due to hardware limitations at the time of manufacture. If you look at the newer mc22 models, they all have only one crank sensor.