Raspberry Pi Dash Camera

This project started out as an attempt to assess the capabilities of the Raspberry Pi camera module. In reading about this device and its capabilities, we decided to apply the knowledge learnt to a specific problem. The aim here is to provide continuous, high-quality video recording in a car, to capture significant events without human intervention. These devices are sometimes called 'dash cams' and provide continuous (rolling) video recording. These devices are very popular in places like Russia but, are becoming more popular in the UK. They are usually used to capture evidence in support of insurance claims. We are looking to add one of these devices to all of our cars.

  • The device has a power switch, to avoid unwanted drains on the battery. Our kitcar uses a light-weight motorcycle battery, which is very easy to flatten with permanently connected loads.
  • In normal operation it records video in 5 minute segments into a folder called 'video'. When these exceed a predefined storage limit, the oldest video clips are deleted until there is free space. These files are recorded at 1080p and 30fps.

BlackVue DR400G HD v2
The type of device this solution compares to (in terms of features) is something like this BlackVue DR400G HD v2, which retails for nearly £250.

This project provides audible announcements in the form of tones or pre-recorded voice messages, so that it is clear what the device is doing. Initially we planned just one mode of operation but, we we have now added a 'parked' mode so that it can record events whilst the car is left parked. We have also interfaced buttons and LEDs to provide control and event detection, using shock sensors.

Note that we do not plan to use this device for action footage (track days, etc.). We have separate cameras to achieve this (these record at a more desirable 60fps). Having said that, the device could be used to capture 'action'.

The Hardware


The initial plan is to use a compact plastic ABS case, with a 3D printed camera holder fixed to it. The main case could sit on the dash and the camera holder will protect the RPi camera module and hold it in the orientation, facing forward. The case will also support a standard camera thread mount so that it can be fixed behind the rear-view mirror. It should also work with a generic Smartphone suction mount.

In our Fisher Fury R1, the plan is to completely integrate the unit into the car and mount the Raspberry Pi behind the dash. More on this will follow soon ...

Switches & Inputs

Raspberry Pi 8 LED & 8 Button breakout board GPIO
Our initial testing is being done with John Jay IO board. This allows us to test out the LED and switched operations.

Digital Outputs & Indicators

Note: The numbering used here is for the Revision 2 board.

When we tested our design with the John Jay IO board, we fund that the GPIO2 outputs using pin 3 and pin 5 were floating, causing the LEDs to light up when not required, so we have avoided these two pins in this project.

To get a nice quality finish, we have used high quality 5mm, flat-top, clear LEDs. The yellow and blue LEDs will never be on at the same time. These don't need to be particularly bright and can be supplied directly from the GPIO pins via a resistor, to limit the current taken from the GPIO pins.

The plan is to have four LED indicators:

  1. Green = power (flashes if no GPS signal) (GPIO8, Pin 24)
  2. Orange = normal rolling recording (GPIO9, Pin 21)
  3. Blue = parking mode (GPIO4, Pin 7)
  4. Red = event(s) detected and captured (not including manual events captured) (GPIO7, Pin 26)

LED brightness levels
As each colour LED varies in electrical characteristics, we choosen the resistor values to get even brightness levels across the various LEDs. They might not look it via the camera but, these are all even. Each uses a 820 Ω resistor, except the green LED which uses a 1200 Ω resistor.

Digital Inputs & Buttons

Note: The numbering used here is for the Revision 2 board and that this code works with our test board, which has all the inputs as active low. Our optical isolation input board works with the inputs as active high. This means the triggers also work on rising edges.

The plan is to use the GPIO pins to detect push-button switches being pressed. We plan to use the same high quality, momentary action switches used in our kitcar. These will be mounted on the case and for our integrated version, will be mounted on the car dashboard. We bought these from JPR Electronics

  1. Orange switch = normal recording mode (GPIO15, Pin 10)
  2. Blue switch = parking mode (GPIO17, Pin 11)
  3. Red switch = manually force event store (GPIO18, Pin 12)
  4. Ignition power - if this is removed, then the device starts its shutdown process, unless it is in 'parked' mode (GPIO22, Pin 15)
  5. Linear acceleration sensor (GPIO23, Pin 16)

Linear acceleration switch
We are using a linear acceleration switch to detect events and impacts. These come in two forms, with different activation ratings. We are testing both, to see which works best in our various cars. The first is rated 2G to 4.9G and the second is rated 5G to 9.9G. We bought these from JPR Electronics

Interface Board

