Hands Free Phone Accessability

A device + app that allows you to access features of your phone while driving, without taking your eyes off the road.

Similar projects worth following


Operating mobile devices while driving is the cause of a large amount of automobile accidents. Luckily, devices are being made to disable a driver's phone while driving. These devices typically send a signal to a user's phone which disables use while the car is moving. This device makes it almost impossible to operate a mobile phone while driving.

However, these devices are only being bought by the most concerned customers. A vast majority of drivers believe that their phone does not affect their ability to operate a motor vehicle and so they feel like a device that disables their mobile phone is useless.

My device would not disable mobile phones, but instead make it so that drivers are able to access features of their phones without having to take their eyes off the road. This makes it safer for users to operate a motor vehicle and appeals to a much larger audience since this devices makes it easier to change music and answer phone calls while driving.

  • 1 × APDS9960 A Gesture + Proximity + RGB Color Sensor
  • 1 × HC-06 Serial Bluetooth Slave Module
  • 1 × MSP430G2553 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × Android Phone App is being developed for Android
  • 1 × LM1117 Power Management ICs / Linear Voltage Regulators and LDOs

View all 8 components

  • Creating The App

    Noah Pena08/15/2015 at 22:00 0 comments

    With the hardware decided on I looked to making a mobile application to control the different phone functions. Since I was using a Serial Bluetooth device, my app would have to process that data and then call the commands on its own, instead of the bluetooth module having the power to do this.


    My goal for this project is to make it so the user can do as many things with their phone without having to look at their phone as possible. The features that I had in mind were:

    • Controlling Music
    • Making and Receiving Calls
    • Handling Texting

    This is a large array of features and are among the most common distractions while driving. Before I started implementing these features, there was one big question to answer first...

    Android vs iOS vs Windows

    Since i'm making a mobile app, I need to decide what systems my app is going to be on .

    Android is pretty easy to get up and running with. You can develop for Android on Windows, Mac, or Linux OS so no problem there. The Android SDK is completely free and you can develop using Eclipse or Android Studio (both are cross-platform). To put your app on the market costs a one time fee of $25 which is not much.

    iOS poses a couple of problems for me. For one the iOS SDK is only allowed for use on a Macintosh computer. I don't have a Mac to use so I already cannot develop for iOS. If I did have a Mac the iOS SDK is free to use, however in order to test on a physical device I would need to pay a licensing fee of $99 per year.

    Windows is fairly easy to get up and running with. To start developing for it, you need Visual Studio (which the community version can be downloaded for free) and the Windows Phone SDK (which is free). Visual Studio is only available for Windows (Visual Studio Code will not work). If you're on Mac you can use BootCamp to run Windows and develop on there. Otherwise you can use VMWare or VirtualBox to run a Virtual Machine and develop using that (which is available for Mac and Linux). To deploy your application on a physical device, you only need to register your device (which is free). However to deploy to the Windows Store you need to apply for a Developer's License. The Individual License is most likely what I would use, which only costs $19, however it also comes with limited features, but thankfully the limited features are more for Business Applications and this project won't utilize any of them. The only problem with Windows Phone Development is that I don't have access to a Windows Phone. I can use the simulator, but I wouldn't be able to physically test it with my device.

    There's also a fourth option of using a multi-platform tool like Appcelerator. However this still doesn't solve the problem that I wouldn't be able to test on an iPhone Device since I don't have a Mac computer, and I wouldn't be able to test on a Windows Phone because I don't have access to one.

    As a result, I ended up settling with Android.

    Controlling Music

    With the platform decided, the first feature to implement is being able to control the music. Since i'm using gestures, I want to try and make the gestures as intuitive as possible. The different gestures that are available are UP, DOWN, LEFT, RIGHT, NEAR, and FAR. For controlling the music the different features we want to use are PLAY, RESUME, SKIP, and PREVIOUS.

    If we look at a generic music player, we'll see a couple of things that could give us hints as to which gestures we should use. The Skip Button is facing toward the right and the Previous Button is facing toward the left, so it would make sense if these two buttons were mapped to a RIGHT Gesture and a LEFT Gesture. The play button is in the center so any gesture that is in the middle would work out. So our options are UP, DOWN, NEAR, or FAR. I'm not super sure which one to pick so i'll leave that for later.

    Another thing to consider is what music we are playing. To play music that is saved onto the device, we can just use the default Music Player, however a lot of people use different music players...

    Read more »

  • Connecting To The Phone

    Noah Pena06/28/2015 at 21:06 0 comments

    With the choice of microcontroller all figured out, I needed a way to connect the user's phone to my device. The idea was that the user's phone would connect to the MSP430 + APDS-9960 and then would send different commands to control the phone and music on the user's phone. From there the user would hear their music or phone call through the auxilary cord in their car.


    My first idea at making this work was to send the commands through the phone's USB port. This way the user doesn't have to download an app on their phone for the device to work. However this proved to be very difficult. The MSP430 doesn't have a hardware USB protocol on the chip so USB would have to be bit-banged. Even if the MSP430 did have a hardware USB or I could big-bang the protocol, sending commands through USB proved to be a non-trivial task, even on a desktop computer. I figured this would be too much trouble than it would be worth.

    Media Bluetooth

    I then turned to using Bluetooth to send commands to the phone. I didn't know much about bluetooth so I had to look up if there was a way to send media commands to the phone such as Answer Call, Decline Call, Pause Music, Skip Track, etc. It turns out there is. The proflie in particular is called Advanced Audio Distribution Profile (A2DP). I looked up a couple of Bluetooth modules that support this profile however, they all seemed to expensive for this application. The MSP430G2553 is $0.70 and the APDS-9960 Module is $15 so the current cost of the device is around $15.70. A particular bluetooth module I was interested in was the RN-52:

    This module cost $25 on Sparkfun which was more than my device cost already! Other stores had similar prices for this module and others that were similar to it, so I decided to look for another solution.

    Serial Bluetooth

    With media bluetooth profiles costing too much for this project I decided to look at another bluetooth profile to send data to the user's phone. In particular I thought of using a Serial Port Profile (SPP). This profile is very simple as it essentially imitates an RS-232 cable. I originally thought that perhaps I could send different AT Commands to control different functions on the phone, however I quickly learned that you would need to write an app in order to make that possible. I really didn't want to have the user download an app (nor did I really want to write one), but I found that Serial Bluetooth Modules were much cheaper. The two that I came across were the


    and the HC-06:

    If you think these two modules look exactly the same, then you're right because they are the same! The only difference between them is the firmware that is loaded onto them. The HC-05 is able to act as a Bluetooth Master Device and a Slave Device, while the HC-06 is only able to act as a Slave Device. This means that the HC-05 can connect to multiple devices and send and receive data to multiple devices, while the HC-06 is only able to connect to one Master and send and receive with only the master. For this project we only need the device to send data to the phone so either devices work for this case. I ultimately decided to use the HC-06 for this project because it is typically cheaper than the HC-05 (not by much, but still on average, cheaper).

    Since I am using a Serial Port Profile bluetooth device, I need to create an app which will relay the different gestures to commands on the phone... Which will be in the next project log!

  • Which Microcontroller?

    Noah Pena06/02/2015 at 06:40 0 comments

    Estimating Requirements

    In order to make this device possible, we need a micrcontroller to control the Gesture Sensor and Bluetooth Module. The Gesture Sensor uses I2C protocol with an extra pin needed as in Interrupt Pin. The Bluetooth Module uses UART to send and receive data which takes two pins, but we only ever need to send data to the phone so only one pin is needed (TX). Overall that is 5 pins that are needed. Both of these devices run off 3.3V so a microcontroller that can supply 3.3V is needed. The device would also be on for long periods of time so the device would need to run off of a battery.

    Our requirements for our micrcontroller look something like this:

    • 3.3V Operation
    • At least 5 pins
    • Supports I2C and UART
    • Small form factor

    The first microcontroller that fit all of those requirements was the Teensy 3.1

    Teensy 3.1

    The Teensy 3.1's statistics can be found on the PJRC webpage for the Teensy 3.1 :

    The Teensy 3.1 fits all of the requirements of this project so I decided to use the Teensy 3.1 as my microcontroller of choice.

    Since the Bluetooth Module uses UART I was able to use the "Serial" Library provided in the Arduino Library. For the Gesture Sensor, I used Sparkfun's APDS-9960 LIbrary:

    I used the "Gesture Test" Example and the code worked like a charm! I was able to receive the different gestures to my phone via Bluetooth! However, the Teensy 3.1's cost lead me to search for other microcontrollers. Although I was able to prove that my project is able to operate how I expected it to.


    With the Teensy 3.1 costing too much, I decided to look for microcontroller's with minimal requirements. The Teensy 3.1 boasts 256kB of Flash and 64kB of RAM, however my device didn't need that much Flash or RAM, so essentially the cost for the extra Flash and RAM is waisted. Because of this I stumbled upon the ATTiny85V

    The ATTiny85V is an 8 pin IC and costs a lot less than the Teensy 3.1. However that cost also means lower specifications

    While the specs on the ATTiny85V on much lower than that of the Teensy3.1, we don't need a very powerful microcontroller for this device so the ATTiny85V should do the job.

    In order to program the ATTiny85V we can use an Arduino Uno to act as a programmer so that we can upload code to the ATTiny85V. I set up the two microcontrollers like this:

    However, a couple of problems arose when using the ATTiny85V as the microcontroller of choice.

    The first problem was that the ATTiny85V actually didn't have a hardware I2C or UART. Instead, the ATTiny85V uses USI (Universial Serial Interface) to emulate I2C or UART. This means we can't use the default library for I2C and UART. For UART I used Arduino's "SoftwareSerial" Library which left the USI open for use as an I2C bus. For I2C I used Adafruit's "TinyWireM" Library:

    The second problem was that the APDS-9960 Library was only meant to be used with the Wire Library, however the ATTiny85V does not support the Wire Library. To solve this, I rewrote the APDS-9960 Library using the TinyWireM Library. The only parts that really needed to be changed with the Init, and Wire member functions. Once I did this, the library compiled.

    The third problem was that the TinyWireM + APDS-9960 + SoftwareSerial Libraries required more than the ATTiny85V's 8kB of Flash. In order to solve this, I deleted all of the RX parts of the SoftwareSerial Library since I am only using the TX pin. This was fortunately enough and the size of all of these libraries together was around 7kB.

    The final problem was that the microcontroller would restart in the middle of trying to guess a gesture. I first started to solve this problem by modifying the APDS-9960 Library to use the Modified SoftwareSerial Library in order to debug the program. From there I saw that the FIFO would start to fill up, but then eventually restart the entire program from...

    Read more »

  • Beginnings

    Noah Pena06/02/2015 at 04:03 0 comments

    My idea for this project began when I started playing around with the APDS9960

    The APDS9960 is a RGB Color/Gesture Sensor. It supports 6 built in gestures and I thought it would be perfect for some sort of user accessability project. I eventually thought of using it in the car to change the music without having to press a button or look at your phone, and I started to expand on that idea until on got this project idea. The APDS9960 module i'm using is a breakout board from Sparkfun :

    However I needed a way to connect to the user's phone in order to handle their music program and so I decided on using bluetooth to connect with the user's phone. Bluetooth modules aren't terribly expensive and are (for the most part) easy to use. I decided on the HC-06 Serial Bluetooth module because of its cost.

