Android and RasPi based Car Computer

Car computer using Android Tablet as interface and Raspberry Pi as backend (with some Arduinos and Teensies thrown in for good measure)

Similar projects worth following
I don't like my car stereo. All it does is serve as a bridge between my phone and the amplifiers.

I have an Android tablet. I'm gonna install the tablet into my dash and let the tablet do everything the stereo currently does and then some.

I am currently working on a very detailed document describing every aspect of this project. It can be found at this link: Description on Google Docs. It is a work-in-progress and should reflect the most recent design. I will keep that link as up to date as possible, but this project page will not be updated as often as the G-Docs file. This project page will also not have the level of detail that the G-docs file contains.

I've changed my mind on the overall design for this project several times. Currently, the plan is to mount my Android tablet into the dash of my car and use it as my source for music and the primary interface for the other systems I'm installing / modifying in the car (lights, AC/heat controls, etc). The tablet will be connected to a USB DAC which will feed into a line level pre-amp, then on to the power amps. The tablet will also be the screen for my backup camera.

I'll be working on this project in stages but can only start installing pieces once all the main parts are done. This includes mounting the tablet in the dash, completing the software to run on the RasPi, completing the auxiliary battery and power supply, installing the audio hardware (including building the electrical interface for the steering wheel controls), and building the mechanical and electrical interfaces for the heat/AC controls. In the process of building all of these parts I have to take into consideration and plan the other things I plan on incorporating into this build, including the turn signal system rebuild, auxiliary lighting, and dash camera / DVR.


| |

\/ \/


