The Treehouse Blog


Initial Software for the Android Car Radio

by on May.05, 2013, under Linux, Radio


Let’s face it, Android is far more interesting when you have full control of it.  The software pre-loaded on the unit does not provide root access.  Hal9k_ on the xda-developers forum has created a software update that provides root and adds some additional features.  To perform the update, you place the files on the root of the removable SD card, power off the radio by holding down the volume knob/button, and start the radio by holding down the volume knob/button and the menu button simultaneously.

Network Connectivity

Not exclusively a software topic, but I’ll cover this here.  For full functionality, it is desirable to have the radio with internet connectivity whenever possible.  When at home, this means a WiFi connection to the home network.  The location of the WiFi dongle provides decent signal strength to the home network from the usual vehicle locations and works as well.

For mobile connections, it is possible to use a 3G USB dongle to provide the unit with network connectivity.  I don’t have such a dongle, and with mobile provider pricing structures such as they are, I have no intention of providing my car radio with a dedicated service at this time.  The alternative is to tether to my cell phone, which is also an Android device.  Right now, I’m using MacroDroid on my Nexus 4 to enable and disable the WiFi hotspot feature automatically.  The rules I have are:

  • On Bluetooth connect to the Radio, and WiFi is not connected on the phone, enable the hotspot.
  • On WiFi disconnect, and Bluetooth is connected to the Radio, enable the hotspot.
  • On Bluetooth disconnect from the Radio, and hotspot enabled, disable the hotspot.

This tries to prevent enabling the hotspot in cases where WiFi is available, but properly turn on the hotspot if driving out of range of the home WiFi.  So far it seems to work relatively well.

One additional area of interest is how to show the cell phone signal strength on the radio.  I found the Tether Signal Strength app that provides a capability for this.  Unfortunately, the current design of the app makes the signal strength hard to see, and worse, is not easily automated to start on boot on the radio, or start on hotspot on the cell phone.  I think either improvements to this app, or maybe a new one entirely, will be the solution.

GPS and Navigation

Always-On GPS

Android generally will only enable the GPS receiver when there is an application actively using it, primarily as a power-saving measure.  Even though there are no real power usage concerns with this device, the default software still disables the GPS receiver when not in use.  Since GPS takes some time to acquire, I really prefer it to be active the entire time the device is running.  I found the ActiveGPS app to meet this need, but there are probably other 3rd party apps that do just as well.  As with the rest of my Android devices, I installed GPS Status to be able to check the received signal strength from the GPS constellation.


Google Maps and Navigation are certainly part of the solution for navigation on an Android device.  I did want to try an App that provided similar functionality to the Garmin nüvi (ad) that I’ve used for years.  While Garmin does sell navigation software for Android, from what I can tell, the reviews of recent versions have not been great, and it is also not currently available for customers in the US.  I wanted something that would be fully functional when working without an Internet connection, since when I’m off exploring in the mountains and valleys around here, it’s fairly common to be without connectivity.

Currently, I’m using Sygic for this purpose.  I’m not entirely sold on it, but it does appear to be functional.  Depending on how actual use goes, I may just use it as a backup for the more accurate Google Navigation.  Here are some notes, observations, etc:

  • The navigation does not appear to be extremely efficient.  I plugged in a destination of Renovo, PA from home, and the proposed route was something like 2 hours longer (and very far out of the way) as opposed to Google or the Nuvi.
  • It has a small battery display which I have not found a way to turn off.  It’s obviously irrelevant for the car radio.
  • By default, it notifies on sharp turns and railroad crossings.  While it starts out kind of novel, it quickly becomes annoying.  Fortunately, these can be easily disabled in settings.

The jury is still out on this.

Vehicle Sensors and Diagnostics

It seems that the application for OBD2 stuff on Android is Torque, and it is pretty awesome.

OBD2 Interface

The most common way of connecting to OBD2 seems to be to use a Bluetooth to OBD2 bridge.  The Bluetooth capability of the radio, however, is not accessible to Android.  The updated software provided by Hal9k_ provides a work-around to this, by adding the kernel modules necessary to support Bluetooth.  You are then able to use a Linux-supported Bluetooth USB dongle.  You need to install a 3rd party Bluetooth manager application, since the Bluetooth settings applet is not included in the software.  When paired with an OBD2 Bluetooth adapter (ad), you’re able to use Torque.