View all 4 project logs

Enjoy this project?



Harish solpure wrote 09/08/2017 at 15:38 point

what is the application used in mobile to to use our mobile hands free??

  Are you sure? yes | no

sdafdsf wrote 06/04/2016 at 21:36 point

Hi ! Awesome project. Can I ask you why didn't you use the ATmega328P ? 

  Are you sure? yes | no

Noah Pena wrote 06/11/2016 at 01:57 point


I mainly didn't use the ATmega328p because the msp430g2553 is slightly cheaper. I also was considering making the project run on a battery instead of just via the USB cable, and the MSP430 uses less power and current consumption. 

However, this project can easily recreated with the ATmega328p. I originally wanted to do it with the ATTiny85, but I had trouble with fitting the code with the RAM and Flash constraints. 

  Are you sure? yes | no

Parkwoodrehab1 wrote 07/14/2015 at 16:39 point

While the effort of building something like this is very educational an satisfying for sure - the basic premise is dubious.  It is actually the act of talking on the phone that contributes to many many accidents.  It is not all about looking at the phone to dial or text.  

  Are you sure? yes | no

Noah Pena wrote 07/15/2015 at 01:14 point

I definitely agree! Any sort of distractions greatly increases the risk of accidents. The real solution to this problem is something that could disable all distractions, but that is unrealistic. People that are concerned about their safety will make sure they are not distracted behind the wheel, but unfortunately they are the minority. 

