Some 10 years ago, I worked for a UK company that designed and built electronics for a large proportion of the racing world. From Formula Ford to World Rally cars, from go carts to NASCAR cars, their electronics found their way in. They designed things like data loggers, sensors, full car looms, and even the £50,000 steering wheels you used to see in the Ferrari Formula 1 cars. However, the really clever stuff was carried out inside the ECU.
The basics of a car engine are easy to understand: suck in some air, mix a little fuel, add a little spark, and bang! You get a big explosion and lots of smelly gases which you throw out the back before starting over again. For most cars running at high rev’s, this is something like 6,000rpm. However, F1 cars can crank up to 19,000rpm and more. Getting the timing right for the adding of the fuel via the injectors and firing the spark at the right moment is lots of hard work for a standard micro.
You then have to consider the complex maths that have to go into deciding how much fuel to add – it’s not how hard the throttle is open that determine this. You also have to consider air temperature and humidity, as well as consider looking at the exhaust gases and work out how well the engine is currently running. Added to this, F1 will also adjust engine power based on the gear they are in and, believe it or not, the car knows where it is on the track so can decide on different amount of power turn by turn. Oh, and did I forget to say that at the time I was working there, engines had 10 or 12 cylinders and, I was told, that it was possible to tune each cylinder differently to get the most from the engine?
So you may consider that you will need a pretty powerful micro to do all this. Well, yes and no. Yes, you could build a computer with the speed to respond and fire injectors and ignition while monitoring and running maths routines very easily. However, you did not have the room for a full size PC inside a F1 car, let alone be allowed the mass. Our limits were very tight on size and mass so another approach was needed.
The solution comes from combining a mid-sized micro and a single FPGA. FPGAs have moved on a lot in ten years so we would assume these are combined in today’s systems. However, at that time, there was a line between high- and low-speed processing. The Micro was responsible for all the low-speed stuff: reading sensors and looking at feedback from gases or track position. The cars in those days were also allowed to have new ‘Maps’ or look up tables downloaded while the car was whizzing around so the Micro also handled all the communications to the pit line, too.
After the Micro had spent some time considering all this, it would then load the FPGA with running data. The FPGA was gears in the electronics that kept the engining turning. This block of logic would monitor the crank shaft and know exactly the position of each piston as well as rotation speed. It would then use timing data supplied by the micro to carefully and with pin point accuracy open and deliver fuel and then fire the spark at the optimal point. The FPGA would not know what gear it was in – its role was all about timing.
In all, the Micro and FPGA were able to calculate and deliver timing way beyond what a single Micro or FPGA could do alone. Today, Micros and FPGAs are much more powerful but also expensive. I’ve read that a micro like in the Arduino will use around 200k gates. When considering price and performance, I think I would still use a small $1 micro and smaller FPGA and balance the load between them.
Working inside F1 and other racing development was very interesting. An experience where cost is no object allowed me to see some very interesting methods and approaches to electronics. I’m interested to hear what extreme environments you have worked in where the normal rules of design push developments in new directions.