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.
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.
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.
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.
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.
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.
- 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.
- 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