Chromebook Remote Control
April 21, 2013
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
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.
Source code available at the bottom of the page.
A video showing channels being changed on a Samsung TV with a Chromebook. https://youtu.be/oW_qJVzQhIg
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.
Copyright 1997-2024 - Michael Kohn