Variable Valve Timing Controller Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The focus of this research was the creation of a controller that can be used for the operation of a simple Variable Valve Timing mechanism in Spark Ignited Internal Combustion Engines running on petrol or auto-gas.

The importance of this research is in the capability of controlling functions that are normally controlled by the ECU (Electronic Control Unit) of an engine, without using an ECU for the whole operation of the engine.

We developed a control unit (ECU) that would be suitable for prototyping engine control algorithms for VVT (Variable Valve Timing) and other functions, as sensor and actuator design. This task needed reliable, high-performance hardware like ARM processor and CAN bus network. It also required some complex in some areas programming code and advanced software too for the configuration of the hardware and monitoring of the system.

The result was to create an efficient controller which could be easily added with more 2-dimensional maps, controlling even more outputs like Nitrous Oxide supply, exhaust butterfly valves etc.

A higher resolution map, the support of stepper motors, could make such a controller extremely useful for engine conversions. And of course maybe some time in the future this project could be implemented to a custom ECU that will manage everything. Fuelling, ignition and secondary outputs for auxiliary systems.

The key finding on this project was the know-how of manipulating data to form 2-dimensional maps which basically consist of arrays.


Preface ii

Acknowledgement iii

Abstract iv

Chapter 1: Introduction 1

1.1 Background 2

1.2 Research Focus 5

1.3 Overall Aim and Individual Objectives of Research 6

1.4 Research Methodology 7

Chapter 2: Theory of Infrared Thermal Sensing 8

2.1 Introduction 9

2.2 Thermal Sensors 9

2.2.1 Contact Thermal Sensors 10

2.2.2 Non-Contact Thermal Sensors 11

2.3 Theory of Infrared 12

2.3.1 Classifications of Infrared Radiation 14

2.4 Basics of Non-Contact Thermal Sensing 15

2.4.1 Target Surface 16

2.4.2 Infrared Measuring/Sensing Instrument 17 Performance Parameters for Sensing Instruments 19


Appendix B: Glossary of Terms

Appendix C: List of Figures

Appendix D: List of Tables

Appendix E: URL Links

Appendix F: Program Codes

Chapter 1


1.1 Background

From the end of the 80's, with the enforcement of the Federal Emission Regulations in 1981 ECU's are being used popularly in most of the vehicles. Most vehicles are using electronics to control the operation of an engine. Manufacturers were forced to do so in order to comply with the requirements on more environmental friendly vehicles. So vehicles were equipped with a device called ECU (Electronic Control Unit) or ECM (Electronic Control Module) if you prefer. The ECM also known as EMS (Engine management system) is an embedded electronic device, basically a digital computer in an internal combustion engine that controls various engine functions like fuel injection, ignition timing and idle speed control system. All these controls are done based on data (like engine coolant temperature, air flow, crankshaft position and speed, engine load etc) received from various sensors.

The ECM's also learns about the engine as we drive our car. The "learning" is actually a process that the ECU uses to track the tolerance changes of the sensors and actuators on the engine. For examples the idle-air bypass valve (automatic choke) at idle with the A/C in the CAR on and off. The ECM stores these "learned" values in battery backed-up RAM so that it doesn't have to start from scratch the next time the engine is turned over.


fig.1 : example of an ECU

As the years went by, emissions regulations became more and more strict, so vehicle manufactures started implementing more technology in order to comply with the regulations and to provide hi-powered engines. Such a thing was VVT (Variable Valve Timing) control. Which is controlled by the ECU, like everything else nowadays. We won't get into details about VVT because it has to do with engine technology, but we should keep in mind that that there are 2 kinds of VVT control. On/off and constantly changing valve timing. In this project we will focus into the first type, the on/off one.

Case study:

The inspiration for this project was a modern-classic passenger vehicle, an Alfa Romeo 75 Twin Spark, which is powered by a 2 liter, twin cam, 8 valve engine, with VVT. Variable Valve Timing comes in the form of a phase variator (fig. 2), that turns the camshaft of the inlet valves by 15 degrees, optimizing the power of the engine. This is an example of an on/off VVT system. When the phase variator is powered from the ECU with 12 volts, it rotates the camshaft by 15 degrees in relevance with the gear of the camshaft.


