Monday, June 10, 2013

Live Streaming TV for the Dodge Caravan

The 2010 Dodge Caravan SXT I recently acquired has an interesting feature - a built in "Vehicle Entertainment System" complete with two rear screens, two DVD players, two aux video/audio inputs, and multi-channel IR headphones.

This is all cool, but who wants to be stuck watching things they happen to be carrying around on DVD?  This is 2013, the age of streaming media!  Immediately, I started pondering how I could bring this system up to date with the current state of ADD-inducing, "always-on" streaming media entertainment!

I. Video in Motion

First thing's first.  The Chrysler/GM "MyGig" system has a Lawyer-induced feature of disabling any video from the head unit when you put the vehicle in drive.  That's rather annoying!  I don't condone watching a movie while you're supposed to be driving, but I'd rather that I dictate to the technology what to do, not the other way around.  Thankfully, there are a couple of companies that make products to fool the head-unit into thinking you're never actually in drive.  I settled on the NAV-TV Allgig.

Installing the Allgig only took about 20 minutes, and most of that was spent opening the console up to pull the head unit out so that I could get at the wiring harness.   The rest was simply a matter of disconnecting the head unit, connecting the Allgig's included wiring harness between the head-unit and the factory harness, and finding a position behind the dash to secure the Allgig unit itself.

II. Streaming Video

So, how to get streaming video?  A coworker had purchased an interesting Android 4.0 device from Zero Devices.  It's a "mini PC" that runs Android, has a USB port for keyboard/mouse input, and an HDMI output port.  [ product link]  It's perfect except for two things:  A) It doesn't have built-in cellular data service.  B) It outputs only over HDMI, whereas the Dodge VEH aux input is standard-definition Composite input.

A. Data Access
I have WiFi Tethering on my cellular data plan, so I can share my existing cellular data service with this device when I'm in the car by pre-configuring the Mini PC with the same WiFi attributes I use for tethering on the phone.  Then I just have to turn on "Mobile WiFi Hotspot" on my phone when I want streaming media in the van.

B. Video Conversion
Thankfully, "there's a device for that" too.  Another Amazon search turns up a well reviewed HDMI to composite A/V converter that seems to be low power and work at any input resolution.  [ product link]

C. Video Apps
I tested the following apps on the device:
  • SlingPlayer for Phones
  • Netflix
  • YouTube
All three worked well over the mobile hotspot with my Verizon data service.  SlingPlayer is the "killer app" for this configuration for me, since I have a SlingBox Pro already.  It allows me to remotely watch live TV from my home DVR.

III. Putting It All Together

I played with a couple of different power / connection combinations of the two devices.  The one that had the least amount of "ground loop" noise was to power the Mini PC with it's included 2A AC adapter, and let the HDMI to Composite converter draw power from the HDMI port.

When I tried powering either devices using a 12V -> USB power device instead, I ended up with either an annoying "buzz" or could audibly hear the digital data transfer over the car's speakers.   A ground loop isolater would probably work if I only had the audio connections, but I don't know a good way to ground-loop isolate an NTSC composite video connection.

Besides, using the car's built-in AC inverter has an advantage over the 12V power port-  there's a switch to turn it on/off in the center console.

IV. Input Device

When I first set this up, I left a Logitech mouse plugged into the Mini PC for control.  This proved to be less than ideal when I wanted to launch Android apps from the front of the vehicle.  I found this mini wirless keyboard-touchpad combo which fits nicely in the center console storage bin. [ product link]

It worked with the Android 4.0 Mini PC right out of the box.

IV. Demo Shots

The Zero Devices Mini PC boots up when I turn the car on:

 Launching Netflix:

Netflix movie playing:

Live TV playing via SlingPlayer

Have fun!  And remember:  Don't watch TV while you're driving!

Tuesday, May 28, 2013

Digispark and programming a raw ATtiny85 with Arduino

I was a backer of the Digispark last year, and love these little devices.  For those who haven't seen them, the Digispark is a tiny ~ 1 inch square board with an Atmel ATTiny85 microcontroller, male USB pins, and custom bootloader to allow it to be programmed directly from a computer USB port.

More succinctly- It's the smallest, cheapest, and easiest way to build a simple Arduino project that doesn't require the larger Atmel microcontrollers.

After playing with my initial three Digisparks for a while, I started coming up with uses for the ATtiny85 that made even the Digispark overkill.  For these simple circuits I didn't want (or need) the bootloader or the USB IO.  I just wanted a way to flash my code onto the raw ATtiny85 and move on.   Enter littlewire - a simple Atmel AVR programmer based on the ATtiny85 and it's ability to implement USB in firmware.

Littlewire uses the same IO pins as the Digispark, so you can actually just flash the existing littlewire firmware onto a digispark, and then immediately start using it as an AVR programmer to program raw Atmel chips!

Below (for my own recollection, honestly) are the steps I took to set this up and my notes about programming raw ATtiny chips with Arduino.  Note: I'm doing this on a 64-bit Linux system.  The steps should be similar for another OS, but YMMV.

Step 1.  Set up & test the Digispark Arduino environment

I just used the pre-built Arduino package with the digispark binaries from   The important part here is getting working micronucleus and avrdude binaries that can talk to the custom digispark bootloader.

Step 2.  Push the littlewire firmware to the Digispark

After you have confirmed that you can program a digispark, you'll need to re-flash it with the littlewire firmware.  The only file you really need is main.hex from the 'firmware' directory, currently located at