We have made a dedicated interface board (Microsoft Powerpoint layout) for this project, using a small piece of Veroboard. It actually supports 8 digital inputs via two ILQ74 quad opto-isolators. These enable us to connect 12V signals (via a resistor) and to provide some level of protection to the Raspberry Pi. The inside of a car is quite a noisy place to be from an electrical perspective, so we switch 12 V levels as the switches will be remotely mounted in our kitcar installation.

RPi template
This board will be mounted using nylon hex spacers and is designed so that the Raspberry Pi sits on top of it, also on hex spacers. This allows further RPi piggyback boards to be added if need be.

Interface board
This is the interface board with nylon hex spacers so that the RPi can be mounted on top of it.

Speaker, Amplifier & Audio

This dash cam provides audible notifications to let you know what is happening. This is to avoid having to look at the LEDS on the device. The voice announcements are pre-recorded and generated using the iPhone 'Speak it!' app. This app supports generation and sending of .aiff audio files and these are played out on the RPi using an audio player. Initially we used VLC but, we have since re-encoding the audio files to the .wav format, so that we can use the aplay command. This is much faster and much more efficient.

We have re-encoded the audio using Audacity. The current announcements being used are:


Firstly we installed the alsa audio drivers and MP3 Player:
sudo apt-get install alsa-utils
sudo apt-get install mpg321

After a reboot, we them enabled the sound drivers:
sudo modprobe snd_bcm2835
sudo amixer cset numid=3 1

MP3 files are require decoding and this adds latency and requires more processing power.


The only player we could see that played our .aiff files was VLC. This installed with:
sudo apt-get install vlc

The command to invoke is:
cvlc --play-and-exit --quiet <filename>

This proved to be a very slow way to play files out, so we converted them to .wav files.

Batteries & Power

We thought long and hard about how to best power this device. There are basically two options:

  1. Power the whole device via the ignition and use an on-board battery to enable tidy shutdown. The challenge with this approach is that the on-board battery needs to just power the device long enough to shutdown but then remove power after a few seconds. This would not allow the device to work in 'parked mode' though.
  2. Use direct connection to the car battery (via a fuse!) and use a GPIO pin to monitor the ignition status. This allows the device to work in parked mode but means the power needs to be physically switched off when not in use and after the device has shutdown. Although the user experience is not as good, this approach works better for us and is the one we have chosen to use for this device.

12V to 5V dc-dc converter
This project uses a high-efficiency 12V-5V dc-dc converter with a USB port for the output voltage. It provides an accurate and stable 5V dc supply for a wide range of input voltages.

The main power switch turns on power to the Raspberry Pi (via the dc-dc converter) and causes it to boot up. When in use, the Raspberry Pi is drawing about 200 mA from the 12 V supply. When the video capture is running, this increases to about 300 mA. When halted, about 100 mA is drawn from the 12 V supply.

Once shutdown, the main power switch needs to be turned off manually, or the Pi will not auto start next time.

Raspberry Pi

Raspberry Pi
We have used the latest Raspberry Pi model B board as this has mounting holes.

This version has 2 USB ports, which are used for the GPS module and the Wi-Fi adapter.

SD Card

There is a list of supported SD cards here. We have used a 32GB class 10 card from 7 Day Shop.

Camera Module

This five-megapixel camera can take stills with a 2592 × 1944 resolution and record HD video in 1080p at a maximum frame rate of 30 frames per second. The camera module does not support audio.

This is a good video clip, showing the module set up process:

The cable on the board cannot be extended and is also very thin and flat. This limits the distance possible between the Raspberry Pi and the camera board.

Switch Off LED

The camera board has a bright red LED, which indicates when the camera is in use. Whilst very useful for testing, it is a distraction with this application and can easily be switched off.

How to enable camera support in Raspbian

This is described here.

sudo apt-get update
sudo apt-get upgrade
sudo raspi-config

Navigate to 'camera' and select 'enable'. Select 'Finish' and reboot.


BlueNEXT GPS USB dongle
We have now successfully added a USB GPS module. The Raspberry Pi does not have a clock by default and we are using the GPS dongle to provide an accurate clock. We also have other plans to use the GPS module for speed and location logging. This part is described in our RPi GPS feature.

Time Zone

The Raspberry Pi needs to be in the right time zone. This is done using:
sudo dpkg-reconfigure tzdata


We are not sure if this is needed yet.


We are currently working on this feature. We need to test it out for our wider plans with the Raspberry Pi in our cars and it makes it easy to access the video footage captured remotely, from within our house. We also want to see how our cars can be used to provide presence and occupancy in our smarthome.

We are testing a number of USB Wi-Fi dongles with the Raspberry Pi.

The Software

Operating System

Downloaded from here. The latest Raspian Wheezy build is 2013-05-25-wheezy-raspbian.zip