fig.2 : phase variator (VVT)

The need for a controller

But anyone could argue that, but since this function is already operated be the engine ECU why bother building a controller in order to control the VVT? The answer comes from the track:


fig.3 : track day /competition vehicle

Car enthusiasts around the world, very often convert these engines to carbureted engines, taking out the factory ECU and its harness. So they can't control anymore the operation of the VVT. Not the best solution for performance, but much cheaper than fitting an aftermarket ECU and independent throttle bodies in order to have a similar improvement in performance. In fig.3 you can see a tuned engine for trackday use, converted to run on carburetors.

Ignition without stock ECU

Since we are talking about a carbureted engine, people now need a device to control the ignition timing, and they can use something like that in fig. 4, from Alfaholics.


fig.4 : 2-Dimensional Mapped Ignition System with Distributor

This ECU controls the ignition advance against engine revolutions, and sends a signal to the distributor which directs the spark to the correct plugs. The ECU is already loaded with an optimal map curve, so no further setup is required by the client. Final ignition advance is controlled by rotating distributor as with normal distributor.

Also there is available an even better solution for the ignition. A full 3-dimensional ignition ECU, incorporating distributor-less ignition:


fig.5 : 3-D map ignition system

This is a full 3-D setup which allows ignition advance to not only be endlessly variable dependant on engine revs, but also with regard to throttle position. This kit comes complete with ECU, 2 coil packs, 2 amplifiers, throttle potentiometer, universal loom, connector plugs and programming kit.

So now with fuel and ignition control taken care of, we still have a function of the engine without control. This function is the VVT. We focused on the existence of two different systems available in the market for the ignition, because we want to highlight the lack of any system suitable to do the task of controlling the VVT. That's why many people turn into designing their own analog circuit to control the VVT function. Inputs usually are throttle position (engine load) and engine speed (rpm).

Chapter 2



2.1 Introduction

In order to control the VVT, we obviously need some kind of microprocessor. And in the labs there were available ARM (Advanced Risc Machines) architecture microprocessor based boards. Also there were available CAN (Control Area Network) bus boards.

2.2 MCB2360 Evaluation Board

The Keil MCB2360 Evaluation Board introduces you to the NXP LPC2368 microcontroller. It allows you to create and test working programs for this advanced architecture.


fig.6 : the KEIL ARM MCB2300 board

Unfortunately this board has only one potentiometer from factory, but the CAN bus interface it supports gives us a lot o potential. Since in our application we require two signals to control the operation of the VVT, engine revolutions and engine load, we can set up a CAN bus (Control Area Network) system to feed these signals to the ARM board. This decision was made in order to practice in CAN bus, and get valuable experience.

We should mention of course that it is possible to install a second potentiometer in the ARM board, as it has available input ports. But our will to practice on the CAN bus, made us to reject that option.

This board features:

A USB 2.0 Full Speed Interface, with Standard USB connectors for USB Device, USB-OTG, USB Host and UART via USB on the MCB2300 board for applications requiring USB communications.

Dual Serial Ports with standard DB9 connectors on both of the LPC2300's serial ports. Application may use either of these ports.

Dual CAN Ports with standard DB9 connectors on the MCB2300 board for applications requiring CAN communications. Application may use either or both of these ports, or they may be disabled with a configuration jumper.

A 100/10M Ethernet Port with standard RJ45 connector on the MCB2300 board that connects to an on-board Ethernet transceiver for applications requiring Ethernet communications.

An LCD Display with 2 lines by 16-characters, working at 8-bit. We may use this text display device to show real-time debug and program status messages.

An LF Amplifier that connects the D/A output of the LPC2300 device to a speaker. We may use this LF Amplifier to generate sound.