I live in a city where texting and talking on the phone while driving is actually illegal, yet even when presented with the facts about how dangerous distractions while driving are, people will still choose to put their lives at risks. This device is mainly for those people, who won't be interested in a device that disables their ability to use their phone while driving, but would be interested in a device that makes using their phone while driving easier, while *secretly* lowering their risk of an accident (if not by a little bit). 
Even a small amount can make a difference =)

  Are you sure? yes | no

Parkwoodrehab1 wrote 07/15/2015 at 15:59 point

With cellphones and driving, we are where drinking and driving was in the 1950's - illegal but everyone does it.  Eventually is needs to become 'dispicable"  but I fear that Apple Carplay and mfr carkits are just making it seem more acceptable.

I build alot of battery powered tech.  If you are using batteries I would suggest ditching linear regs and using a buck-boost regulator like those sells.  You can run a battery set over a good range to get the most life from the cells.   Don't forget surge and reverse protection -  I use a reversed pchannel FET with a slow-on rc leg.

  Are you sure? yes | no

Noah Pena wrote 07/18/2015 at 02:35 point

Even driving under the influence is still a big problem. It's hard to make using your cell phone while driving "dispicable", because cell phones play such an important part in our lives. 

Thank you for the tips! I'm not sure whether I am going to power it by batteries or by the car electric jacks, but I ordered a buck-boost regulator and some other parts just to try out both options.

  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