You keep the operating system files up to date using the commands:
sudo apt-get update
sudo apt-get upgrade


rpi-update is a tool to upgrade the firmware for your Raspberry Pi. The firmware is a small package of code that usually lives on a special chip of a computer that helps the software know how to talk to the hardware. With the Raspberry Pi, the firmware resides on the first partition of the SD card. This is nicely explained here.

Auto Start

The Raspberry Pi will auto-boot when powered up and our dashcam application will then auto-run. The delay in this happening is quite short.

This is done by adding our script to the /etc/rc.local file. It will run with root privileges and also run before the user login prompt appears. One advantage of this is that is that you aren't leaving a logged-in terminal. This approach is usually used to run new services and our dashcam application could also be considered a new service. The service needs to be run in the background or it will not allow you to login to the RPi.

Auto Login

The RPi can also be set to auto-login. If you want to start a script off when your RPi boots up there are various ways to do it. This is the one we are using:

  • Edit /etc/inittab and comment out the line:
    1:2345:respawn:/sbin/getty -noclear 38400 tty1
  • Below it add the line:
    1:2345:respawn:/bin/login -f pi tty1 </dev/tty1 >/dev/tty1 2>&1
  • This does is an automatic login on tty1 (the first terminal), so a sudo reboot should now login the user pi automatically.

This next part runs our dashcam script automatically too:

  • Edit .bashrc and add this code to the end of the file:
    if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
    ./dashcam.sh &

Capturing Video & Images

raspivid is the command line application that allows you to capture video with the camera module (raspistill allows you to capture images). The main command line arguments of interest are:

  • -o specifies the output file
  • -b sets the bitrate. The default is 17Mbps and 10Mbps = -b 10000000.
  • -fps set the frames per second. The default is 30.
  • -w = video width (default is 1920)
  • -h = video height (default is 1080)
  • -n turns off the video preview


This is simply a shell script that is run automatically, when the Raspberry Pi boots up.

It does a few initialisation tasks, then it runs our dashcam.py Python code in the background.

It has a control loop that records 5 minute video segments, each with a filename that is based on the start time and date (e.g. 2013_06_29_13:34:45.h264). After each recording the allocated storage space is measured and older files deleted to bring usage down below a pre-set limit. The gap between each video file is very short. The filename of the previously recorded file is also stored, so that we can copy this to the events folder if needed.

The program loop runs until the contents of a file called dashcam.mode are changed to something other than 'exit' or 'shutdown'. The default value is 'record'. This provides a very simplistic means of inter-process communication.

If the contents of a file called dashcam.mode are changed to 'event', then this code copies the previous and current video files to the 'events' folder, as a background process. The contents of the dashcam.mode file are then reset to 'record'.

This code is still in progress but, the latest version is included below:



This is a Python script that is also auto-started. It monitors the GPIO pins and decides takes appropriate action. It can kill the raspivid process (to stop the current recording segment) and also write control commands to the dashcam.mode file:

  • 'exit' - the dashcam.sh program loop exits. This is used for testing.
  • 'parked' - the Raspberry Pi keeps recording even after the ignition is switched off.
  • 'record' - the Raspberry Pi keeps recording until the ignition is detected to be off.
  • 'shutdown' - the Raspberry Pi is shutdown.
  • 'event' - an event has been detected (via the GPIO pins).

This code uses the event_detected() function to detect changes to the switches and from the sensors. This basically enables multi-threading.

This source code is still in progress but, the latest version is included below:


Disk Usage

We use a folder call 'video' for storage of the video, then we can check the size of files in this directory using the command:
du video

We then regularly check that this does not exceed the space allocated and delete the oldest files until it does. The way our code works is that it deletes old files until our storage limit is met. It then records the next file. This approach results in a very short break in the recorded video, even with the old files being deleted.

All code will be published here soon.

Each 5 minute segment uses about 330MB of disk space (1080p at 30fps and 8Mbps bitrate). I need to do some more real world experimentation before I settle on the optimum bitrate to be used but this works out at about 4GB used for each hour of video stored. We have allocated 24GB of the 32GB SD card to video recordings, so we should hold the last 8 hours of driving.

After each event is stored in the 'Events' folder, the code checks to see how much data is in the folder. If this exceeds the pre-set limit (currently 4GB), then an audio announcement is played out saying "Event store full".

Fixed IP Address

In order to remotely manage and access this device on our home network, we have given if a fixed IP address.

Remote Access

The RPi supports SSH by default, so any suitable client can be used to remote login. A fixed IP address makes this a lot easier!