An Analog Voltage Control for ADC Input for testing the Analog to Digital output feature of the LPC2300. A configuration jumper enables and disables this feature.

A JTAG (Joint Test Action Group) Download and Debug interface, coupled with the ULINK USB-JTAG adapter, that allows flash programming. The on-chip debug interface can perform real-time in-circuit emulation of the LPC2300 device. For fast PC communication, we must use our PC's USB port.

2.3 PCAN-MicroMod Evaluation Kit

Since we decided to use a CAN bus system to transmit the necessary signals to the ARM board we needed a CAN bus module with the straightforward capability to provide electronic circuits with I/O functionality and a CAN connection. Configuring is done with a Windows® program which sends the configuration data to the module via CAN. Several modules can be configured independently on a CAN bus, but it's not needed in our application.


fig. 7 : PCAN-MicroMod Evaluation Kit

This board features 1 microprocessor,8 digital inputs, 8 digital outputs, 4 frequency inputs (1 Hz-10KHz), 4 frequency outputs, 8 analog inputs with 5V reference voltage, 4 potentiometers, CAN bus interface and a RS-232 interface.

We will use this board to transmit through CAN bus the signals we need in order to simulate the function of the VVT controller.

Chapter 3

Engine signals

3.1 Introduction

As mentioned earlier, we will use for our VVT controller 2 engine signals. Rpm and engine load.

3.2 The rpm signal

We use a waveform generator to feed into the PCan board a sine-wave signal varying from 1 Hz to 7 KHz, at 5 volts peak to peak. Each Hz represents 1 rpm of our engine, so we can simulate up to 7000 rpm, which is a realistic upper limit for an engine. This signal is allocated to frequency input 0. In order to be absolutely exact, we are not generating a real rpm sensor signal, since we are not simulating the missing tooth effect on a VR or Hall effect sensor. This kind of sensors is speed/position sensors commonly used in motor vehicles.

3.3 Engine load

Engine load is simulated by a potentiometer in the PCan board, and varies from 0 (throttle closed) to 5V (throttle fully open). Conventionally engine load varies from 0% to 100%. This signal is allocated to analogue input 0. In reality engine load is measured as intake manifold pressure usually, but this is not the only method.

Chapter 4


4.1 PCan MicroMod

We use the PCan MicroMod evaluation software created by PEAK-System Technik to configure the PCan board to generate the CAN bus messages that will be driven to the ARM board. The CAN bus is set to 500 Kbit/sec, as there is really no need to use the full speed of the system, which can go up to 1 Mbit/sec. We use 2 different CAN message id's, hex 010 and hex 011, with 11 bit identifier. The first one is for the rpm signal, the second for the engine load signal. Both CAN messages are using a 2 byte long data field, with every byte having 8 bits. Also both CAN messages are generated every 500 ms, which is adequate for the requirements of our application.


fig.8 : MicroMod configuration for rpm signal


fig.9 : MicroMod configuration for load signal

As you can see in the screenshots taken, the PCan board is connected to the PCan-PCI card at the speed of 500 Kbit/sec. In both analog input window and the frequency input window, we configure where about in our CAN message structures the values are stored in. The values for both load and rpm are stored in 16bit numbers, 2 bytes long, starting from Byte 0 bit 0, going to the left up to Byte 0 bit7, and then it continues to Byte 1 bit 0, ending at Byte 1 bit 7. This format is called Intel format.

4.2 Keil Uvision

The UVision IDE from Keil combines project management, make facilities, source code editing, program debugging, and complete simulation in one powerful environment. The UVision development platform is easy-to-use and it helps us to quickly create embedded programs. The UVision editor and debugger are integrated in a single application that provides a seamless embedded project development environment. It's the perfect tool for programming, as it uses C programming language instead of assembly.

Starting the project in Uvision software, we need to define what exactly we need our ARM processor to do. In our case we start by using the RTX kernel. This is a Real Time Operating System (RTOS) that enables you to create applications that simultaneously perform multiple functions or tasks. This is very useful in embedded applications like ours, were the ARM processor needs to process information and output a result at the same time. While it is certainly possible to create real-time programs without an RTOS (by executing one or more tasks in a loop), there are numerous scheduling, maintenance, and timing issues that an RTOS like RTX can solve for us. So the RTX kernel is one way road for us.

