The idea of the carputer was born in the late 90s and early 2000s as a way for geeks to get the large MP3 collections they had downloaded into their automobiles. Of course once people had added computers to their cars the question was “what else can I do with this?”. A lot of people added things like GPS functionality and Bluetooth, giving them the technological sophistication of a modern automobile long before it was commonly available.
One thing that seemed to get brought up time and time again on forum after forum was the idea of hooking into the OBD system to get detailed information and read the trouble codes of the engine from the carputer. However this rarely seems to get implemented in any carputer system. After a chat with my old friend Qain during a recent trip to Berlin (who is currently working on a carputer project) it dawned on me why this is: developing the appropriate software is difficult because there is no way to test it easily. In order to do a full end to end test of reading the sensor data you would need to take your whole setup out to your car and work on it there. Worse yet, if you wanted to simulate the trouble codes you would need to deliberately break your car in order to generate them.
So, what is needed is a box a OBD reader can be plugged into and will generate appropriate sensor values and error codes. One where those values can be changed on the fly from a computer, and can also send back trouble codes. Such things are available, but are much too expensive for all but the most hardcore hobbyist. So this is exactly what I have built, and OBD simulator that can be put together for less than US$20 (probably less than US$7 if you try). It can be controlled from a PC to manipulate the error codes it presents and the values it returns and I’ll use it to retrofit the ability to use a USB-based OBD reader to an open source Android app that only supports the bluetooth versions of such devices.
Developing the hardware.
Initially I started out with just the CAN bus shield from seeedstudio. I put this on an arduino uno, loaded a small script that would return ‘0’ for any value requested over the CAN bus and hooked up my USB reader. Then I fired up some OBD software and……. Nothing. No connection. I checked all of the connections, and it all seemed fine. Then I remembered something.
- There was also a bluetooth version of the OBD reader I was using.
- The BT version would have to be powered from the CAN Conector, not from the USB.
- Because hardware development is expensive, my USB cable probably shares most of its design with the BT version.
So, I tried adding 12V between pins
Next, I decided that I would convert this to a version that used an arduino pro micro and this smaller CAN board. The connection between the CAN board and the arduino was exactly the same as if I was using a regular arduino. In order to make it a bit more robust I put it in a project box and made the USB connection more robust by using a big chunky USB-A connector. I also had to short the jumper on the CAN board so that the connection was terminated properly.
The diagram below shows everything you need to build your own one of these. If you have a spare arduino lying around you can avoid this and just get the Seed Studio can Bus Sheild and connect the CAN high and low to pins 6 and 14 respectively, and 12 V between pins 16(+) and 4 and 5(-).
The simulator software
To begin I started by writing an arduino sketch that just output in incoming messages on the CAN bus via the serial output. I then hooked my OBD simulator up to and OBD cable and ran sent some commands to the simulator to see what they looked like. Using this information and the documentation on wikipedia I was able to simulate most diagnostic data as well as the ability to send error codes. I even put in the ability to clear the error codes if the simulator received the appropriate message. The only thing that was a little unexpected was the fact that the way that the error codes are sent back works a little differently to that it is described on wikipedia. The main differences were that it seems that you don’t actually send the full length of all the error codes in the first frame, and when sending the latter frames codes can not be split up over multiple frames.
Once I had some software to run on the arduino I modified it to accept simple commands over serial to manipulate the values it returns and add error codes to the list of error codes returned when requested. I then wrote a small python script that would be able to send these commands. From here I had all I needed for the next step.
Converting the Bluetooth app to use serial
Because the bluetooth versions of ELM327 devices look like serial devices as well this was rather quite simple: The first step was to add in the ability to choose a USB device instead of a bluetooth device. Then, because input and output to seach device is just an input and output stream, all I needed to do was to put the bluetooth device between an interface and then implement the same interface using a USB serial device. One thing that helped greatly in this was to connect my android tablet that I was doing my testing on to Android Studios via WiFi rather than USB. This way I did not need to unplug the OBD cable ever time I wanted to update the app.
Where to go next
Right now all of the diagnostics data are stored in a single byte, which is obviously wrong, and will need to be rectified before this is really complete. I will of course get that done before sending this off to Qain but apart from that I think I’m pretty much done with this one. As usual I would like to minatureise this, with an ATtiny but I never get around to doing that part of these projects.
The more interesting question is that now this is built what software can get built with it. For that you'll have to stay tuned.