ECU Inputs

ECU Inputs

As mentioned earlier, the ECU fuel injection computer does its job by watching a set of sensor inputs, then using those inputs to generate a set of outputs that control fuel and spark timing, among other things. The set of inputs available to the Aprilia ECU can be determined in a couple of ways. The easy way is to look at the wiring diagram in the service manual and see what sort of things are connected to the ECU connectors. This will define most of the inputs to the ECU. Even so, some inputs are contained entirely within the ECU circuitry itself. Once the circuit diagrams have been reconstructed, the complete set of ECU sensors and inputs can be determined.

The complete set of ECU inputs is listed here. Click on the links to learn about each particular form of input:

In addition, the ECU circuit board appears to potentially support some features that Aprilia did not use. It looks like there may have been space on the board to manage an oxygen sensor for closed-loop fuel injection applications. The Aprilia ECU implements a simpler open-loop control mechanism, so the oxygen sensor circuitry is not present. I have heard rumors that this ECU was actually designed as a car ECU. Maybe those inputs were used in the car applications.

Managing Inputs

The processor reads its inputs constantly. As fast as computers are, they can't read every possible input all of the time. However, the processor's job can be made easier with the realization that certain inputs do not need to be checked as often than others. For example, while the throttle angle sensor can move from fully shut to fully open as fast as you can twist the handgrip, the water temperature will take minutes to move from cold to hot as the engine warms. This means that the software should check the throttle position more often than it checks the water temperature.

This is exactly what happens inside the ECU software. It turns out that the ECU is set up to read just a single sensor once every 1.5 milliseconds. While this sounds fast, with so many sensors to read, the processor would fall behind on the fast-changing inputs. Because of this, the software is designed to schedule how it reads its sensors. The schedule is based on how fast the sensor might change. Decoding the software shows that the scheduling algorithm looks this:

Since one conversion is performed every 1.5 milliseconds, the table shows that the water temperature would be tested every (128 * 1.5 milliseconds) or 0.192 seconds (roughly 5 times a second). In contrast, a fast-changing input like throttle angle is checked about 333 times a second.

There is one screwy thing regarding the Throttle Angle conversions. Analyzing the software shows that even though the Throttle Angle sensor is converted the most often (128 times out of 256 possible conversions), it gets sampled twice in a row, and then the next two conversions will be performed on two of the other inputs. I have always wondered if this was a bug, and they meant to sample the throttle angle between every other possible reading. Maybe some day, I will fix that code and see if the throttle response changes in any perceivable fashion.

Detecting Sensor Errors

One final important task that the ECU performs is to try and make sure that its sensors are telling it valid data. For example, if the throttle angle sensor breaks, the ECU might think that you are trying to run the engine wide open all the time. Obviously, erroneous inputs of this sort would cause the ECU to make all kinds of bad decisions about how much fuel to put into the engine. Fortunately, there are a variety of techniques that the ECU can use to validate or cross-check the input that it gets from its sensors. When a sensor malfunctions, there is a good chance that the ECU can detect it and signal the user by flashing the EFI warning light on the dash. The methods used to detect broken sensors will be covered under the description for each sensor in the list, above.