THE COMPLETE DESIGN OF AN ENGINE MANAGEMENT SYSTEM FOR RIT S FORMULA SAE TEAM

Transcription

1 Multi-Disciplinary Engineering Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York Project Number: THE COMPLETE DESIGN OF AN ENGINE MANAGEMENT SYSTEM FOR RIT S FORMULA SAE TEAM Brandon Mancini/ Mechanical Engineer Brad Greene/ Electrical Engineer Erich Fiederlein/ Mechanical Engineer Greg Doelger/ Mechanical Engineer Kenvin Tung/ Electrical Engineer Andrew Bloom/ Computer Engineer ABSTRACT The goal of this composition is to outline the design process for an engine management system as proposed by RIT s Formula SAE team. Pre-design objectives will be discussed, such as concept generation and specification selection, as well as the techniques and theory used to complete the design, analysis, build, and delivery of the unit. The overall result of the project, the level at which customer expectations were met, and insight needed for future developments that are necessary to deliver a completely functional system will be given. To further create a better understanding of the project, the three disciplines involved, which include electrical, mechanical, and computer engineering, will have designated sections, which will outline their respective contributions in the forms of hardware design, case design, and graphical interface and embedded program design, respectively. INTRODUCTION The high cost of high performance engine control units creates the desire for an in-house unit. To create this a senior design project is proposed. Sponsored by RIT s formula SAE team, this project is the first phase of several, which is intended to create a base for future senior design projects. With an RIT made engine management system, which is based on MoTeC s M400 ECU, the formula team can significantly cut costs and gain recognition for their uniqueness in design. In addition, the ECU is designed and customized specifically for the RIT formula car, which can allow for greater freedoms in tuning, inputs, outputs, and data collection. The design objectives of the in-house electronic control unit, which will be referred to as an ECU from now on, is to satisfy the aforementioned perks, as well as meet the specific design specifications that were jointly developed between the design team and the sponsor. PRE-DESIGN Prior to designing the ECU, roles for each team member were assigned, customer needs were assessed and design specifications were developed. After these steps were completed, a design schedule was implemented and the team began generating product concepts. Needs Assessment The customer needs that were developed during conversations between the sponsor and the design team are outlined below: The ECU will run the formula car s engine It will do so in an easily tunable manner to reduce tuning times 2007 Rochester Institute of Technology

2 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 2 The ECU will have closed-loop auto-tuning capabilities A graphical user interface with tuning maps will be developed for laptop-capable tuning The ECU will have data logging capabilities and USB plug and play storage abilities The ECU case will be watertight and vibration resistant and will have reliable connectors (preferably the same as the MoTeC M400 ECU) The ECU will have several open I/O for the future addition of features such as wireless telemetry; knock sensing, an integrated display, and traction control. The budget and design will be well documented and updated in frequent intervals, while utilizing existing supplies. Specification Selection From the above needs, design specifications were developed, which included marginal and ideal values. The ideal values were based on the MoTeC ECU quantitatively. Some of these specs include the dimensions and weight of the ECU case, the number of digital, analog, and pulse width modulated inputs and outputs, processor speed, the amounts of RAM and flash memory, maximum RPM, battery transient protection, and several others that can be viewed in the design history file. The marginal values offered a lower limit for the specifications that were acceptable if the ideal values could not be met. Concept Generation Another crucial pre-design step to take, which takes advantage of each team member s input for a design is concept generation. To do this, the team met several times to discuss possible designs for the electrical, mechanical, and software aspects of the ECU project. During these sessions each team member was to brainstorm about different concepts in each discipline. After several concepts were developed, the use of Pugh charts was considered for assigning popularity, feasibility, and overall effectiveness. Electrical Concepts The electrical aspect of the project includes circuit board design, hardware selection, and interface determination. The different concepts, which were decided upon were: which type of oxygen controller to use, what power supply to design, microcontroller selection, data logging types, input filtering, pc interface, and vehicle interface. For each of these categories there were at least three different options available. The ultimate selections for each of the mentioned subsystems were: to have an onboard oxygen controller that utilizes a digital and analog loop, to use a DC-DC discrete power supply, to use a microcontroller with on-chip flash and a multiplexed ADC, to have on-chip flash for data logging, hardware and software input filtering, an RS232 pc interface that can be changed to USB with an adapter, and to use the same connector as the MoTeC system to interface the hardware and software with the vehicle. The details of the electrical systems and hardware will be discussed later in the electrical design section. Mechanical Concepts The initial concepts for the mechanical aspect of the project, the case, were to have a case in which the front opened only, a case in which the top opened only, or with the top, sides, and back of the case being one piece. The selected design was to have the case with the top, sides and back one piece to make assembly, vibration dampening, and heat dissipation easier feats. After starting the design of the case and reviewing more options, a totally different design was chosen, which is outlined in the mechanical design section of this paper. Embedded and GUI Application Concepts To ensure proper engine operation and communications between sensors and the hardware, a carefully implemented embedded program is necessary. The development of the program involves using IAR Embedded Workbench, which is the application used to develop the C code that is run in the microcontroller. The C based program is responsible for controlling the entire system, providing fuel and timing values based on the readings from the various sensors attached to the engine. This was a quick decision to make and there was little to no concept generation involved since the basic principles behind running an engine are virtually standard. In addition, an easy to use graphical user interface must be created in order to let the user tune the engine from a pc or laptop as demanded by the sponsor. The different platforms that were proposed during this portion of concept development were to use C/C++, Java, or Ruby for creating the GUI. The decision to use Ruby was made because of its customizability, updatability, high speed of development, and crossplatform abilities. These characteristics show to be better when using Ruby, which will allow future design teams to make edits quicker and easier. ELECTRICAL DESIGN The electrical design was initiated by the completion of a top level block diagram. This served to outline the overall inputs and outputs of the system as well as define the individual blocks that would make up the entire system. Once the number of inputs and outputs needed was determined, the amount of memory required to store the microcontroller run-code and data tables was computed. Based on these specifications Paper Number 07222

