This project was undertaken as the final project and dissertation for my MSc in Automotive Electronic Engineering. The projected aimed to develop a simple engine control unit for a single cylinder port injected 4-stroke gasoline engine. The ECU has been developed on an Arduino Mega board and the project primarily focuses on the software rather than the electronic interfaces.
I’ve been using the Arduino IDE for some project development recently, and finding that I’m getting very high CPU usage from Java to the point that it’s slowing my machine down, and then Arduino IDE becomes unresponsive. I couldn’t find any info on any of the forums related to this, but from my own research I believe I have found the problem.
It seems that my problem comes after a long time connected to the Serial Monitor and receiving data from the Arduino. It then gets worse and worse until things start getting unresponsive. The solution for me appears to be to basically just close the Serial Monitor, and reopen it. this can sometimes take a long time, and has caused Arduino to become unresponsive before, causing it to crash and restart. However, this appears to have been the only time I have seen this problem online.
Arduino have just announced a bunch of new boards, including one with an on board FPGA chip (plus a SAMD21 Cortex-M0+, plus an ESP32 WiFi and Bluetooth Module). A Field Programmable Gate Array (FPGA) chip is possibly the most impressive piece of electronics going. They are essentially a way of creating entirely custom digital electronic circuits (resistors and transistors) all inside a tiny chip, and completely reprogrammable – genius!
See more about the Arduino Vidor CAN bus support after the break.
I have been busy over the last few weeks with various things, but have now completed most of the practical work on my project and am now at the stage of writing up the report/dissertation. I have successfully managed to achieve closed loop ignition timing control by using the Stellaris Launchpad development board to directly interface with the optical encoder on the engine and the pressure sensor charge amplifier (this replaces the AVL IndiSet 620 in my system).
ECU in black on left, angle of peak pressure and optical encoder interface on right. Connected together via serial
In order to run the engine inside, I had to set up an external exhaust to get the fumes outside. This had been done with a big exhaust manifold attached to a flexi rubber marine exhaust hose, and then poked through a hole in the wall. This was ok operating the engine at idle and under low loads, but the rubber hose would get extremely hot under high load high speed conditions. It then began to melt internally and was causing the whole building to smell of burning rubber.
So one of the aims of my project is to use in-cylinder pressure as a means of providing a measurement of what is going on with the engine, and hence use this to in some way control my ignition and fuelling.
I needed a high speed ADC for sampling in cylinder pressure for my ECU, and settled on trying a few from Texas Instruments. I am using an optical encoder on the engine which provides 720 pulses per revolution . If I took a sample every pulse, then at 6000 RPM (100 Hz) then I would be looking at about 720 * 100 Hz = 72,000 Samples per Second (SPS) or 72kHz ( although I realise now that I could take a sample on each edge, resulting in 1440 samples per revolution, or 144,000 SPS). That’s pretty high speed, considering most ADCs built into microcontrollers take a few microseconds to perform their conversion which results in a sampling rate of perhaps up to 50,000 SPS max for the Arduino for example. DSP chips or higher end micros probably have better performance, but for the sake of learning, I fancied trying to use an external ADC anyway.
Just a quick one on what I’ve been up to the last few days. I now have the engine set up inside so that I don’t have to keep pushing it outside or waiting for the rain to stop. I’ve also set up an optical encoder, in-cylinder pressure sensor, and AVL IndiSet high speed data acquisition unit to capture data on a 0.25 degree crank angle resolution.
More progress made today, I connected up the alternator to the engine to begin testing it under load. This was pretty successful, and the ECU all performed as expected, with only a few tweaks to the PID controller parameters to improve the AFR control. I restricted the range of fuelling down to as restricted as possible to prevent the system setting wildly large or small fuelling amounts under certain conditions. I finally managed to get the PID to maintain the AFR slightly rich within a few percent under steady state conditions.