There are some apparent downsides to this approach.  For the cheap adapter I bought, it is powered by the OBD2 port and stays active even when the engine is off.  I’m not sure how significant of a drain this would be, but I would prefer not to deal with it.  The second issue is related to security.  The Bluetooth adapter uses a fixed, default security code for pairing, and appears to always be available to pair.  It would not surprise me at all if the OBD2 could be abused to do terrible things, such as unlock the doors, by someone knowledgeable.  Sure, this is probably a very small risk, but I’d prefer to avoid it.  (I think those of you with OnStar are insane from a someone-else-can-control-my-vehicle-remotely standpoint).

Alternatively, Torque also supports OBD2 to USB adapters.  Hal9k_’s software update also provides the pl2303 kernel module, which supports the USB to serial bridge used by many of these adapters.  If you have one of these, the only additional thing you need to do is configure Torque to use it.  While Torque does have USB settings in its menu, these appear to be insufficient and you need to create a configuration file that makes it think it is a Ca-Fi unit.

echo "finland_rds_ru" > /etc/carit_version2 ; chmod 644 /etc/carit_version2

Alas, the OBD2 to USB adapter (ad) that I bought does not use the pl2303, and instead needs cp210x.  I did successfully build and install the cp210x kernel module, but it was an ordeal that deserves its own article.  The adapter is powered by the USB, so it does not draw power when the vehicle is off.

Sensor Monitoring

Torque provides a variety of dials and graphs that can be used to display sensor data.  You place them on a grid on the screen, and can swipe to page between multiple screens.  I found it difficult to get accurate placement using the resistive touchscreen, so I used a USB mouse for most of the screen setup.  As far as the sensors themselves, I was just recently able to add what seems to be a transmission fluid sensor reading.  I still can’t find a usable PID for fuel level, which I found odd, since my truck and previous car both support the general PID for this, which is apparently not common.  I would also like to find a way to show more details about transmission operation, such as current gear.

Software-Defined Radio

When I saw Doug give a short presentation on SDR on Android using the same RTL2832U/E4000 USB dongles that I have laying around, I knew this had to be an objective of my Android-in-the-car project.  On the face of it, it looked as if it could be a problem.  Most of the information on the SDR Touch software was on Android 3.0 or higher, while the head unit still runs 2.3.  I also was concerned that the device would not have enough CPU power to make it work, or that the USB port would not have enough power to keep it working.  Fortunately, these concerns were mostly unwarranted.

Out of the box, the software did fail to work.  After some Google’ing, it was determined that the chmod that comes with this system does not support the -R option.  This caused the software to fail when trying to change the permissions on the USB devices.  Mounting the /system file system as read-write, and then linking chmod to the busybox binary, resolved the problem.

As far as CPU usage was concerned, it was not as bad as I feared it might be.  Here is a table of observed CPU usage of the androsdr2 process, when performing NFM demodulation with different settings.  In all cases, the rtl_tcp_andro process is running at a steady 5% CPU utilization, which is not included in the numbers below. Also, as one would expect and hope, when the app is not in the foreground it behaves as if the spectrum display is off.  There was a noticeable, but not substantial, degradation in audio quality with the Low CPU option enabled.

SDR CPU Selection Spectrum Display CPU Usage
normal on 57%
normal off 42%
low on 33%
low off 15%

The user interface of the software is not very well suited (yet) for use in a vehicle.  Too much user interaction is required to operate it.  When loading the software, it does not automatically enable the radio.  You have to select the “Off” button to turn it on.  It does remember the last tuned frequency, but it does not remember the bandwidth last selected.  In my case, to listen to the local weather band transmissions, it greatly improves the intelligibility of the audio to narrow the reception bandwidth.  This requires something of a precise dragging motion on the screen, which is not trivial with the resistive screen, and is not really possible while the vehicle is in motion.  Some minor improvements in the app could really improve this – such as remembering the last bandwidth, enabling the radio reception upon the app starting, and providing a means of having pre-sets of frequency and other parameters for listening to favorites.

Overall, this is still an amazing capability to be able to add to a car radio head unit.

SDR Touch listening to 162.55 MHz

There is probably more to say on this, but the article is long enough.

Comments Off on Initial Software for the Android Car Radio :, , , , , , , , , , more...

Android Car Radio

by on Apr.28, 2013, under Computers, Linux, Radio