An RTOS enables flexible scheduling of system resources like CPU and memory, and offers ways to communicate between tasks. The RTX kernel is a powerful RTOS that is easy to use and works with microcontrollers that are based on the ARM7â„¢TDMI processor.

RTX programs are written using standard C constructs and compiled with the RealView® Compiler. The RTX-CAN.H header file defines the RTX functions and macros that allow you to easily declare tasks and access all RTOS features.

The RTL.H (Real-Time Library) header file is a group of tightly-coupled libraries designed to solve the real-time and communication challenges of embedded systems based on ARM-powered MCU devices.

The LPC23xx.H header file includes the library definitions for our program.

The LCD.H header file includes the library definitions for the functioning of the LCD display. Even if we don't want to use the LCD display of the ARM board to display any info about the operation of the system, we need to at least make sure that it won't display any information from the program the board was flashed with by the previous user. Powering off these boards does not erase the program they were flashed with, so at least you have to make sure nothing is displayed on the LCD.

There are various kinds of VVT control. Rpm based only, rpm and load based, rpm, load, and engine temperature based etc. We decided to use the rpm and load based type of VVT control, but even in this case you can just have a system that just turns on the VVT when both of the signals reach a certain level, independently from each other. We decided to use a map based system, which gives us the option to configure the VVT function for every state of engine operation individually. Actually factory ECU's utilize a number of 2-dimensional and 3-dimensional maps, in order to control fueling, timing, VVT, etc. There is no more efficient way to do it.

A "map" in an ECU is an array of numbers, and in order to define where about we are, we need to have a "X" and "Y" for a 2-dimensional map, or a combination of "X", "Y","Z" for a 3 dimensional map. Even the most sophisticated VVT systems are working efficiently based on just 2-dimensional maps, sometimes with the only limitation of the engine temperature being above a certain level. So we chose to use a 2-dimensional map for our system, since we are using only 2 engine parameters to control the VVT operation.














































































































fig. 10 : Actual configuration of our VVT based on load and engine rpm

We created a 7 by 10 map with 70 cells of course. In each cell we either put a "0" or a "1". That's how we define on and off for our system. "0" stands for off, while "1" stands for on. The way we decide where to set on our system, has to do with engine technology and tuning, however we were able to map our system in accordance with the general VVT principles. This means that out system should turn on the VVT when throttle is pressed hard or/and when engine rpm is high.

After including the header files in our code, we created the map which defines the on/off state of the VVT. Next step was to disable the ETM interface, since we are using the JTAG one. Embedded systems development relies on debuggers talking to chips with JTAG to perform operations like single stepping and break-pointing.

Then we enable the LED's on the ARM board, and define LED P2.0 as the output of our system. In reality the output would drive a relay, which would power on the VVT's phase variator.

We enable the LCD display and configure it to give us the message "Variable Valve Timing Control". More information in unnecessary to be displayed. Now at least we get to know that the ARM board is flashed and running our code.

We initialize one of the CAN interfaces of the ARM board and set it to the same speed as the PCan board. We don't need a second CAN interface in our application, but we do need the same settings on all CAN nodes (ARM board and PCan board) in order for our system to be functional.

After setting the communication between our ARM and PCan board, it's time to define the messages which our ARM board will read from the CAN bus, in order to take the information it needs. Remember that we do need a pair of numbers every time to define the on/off state of the VVT. So we enable the reception of these two specific messages, and we also tell our system the format of the messages and the CAN message id of each message. As we said earlier, message 0x10 provides the system with the engine rpm, and message 0x11 provides the system with the engine load. Now we are ready to start the CAN controller number 1.

