6 months ago I bought an 80 series Toyota Land Cruiser and the time since has been doing the car up in preparation for a trip around Australia. Since its release the 80 Series Land Cruiser has earned itself a reputation as a dependable and an almost unbeatable machine off road.
But given the advances in automotive technology since the car was first designed. The lack of electronics and creature comforts in the vehicle make it look downright Spartan when compared to one of the latest 200 series Land Cruisers.
So I decided the car needed a technology boost to help bring it up to speed with the modern day. My first step toward bringing the Land Cruiser into the present day were replacing all of the standard factory interior lights with LED’s. But beyond this I had two main requirements:
- The trip around Australia was going to cover a lot of distance ( A lap of Highway 1 is approximately 14,500km ) so a very large supply of music is needed.
- The 35inch mud tires currently on the car make the speedometer read around 10% lower than the actual speed of travel. So in order to avoid unwanted speeding fines along the way I was going to need a more accurate way of determining speed when driving.
The system chosen to fulfill these requirements would have to operate under normal automotive conditions ( 12 volt power, temperature extremes, vibration and significant knocks when off road ). Along with being easy to operate, highly customisable, touch interface and be extensible with normal off the shelf hardware.
Some kind of Android device would probably make it easy to achieve around 90% of what I wanted with minimal fuss. But I was concerned about possible flexibility issues and having an user interface that matched the vision in my head. Around this time the Raspberry Pi foundation released the new 7 inch touch screen display for the Raspberry Pi and I decided I really wanted one! I just needed a project to justify the purchase. So that killed the platform debate, I was going to build a car computer for using the Raspberry Pi 2 and the new touch screen display.
With the hardware decisions out of the way, the operating system part was easy I love Debian so the underlying system was going to use Raspbian. From this point I just needed to figure out how the actual functionality was going to work. I took a look around at the majority of the popular Linux music players but most seemed to be lacking an interface suited to a smaller touch screen environment. I loved the look of Raspyfi but since it is built as a stand alone distribution I had some concerns about extensibility.
I decided in the end to roll my own interface using the Ionic Framework based on AngularJS. With the Music Player Daemon (MPD) handling the music playback functions on the device and GPSD providing location data. In the following article I aim to cover off some of the design decisions I made during the development phase of the project. Along with some steps on getting the auxiliary services up and running in case some one else would like to build one. The code for the front end has been released under an open source license and people are welcome to contribute to the project.
At the time of writing the application front end offers the following features:
- Now playing module on the home page allows a user to resume / pause or stop the music playing via the MPD daemon.
- GPS backed speed and location readout updated every 1000ms. Providing the car’s current speed, heading, altitude and longitude / latitude location.
- Current estimated speed limit for the current location. If the speed limit is being exceeded the colour of the current speed readout will change to Red. This functionality uses the API at Here.com to get the speed limit for the current road given the cars current location but needs Internet connectivity to work properly. By default the update frequency is set to 300 seconds, this can easily be increased if desired but has been intentionally left fairly low to reduce bandwidth usage. The feature is not intended as replacement for watching the posted speed limits on the road since it is not real time. More just a nice to have when turning onto roads in country areas where the speed limit may not be sign posted very frequently.
- The weather forecast for the current location. By default this information is retrieved from the API at Here.com and is cached in a local storage object for an hour.
- Ability to add predefined .m3u play lists to the current play queue.
- Play queue management offering the ability to purge the queue, skip to or remove tracks from the line up.
- Random track playback.
- Ability to browse the MPD file system, adding directories and individual tracks to the play queue.
- Car reference documentation, in this part of the application I have added a collection of workshop manuals and electrical wiring diagrams for my car in PDF format. In case of breakdown having these resources handy ( even more so in remote areas) can be invaluable when trying to diagnose and fix issues.
- Night mode, this switches to a simplified UI display using grey text on a black background with the speed and location data. It was added to help reduce glare in the drivers peripheral vision while driving in a dark cab at night.
- Retrieves related album cover art for music via the Internet and stores locally using a file system cache.
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]Update: With the launch of the new Raspberry Pi 3, I have since upgraded the Pi board on my system. The system is a great deal more responsive and smooth with the faster 64bit ARM CPU. Power consumption was slightly higher than the Raspberry Pi 2 unit but I would highly recommend anyone building the system for themselves to use the new board[/fullwidth]
On my unit the following components were used for the build:
- Raspberry Pi 2 Model B
- SanDisc 32GB Class 10 sdcard
- Official Raspberry Pi Touch display
- Powered 4 port USB hub
- Adafruit Ultimate GPS Hat
- SMA Female to RP-SMA Female Adapter Converter ( for connecting GPS hat to external GPS antenna )
- RP-SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable ( for connecting GPS hat to external GPS antenna )
- GPS Antenna – External Active Antenna – 3-5V 28dB 5 Meter cable
- 1TB Samsung 2.5inch notebook drive
- USB to SATA Cable
- Huawei K3715 3G Dongle
- TP-Link TL-WN821N v3 USB Wifi Dongle
- 12v to 5v 3A voltage converter
- “Make a shelf” metal strips and corners, I brought these from Bunnings a large hardware chain we have in Australia. But you should be able to find something similar in any hardware store.
- Can of Black Wattyl Rust Guard spray paint ( I had it handy )
- Various Phillips head bolts and nuts to hold the metal framework together.
These parts can be substituted if you intend to build your own unit. Some parts such as the 3G and Wifi dongles, I used simply because I had them in the house from other projects. During the development phase of the project I was initially using an un-powered USB hub, but unfortunately the 3G dongle was pulling too much power and disrupting the operation of the other main power hog, the hard drive.
I also used a USB ND-100S GPS dongle from Prolific Technologies in the early stages of development. Before switching to the Adafruit Ultimate GPS hat, mainly due to the limitations experienced when trying to develop the GPS related code inside a building without a clear sky view.
With the Pi on my window sill in a low / medium density area I was only able to pick up 2 satellites the majority of the time. Switching to the Adafruit GPS hat with an active 28db antenna on a cable that could be placed out side instantly increased the average number of visible satellites to 12.
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]NOTE: Be forewarned if you use the Adafruit Ultimate GPS module you will need to solder the wires (pictured) from the display board directly to the ground and 5V rails on the GPS board so the display board can get power without access to the GPIO port. Also beware that the use of an active antenna will increase the units power consumption compared to just using the on board passive antenna.
Not long after piggy backing my Raspberry Pi and the display board to the back of the touchscreen. I came to the realisation the setup was going to need a case of some kind of casing to keep everything together, protect the fragile insides and make mounting in the car a bit easier. I tried attaching a hard drive to the top of a plastic jiffy box with the Raspberry Pi and its associated circuitry contained within. The result was jiffy box got mutilated with holes all over it. Allowing access to the various sockets on the Pi. I also had concerns about heat build up having the circuitry enclosed without a fan or other controlled air flow especially when traveling through the hotter areas of the country.
The touchscreen has 4 outer holes that standard computer screws fit into. I just needed to figure out how to piggy back some sort of improved enclosure on top of that.
My answer came from the local hardware store when I found some metal “make a shelf” brackets. Right angle brackets cost me around $1.50 along with some metal strips for around $3 that can easily bent and snapped with pliers. Both the corners and the metal strips have pre drilled holes at regular intervals. So from there it was just a matter snapping the strips down to the required size. Then bolting them together in a rectangle shape that could screw into the back of the display.
I gave them a quick spray of paint with a can of Black Wattyl Kill Rust to make them look a little more presentable. In some of the photos you may notice a strangle wrinkled pattern on the brackets. This was not intentional after the paint had dried I tried to cover with a spray of clear coat for some extra protection. But the two layers seem to be incompatible, and seconds after applying the clear coat the surface texture would change into a raised wrinkled pattern. In the future I would like to repaint the enclosure of mine again to improve the appearance. I also painted the 2.5 inch notebook hard drive black too, if you are going to paint a hard drive though take care to cover any breather holes on the drive first they don’t get clogged with paint.
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]WARNING: Take care when trying to screw anything into the outer holes on the back of the official Raspberry Pi display. If your screw goes in too deep it will start to push the screen outside of its frame on the opposite side of the display. This has the potential to separate the two parts and leave you with a broken screen. So be sure to pay attention to both sides of the screen when putting together. Using a few washers to stop the screw going in too deep may help save a lot of grief when trying to attach anything to these holes.[/fullwidth]
After getting the basic metal framework bolted together and the basic components mounted I installed Raspbian as the Operating System and the LXDE desktop environment. LXDE was chosen as it contained the best support for the official Raspberry Pi touchscreen at the outset and I didn’t really want to waste time fighting against the hardware.
A 2.5 inch Samsung 1TB drive containing all of the media files is mounted on the file system at /media/usbstick (initial work started with a flash drive) at boot. With pre created music playlists in .m3u format stored on the SD card at /var/lib/mpd/playlists.
After the desktop environment is loaded the Chromium browser starts full screen running in kiosk mode. The web application that provides the UI is set as the browser home page. With the PHP internal web server serving the application from port 8000. The UI part of the application is built using the AngularJS based Ionic Framework. But PHP is used in some back end scripts to parse location data from the GPSD daemon and other remote sources. All the projects PHP dependencies are located in the /www/php folder of the code base. At a minimum the PHP5-Common, PHP5-Cli and PHP5-Curl packages will need to be installed on the system to cover the PHP requirements of the project.
The UI layer of the application uses the MpdJS library to keep informed of events from the MPD server via web sockets. The web socket part of the application is made possible by websockify providing a TCP websocket bridge to MPD. For location data a PHP script is simply polled every 1000 milliseconds to update the $scope data object and AngularJS dutifully trickles the changes on the display.
The UI is also reliant on Chromium ( Chrome is not available for the PI ) as the browser to run properly. It uses the HTML5 file system API for the storage and retrieval of album art. But unfortunately the API has so far failed to gain inclusion in many of the other browsers.
The application can be run easily outside of the Raspberry Pi on a standard desktop using a browser. For most of the system was built without the Pi to speed up development. Just keep in mind if running though a desktop browser the native resolution of the Pi touchscreen is 800×600.
Outside of the main application, data connectivity is provided to the system via 3G data connection. The inclusion of the Wifi dongle allows the system to also act as a wireless access point providing a mobile “in car” hot spot for use by other devices while on the road.
Power is fed from the standard 12v car supply into a 12 to 5 volt converter capable of providing 5 volts at 3 amps. 5 volts x 3 amps allows for a maximum power draw of 15 watts assuming the components limits follow the label.
From here the power flows into a connector where it goes through one set of wires to a micro USB connector plugged into the Raspberry Pi. Another set of wires provides electricity to the powered USB hub.
With my hardware setup I tested current flow during development and found during the boot process total current draw peaked at 870mA on the 12 volt rail. Giving a power consumption of 10.44 watts.
Once the system has finished booting, all the applications loaded and running normally the current draw settled down around 650mA mark. Giving an average power draw of around 7.8 watts.
These numbers will obviously vary depending on the exact hardware used in the build. But I figured it was worth putting some numbers down to give people a ballpark on the systems power requirements in general. Personally I would be curious to run the numbers again with a newer 3G/4G dongle as the Huawei K3715 seems extremely power hungry. Even when just running off the Raspberry PI USB port on its own.
Ionic Framework – Project Github
Core framework the application front end is built using.
ng-elif – Project Github
AngularJS module that extends the ng-if statement to allow the use of if/else arguments in the application templates.
mpd.js – Project Github
angular-imgcache.js – Project Github
AngularJS module that uses HTML5 filesystem API to cache images locally.
angular-growl-2 – Project Github
Brings Growl like notification messages to AngularJS.
websockify – Project Github
Acts as a bridge allowing browser based code to communicate with standard application services.
This section is going to be a bit of a diversion from the rest of the article. I assume that the average person reading this is very technical so I didn’t really think a set by step guide to “Building a Car Computer” would be appropriate. Most people who want to create something similar most likely already have the required skills to clone the project code from github and have a general idea how to use it.
So instead of trying to cover absolutely everything, I am dedicating this section to a partial discussion covering configuration of the operating system, related system tools and underlying dependencies of the system. If you just want a general introduction to the system, how it works and are not in the process of building the system at the moment you can probably just jump forward to read my closing thoughts and future improvement list.
For those that I failed to scare off with my last paragraph, lets continue on!
The front end of the application needs to use Chromium for the album art image cache to work correctly. Unfortunately a package for Chromium is not available from the standard Raspbian APT package repository. But fortunately pre built packages are available to download for the ARM architecture from Launchpad.
wget http://launchpadlibrarian.net/201290259/libgcrypt11_1.5.3-2ubuntu4.2_armhf.deb wget http://launchpadlibrarian.net/228271146/chromium-browser_47.0.2526.73-0ubuntu0.14.04.1.1106_armhf.deb wget http://launchpadlibrarian.net/228271148/chromium-codecs-ffmpeg-extra_47.0.2526.73-0ubuntu0.14.04.1.1106_armhf.deb
The packages for these programs ( especially Chromium ) have fairly quick release cycles. So you may want to check the repositories directly before completing this step to ensure you are installing getting latest packages available. These are:
After downloading the three required packages to the local system. Simply install them with dpkg, then run from the LXDE menu to check that it runs.
dpkg -i http://launchpadlibrarian.net/201290259/libgcrypt11_1.5.3-2ubuntu4.2_armhf.deb dpkg -i http://launchpadlibrarian.net/228271148/chromium-codecs-ffmpeg-extra_47.0.2526.73-0ubuntu0.14.04.1.1106_armhf.deb dpkg -i http://launchpadlibrarian.net/228271146/chromium-browser_47.0.2526.73-0ubuntu0.14.04.1.1106_armhf.deb
Boot Time System Parameters
I added a few lines (below) to the /boot/config.txt to change the operation of the system. These are not really essential but in my case they helped make life a little easier.
max_usb_current=1 lcd_rotate=2 disable_splash=1
The boot config options above have the following effects:
- max_usb_current – Increases the maximum amount of current that the USB ports can draw from the default 600mA to 1.2Amps. You will need a good power supply to keep everything stable. This tweak may not be needed if your just using a large USB flash drive or similar low powered device for media storage. But when first building my system I used the Samsung 1TB 2.5 inch drive on one of the Pi USB sockets and it could not get enough power to register at boot without this option.
- lcd_rotate – Vertically flip the LCD display, I found to having the power and audio connectors facing upward on the Raspberry Pi. Was a lot easier than having them pointed down at the surface the system was sitting on.
- disable_splash – This setting is not essential and simply removes the Raspberry Pi splash screen for aesthetic purposes.
Another parameter you may be interested in is avoid_warnings=1. When the 5v voltage rail drops below 4.65 volts a rainbow coloured “warning” square appears in the top right hand corner of the screen.
If you are confident in your power supply being up to the task. Another cause if this issue can be thin wires in the MicroUSB adapter (see this post on under voltage warnings for more details) . If the Pi is still stable and you won’t or can’t rectify the voltage drop for whatever reason, you can use the avoid_warnings parameter to just stop the rainbow square showing up.
Overclocking The PI
Being a system that relies on a lot of real time data a lot of code needs to run periodically to read data from MPD and GPS. In order to reduce latency in these actions I over clocked my Raspberry Pi. The Raspberry Pi 2 comes with a 900MHz quad-core ARM Cortex-A7 CPU but by default it is configured to run at 700Mhz.
The Raspberry Pi can be pushed past 1Ghz with some changes but due to heat and power concerns in the car I have simply configured my system to run at its full CPU speed of 900mhz, with the GPU core and SDRAM running at 450Mhz. If your interesting about learning more about Raspberry Pi over clocking via the boot parameters I highly recommend you take a look at this post on the subject.
To replicate my setup though you can simply add the following lines to the bottom of your /boot/config.txt file:
arm_freq=900 core_freq=450 sdram_freq=450
Setting Up GPSD and the Reciever
First up install GPSD and its associated programs on the Pi.
sudo apt-get install gpsd gpsd-clients python-gps
Then start the gpsd daemon telling it where the device is that will be providing the GPS data:
sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]NOTE: I started this project using a cheap USB GPS dongle made by Prolific Technologies which was /dev/ttyUSB0. Then later on I switched to the Adafruit Ultimate GPS hat which uses the device assignment /dev/ttyAMA0. So your device location for these commands will change depending on the hardware you choose to use.[/fullwidth]
With the gpsd daemon up and running you can check that everything is working okay by running the cgps program in the terminal and it will display information about the current GPS status.
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]
NOTE: You probably won’t be able to get a fix on your Pi while inside. As mentioned earlier even with the Pi placed on a window sill. I was still only getting a sporadically getting signal from 1 – 2 satellites due to the limited sky view. As soon as I switched to an external antenna that could be placed outside the number of satellites rose to around 12 and the device was able to reliably get a location fix very quickly. Another point to keep in mind is that even with a clear skyview on new hardware it may also take a long time to get an initial fix ( see this Wikipedia page for more information on the reasons behind this ).[/fullwidth]
Starting Chromium On Boot
Edit the LXDE start up file:
Then add the following lines, obviously changing the script location in the first line to at the start script in the root of the project code base:
/home/pi/Software/car-computer/start.sh /usr/bin/chromium-browser --kiosk&amp;nbsp; --disable-infobars http://localhost:8000
The first line will start websockify for communication with the MPD server and an instance of the PHP webserver on port 8000. It will then also open up the application in a new Chromium instance using kiosk mode. To exit kiosk mode for whatever reason plugin a keyboard and press ALT + F4.
The –disable-infobars option has been added when starting Chromium so it doesn’t to stop. Then ask if you would like to restore any past tabs on start up due to the Pi not closing the browser cleanly.
Internet On The Move
I have tried to split the steps involving getting the system on-line into two parts. In the first part (this one ) I am going to cover off the steps needed to get the Raspberry Pi connected to the Internet via the 3G dongle. Then in the second part I am going to detail how the Raspberry Pi is set up to act as a Wifi hotspot allowing other devices Internet access through it.
My first approach to getting the Raspberry Pi on-line, was just to install wvdial and let it take care of bringing up the connection. But after almost a day wasted testing various configurations, looking up Hayes modem commands and trolling through my telcos support forums trying to nail down what APN I needed to use for service.
I didn’t really feel like I was not making much headway. Finally i came across the UTMS Keeper collection of scripts it uses the sakis3g program for determining the correct network configuration to use. Along with the heavy lifting involved with bringing up the connection. While the UTMS Keeper script itself monitors the connection status and if off line asks the sakis3g script to try an bring it back up again.
First up you need to ensure PPP and USB-modeswitch packages are available on the system:
sudo apt-get install usb-modeswitch ppp
Then the UTMS Keeper package needs to be downloaded and prepared:
sudo su cd /root mkdir scripts mkdir scripts/umtskeeper cd scripts/umtskeeper wget "http://mintakaconciencia.net/squares/umtskeeper/src/umtskeeper.tar.gz" md5sum umtskeeper.tar.gz tar -xzvf umtskeeper.tar.gz chmod +x sakis3g umtskeeper
From here the sakis3g script is run in “interactive” mode. On start select the “Connect to 3g option”, to run through the configuration of your modem and your ISP configuration parameters:
When the script has finished the gathering the required configuration parameters and has connected to your provider. Select the option on the main menu of the script that is labeled “Generate Success Report”. It will give you a bunch of parameters that look similar to below to use as parameters with UTMS Keeper:
Please report following text: Sakis3G version: 0.2.0e Running a stripped version. System provided Usb-ModeSwitch: * usb_modeswitch: handle USB devices with multiple modes * Version 2.2.0 (C) Josua Dietze 2014 * Based on libusb1/libusbx ! PLEASE REPORT NEW CONFIGURATIONS ! Kernel version: 4.1.13-v7+ Architect: armv7l Selected UI is: whiptail Interface: P-t-P (ppp0) Network ID: 50501 Operator name: BOOST APN: telstra.wap Modem: K3715 Modem type: USB Kernel driver: option Device: /dev/ttyUSB0 Variables: --console --interactive APN="telstra.wap" USBDRIVER="option" USBMODEM="12d1:1001" OTHER="USBMODEM" MODEM="OTHER"
Take note on this screen as some of the values provided will then need to filled in as runtime options for UMTSKeeper. For example the screen above with my set up is provided to UTMS Keepers as:
./umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1001' SIM_PIN='1234' APN='telstra.wap' CUSTOM_APN='BOOST' APN_USER='0' APN_PASS='0'" --sakisswitches "--sudo --console" --devicename 'HUAWEI Mobile' --log --nat 'no'
With any luck the program will tell you that are now connected. If not I would double check the parameters and the APN name from your data provider.
After your on-line unplug the 3G dongle for a few seconds before plugging it in again. The UTMS Keeper script should try and resume the connection.
Now that you have a working 3G connection that reconnects on fall over. Its time to get all this working on system boot, for this I just created a simple service definition in /root/scripts/car-network.service with the following contents:
[Unit] Description=Start 3G and related car netwoking features After=systemd-modules-load.service [Service] TimeoutStartSec=90 ExecStart=/root/scripts/car-network.sh Type=oneshot RemainAfterExit=yes User=root [Install] WantedBy=multi-user.target
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]
NOTE: I am defining a service to run the connection script so it will run at boot time. After Debian Jessie ( 8 ) switched to using Systemd run level scripts have been superseded. <br />If your having trouble with the service not being available after boot, check what order the script is being executed. It may be that the script ran and exited with an error as a required service was not ready yet. I have mine set to run after systemd-modules-load.service that loads in the kernel modules as it is set to run last on the system. Another option is to replace the “after” parameter with “requires” and then bind it to a related service like the modem manager. Then the other service is classed as a dependency and they will brought up together.
To compliment the new service a simple script is created to bring up the connection with UTMS Keeper, enable packet forwarding, and create an IP tables rule to route packets:
#!/bin/bash # Umtskeeper to manage 3G connection /root/scripts/umtskeeper/umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1001' SIM_PIN='1234' APN='telstra.wap' CUSTOM_APN='BOOST' APN_US$ # Enable IP forwarding /bin/echo "1" &amp;gt; /proc/sys/net/ipv4/ip_forward # Set up a rule to route packets /sbin/iptables-t nat -A POSTROUTING -o ppp0 -j MASQUERADE
In Car Wifi
When trying to negotiate a new wireless connection one of the first things the client device will request is an IP address to use. So a DHCP server will need to be set up on the Pi to manage these requests.
apt-get install udhcpd
After the package manager has finished the installation process edit the configuration file /etc/udhcpd.conf and change to suit the desired network parameters. For my system I am just going to use the 192.168.0.0/24 subnet for inside the car. I have made sure this does not conflict with the subnet used on my home network. That way I can easily bring unit inside the house and plug it in to an ethernet cable for updates and patches.
Be sure to change the DNS option to some DNS servers appropriate for your location, or simply set to 126.96.36.199 and 188.8.131.52 to use the Google Public DNS service.
start 192.168.0.20 end 192.168.0.100 interface wlan0 remaining yes opt dns 184.108.40.206 220.127.116.11 option subnet 255.255.255.0 opt router 192.168.0.1 option lease 864000 # 10 days max_leases 80
Save the changes and then edit the file /etc/default/udhcpd commenting out the second line to enable the DHCP server on start up. Then simply create a file for the udhcpd service store the IP leases:
Finally start the udhcpd service:
service udhcpd start
Edit the /etc/network/interfaces file and assign the IP address you configured as your router in the DHCP server configuration to the wireless interface.
allow-hotplug wlan0 iface wlan0 inet static address 192.168.0.1 netmask 255.255.255.0
Create a new configuration file for hostapd service at /etc/hostapd/hostapd.conf. Changing the wpa_passphrase parameter to a unique wireless key for the network.
interface=wlan0 driver=nl80211 ssid=80-Series hw_mode=g channel=8 wpa=1 wpa_passphrase=MYSECRETPASSWORD wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP CCMP wpa_ptk_rekey=600 macaddr_acl=0
[fullwidth background_color=”#000000″ border_style=”solid” border_size=”1″ border_color=”#FF0000″ padding_top=”20″ padding_bottom=”20″ padding_left=”20″ padding_right=”20″]NOTE: The driver entry on the second line! Up until this point in the development I was using a Billion 3011N wireless adapter. Hostapd has particular tastes though when it comes to wireless chipsets and the Billion wifi device was using a poorly supported Realtek chipset. Some people online claimed to have gotten the Realtek chipset working after patching the Hostapd binary. But I had a TP-Link TL-WN821N v3 adapter spare that has an Atheros Chipset so in my case it was the path of least resistance to simply switch. Either way it may pay to do some research on hardware before rushing in and buying a Wifi adapter for your own build.[/fullwidth]
With the hostapd service configured, you can start the service with:
/usr/sbin/hostapd -d /etc/hostapd/hostapd.conf
From here you should now be able to see the newly created access point if you check from another device. To make it start on boot I added it to my /root/scripts/car-network.sh service. With the -B flag to run the service as a background daemon instead of the -D flag for debug.
So my final version of the network start up script contains:
#!/bin/bash # Umtskeeper to manage 3G connection /root/scripts/umtskeeper/umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1001' SIM_PIN='1234' APN='telstra.wap' CUSTOM_APN='BOOST' APN_USER='0' APN_PASS='0'" --sakisswitches "--console" --devicename 'HUAWEI Mobile'&amp;nbsp; --nat 'no' &amp;amp; # Enable IP forwarding /bin/echo "1" &amp;gt; /proc/sys/net/ipv4/ip_forward # Set up a rule to route packets /sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE /sbin/ifconfig wlan0 192.168.0.1 up # Hostapd service /usr/sbin/hostapd -B /etc/hostapd/hostapd.conf
Future Wish List
- If Chromium was able to use GPU acceleration on the Raspberry Pi. It would probably help take some of the load off the CPU and make the application feel a lot more responsive in places. The latest Raspbian Release ships with an experimental OpenGL driver. But activating the module on my system left it unable to boot. I have seen some grumbling on the forums that the driver is not compatible with the 7inch touch display at the moment. So fingers crossed that gets sorted out in a later release.
- My car has a dual battery system with the main battery being used for starting the engine and running the winch. The second deep cycle battery provides electricity to outlets in the car for powering fridges, lights etc. The car has an analogue voltage meter on the dash for the primary battery and I have wired a LED digital voltmeter to a power outlet in the cargo bay of the car so I can see the voltage on the second battery at a glance. But ideally I would like two low power bluetooth voltage monitors so I can monitor the status of both batteries in real time from the Pi. Cheapest I have been able to find them so far is around $70 each on ebay and so far have not been able to justify the added cost.
- Unfortunately Australia dragged its feet with ODB2 integration on our cars. My car has a port labeled ODB2 but unfortunately it was only active with the wiring loom used in the models shipped to the North American market. Still it would be really great to be able to process live ODB2 data into a nice format using the Pi for newer cars.
- The camera port on the Pi is unused, so I was thinking it could be pretty cool to add the official Raspberry Pi camera module to the back of the unit. Then add in a script that tweets or posts the cars location and a picture from the dashboard at predefined intervals.
- Turn by turn navigation access without a keyboard. I am using navit as an engine for turn by turn navigation on my system. But at the moment I need to use a keyboard to exit from Chrome kiosk mode (ALT + F4) to start the navigation software. In the future I will try and add a menu option in the UI that allows the user to exit the application with the help of this Chrome plugin.
- If the price of SSD hard drives continues to drop it may be a worthwhile upgrade to the system, given their reduced weight, power draw and tolerance to vibration.
- A GPS backed trip meter allowing the storage plotting and export of trips taken as .kml files.
- Fuel usage and cost tracking software, simple interface for logging the location of fuel stops, the amount purchased and the price. With the ability to export as a CSV file to keep tabs on fuel consumption and costs.
- I found the audio quality from the Pi to be fine as long as its feeding into an amplifier or similar. Plugging in earphones or a similar low impendence device will result in a terrible amount of static and “popping” due to the design of the Pi. If you find the sound quality as unacceptable even with the use of an amplifier or similar you may want to consider the use of a USB sound card or a hat like the HIFI berry if your not using the GPIO port.
- Due to the shape of my dash the unit sits pretty well on top and just sends the audio to a standard CD player / amp via an aux input. The upside is the unit can be removed easily for providing entertainment outside the car when traveling. But combined with some simple standalone amplifier circuitry it could just as easily be incorporated into the dash as a head unit.