While shopping for my 2011 Toyota RAV4, I tried out vehicles that both had and did not have the factory navigation package. I decided that I basically didn’t like it. The one I purchased did not have the navigation package, but did have the “JBL” audio package and Bluetooth hands-free support, which seemed to work well.  After having some annoyance in mounting my aging Garmin nuvi (and having it stick properly), problems with the factory radio sometimes not working, and probably some pent up desire for a “project”, I embarked on finding a alternative.


I gave up on any cellphone-only solution since I needed to replace the factory radio anyway, and did not wanted a solution that appeared integrated (e.g., did not involve something with a windshield or bean-bag mount).

One set of options are the new head units that tether to your cell phone, allowing you to control your cell phone through the in-dash unit.  These generally involve HDMI output from your phone and use a Bluetooth connection for communicating touch screen interactions.  An example is the AppRadio series from Pioneer.  In researching this, it appears that the functionality is somewhat crippled out of the box, and that with a 3rd party app (ARLiberator).  I do think this notion has promise (and it did finally push me over the edge to buying the Slimport to HDMI adapter that works with my Nexus 4), but if I had to plug in my phone for each use, it mostly would be left undone except for extended trips.  This just did not seem to be the right answer.

The next option was a head unit that natively runs Android.  There brand name in this field seems to be Ca-Fi.  There are a number of knock-offs of this brand, the most common of which is being actively discussed on xda-developers.  I chose to get one of these units, and I will detail that adventure in upcoming articles.

Comments Off on Android Car Radio :, more...

Isn’t AMPS dead yet?

by on May.10, 2010, under Radio

It was with some great fanfare that AMPS met its death on February 18th, 2008.  But did it really die?  As far as I can tell, all that happened on that date was that the FCC no longer required cellular providers to make AMPS available, and many did eagerly turn it off.  But, unlike the conversion to digital television, there appears to be no requirement at this point for providers to abandon AMPS if it is still making them money.  That being the case, are there any AMPS providers still out there?  Public filings (available here) concerning AMPS status were made prior to the sunset date and reveal that some companies had a lot of AMPS customers still and had no plans to turn the service off.

Why do I care?  Because I loathe 47 CFR 15.121 and would like to see it abolished.  This is the section of FCC regulations that forbids the manufacture of devices that can receive, or be easily modified to receive, cellular frequencies.  This requirement only covers the Part 22 Cellular Service (824-849, 869-894 MHz) and not the all-digital PCS and AWS bands that cell service has expanded into.  With AMPS, conversations were transmitted using FM, and so could be easily decoded by any FM receiver that could tune to the appropriate frequencies.  With the digital services, more sophisticated handling of the signal (and even decryption) would be required, which apparently made it unnecessary to have the same kind of regulation.  As far as I know, this is the only restriction placed on what frequencies can be tuned by a receiver.  On freedom grounds alone, I have a big problem with that.  If AMPS does finally die – and I hope it does – I hope that 47 CFR 15.121 can die with it.

Comments Off on Isn’t AMPS dead yet? :, , , , , , , , more...

TM-D710A Transmit Inhibit

by on Apr.06, 2010, under Radio

I did recently get a TM-D710A and have been playing around with it.  I have found one missing feature that would be nice, and a workaround for it.  Suppose you want to add an amateur frequency as a memory channel for listening/scanning purposes only, but don’t want to ever accidentally transmit on that channel.  I think it would make sense to have a flag that could be set on a per-channel basis to inhibit transmission on that channel, but unfortunately there is not.  I have come up with a viable workaround though.  It is possible to configure a memory channel as “split” – with a receive frequency and a separate transmit frequency.  It is required that both frequencies be on the same band… though I’m not sure why – this would be a useful feature as well, so that one does not need to tie up both sides of the radio for half-duplex cross-band applications.  Anyway, it is possible to configure the transmit frequency to be within the same band and still outside of the portion of the band which the radio can transmit on.  This results in a beep and no transmission when PTT is pressed – which would be exactly the desired behavior of a transmit inhibit flag.

Comments Off on TM-D710A Transmit Inhibit :, , more...

TM-D710A vs FTM-350R

by on Feb.23, 2010, under Radio

I’ve been checking into some mobile amateur radio rigs recently.  I had for awhile been intending to get the Kenwood TM-D710A, but a new contender has recently entered the market, namely the Yaesu FTM-350R.  I don’t presently own either rig, but as there is a lack of direct comparisons between them currently posted online, I wanted to share my research.  If you find any errors, please let me know so I can correct them.  If someone who actually owns or has used both rigs eventually posts a comparison, I’d like to link to it as well.