The heart of our code is the part where the CAN messages are received. The 16 bit values in the data field of the CAN messages must be converted back to analogue values. Next step is to scale these values in order to range from 0-9 for the load, and from 0-6 for the engine rpm. Remember that we are using a 7x10 table, so signals must be scaled to fit in.

In order to define a position in a 2-dimensional map, we need two values. We need an X and a Y, as we have already mentioned earlier. If you go back to the MicroMod configuration, you will see that the signals for rpm and load are transmitted with a delay of 500 ms between them. They are NOT transmitted in pairs. So in our ARM board we get an "X" and a "Y" with 500 ms delay between them. But we need pairs of "(X,Y)" and not "(Y,X)" in order for our system to work properly, because our map is 7x10 where X values go from 0 to 6 (7 values) and Y values go from 0 to9 (10 values). So we had to make sure that pairs are created in the "(X,Y)" form.

By using flags, we make sure that when an "X" is received, it waits until a "Y" it's received too. When a value for "Y" it's received, we have the "(X,Y)" pair we need in order to find in which area of the rpm/load map our engine is working, and depending on the setting on the specific field, the output turns on or off. Both flags for X and Y are reset to 0, and the system waits for the next signal to be received.

4.3 CAN-bus VIEW

After configuring the PCan board through Micromod to transmit the required CAN messages, there is another program from PEAK-Systems, which enables us to view everything transmitted over the CAN bus. This software is called PCAN-View. We can monitor the CAN message id's and the values transmitted (fig. 11). But they are on hexadecimal format, which is not very practical. Anyway it gives us a first glance of what is going on over out CAN bus.


fig. 11 : Message id's and values of our signals transmitted

4.4 LabView

Because PCAN-View is not very practical in order to monitor the values of our signals mainly, we used LabVIEW in order to do the task. LabVIEW is a graphical programming environment used by engineers to develop sophisticated measurement, test, and control systems using intuitive graphical icons and wires that resemble a flowchart. LabVIEW offers unrivaled integration with thousands of hardware devices and provides hundreds of built-in libraries for advanced analysis and data visualization. The LabVIEW platform is scalable across multiple targets and operating systems, and since its introduction in 1986 has become an industry leader for these tasks. We used it for a rather simple task.

We created a graphical interface in order to monitor the rpm and engine load signal going to the ARM board. It gives much more of a feeling now as an automotive project. In the big gauge on the left we can see an rpm meter, looking very similar to the one a vehicle utilizes on its instrument panel. On the right we can see a small gauge, displaying the engine load.


fig. 12 : LabVIEW Front panel


fig.13 : LabVIEW Block diagram for engine load


fig.14 : LabVIEW Block diagram for engine rpm

Chapter 5

Testing & Improvements

5.1 Introduction

Now with our ARM board flashed with our programming code, the PCan board transmitting the necessary signals, and these two boards connected together using the CAN bus, it's time to test the operation of our VVT controller. We can see that the ARM board is ready because it gives us in the LCD display the "Variable Valve Timing Control" printout. This means it's running our programming code. We vary the rpm and/or the load signal, and we observe if the LED on the ARM board turns on when we are at the operating conditions set by the 2-dimensional map we created. Indeed in the lab, we verified the operation of the controller by checking its function in all 70 cells of the 2-dimensional map. We tested extensively the operation of the board, making sure its operation is not affected by the set point we start from.

5.2 Discussion

We did discover a bug in our software, which is not affecting the operation of the VVT controller. We did expect this to happen, because of the way we scaled the signals to fit in our map. When setting 4 KHZ in our waveform generator, the ARM board is reading 4000 rpm. But because we need to scale rpm in 0-6 columns in the map, we divide by 1001. This takes us to the 3000-3999 rpm region of the map, instead of the 4000-4999 rpm region. So we could get a wrong operation of the controller, someone can argue. But the truth is entirely different. The map for the VVT is tuned after testing the performance of the engine, and is based solely on that, not on rpm and load. The VVT has some delay time when engaged anyway, and does not need to be switched on rpm with round numbers, like 3000 rpm. We won't argue that a higher resolution map would be highly beneficial, and could give a very detailed tuning of the VVT function. Nevertheless, please do not forget that the purpose of this project was to simulate a specific (VVT) function of an internal combustion engine, not to go after the perfect VVT controller in terms of map resolution.

