How do you fit an Audi A4 on a developer's desk? [Part 1]
Here at Silvercar we created custom hardware and software that interacts with an Audi A4 to revolutionize the way people rent cars at the airport. Writing code that interacts with a full size four door sedan comes with some logistical challenges. Sometimes our developers need to be physically near a car to work on our applications that talk to the car.
In Austin, our headquarters are located on the second floor of a 139 year old building. There is absolutely no way we could get an A4 in the office. We also have a manufacturing partner who needs to test hardware on a car and contractors that do dev work in different parts of the country. Giving an A4 to all of these people, even temporarily, just isn't practical.
Part of my job is reverse engineering the CAN bus messages in the A4 to figure out how to talk to the car. A CAN bus is a communication network inside of nearly all modern vehicles. The data that is transmitted on these in-vehicle networks is formatted differently for each vehicle manufacturer and is kept secret. Silvercar’s custom hardware interacts with the CAN bus in the A4 to gather information like fuel level, mileage, etc and it also performs actions like lock, unlock and opening the trunk. After spending several months learning how the CAN bus works in the A4, and spending my spare time at home learning more about electronics I realized I could probably build an Audi A4 CAN bus simulator that would replicate enough of the functionality of the A4 to test our hardware and software. And make it small enough to fit on a developers desk. So that’s what I set out to do.
The prototype
For the brains of the project I chose the Arduino Mega 2560. My microcontroller experience is mainly with Arduino boards and the Mega has a bunch of I/O that I would need to simulate various functions of the A4.
For CAN bus communication I decided on the Seeed Studio CAN-BUS Shield.
The first version of the code just broadcast a few basic CAN bus messages to test communication between our Silvercar hardware and the Arduino board, but I immediately I ran into an issue. Nothing was working. No messages were flowing on my benchtop CAN bus. After spending some time watching the the bus on an oscilloscope I realized there was something electrically wrong with the CAN bus between the boards. After a lot of banging my head against the wall and pulling my hair out I finally figured out that the termination resistor on the Seeed CAN-BUS shield was the wrong value. Most CAN networks use 120 ohm resistors at each end of the bus. For some reason Seeed put a 60 ohm resistor on their shield. Having different resistor values at each end of the bus was causing all sorts of wackiness. When I removed the surface mount resistor from the Seeed shield and placed an axial lead 120 ohm resistor across the screw terminals everything started working correctly. I believe Seeed has fixed the resistor value on the 1.2 version of their shield. With that issue figured out I was able to start making some real progress on the prototype.
I built the prototype using a couple of breadboards mounted to a spare piece of plexiglass I had in the garage. I connected everything together with jumper wires or lengths of solid core wire. The pots were mounted to the plexi with double sided tape. It’s not pretty but it worked. Even in this form it is much more portable than a 1.67 metric ton sedan!
I started adding features to the CAN bus simulator to replicate all of the items our hardware needs to interact with in the A4: Locks, Windows, Ignition status, etc. I added potentiometers so we could adjust the fuel level and battery voltage. Adjusting these pots causes the data in the CAN bus messages to change which is then read by Silvercar’s hardware. When Silvercar first started I had to drive up and down the highway to burn off fuel to do this same testing. Now I can just twist a knob and set the fuel level anywhere from zero to ninety-nine liters. I added a small toggle switch to simulate turning the ignition off and on and I connected up a 20x4 character LCD screen to visualize the status of the functions.
I showed the prototype to our manufacturing partner and he wanted one ASAP for testing our hardware after it came off the manufacturing line. Our firmware contractor also wanted one ASAP. I had to get busy figuring out how to make this more permanent and mount it all in a box. Part two of this series will cover that.