3 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 3 with the additional specification of processing speed, the TI TMS470 microcontroller was selected. The next step in the design of the ECU was to research the functionality of the individual blocks of the controller. These included: O2 controller, analog input conditioning, temperature sensor interface, injector drivers, power supply and hall sensor inputs (cam and crank position sensors). Once an understanding of how these circuits would function was established, time was spent completing circuit design and simulation. Once verified, these designs were rolled into a schematic and eventually a complete PCB (printed circuit board) layout was created. 02 Controller The primary resource used to provide information regarding the design of the 02 controller was Tech Edge. Tech Edge provides a great deal of information regarding how 02 controllers function on their website ( In addition they also supply detailed datasheets, which are not readily available from Bosch. Tech Edge manufactures and sells inexpensive 02 controller solutions to the general public. Included in their product line are DIY kits that include un-assembled circuit boards and parts. Wideband 02 controllers function by using 2 different control loops. One loop is responsible for monitoring the sensor s temperature and supplying power to a heater element to achieve a constant operating temperature. It is important to regulate a constant temperature to ensure accurate sensing. The temperature of the sensor is determined by monitoring an AC coupled waveform with a frequency of 4 khz. When the internal resistance of the oxygen sensor cell reaches 80 ohms the sensor has reached its ideal operating temperature. The resistance of the cell is found with analog circuitry that supplies an analog voltage proportional to the cell resistance to the onboard A/D converter of the TMS470 microcontroller. The microcontroller monitors this voltage and varies the duty cycle of a PWM signal that the controller supplies to the heater element. An important function the controller also provides is limiting the speed at which the sensor is heated. If it is heated too rapidly the ceramic core of the sensor can be cracked. The other control loop supplies current to a gas pumping cell on the sensor. At a stoichiometric air/fuel mixture of 14.7:1, the 02 sensor outputs 0.45V, but the voltage increases or decreases rapidly with small deviations from this ideal mixture, making the accurate measurement of non-stoichiometric air/fuel ratios very difficult. The wideband 02 sensor overcomes this through the use of a pumping cell, which serves to increase or decrease the amount of exhaust gases captured within the measurement cell. A change in the amount of exhaust gases in the cell alters the overall amount of oxygen detected. This means that by applying a positive or negative current to the pumping cell, the measured 02 level can be changed. A control loop is used to maintain an output voltage of 0.45V. The actual air/fuel ratio can then be determined by monitoring how much current is being supplied to the pumping cell. Figure 1: 02 cell voltage as a function of AFR Figure 2: Pumping current as a function of AFR To ensure the proper operation of the 02 controller extensive simulations were performed. However, there was difficulty in accurately modeling the sensor at this time in the design, so additional changes may be needed to have the controller work to its fullest potential. Analog Inputs Analog inputs for the ECU include sensors such as the manifold absolute pressure sensor and the throttle position sensor. All sensors on the car operate off of a 5V supply rail, so the input range needs to accept a 5V swing and translate it to a 3.3V swing to be accepted by the analog to digital converter. The input filters also serve to slow down the input signal and filter out any noise. A simple 2 nd order op-amp filter is implemented with a corner frequency of 1 khz to achieve this goal. The output of these filters is sent directly to the on chip ADC of the microcontroller and is used to determine fueling and timing parameters. Temperature Sensor Interface Temperature sensors are utilized on the FSAE car to monitor intake air temperature and water temperature. These sensors use a NTC thermistor, which means that as the temperature of the sensor increases, the Copyright 2007 by Rochester Institute of Technology

4 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 4 resistance decreases. The temperature sensors on the car are measured with a single stage op-amp circuit, which serves to supply voltage to the sensor in order to determine its resistance and to filter the resulting voltage, much like in the case of the analog sensor inputs. The output voltages of this circuit are fed to the microcontroller ADC. Injector Drivers Two common types of injector drivers exist: peak and hold, and saturated. Saturated injectors have higher impedance and are operated by supplying a constant voltage for the duration of the time the injector is to be opened. Peak and hold injectors typically require a current spike of 4A to open the injectors and then a constant current of 1A to keep the injector open for the remainder of the injection cycle. Fortunately, both injector types can be controlled by identical circuitry, which eliminates the need for separate drivers for the two types. The driver functions by providing maximum voltage to the injector and sensing when the current reaches 4A. At this point the current is reduced to 1A and held there by control circuitry that modulates the voltage supplied to the injector. In the case of the saturated injector, the higher impedance prevents the injector from ever reaching the 4A threshold and the driver never enters the 1A current holding mode. The injector driver is controlled by the National Semiconductor driver IC part number LT1949. Power Supply Many different voltage rails are required to operate the ECU. A 1.9V supply is needed to power the core of the microcontroller, while 3.3V is required for the I/O of the controller. All sensors on the car operate off of 5V with the exception of the hall sensors that utilize 8V. A power analysis was conducted to estimate the amount of current needed on each line. Since the voltage to the power rails is being produced from the car s battery and alternator, they must be created off of a 12 to 14V rail. For this reason DC-DC power converters were employed to minimize the amount of current drawn by the ECU and the power dissipated by the converters. The exception is that a linear regulator was employed for the 3.3V rail, since it is only a slight drop from 5V and the rail draws little current. DC-DC For the DC-DC, a component from Linear Technology was chosen because of its wide input range, ability to handle the 200mA loads that were determined through the aforementioned power analysis, and its having a simulator available specifically for the component. The LTC1778 was chosen because of its flexibility and its ability to accomplish what is needed. For this component, Linear Technology provides a typical application configuration of external components to drive the DC-DC and the configuration is kept for our design. For this design, there are only a few components that require change to fit our application. The on resistance for the IC is calculated to determine when the DC-DC will have the proper output voltage available at the output node of the IC. This is the pin labeled Ion in figure 3. Figure 3: Schematic for Linear Technology s simulator. The equation to calculate the proper on resistance value can be seen in equation (1). A switching frequency of 400 khz was chosen to reduce the inductor size. The drawback is that at this high frequency, there is much more dynamic power loss, thus, driving the efficiency down. This drawback is justified through the idea that the larger the inductor, the larger the physical space required for the inductor on the PC board. For this equation, the output voltage for the DC-DC is designed for, 8V, 5V or 1.9V. The Von is defaulted to a value of 0.7V. With this information, values for Ron are calculated. f V ON V R ON ( ) [ Hz] 10pF OUT = (1) In addition, to maintain the output voltage that is desired, the FB pin is required for this design. The FB pin must maintain approximately 0.8V. This is created by a voltage divider through two series resistances, where the voltage is sourced from the output voltage and is referenced to ground. Resistance values are chosen to maintain the 0.8V across the second resistor as seen in figure 3. Lastly, the inductor must be chosen. This is done by using equation (2). For this equation, the maximum ripple current is designed for 40% when the input voltage is at its maximum. = f I V ripple,max I out,max V 1 Vin out out L (2),max Paper Number 07222

5 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 5 Hall Sensor Inputs The hall sensors operate off of an 8V supply and produce an inverted pulse that occurs each time a magnet passes by the surface of the sensors. To minimize errors, the interface circuitry in the ECU utilizes comparators with an adjustable threshold. When the input voltage from the sensors steps below a desired voltage a transition in the output of the comparators occurs sending a digital pulse to the microcontroller. MECHANICAL DESIGN In designing an ECU, an enclosure that dissipates heat away from the pc board, isolates the hardware from harsh vibrations, is lightweight, watertight, and compact, and that integrates reliable connectors is crucial to ensure the longevity of the ECU. As mentioned in the concept generations section of this work, there were three different case designs that were formulated at first, to which the top-sides-back are one piece was the main one that was selected. After further consideration for connector incorporation and the manufacturing processes that are involved in machining a case, a new design was created. This time the case design resulted in what can be seen below in figures 4 and 5. Figure 4: The ECU Enclosure Design- Exploded Figure 5: The ECU Enclosure- Assembly Case Construction The case will be machined out of 2024 Aluminum. To reduce material costs and manufacturing time, sheet metal will be used. The sheet metal aluminum will allow for good heat transfer, excellent machinability, and light overall weight characteristics for the case. Tabs will be added to the bottom of the case to allow for mounting capabilities using M4 bolts. Other mounting possibilities would be to add industrial strength Velcro to the bottom of the case, which would allow for greater vibration isolation and more mounting location possibilities. The case also has fins located on the top, which allow for 45 watts of heat dissipation from the electronics that will be mounted on the underside of the top. The 45 watts was determined to be the maximum about of heat generated by the electronics in a worst case scenario. This heat would mostly be generated by the injector drivers if there was a constant-on condition that ran the injectors at full power. A thermally conductive pad will act as a barrier between the case and the pc board to prevent vibration transfer to the board, but allow a contact surface for heat transfer. Connector To meet customer needs and give an added hot-swap capability of the ECU with the currently used MoTeC M400 ECU, the design team decided to use the same connector as the MoTeC system. The connector is a super sealing connector produced by Tyco Electronics that integrates smoothly with the new case design and the pc board, allows for the same number of connections as the MoTeC ECU, and provides a robust and waterproof connection between the pc board and the vehicle s systems. Vibration Isolation The dynamics of the formula car s engine, which is hard mounted to the vehicle s chassis exhibits a various range of vibrations that could damage the hardware of the ECU. To aid in the prevention of such damage, the design team had to first sample the vibrations from the car and search for proper vibration isolators. To sample these vibrations, a test was performed, which involved taking a 3-axis accelerometer and mounting is on the chassis, near the engine. This location was assumed to be the best area to sample from since there was little vibration dissipation from the chassis. From here, the engine was started and data was recorded at intervals of 3000 RPM of the engine up to a maximum value of RPM. From the results, we were able to select Geltech Gel Bush type isolators for isolating the board. The bushings mount in the board and offer a cushion between the mounting screws that are used to mount the board to the case. These isolators not only provide vibration isolation, but they also provide some level of shock absorption Copyright 2007 by Rochester Institute of Technology

6 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 6 to protect against dropping the case and harsh road conditions. Waterproofing To ensure that the case is water tight, the team opted to use RTV sealant along the edges of the case. In addition, the connector provides excellent waterproofing characteristics. The decision to use RTV sealant was reached when it was decided that the case would not be opened and the low cost of the material was observed. Case Analysis As a part of determining the size of the fins needed to dissipate 45 watts of heat, an ANSYS analysis was used to simulate the scenario. Figure 6 shows the analysis and the results. Figure 6: Case Analysis using ANSYS The simulation for heat transfer was conducted assuming no forced convection, an ambient starting temperature of 120 F, and a maximum allowable temperature of 85 C, which is limited by the hardware. EMBEDDED APPLICATION DESIGN The embedded application is responsible for controlling fueling and ignition pulses, as well as the recording of sensor data and updating of the static tables. The precision and accuracy of this application is crucial to the completion of the project. Each of the three areas of the application require careful planning to make sure that not only do they work properly, but they all work together without interfering with each other or running too slowly and missing deadlines. HET The running of the engine utilizes the TMS470's HET (High Efficiency Timer) to try to guarantee the completion of every deadline. In terms of software, the HET listens for the cam trigger (Hall Effect Sensor) to start a loop. This loop waits to catch a pulse from the crank trigger. The time between these pulses is used to calculate the RPM of the engine. This value is passed back to the TMS470 through shared memory. The RPM along with the MAP sensor (sampled by the ADC) are used to determine the location in the static tables for fuel and ignition values. The values for output are placed in shared memory and a ready bit is toggled, which signals the HET to output them starting on the next pulse of the cam trigger. In mechanical and electrical terms, the HET generates edge triggered interrupts to determine the start of the engine cycle. As mentioned before, the HET is used for the crank position sensor, the cam angle sensor and the four fuel injectors. It is known that an engine has 720 of operation. Within this 720 of operation, the cam angle sensor produces a pulse when at 0 indicating the start of the intake cycle for cylinder one. The HET is used to capture the start of the intake cycle and then used to capture the period of a pulse that is output by the crank position sensor. This period is relative to the RPM of the engine and then is used to calculate the duration of the fuel injector pulse. This injector pulse is then stored into the HET and awaits the proper angle of the camshaft to output the pulse. UART Portions of this system are required to run in real time. The pulsing of the fuel injectors and the distributor has to be perfect or the system is unusable. The data logging and the static table (fuel, ignition, and correction) modifications are important to the system but not crucial to running the engine. These features can be sectioned off as UART (Universal Asynchronous Receiver/Transmitter) or communication. The communication portion of the application will only be used when the engine is off. While the engine is running, it takes the highest priority. The UART portion of the application uses one of the SCI (Serial Communication Interface) ports present in the TMS470, which is connected to an RS232 to USB adapter. The serial driver allows for both a console interface designed for development and debugging purposes, as well as a simple stripped down protocol for communication with the GUI application, which is used for tuning. The section responsible for interfacing with the tuning application has three basic features: reading data from the stored sensor logs, reading the static tables, and updating the static tables. Communications take place at a speed of bps (bits per second), uses 8 bits, no parity, and 1 stop bit. In the console mode, (for debugging purposes) commands in the code can print data out allowing output and message passing. When connected with the tuning application running on a personal computer the application waits to receive one of three commands: data_dump - sends packets of data representing each 100ms sample over the SCI port. Paper Number 07222

7 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 7 table_read <table id #> - returns packets in the format of [row, col, value]. table_update <table id #> <row> <col> <value> - updates the cell at the location specified in the table selected table with a new value. GUI APPLICATION The GUI application is an important aspect of this project. Once the hardware and embedded application have been proven to work and be stable the Formula SAE team will need an easy way to tune their car. Tuning an internal combustion engine is complicated and involved. Because of this the design of the GUI application was setup to allow for easy updates and modifications by other Senior Project teams in the future. The application is written in Ruby using wxruby, a wrapper for the C based wxwidgets library along with Ruby-Serial Port, which lets the application run the same on Windows, Linux or Mac OS X, an important feature in an academic environment. Ruby was chosen as it is a fairly simple language with many features available as add-on libraries which are easy to find and install through the 'gems' system as well as being quick to develop in and with good cross platform support. When tuning a car the main focus is on the fuel and timing maps, with other correction factors and options (rev limiter, boost cut, etc) being tertiary. Because of this the application uses a tab structure with three main views, fuel map, timing map and extras. The fuel and timing maps look very similar and are just data grids similar to what one would find in a small Excel spread sheet. The final tab contains other smaller grids for correction factors as well as input fields for extra features. To keep structure and order in the application an MVC structure was developed. Due to the simplicity of this revision of the application (both GUI and Embedded) the only model is the Rom. The views contain nothing more than wxruby calls to create and display the various GUI elements. Functionality is pushed into the controller when it is unrelated to the Rom itself. TESTING Electrical The electrical testing is performed by individually testing each circuit, then by integrating the circuits and doing more exhaustive system testing. voltage levels and ripples are verified, the rest of the circuitry can be connected to the power rails so that the rest of the ECU testing can be completed. The supplies will also be checked for responses to variations in load and input voltage. Sensor Interface Testing The preliminary tests will be performed using a simulated sensor input/output like a signal generator or a variable resistor. Once it is determined that it is safe to use the actual sensor in the circuit without damage occurring, a second round of testing will be performed to guarantee the correct operation of the ECU. If time allows, detailed tables will be constructed of the sensor characteristics to allow accurate correction to be performed on the input voltages seen by the microcontroller. Injector Driver Testing Before connecting the ECU to an injector, the operation of the driver will be verified by applying a load to the circuit that simulates the electrical properties of the injector. By using a dummy load, damage to the injectors can be avoided in the case of faulty circuitry. In addition, the current being sent to the injector will be monitored to ensure that the peak and hold circuitry is operating correctly. Mechanical Testing To ensure the case will actually dissipate 45 watts of heat, physical heat transfer tests are necessary. In addition, vibration tests with the board mounted in the case are necessary and waterproof checks must be performed. Given the time constraints of the project, testing was not completed and is recommended for future design teams to perform. Embedded Application and GUI Testing The embedded application must be tested to make sure it is working properly. The test stand for the application is a development board with the TMS470 microcontroller, created by Texas Instruments. As the code is written, periodic testing on the dev board must be administered to show that each routine works effectively in sections, and then as a whole. To test the GUI, the hardware should be interfaced with the GUI and values for the static tables should be changed and simulated. This will show that changing values will usher changes in the electrical output and changes in the system behavior. This testing must be done carefully and by someone who knows how to adjust fuel and ignition values and how their changes should impact the system. Power Supply Testing The first tests performed will be done to verify the operation of the power supplies. Once the output Copyright 2007 by Rochester Institute of Technology

8 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 8 CONCLUSION AND RECOMMENDATIONS In conclusion, we can say that most of the customer needs were met to the formulated specifications. An excellent base point for future teams was set up, but minimal testing was performed and there is a need for proper systems integration to deliver a complete product. Some of the criterion that was met include: The case dissipates enough heat for worst case scenario, is watertight, integrates vibration isolators to protect internal components, and uses same connector as competitors for easy switching. Also, the overall size of the ECU is slightly bigger than the competition s due to the additional need for heat dissipation surfaces. The GUI and embedded application were written with extensibility in mind to allow for future expandability and has a simple interface to ease tuning and reduce tuning times. The PC board has extra unused I/O for future expandability and the design includes an integrated injector driver circuit and Wideband O2 sensor controller. The ECU is capable of logging and storing 32Kb or 3 minutes of data via an RS232 or USB port as well. To satisfy the needs and specifications that were not met, there are several recommendations for future design teams. To accomplish having closed-loop auto-tuning capability, the embedded program must be further developed and tuned to work properly with the hardware and GUI. Also, it is recommended to explore the current case design more by performing physical vibration, heat transfer, and water tightness tests in order to ensure the proper behaviors. The hardware of the system may need adjustments and calibration for future development and more testing is greatly needed on the circuitry as mentioned in the testing section. Implementation of extra features, such as wireless telemetry and increased data logging capacity requires monetary investment and further development. Continued development and testing of the GUI and embedded code should be focused on to ensure accuracy and functionality as well. To access important information regarding any aspect of this project, the design history file and team website can be accessed as an organized base point to continue development of the in-house ECU for the formula team. ACKNOWLEDGMENTS Our thanks go to the RIT Formula SAE Team and Anthony Capobianco for sponsoring this project. Special thanks go to Dr. Nye, Professor Slack, Chris Deminco, Stephen Mokey, Texas Instruments, Geltech, Linear Technology, Analog Devices, Coilcraft, Freescale Electronics, Tyco, and all others who have helped along the way. REFERENCES [1] Bosch, R., 1999, Gasoline-engine management, Robert Bosch GmbH, Stuttgart, Germany. [2] Bosch, R., 2001, "Technical Customer Information: Planar Wide Band Lambda Sensor," Robert Bosch GmbH, Stuttgart, Germany. [3] "Oxygen Sensors," Service Tech Magazine, May, 2001, pp [4] Tech-Edge, 2007, "How 5-Wire Sensors Work," [5] M400 System Specifications, MoTeC Pty Ltd m400specs.pdf. [6] MoTeC M400/M600/M800/M880 User s Manual MoTeC Pty Ltd, pp [7]Linear Technologies Schematic Screenshot from SWCAD Program simulation. Paper Number 07222