5.3 In Application Programming

Except from higher map resolution and a better way to scale the signals into the map, there is another significant improvement that could be done. Let's assume that we have built the controller, and we are trying to tune the map for the VVT while testing the vehicle in the dynamometer. We will have to compile, build and flash the whole code every time we make changes in the 2-dimensional map. This is somehow inconvenient. What we really need is the option to be able to change the values in the 2-dimensional map, without much fuss. The answer to this is called In Application Programming (IAP).

The NXP LPC2000 series flash microcontrollers provide the user a convenient way to update the flash contents in the field for bug fixes or product updates.

In-Application (IAP) programming is performing erase and write operation on the on-chip flash memory, as directed by the end-user application code. The Flash boot

loader provides the interface for programming the Flash memory. The flash boot loader controls initial operation after reset and also provides the means to accomplish programming of the flash memory. This could be initial programming of a blank device, erasure and re-programming of a previously programmed device, or programming of the Flash memory by the application program in a running system.

Basically with IAP we can change the data in a specific area of RAM memory.

5.4 Alternative uses of the controller

While working on this project, we discovered that it was suitable for other tasks too. Nitrous oxide, and exhaust output control for example. These tasks only require an on/off signal, like the one we get for the VVT function.

Nitrous oxide is used to boost performance in petrol engines, and must be turned on when engine rpm and load is high. Again this must be tuned by a specialist, because many engines were destroyed while nitrous oxide was turned on. Of course nitrous oxide is only for a few drag races, so a manual switch is also needed to make sure it stays off when not needed.

Now let's focus on the control of the exhaust output of an engine. Some companies around the world have developed aftermarket exhausts, which implement a sophisticated butterfly valve mechanism in order to redirect exhaust gas flow and make the sound and the performance of the engine vary between stock muffler and performance muffler equipped. This happens thanks to the recirculation of the exhaust gas flow through the muffler. They are using a manual control system to alter the operation of the butterfly mechanism, so this function is not dynamically adjusted on the engine operating parameters. Our VVT controller is suitable to do the task. It can control the butterfly valve and open or close it based on the rpm and the engine load. That would lead in low noise levels while cruising in the motorway with average engine rpm, and possibly more torque while the engine rpm is low. But it can also free the exhaust gas flow, and give better performance and sound while racing in track-day events. All these as long as the controller is tuned for the application while testing the engines performance in the dynamometer.

Chapter 6

Testing & Improvements


fig.1 : National Instruments Corporation (2010), ECU Designing and Testing using National Instruments Products [online]. Last accessed 10 May 2010 at

fig.2 : Unknown writer (2010), Alfa Romeo 146 Junior Site [online]. Last accessed 10 May at

fig.3 : Richard Banks & Alfaholics Limited (2010) [online]. Last accessed 10 May 2010 at

fig. 4 : Richard Banks & Alfaholics Limited (2010) [online]. Last accessed 10 May 2010 at

fig. 5 : Richard Banks & Alfaholics Limited (2010) [online]. Last accessed 10 May 2010 at

fig. 6 : Keil, an ARM company (2010) [online]. Last accessed 10 May 2010 at

fig. 7 : PEAK-System Technik GmbH (2010) [online]. Last accessed 10 May 2010 at[catUid]=8&tx_commerce_pi1[showUid]=26

fig. 8 : (labs), MicroMod screenshot, rpm signal

fig. 9 : (labs), MicroMod screenshot, load signal

fig. 10: 2-dimensional map, configuring the on/off state of the VVT controller

fig. 11 : (labs), PCAN-View screenshot

fig. 12 : (labs), LabVIEW Front panel screenshot

fig. 13 : (labs), LabVIEW Front panel screenshot

fig. 14 : (labs), LabVIEW Front panel screenshot