It’s been over a year since I first started building my car computer with the Raspberry Pi. In the time since, it’s traveled over 15000km through four Australian states. The majority of the distance has been on dirt roads and tracks, pushing the hardware to its limits.
As a whole the car computer has performed great, but after time on the road. There are some changes and fixes that I would make if I was starting again. Along with a rough road map for planned future functionality.

The Raspberry Pi Car Computer has suffered a lot of torment getting shaken violently on rough tracks around the country.
A New Screen
Before we even set off on the trip, I managed to damage the touchscreen! Eventually the computer is going to be mounted permanently in the center console of the car but for ease of patching,testing and development etc it has just been tied up to the grab bar on the passenger side.
Early one morning, when putting it back into the car I, didn’t realise the computer was in a bag that I handled a little roughly and some of the glass on the side of the touchscreen got broken off (pic).
Financial and time limitations before our departure date meant that the screen could not be replaced. In its defense, it still worked for the most part.
Overtime, the touch functionality started to stop working in the lower half of the screen though.
The plan was to live with it and replace the screen when I finally mounted it in the car for good. But, as more time passed, the slightest vibration would have the cursor randomly moving around clicking things.
The random playing, stopping and starting of songs was starting to get to me! The system was becoming unusable so I paid the money and got a brand new Raspberry Pi touchscreen delivered.
The original display was purchased a few days after release, so it had the v1.0 display controller. The new unit has a v1.1 controller board, so the backlight brightness can be controlled from the Raspberry Pi.
Even using “night mode” having the display backlight at full power causes a lot of glare in the cabin at night. So functionality to control the screen brightness will be added to the Car Computer settings pages as soon as possible.
Power Connections
The power coming into the computer travels from a connector to a voltage converter, which then provides power to the USB hub and the Pi. The wire connections are a source of pain, dirt roads in the outback are commonly heavily corrugated from water. Driving across them literally shakes your car apart. Terminal connectors holding the wiring together need periodic tightening, otherwise the car computer randomly turns off and on as the wires gets shaken around.
It’s not going to be an issue for a car that never leaves tar roads. But if any off road travel is planned, crimp or soldering the wires together as best as you can or the vibration will play havoc with the system.
Hard Drive
Setting out, I thought car vibration may cause issues with a normal 3.5 inch notebook hard drive. But due to the cost of larger solid state hard drives I decided to risk it anyhow.
So I am glad to say, the hard drive has up till this point, no issues whatsoever. If money was no object, I would choose an SSD, given the lower power consumption. But the notebook drive has performed well enough and given the 1TB storage size offers, a huge amount of storage for little cost.
Connectivity
Originally a Huawei K3715 3G Dongle was used for Internet connectivity on the road. But in the days of 4G mobile networks it was slow, reception was never great and seemed to also draw a lot of power.
So I purchased a Telstra Branded ZTE MF823 4G LTE dongle for $39 from an Australia Post outlet. It has sockets for two external antennas allowing me to use an Axis CLR8 7-9db external 4G antenna mounted on the bull bar for improved network reception.
Another added benefit from the upgrade was system simplification. Originally I was using the sakis3g script to control the mobile network connection. The ZTE MF823 has a different architecture though, rather than being a standard mobile dongle. It also houses a small embedded Linux system that appears on the host system as a standard ethernet adapter. The embedded system manages the connection so the sakis3g script is no longer needed.
UI Design
The layout of a user interface hugely important to the usability application but for the most part it’s not something that most of us think that much about. Most of the changes to the system while on the road have been changes to the layout of the application to try and minimise the amount of input required from the user.
A perfect example is commit 8700293, automatically starting the playback of a play list when loaded, if music is not already playing. Before this change, a user would have to select the play list they wanted, navigate back to the homepage and then select the “Play Queue” option from the main menu. It’s only two more taps, which may not seem like a great deal but when off road the car is jumping around on an unstable and unpredictable surface, so aiming and landing a tap in the right area of the screen can be an extremely frustrating pain in the arse.
So the new approach to the code base is going to be ‘interaction minimisation’. Anything music related that can be handled with less input from the user, is going to simplified as far as it can. Most of the time in the car you just want some music; it’s not something I want to get frustrated at, because I cannot get something working while bouncing around.
Future Direction
- The trip meter and trip mapping functions still suck. This functionality in theory should be easy: collect some data points, calculate the distance between then and plot the data on to a map. In the real world, it’s not so cut and dry though. Extensive road testing has at least given me more trip data and I am to use this to sort out the bugs that seem to keep popping up in this part of the application.
- Backlight brightness control: as mentioned earlier in the post, the official 7inch Raspberry Pi touchscreen v1.1 and above allows the user to control the display brightness. This will be controllable from the settings screen and will help reduce glare in the cab at night.
- A down loadable image file, building the system from scratch is all well and good but its time consuming. Over the next couple of months, I am going to try to create a small (few gigabytes tops) image file that can be written on to a SD Card, and the put into a Raspberry Pi to get a user up and running as quickly as possible.
- Longer term, the application has been built using Ionic Framework 1.x which has now been deprecated. So I need to investigate the work required to bring the application up to date with the latest releases.
Further Reading
- The original post on building a Raspberry Pi car computer.
- Upgrading the car computer from the Raspberry Pi 2 to the newer Raspberry Pi 3.
- The application codebase on github.
- Raspberry Pi Car Computer project page on Hackster.io
This is really great work and I look forward to your downloadable image file.
Thanks for keeping this updated mate. I’ve recently started looking at (a lot of) in-car computers for exactly the functions you’ve built into yours. It’s great to see you’ve laid it out so well and are devoted to a streamlined UI. I’ve just ordered a pi 3 (my third) and 7″ screen to start playing around with this. Like you I’m looking at trying to add OBD data, but to be honest I don’t know if it’ll really do anything beneficial for my ’01 Hilux. I’d prefer to tether the system to my phone for data too, instead of having to pay for a separate account for the dongle (pre-paid I assume?). Telstra make enough money without me needing to throw more at them.
Thanks Craig its a work in progress. You add in new features that you think are going to be great, then after some “in car” testing you find it doesn’t work as well as you had hoped.
A 2001 Hilux will be in the same boat as me. I don’t think the Hilux in Australia got an actual compliant OBD2 connector until 2007 or similar. It was MOBD in the models before that 🙁
Tethering is a great idea if you have the data it would help simplify things. It would allow you to cut out the DHCP server, the routing, wireless AP configuration and the dongle. Then you can just set the Pi to connect to the phone for data via the Wifi adaptor when the phone is available.
Hiya, I forgot to ask, how did you handle shutting the pi down properly so the sd card didn’t become corrupted? Or did you just not have a problem with it at all?
Hi Craig, Originally I looked at using a Pi UPS unit to allow for a graceful shutdown. The GPIO port was occupied by the GPS hat in the end so had no way to connect it.
The Pi is just cutting out when the ignition is turned off. I saved an image of the SD card to my laptop in case of corruption. So I could easily just re-image the card but so far no problems have arisen on either the SD card or the media hard drive.
Hello,
Thanks for all informations sharing. Just for your information, i tried to use the nomadic Pi downloading version in your website ( https://www.nomadicpi.com/download.php ) but there is an end kernal panic on booting (syncing: no working init found )
Nathan
Hi Nathan,
Thank you for sharing your issue. I took a look at this thread on stackoverflow here and it seems to point to SD card corruption. So I would try to run fsck against the filesytem, or rewrite the image to the card if you still have it handy.
That said if you have a fast Internet connection it may be worth downloading a new image file. I have since released a v1.1 of the image that allows you to exit the interface and use programs like navit for turn by turn navigation in the car.
Cheers
Anthony
Hi Anthony,
Thanks for sharing, version v1.1 is working well. I will customize everything tonight!
Awesome great to hear!