The 'micronucleus' binary you got (or installed) with the Digispark Arduino package is the magic command to push a pre-compiled .hex file to a digispark.  So, from a command prompt, simply run:
micronucleus main.hex
and then plug in the digispark you wish to re-flash.  (Substitute the full path to main.hex if necessary.)  NOTE: My laptop has some minor timing issues talking to the digispark, so it actually took three or four attempts to make micronucleus successfully upload the firmware.  

Once this is successful, the Digispark will identify itself on the USB bus as a USBtiny after the initial Digispark bootloader 5 seconds is up.

Step 3.  Install Arduino support for the ATtiny* family of AVRs

At the ATtiny AVR support to Arduino.  I used the library available here:
  •  create a hardware directory called 'attiny'
  •  extract the attiny support library into the attiny/ directory
  •  edit / create "boards.txt" under that directory with the entries from "Prospective Boards.txt"
Note:  The MIT High Low Tech blog guys apparently have their own Arduino ATtiny library as well, which should also work.  I haven't compared them.  [Anyone used both?  Let me know the difference!]

You should be all done!  Verify you can complete the steps below:

Programming AVRs with your new programmer

Connect the Digispark-Littlewire to a chip to be programmed:
DigiSpark => ATtiny85
    p0    => pin 5: PB 0 (MOSI)
    p1    => pin 6: PB 1 (MISO)
    p2    => pin 7: PB 2 (SCK)
    p5    => pin 1: PB 5 (RESET)
Naturally, you'll also have to supply +5V (pin 0) and GND (pin 4) to the target chip as well.  You can safely leech these from the 5V and GND header pins of the Digispark to use the USB power.

From within the Arduino interface:
  • Select Tools -> Programmer -> USBtinyISP 
  • Select Tools -> Boards -> ATtiny85 (xxx)  for the appropriate settings you want.
NOTE:  If you select a new clock speed, you'll have to change the fuse bits on the processor to set them.  The Arduino "Burn Bootloader" command will do this for you if you used the library I did.  Otherwise, set the fuse bits yourself using avrdude from the command line. 
  • Upload!  You're done!
One big advantage to using an AVR programmer in this configuration is that you can leave the AtTiny85 plugged in and re-program it at will, since the AVR programmer uses the pin 1 (RESET) pin to reset and reprogram the ATtiny85.

Conversely, the drawback is that you lose the use of pin 1 as an I/O pin (D5) unless you want to set the fuse bit to disable RESET - at which point you can no longer program it using the AVR programmer.  

You can get DIP package ATtiny85 microcontrollers for cheap from all sorts of places.

Have fun! is now hosted on Blogger!

For those of you who follow my (neglected as of late) blog, you may have noticed some downtime lately.   My previous web hosting provider was being rather fascist about controlling the DNS for the domain names that I own, so I decided to re-take control of them and move my blog elsewhere.

Blogger seemed like the easiest choice, as I have tired of maintaining WordPress on my own and never really liked it anyway.

The move required me to export all my old posts, modify them to re-link all the static content that I had hosted elsewhere, convert it to Blogger-compatible format, and then import it into Blogger.  It seems to have gone relatively smoothly, but feel free to send me a message if something you're looking for is gone or doesn't work.

On the positive side, I will probably go back to blogging cool stuff again, since I'm back on an easier platform to do it from.

 - K.C.

Saturday, January 12, 2013

Accessing Google Cloud SQL externally from Python

I started playing with Google Cloud SQL recently, hoping to use it to tie together a data collection application I run on a home server with an Google AppEngine interface for querying the data.  The problem came when I realized that the only external interface into Cloud SQL is via a JDBC driver, and my program was written entirely in Python.

After some toying around, I successfully got the Google Cloud SQL JDBC driver to work from within Python 2.7 under the Python JayDeBeApi module and jpype.

I'm documenting the final steps here in case I need them later.  YMMV

  • Set up a Google Cloud SQL instance and database.

    • This will also require you to register a project in the developer console, and enable billing if you haven't already.  I'm using the temporarily available free trial of Cloud SQL, but you have to have billing associated with the account in case you exceed the free trial quota.

On the system you want to connect to Cloud SQL from:

  • Make sure you have a working JVM environment. (I'm using openjdk-1.6-amd64 on Ubuntu 12.04 64-bit Linux)

  • Download and install JPype

  • Download and install JayDeBeApi

  • Download and unpack the Google Cloud SQL command line tool.  (NOTE: This will also be the .jar file used by python, so make a note of where you put it.)

  • Follow the command line tool instructions to launch the command line tool and connect to your Google Cloud SQL database once, running as the same local user your python script will run as.   This will take you through the OAuth2 flow and store OAuth tokens locally which will be used by jaydebeapi later.

In your python program:

  • Add the path to the google_sql.jar file you unpacked above to the java.class.path in jpype.StartJVM()

  • Connect to your Google Cloud SQL instance & database using driver and URI described on the Google Cloud SQL Connecting from External Applications page.

    • Note:  Pass empty strings ('') for the user and password fields to jaydebeapi.connect() .  What's happening here is that google_sql.jar is using the previously created and stored OAuth2 token on the local filesystem to authenticate.

A q&d python example that works in my environment looks as follows:  (You'll likely have to change the classpath, jvm_path, and insert your database details.)

import jpype
import jaydebeapi

classpath = ('/usr/lib/jvm/java-6-openjdk/jre/lib/'
jvm_path = '/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/'

jpype.startJVM(jvm_path, '-Djava.class.path=%s' % classpath)"hello world")

conn = jaydebeapi.connect('', 'jdbc:google:rdbms://instance/database', '', '')

cur = conn.cursor()

cur.execute('SELECT * from my_table_name')
print cur.fetchall()


The interface exposed by jaydebeapi appears to be the same as the other python DB-API interfaces. Have fun!