Much of our IT work at Shine Technologies deals with fairly dry commercial concepts like page views, web clicks and conversion rates. In this post I’ll describe a personal IT project I undertook with a more tangible “real world” application: adapting a modern car’s electronics to work in a replica of a 1950’s sportscar. I hope that, in doing so, I’ll encourage you to consider playing with microcontrollers and interfacing to the real world too.
Background: Why even play with computers outside of work?
In short, I built a replica of a Lotus Seven. Here’s what the original looked like, along with it’s creator Colin Chapman in 1957:
For my replica to be registered, it had to pass a current emissions tests (since it’s actually a “new” car). This meant using a recent engine. To supply the engine, I bought a smashed Ford Focus.
Like most modern cars, the Focus is full of computerised modules, many of which are linked to the engine. The Seven is much simpler in comparison:
Amongst other things, you can see that the Seven has:
- No Anti-Lock Braking (ABS). Instead, I choose to rely entirely on what’s between my ears to tell me how to apply the brakes.
- No power steering. Instead, I choose to use my puny arms.
- No windows or doors. Pfft, they’re overrated.
The problem is that, if you don’t actually have an automatic gearbox, ABS, power steering and so on, the engine and instruments won’t run properly. The car will go into limp-home mode, show idiot lights and error messages on the dash, or just not start at all.
My solution? Figure out what the modules were telling each other, then build a replacement computer that fakes the messages.
Figuring it out
Luckily, my daily drive is also a Ford Focus, giving me a working case that I could reverse engineer.
The first step was to build a network analyser. I chose a Microchip PIC microcontroller. At first glance, the PIC chip seems low powered:
- 40Mhz clock rate
- 8-bit arithmetic
- 1536 bytes RAM (Yes, I mean bytes)
However, it makes up for this by being able to talk to the outside world via a number of different interfaces, including:
- Multiple digital I/O pins
- Analog to digital conversion
- Serial port
- Several timers
- CAN (an automotive network standard used on modern cars)
Microchip offer a development environment with a Windows IDE so that you can program the PIC via a USB device. There’s a choice of assembler or C compiler. The IDE can debug even while the PIC chip is in the final circuit. This means I can literally single-step and examine registers while it’s talking to the car. Pretty impressive to me.
After building a simple circuit on a breadboard, followed by weeks of assembly language programming, I had a tool to show me the contents of the car’s messages. On one side it plugged into the car’s diagnostics port, while on the other side it connected to a PC serial port.
Here’s a typical dump of messages on the car’s engine network, which I’ve annotated to indicate what’s what:
The network produces hundreds of these messages each second.
The process of figuring out which component was producing which messages was crude but effective. I’d pull out a component – for example, the power steering pump’s fuse – and record another dump. By comparing the ‘before’ and ‘after’ dumps, I’d see: “Aha! Message ID 0240 has disappeared – so that’s the pump”.
Figuring out how the speedometer works was interesting. Normally, the ABS unit monitors a sensor at each wheel, timing pulses and then performing a calculation to determine individual wheel speed. Next, it averages the four and sends a message along the lines of “We’re doing 100km/h”. The speedo responds by swinging the needle around.
I drove up the road with the Focus plugged into my breadboard, which was in turn plugged into a laptop. I logged all of the messages at 10km/h, 20km/h, 30km/h … then took the dump files home to dissect. It turned out that the network messages have all of the individual wheel speeds as well as the average, all expressed in tens of meters per hour.
Putting it together
Now that I had all of the required data, I built a circuit with two microcontrollers: one for the high speed (engine) CAN bus and one for the low speed (body) CAN bus.
In the absence of an ABS unit, I needed a different way to detect and report speed. Instead, I processed a signal coming in from the Seven’s gearbox, which pulsed as the driveshaft turns. By timing the pulses and doing some maths, the microcontroller was able to determine the speed and send it out as a CAN message.
In this way I was able to account for all of the missing modules; for example, one hundred times a second one of my microcontrollers sends a “I’m the power steering and I’m happy” message using the formats found earlier.
Voila! No more idiot lights. No more error messages. And the speedo works beautifully.
So was it worth it? You bet! Here are some things I learnt along the way:
- Microcontrollers are fun. Being able to both respond to and control the real world is quite satisfying. I had great joy the first time I could swing the speedo needle around to 240km/h with the car stationary in the shed.
- Assembly language is intellectually interesting but crikey the rate of development is low. For my next project (a data logger), I’ve moved up to 1970s technology: C.
- With a new stack, it’s best to design overall first, but develop vertical slices bottom-up. I’ve found this applies to the work I do at Shine as well. For example, building a website I first prove database access, then build server-side logic, then basic presentation, and only then work towards the pretty front end. It’s funny how the same approaches can be applied across very different domains.
Want to learn more?
- The Controller Area Network (CAN) standard for networking within cars is definitely worth learning about.
- The datasheet for the PIC chip contains lots of low-level detail that only hardcore geeks without a life would be interested in. Needless to say I’ve read it many times over.
- Interested in these little cars? If you’re in Melbourne we have a club where you can come along and have a ride.