When I purchased my new phone (Galaxy Note 3, if you're curious), AT&T gave me a tablet for free (as long as I signed up for a two-year contract for the tablet). At that moment I had the great idea of installing this tablet in my 2012 Scion tC so I accepted their terms. Since then, I've been working on this project but haven't made much headway as far as installation goes. I've mostly been trying to work out the logistics of the project and have been tossing around several ideas for how to go about implementing my idea. At this point, I've been at it for about a year. The overall project design has gone through several iterations and I have finally arrived a a version that meets all of my requirements. Instead of mounting the tablet in the dash as the direct interface, I'm going to replace my stereo with a headunit that has HDMI / MHL capability. Using that feature, I'll route video from my old Galaxy S3 to the headunit and use the headunit itself as the primary interface. Because I'll be able to use the headunit screen as the interface to the phone, I'll be able to access all the features of the phone. I'll use the SIM card from the tablet to enable data-only access to the cellular network, and I'll still use the tablet to control accessories and view data about the vehicle.

Initial design ideas

When I first started working on this project, I had no idea how I was going to make it work. And so I started off with simply trying to decided where in the car I wanted to install the tablet. My first instinct was to install it where the stereo is but I didn't want to lose the option of playing a CD or listening to broadcast radio. And so I started to consider other places in the dash to install it. The location had to meet these requirements: easily reachable, plainly visible, not block line of sight, not block heat/AC vents. The best place that I could figure to install the tablet was where the heat and AC controls are. This would have meant integrating control of the heat and AC into the tablet somehow.

After inspecting the inner workings of the heat and AC controls, I decided that it would be a little more difficult to implement than I wanted to deal with. Therefore, I reconsidered the option of install the tablet in the current location of the stereo. About this time I realized...

Read more »

  • 1 × Samsung Galaxy Tab S2
  • 1 × Raspberry Pi RasPi Model B with 512MB RAM
  • 1 × Arduino Due
  • 2 × Arduino Uno + Ethernet
  • 1 × ODB Solutions STN1110 ODB-II communications interface
  • 1 × Schiit Audio Modi 2 Uber USB DAC with S/PDIF and TOSLINK
  • 1 × AudioControl Three.2 EQ/Xover Audio equalizer and crossover with auxiliary inputs
  • 2 × Actobotics Gear Box 7:1 gear box, continuous rotation
  • 4 × MCP45HV31 Digital Pot Single channel, high voltage, I2C interface, audio log taper, digital potentiometer
  • 4 × TSSOP-14 breadboard adapter

View all 14 components

  • Volume Controller Code

    AndrewMcDan05/28/2016 at 21:27 0 comments

    Code for the volume controller is complete. Pretty simple stuff. Find it on GitHub here.

    Here's a breakdown of code:

    To start, include some libraries, declare some globals. The byte-sized variables are the I2C addresses for the digital potentiometers.

    #include <Wire.h>
    #include <mcp_can.h>
    #include <SPI.h>
    long unsigned int rxId;
    unsigned char len = 0;
    unsigned char rxBuf[8];
    MCP_CAN CAN0(9);
    byte addr_MSTR_L = B0111100, addr_MSTR_R = B0111110, addr_SUBW_L = B0111101, addr_SUBW_R = B0111111;
    setup() is pretty simple too. Start up the Wire library, set our "interrupt" pin for the MCP2515 as input. The CAN bus controller I'm using is a MCP2515 which has interrupt capability when it receives data on the bus that matches the filter. I'm just gonna poll this pin rather than setup and actual interrupt. After starting up the CAN library at 500kbps, we set the receive masks and filters so that we only get messages sent to device ID 0x00F.
    void setup() {
      pinMode(8, INPUT);
      CAN0.init_Mask(0, 0, 0x7ff);
      CAN0.init_Mask(1, 0, 0x7ff);
      CAN0.init_Filt(0, 0, 0x00f);
      CAN0.init_Filt(1, 0, 0x00f);
      CAN0.init_Filt(2, 0, 0x00f);
      CAN0.init_Filt(3, 0, 0x00f);
      CAN0.init_Filt(4, 0, 0x00f);
      CAN0.init_Filt(5, 0, 0x00f);
    The loop() runs without doing much unless the "interrupt" pin is driven low, in which case we read the data from the CAN bus and send each byte to its corresponding digital pot.
    void loop() {
      //  check for CAN bus interrupt
      //  if interrupt, read data and store, set new flag
      if (!digitalRead(8)) {
        CAN0.readMsgBuf(&len, rxBuf);

    Yeah, pretty simple stuff. But it works.

  • Mechanical bits: Heat and AC Controls

    AndrewMcDan05/22/2016 at 19:22 0 comments

    I've made some major progress on the mechanical part of controlling the heat and AC stuff. The knobs that control the temperature and which vents the air comes from are connected to cables that go into a box with (what I am assuming are) a bunch of butterfly valves. I have replaced the knobs with servos and now I can control the air box butterfly valves electronically.

    On the left, I assembled everything and stuffed into the dash hole. This is pretty close to where it will be mounted when it comes time for it.

    The one on the right shows the assembly before I stuffed it into the dash. The servos are mounted in "gearboxes" that give them 7:1 advantage. ( I think the servos could have turned the cable assembly without the gear reduction, but I didn't want to risk one of them burning out after the project is finished. The gear reduction makes it a little easier for the servo to achieve the desired position since I can program it so run at full power until it is very, very close to correct spot.

    I used 1/4" acrylic for the brackets and (what I am calling) the adapter hubs.(The "adapter hubs" are screwed to the top of the big gear.) Why 1/4" acrylic? Because it's what was in my garage and my CNC router can cut it.

    I've also made progress on some of the electronics. Right now I'm working on the EQ/Crossover/Line-driver that arrived a few days ago. It is an AudioControl Three.2, and it will take the output from the Schiit Modi and make it awesome. Actually, it is going to do exactly what it is meant to do. There is one thing about it that I have to modify though: volume knobs. This thing is going to be mounted inside the dash with no easy access but it will be my primary method of controlling the volume. To solve this problem, I am replacing the mechanical potentiometers with digital ones that are controlled via I2C (MCP45HV31).

    Here you can see where I've desoldered the original pots and soldered in some ribbon cables. These will lead to a box with the digital pots, arduino, and CAN transceiver that will be mounted to the top of the EQ. The other two wires you see in the pic (black and green) are power for the digital pots. The MCP45HV31 is a "high voltage" part, meaning the potentiometer can be connected to a system with up to 36V between the high and low terminals of the pot. This EQ, being of such high quality, feeds a rather high voltage signal through the volume control pots: a max swing of -13V to +13V. The digital pot needs a power supply of at least the maximum swing voltage and luckily the EQ provides me with it. So, the black wire is connected to -14V and the green wire is connected to +14V. That's it for this update. Hopefully I'll have some functional stuff to demo in my next update.

  • Software Progress

    AndrewMcDan01/16/2016 at 21:09 0 comments

    I have made some decent progress on the software side of things. The user interface is basically complete, but the back-end software on the R-Pi is nowhere near done. Here's a screenshot of the UI:

    Here's a video demo:

    It's obviously an incomplete demo, but hey it's something. Also, most of the code I've been working on is available on Github.

    Just to give you an idea of what I have on my plate, here's a diagram of most of the components of this project...

    And a sort of pseudo-schematic for the Arduino Due:

    I plan on updating the Google Docs file that has the full description of everything in it soon. I'm still working out some details and once that's done I'll get it updated. The link to the G-Docs file can be found on the main project page.

    That's all for now. I'm waiting for my brother to put the finishing touches on the dash piece so I can keep working on that part of this project. He works at an automotive body shop, so when it comes to fiberglass and bondo, he's got me covered. I'll post an update once he gets the piece back to me. Until then......

  • Just a quick update - Dash panel progression

    AndrewMcDan12/14/2015 at 02:15 0 comments

    The new dash panel is coming along nicely. The first picture shows an approximation of where the tablet will be mounted in the final piece. The second is a mock-up of the piece in the dash. That's all for now.

  • Actual Work Commencing

    AndrewMcDan12/11/2015 at 01:14 0 comments

    After much delay, I have finally started real work on this project once again. Here's a list of project accomplishments for the week:

    1. Purchased a new tablet to install in the dash; a Samsung Galaxy Tab S2.

    2. Completed some experiments with the new tablet and determined that I can go back to my original plan of doing away with the stereo head-unit of the car.

    3. Started work on the new dash panel that will house the tablet.

    Here's a pic of the progress on the dash panel:

    As you can see in the pic, I've done away with the opening for the stereo and the opening where the clock, passenger airbag indicator light, and hazard light switch used to be. The new piece still needs to be cleaned up and the edges trimmed down but it is a start.

    As for the tablet and related experiments, I have solved the one big issue I had when I started this project: audio. I want to use the tablet as the audio source for music but retain the ability to connect my cell phone through Bluetooth for phone calls. Through several iterations of methods of connecting the tablet's audio and the BT call audio to the car, and many revisions of the overall vision of this project, I came to the conclusion that I couldn't have all the features I wanted. Enter the new tablet.

    As it turns out, the Tab S2 has the ability to output audio through USB audio devices. It also supports USB hubs, cameras, keyboards (with media keys), and pretty much anything that you can find an app to use it with. It also does this nifty thing where when you turn on the WiFi Hotspot, it creates a proper IP routing table. This may not seem important on the surface, but it allows the tablet to communicate with the RasPi without interrupting its own ability to access the internet. It also has the obvious advantage that it gives the RasPi and internet connection.

    Back to USB. Audio output will be handled by a USB DAC, probably a Schiit Audio Modi 2 Uber. Track controls will be implemented through a virtual keyboard through an Arduino Leonardo. The backup camera will be a Logitech HD Pro C270 (or C920, perhaps) webcam being displayed through an app called CameraFi. The last port on my USB hub will be connected to the stock USB plug in the dash.

    There is still one issue with the tablet: charging. I don't want to have to bring the tablet inside every day to charge it but it won't charge will USB devices are attached. Hopefully I can hack a cable to get it to charge while the USB devices are connected, but if not, I'll have to use relays to simulate the disconnection of the USB stuff. That would mean setting up an auxiliary battery that is charged when the engine is running and charges the tablet when the engine is off. Perhaps those details will come in my next project log.

    When it comes to audio, here's how I'm gonna set it up: tablet --USB-- > DAC --> line level preamp --> level control --> power amps. The DAC also has a S/PDIF input which will be the insertion point for the call audio from the BT module. It will be controlled directly by the RasPi which will receive an interrupt when a call arrives and display the call on the tablet screen. The RasPi will control the level of the signal going to the power amps through some means that I haven't fully worked out. I want to be able to do this so that a set volume can recalled whenever a telephone call comes in.

    More work will done in the coming weeks and if I remember, I'll post more updates.

  • Power Supply Build (part 1)

    AndrewMcDan02/28/2015 at 13:33 0 comments

    I've made a fair amount of progress on the power supply for the various 5 volt and 3.3 volt components (Arduinos, tablet, etc.). This includes the battery for powering the remote start controller and the standby controller for lights.

    { Battery pack showing the mess of wire I created along with the three single cell batteries }

    { The completed battery pack }

    The battery pack is made of three Turnigy 5000mAh 1S 20C 3.7V Lipoly batteries connected in series to form a 5Ah 3S 11.1V pack. The battery pack is directly connected to a Mini-Box OpenUPS. The OpenUPS charges the battery pack and manages battery run time after the ignition has been switched off. Once the ignition is switched off, the battery powers certain devices for a preset amount of time before removing power from them (e.g. RasPi). The controllers that require battery power all the time will be connected directly to the battery pack through efficient DC-DC buck converters. I plan on building within the power supply a controller that monitors battery voltage, and in the event the battery voltage dips below safe voltage on any cell, it will completely disconnect the battery pack through latching relays. The OpenUPS feeds into a Mini-Box PicoPSU that outputs 12V, 5V, and 3.3V. This supplies all devices that require 3.3 volts and any device that requires a shutdown timer on 12 volts or 5 volts.

    For devices that do not require a shutdown timer but are not high power devices, 5V and 12V will be provided using a pair of Mini-Box DC-DC USB 200 power supplies. This provides plenty of power for all the microcontrollers and the handful of 12V devices that require regulated voltage (camera, DVR). More photos and details to come.

  • Been a while since updating, still working on it

    AndrewMcDan02/18/2015 at 16:58 0 comments

    So, it has been quite a while since the last time I updated this project, but I an still working on it and have made some progress. Once again I have revised the vision I have for the dash and I'm going back to the plan installing of the tablet in the dash. I've also made some progress on the power regulation and delivery system and have come up with a new idea for communication between modules. I'll be posting details and photos soon.

  • Entering TheHackadayPrize, Installing the new head unit

    AndrewMcDan07/12/2014 at 06:09 0 comments

    After much debating with myself, I've decided to enter this project into TheHackadayPrize contest. One of the requirements for a project to be eligible is that the hack be connected somehow. Going back and reading my project description I realized that I left out the bit about remote starting the vehicle from any internet connected device and potentially being able to stream video from the car's camera and reading log data.The data connection in the Android device will help make this possible. I'll be posting more details as soon as I've had a chance to make some headway on that front.

    In the meantime, how about some details about how I managed to make the new head unit (JVC JW-V50BT) work with the existing USB, auxiliary input, and microphone in my car? Starting with the easy stuff. The USB and auxiliary connections were fairly easy. It was just a matter of examining the wiring schematic for the car and making adapter cables. The microphone was a different story. 

    The new head unit came with a crappy little mic that they expect to be mounted on the dash with two-sided tape. But I figured that would be silly since my car came stock with a mic built into the dome-light assembly. Upon comparing the connections of the two mics, it was clearly apparent that this would definitely be more of a hack than an adaptation. To the right is the stock connector for the mic. The new mic had a 1/8 inch TS connector on it. The goal: hack a 2 conductor connection to work with a 5 conductor connection (actually 4, but there's 5 wires there).

    This is the connection to the microphone module. I took it apart (and forgot to take pictures) and figured out which wire served which function. I had done a bit of searching on the web to see if I could find anyone that had already sniffed out the functions of each of these wires and the best information I could find was that the microphone requires power. The schematic lists the connections to the mic module as SNS2 (pink), MCO+ (black), MCO- (white), and MACC (red). (The schematic also shows the shielding around the cable. That would be the gray wire.) Although I wasn't certain, I figured that they were, respectively, sense (for the stock head unit to detect the presence of the mic, Bluetooth in that head unit will not work without it), signal output positive, signal output negative, and accessory power.

    This turned out to be pretty easy to confirm once I had a look at the PCB. The white and pink wires are both connected to the ground plane on the PCB inside the module. The 5 volt supply has an AC blocking capacitor near the connector. The positive side of the signal has a DC blocking capacitor near the connector. Knowing this information made it possible for me to work out a way to connect it to the new head unit.

    Finding a 5 volt supply for the microphone wasn't too difficult since I've got a couple of spare USB cell phone chargers laying around. That was just a matter of splicing them together. The signal wire was a different story. First step was to figure out which side of the 1/8"TS connector was connected to ground. A simple multimeter/resistor combination made this trivially easy. Then on to connecting the two. Since the stock mic module has a built in pre-amp, I figured it would output a really hot signal. I hooked up my handy little DSO Nano o-scope to output of the stock mic and saw a nice waveform in sync with door chime. I noted that the peak voltage was about 100mV. 

    Then I hooked it up to the crappy mic that came with head unit and couldn't get any decent reading out of it. I tried talking directly into the mic, tapping it, holding it up to the speaker on my cell phone. It never registered any voltage. And this was with it connected to the head unit. What's more is that the head unit acted like the mic wasn't even plugged in. This was unsettling and very annoying.

    So what is a good hacker to do? Well, pop open the brand new $400 head unit and poke around of...

    Read more »

  • Twisted Pear / Wolfson Audio WM8804 board

    AndrewMcDan07/06/2014 at 15:44 0 comments

    After much research and fiddling, I finally figured out how get the Twisted Pear Audio WM8804 board to do my bidding. The only thing I want it to do is convert I2S data to S/PDIF data. I had a hard time figuring out how to make this work because the user manual from Twisted Pear Audio only gives configuration information for converting S/PDIF to I2S. I initially thought I would need a microcontroller to configure the registers in the chip, but after digging through the datasheets for WM8804, I finally found a small section describing how to run the chip in hardware mode (no µController needed) and get the results I wanted. Below is a picture of my test setup using the RN52 bluetooth module as a I2S source, and a picture of the WM8804 board showing the switch positions for configuration.

    The picture (left) doesn't do a very a good job of showing it, but in order to make this work, I connected the bit clock output of the RN52 to both the master clock and bit clock inputs of the WM8804 board. The S/PDIF output from the WM8804 board is then connected to a TOSLINK optical transmitter which is connected to a cheap TOSLINK to analog converter. This configuration works flawlessly.

    In the picture to the right, you can see the dip switch positions. The dip switches, from left to right are up, down, up, down. This translates to low, high, low, high levels. 

    I haven't decided if I'm going to use this board or not. Although I still really want to use an optical medium to move audio data across the vehicle, I'm not sure I want to go through the trouble of figuring out volume control. 

  • RN-52 Module not going to be used

    AndrewMcDan06/01/2014 at 18:03 0 comments

    After getting the RN-52 module hooked up to a USB/serial cable and getting the module configured and paired with my phone, I connected my logic analyzer to the digital audio output. It took me an embarrassingly long time to figure out that the silkscreen on the breakout board was incorrect and that I was trying to monitor output from a input line (I should have just read the product description on Sparkfun's website). But, silly mistakes notwithstanding, I did manage to get data out of the device and it appears to output good I2S data. 

    While digging through the datasheet for specifics on how to configure the device, I found that it is capable of outputting S/PDIF. I set the module to output S/PDIF and connected it to my A/V receiver. It works great as a Bluetooth A2DP to S/PDIF adapter. (I might re-purpose it for that.)

    After listening to a few songs and playing with software control of pause/play/next/prev, I started digging through the datasheet and command reference to try to figure out how to get track/artist information from the Bluetooth source. Lo and behold, the RN-52 is not capable of retrieving that information. I should have figured that out long ago, but I was skimming the datasheets like an idiot. And so, I have to figure out a new way to handle audio.

    My current idea on how to do this is to use the existing head unit since it has all the Bluetooth capabilities I'm looking for, it already has the circuitry/interfaces for the microphone and steering-wheel controls, and it has a built-in amplifier. That's a few less things to figure out. The plan is to offset the head unit back a few inches into the dash and mount the tablet in front of it. I'm considering eliminating all of the parts of the head unit that do not contribute to producing sound from either Bluetooth or line-in. That would leave me with only a single PCB (with two small daughter boards) to mount behind the tablet.

    The one big question is how to communicate with the head unit to get track/artist info and send commands (play/pause/next/prev, answer call, volume, etc.). I poked around the innards of the unit a bit and found a few interesting things. Bluetooth is implemented using a BT module much like the RN-52. It's soldered to the main PCB in the head unit, and most of the useful data lines have bare solder test points that are easily soldered to. These data lines include AVRCP control lines over ASYNC serial and PCM I2S signals. 

    The test points are on the bottom on the PCB. This is the top side showing the Bluetooth module. It's worth noting that this module does not have a built-in antenna as the RN-52 does. There is a U.FL connector nearby for the antenna that is mounted in the front panel.

    Here is the bottom side of the PCB. 

    Box 1 is the UART that I found AVRCP data on. The track info is tranferred as normal ASCII data. Box 2 shows what appears to be a UART but I wasn't able to get anything useful from it. The silkscreen in box 3 tipped me off to the possibility of there being I2S data lines there. I recorded a little bit of data from the for points in box 4 and it appears to be valid I2S. It would make sense becuase most CD players use I2S to transfer audio data around. You can also see some silkscreen that implies some other functions can be hacked into with little work. 

    The front panel of the unit connected to the main PCB with a single ribbon cable. It has its own µC that seems to interface everything on the front panel to the main board. In the picture below you can see the RX/TX lines that I ended up getting data from. 

    When I connected the logic analyzer to it, I assumed that it would be communicating using standard 8N1 ASYNC. But all of the data I captured had framing errors. My initial thought was that the two controllers were communicating with 10 bits instead of 8, but this only helped about half the framing errors. Not to mention, the data the analyzer came up with seemed random. After fiddling with the analyzer...

    Read more »

View all 11 project logs

Enjoy this project?



Jay Mullen wrote 04/03/2016 at 17:32 point

Awesome project, this is exactly what I am looking to do. Modernize controls & display of AV in a car that does not have it as an option...or never had the technology available.

Super cool. Keep up the good work.

  Are you sure? yes | no

Thaddaeus wrote 12/11/2015 at 02:18 point

Great project, I was curious to see a practical application of completely replacing the head unit, I haven't had a lot of time to play around with my own project lately, but I'm interested to see what can be done to get functional use out of my steering wheel stereo controls, ultimately I'd like to re-purpose my track seek buttons to work as a means of navigating the system, but I still don't have all the specifics of that issue entirely worked out just yet (haven't had time to pour over wiring diagrams). You definitely have a solid work in progress though, I hope to see more updates on it.

  Are you sure? yes | no

millab wrote 05/31/2014 at 10:58 point
Hey, thanks for subscribing to my project!
I actually completed a similar build in my FJ Cruiser about 18 months ago. I used a Google Nexus 7 connected through bluetooth to the standard head unit. The steering wheel controls work, and I was still able to pair my phone which will take over control when a call is received.

All I had to do was make a new bracket for the standard head unit, which made it sit further back into the dash. Then I inserted the 7in tablet in front of the head unit.

If you need any questions answered I am happy to help

  Are you sure? yes | no

AndrewMcDan wrote 05/31/2014 at 16:52 point
Yeah, I had considered leaving the head unit and doing exactly as you did. The one big reason I chose not to was that I usually don't take my phone out of my pocket when I get in my car and the "Answer Call" button is on the face of the unit. It would be a little annoying to have to dig my phone out to answer a call.

Thanks for the input and please, if you find any aspect of this project that you think I could do more efficiently, let me know. This is why I'm on

  Are you sure? yes | no

millab wrote 06/01/2014 at 00:27 point
Oh ok, with the FJ Cruiser there are answer/hang up buttons on the steering wheel so that got around that problem. Will keep an eye on your progress :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates