April 21, 2013

Introduction

Around a month ago I got this Google Chromebook (mostly because I wanted an easier way to do some testing of the ARM assembler of the naken_asm project I'm working on) so I figured I might as well play around with making a little app at the same time. So my original plan was to make a TV guide app that could show me what's on TV. As an added bonus I could make it so I could click on what I want to watch and a small circuit either controlled by Bluetooth or RS232 could change the channel for me. Unfortunately, I couldn't find a good feed for TV schedules that didn't cost money and I didn't really want to parse someone's HTML to grab it, so I decided to just make an app with icons of the TV channels I might watch and change the channel when I click on those.

Related Projects @mikekohn.net

Explanation

A while back I made a simple ATtiny13 remote control circuit for Samsung TV's so I pretty much just followed what I already learned from that project. I used a timer interrupt which gets called at twice the carrier frequency of a Samsung remote (39.2 kHz carrier frequency * 2 = 78.4 kHz interrupt routine.. NOTE: this is incorrect, it should be 38 kHz) so a simple xor.b #1, &P2OUT in the interrupt routine is all it takes to create the "on" pulse. Unfortunately, unlike the Atmel device, which has a fairly accurate clock, the cheaper MSP430's can't take an external crystal bigger than 50kHz or such so I basically calibrated the MSP430 DCO with an oscilloscope. If anyone wants to copy what I did here, the timer interrupt and RS232 baud rate registers will have to be calibrated also. There are tricks to doing this with a 32kHz crystal, but I didn't feel like messing with that. I really wish TI would make an MSP430G in DIP format that can take 16MHz external crystals :(.

The main program is basically just an infinite loop that reads TX of the RS232. When a character comes in, it gets put into a queue of 16 bytes. The interrupt routine is a kind of state machine where the first state just looks for a byte to pull out of the queue. If something exists it checks if it's a '-' or between '0' and '9'. If it is, it sets the next chunk of data to the next 32 bits to go out: a start marker of 0xe0e0 and a 16 bit code for the button that was pushed. So the next state is 4.5ms of the IR LED blinking at 39.2kHz, the second is 4.5ms off, the next state is sending 32 bits out, and the last state is a pause. Without the pause if the channel has two of the same numbers in a row, it will ignore the multiple numbers. I believe this is because the remote sends the button you push multiple times in a row just to make sure the data makes it to the TV. So if you push '1' on the remote, it really sends '1' '1' '1' '1' incase one of them misses the TV. I noticed this behavior while working on my Sony SIRC project.

The assembly source code below can be assembled with naken_asm using the command: naken_asm -l -o samsung_tv.hex -I$(INCLUDE) samsung_tv.asm where $(INCLUDE) points to naken_asm/include/msp430_old in the naken_asm source tree.

The next step was the Google Chromebook. So other than a Samsung SmartTV app I wrote back in December, it's been a while since I've seen "modern" Javascript. I just have to say, what the hell did they do to such a simple language? To make the language more object oriented, instead of just adding a "class" token and leaving the syntax for a function "function name(params) { }" it's now "var name = function(params) { }". Terrible. Anyway, after sifting through Google's documentation on doing Bluetooth and RS232 through Chrome, I decided on RS232 since it seemed a bit simpler. I could then avoid the whole pairing phase of the Bluetooth and just connect directly to my circuit. After putting my Chromebook in developer mode and connecting my USB-RS232 device I was able to open a shell and see a /dev/ttyUSB0 was added. The code to read from /dev/ttyUSB0 in a Chrome browser app I pretty much just copied from Google's samples. For the most part it's pretty simple and straight forward.

Source code available at the bottom of the page.

Video

A video showing channels being changed on a Samsung TV with a Chromebook. https://youtu.be/oW_qJVzQhIg

Pictures

Here is a picture of the Chromebook running the app.

Here is the small test circuit from the schematic below.

Note: I left out the part number for the IR emitter because I kind of picked a terrible choice for this. The beam on this emitter is so focused that when the remote is so close to the TV it has to be aimed directly at the sensor on the TV.

Note too, the signal can be made stronger by reducing the resistors on the IR part. The IR emitter I used could take much more current but it wasn't needed to prove my test.

Source code
chromebook_remote

Copyright 1997-2024 - Michael Kohn