RF Capabilities

Both rigs provide 50W power on the 2-meter and 70-cm ham bands.  The 350R additionally can transmit 1W on the 1.25-meter band.  The extended receive ranges are also divergent, with notable differences being the lack of 13cm/1.3GHz band (and possibly the 33cm/902MHz band per a footnote) coverage on the 350R .  There are published mods to provide extended transmit capabilities for both units.  Both radios have a cross-band repeater capability.

Kenwood TM-D710A Yaesu FTM-350R
Transmit 2M – 50W
70cm – 50W
2M – 50W
1.25M – 1W
70cm – 50W
Extended Transmit Range 136-174 MHz
400-470 MHz


136-174 MHz
420-470 MHz


Receive Range Band A: 118 – 524 MHz
Band B: 136 – 524 MHz
Band B: 800 – 1300 MHz (excluding cellular)
0.5 – 1.8 MHz (AM Radio)
76 – 108 MHz (FM Radio)
108 – 250 MHz
300 – 1000 MHz (excluding cellular)


APRS is the feature that places these two radios in their own category.


One aspect of APRS is the use of a GPS for automated position reporting.  In the D710A, an external third-party GPS receiver (such as the GPS-710) needs to be connected to the control head.  For the 350R, Yaesu sells their own FGPS-1 module which installs in the back of the control head.  Documentation indicates it is possible to use the FGPS-2 module, which is the GPS receiver used on the VX-8R, but the required CT-133 cable could not be located from various retailers websites.  It does not seem to be readily possible to use a non-Yaesu GPS receiver.  Personally, I think having a GPS connection available from the radio body would make sense.  My intended control head mounting location is not likely to have the best view of the sky.

Digipeater Functions

The D710A appears to have a robust set of digipeater functions.  This feature would primarily be useful in situations where a temporary digipeater was needed to serve an area not covered by a permanent digipeater.  The 350R appears to not have this feature.

Other APRS Features

The D710A supports QSY information, weather station attachment, and a Kenwood GPS format for tactical display integration with AvMap G5.  Both radios are equipped with the SmartBeaconing feature which bases position update intervals on the speed of travel and direction changes.  The 350R has some navigation enhancements providing direction indication to other stations.


The built-in TNC on the D710A can be used by a PC or other external device, and supports KISS.  The 350R supports a “modem” mode for both 1200 and 9600, which hopefully means it can be used as a TNC as well, but I’ve not found anything explicitly confirming success with this.

Software / Firmware

These modern radios, like most recent electronics, have some computer-ness to them.  Programming software and firmware updates for the D710A are freely available from Kenwood.  These updates have added new features to existing products at no additional cost.  So far, there is no indication of any software available for the 350R[Update 2010-04-24: KC7HP pointed out that software is now available.] The repair for the navigation issue discussed below involved mailing the unit in for repair – for what should be a firmware update.  Given the newness of the product, it is possible that the rolling out of consumer firmware updating is forthcoming, but the situation with the VX-8R upgrade to VX-8DR doesn’t make this prospect seem likely.


It’s only fair to mention that the 350R has an optional Bluetooth module.  The only Bluetooth capability provided is audio, such as the use of a Bluetooth headset for using the radio.  I’d be much more interested in this if Bluetooth data capability of some sort were provided.


The 350R is a really new radio, and that means there is not much information available, and that it has a few bugs and quirks.  Already there are reports that APRS navigation feature leads you in the wrong direction.  There are also reports that the radio will hang, requiring power to be physically removed to reset the unit.


While the 350R does introduce some new capabilities (222 MHz, Bluetooth, integrated GPS, navigation feature), there are still features of the D710 that it seems to lack (digipeating, tactical GPS protocol).  The free firmware/software of the D710 is hard to beat.  Given the quirkiness of the new hardware, and feeling that the features unique to the D710 have more potential use than those unique to the 350R, my inclination would be to get the tried and true D710 if purchasing a unit today.

Comments Off on TM-D710A vs FTM-350R :, , , , , , , , , more...

December 2019
« Nov    


Content Copyright © 2004 - 2019 Brady Alleman. All Rights Reserved.

As an Amazon Associate I earn from qualifying purchases.