The thinking was that we could have time and date stamped logs (one file per day) but, these only make sense if we have a real-time clock. Despite having GPS to set the system time, there will be periods when it doesn't get a lock and the system clock is set to the wrong time. We are also thinking that the log file could have a continual stream of GPS date (longitude, latitude, altitude, speed, etc.) and that this would need to be captured quite frequently.

Working on this basis, we have decided to use a single log file called dashcam.log. Processes will append data to this file and each line will start with a numerical value that represents the 'Epoch time' as currently understood by the Raspberry Pi. This is the number of seconds since 12:00am 1st January 1970 and is accurate to many decimal places. This will help us understand how well the GPS device is working in terms of setting system time. We will see a chronologically ordered file, along with the system time.

In the Linux shell this is achieved using the command: date +%s.

In our Python code we use ticks.


This V1.0 is pretty much complete and under going testing in our family car. The only thing really left to do is to finalise the packaging before we permanently install it.

The only downside we have found to this project so far is the time it takes to start recording (about 30 seconds). To be honest, this really isn't a problem for us but it might be for some people. WE haven't even looked at optimising the RPi boot time yet though and are confident this time could be reduced significantly.


Having left my code running for a while, we initally noticed that lots of errors were generated of the form:
mmal: Failed to write buffer data - aborting

We realised that we had got the storage space limit wrong and had managed to fill up out test SD card, which is only 4GB.

It is possible to log the CPU and GPU temperature, so we tried doing this. If the temperatures exceed a pre-set value, we then play out a voice announcement warning. This is done after each 5 minute recording segment completes. Typically, we are seeing temperatures around 60°C and have set warnings for 70°C.

You can get the GPU temperature with the command:
/opt/vc/bin/vcgencmd measure_temp | cut -c6-9

The problem we have found is that doing this eventually causes the RPi to lock up, so this bit of our code is currently commented out.

Related Links

Video Samples

Sample 1

Early test using 720p video capture on drive

Sample 2

A short segment shot on the road in 1080p, with the camera mounted on top of the dash:

This sample shows that the field of view is pretty good but, not as wide as a dedicated dashcam (typically 120° field of view). We are not sure what the strange strobing/wobbling effect is but are looking into this. The camera module does not handle driving into the sun very well but, none ofthese cameras do. It may well be possible to improve on this by changing some settings.

The biggest challenge is the lack of on-board real-time clock. The GPS is needed to get the timestamps correct on the video.

Stuff We Are Thinking About For V2.0


We were also interested to see what role there is for email on this device. It would be nice if the event files were emailed to us, when the car gets in range of our home network and then deleted from the event cache. This assumes we have added Wi-Fi though.

For our initial testing we have installed the Claws email client. In the end we wrote code to FTP to out home server and then synchronise via DropBox. This seems to work better and it just happens in the background.

Rear Camera

We plan to add a 720p USB webcam as a second camera for rear view recording. Our tests should show if the Raspberry Pi is powerful to support this second camera.

Next Car

We are currently designing and building our next car and the plan is to fully integrate a Raspberry Pi into it for this functionality and a lot more :-)

Reversing Camera

If we are going to go to the trouble of installing a rear view camera for recording, should we not also add a small screen and provide a rear-view camera to help with parking?

Gyro & Accelerometers

We are going to use an add-on board to provide this measurement and logging of acceleration later. This is an interesting article on the subject.


October 2013

This project is becoming much more than just a dashcam! We have now added an on-board 'quit' button to help with expansion and testing. This enables us to stop recording without shutting the RPi down. We are glad we supported additional inputs (8 in total) as we are adding new features. We are are also adding an I2C analogue input board with a view to monitoring the engine temperatures, etc.

This means there is now updated code. Note, this latest code uses the proper I/O board and hence tests for rising edges (switch presses) and falling edge (ignition off).

December 2014

Just discovered you can now get longer ribbon cables for the Raspberry Pi camera module. This makes it much easier to package up :-)

Summary & Conclusions

This project has a lot of potential! We see this project as an on-going experiment of what is possible with a Raspberry Pi in a car. Having said that, we are really stuggling with the packaging issues and in making this project small enough to use every day in our main family car. We are likely to stick with a bespoke 'off the shelf' model of dashcam for daily use in our Mazda 6.

We are mainly using this dashcam in the Fisher Fury R1, where is is easier to install and hide the hardware. This is also an ideal testbed for our on-going experiments. It is slowly growing to be a full on in-car video and data logging system. We are now looking at using it as a secondary digital dash, with the HDMI fed into a 7" or 9" screen.

Mini 0801 Dashcam
We have now bought an off-the-shelf dashcam (our review), which we are using in our family car.

Share ...
We are on ...
Facebook Twitter
YouTube Flickr Follow us on Pinterest