SparkFun Forums

[Mee_n_Mac]

Hi, first-time poster asking for some advice before I start a project. What I'm looking to do is make a non-universal, dedicated-for-the-TV-only, big button remote for my mother (who is 85). As is typical for people her age, she's not exactly "tech savvy" and her eyesight is quite bad due to macular degeneration. Thus the remote included with her new TV (a Vizio) is very hard for her to use (too many small, indistinguishable buttons). I got her a reasonable BB remote but it seems to loose it's device code too often as of late and the "extra" controls for the DVD, sat, etc tend to confuse her.

I have a non-functional, multi-button BB remote I can scavenge for (some of) it's big buttons and the rest I figure I can build myself, with a micro (probably a PIC but ...) as the heart. What I'd like is some advice on what micro best suits the project, as well as any other general comments people think apply.

As for requirements I believe the remote needs 20-22 buttons (0-9, -, pwr, vol+, vol-, mute, chan+, chan-, back and 2-4 favorites) which says to me 10 I/O lines to make a scan matrix. Ideally the inputs would have a interrupt on change capability so the micro can sleep and conserve power when not doing anything. When a button has been pushed (and validated) two things then happen in sequence. First the modulated IR (38 KHz, ~30% DC) is transmitted with the needed encoding (NEC1) for that buttons function. My thinking is to store a set of timings corresponding to the timings for each mark and space in the encoded IR stream. IIRC the NEC1 format is a preamble plus 32 bits. Using a byte to store the time of each mark or space means about 750 bytes to store the timings. The shortest timing is 560 usec and the longest is 9 msec so I don't think I need a high speed micro but I do need a timer to cover that range. Timing accuracy to a few % should work OK so I don't think an external crystal is required.

But here I have a question re: the actual IR output. I can use an external oscillator (think 555-ish) to do the IR modulation and drive the LED. The micro could then enable/disable it with a single output line. Or I could use a PWM function (setting the period and DC in software) and enable/disable that function (and thus output) via software. The downside to the latter is I think the output pins of micros are limited in drive current to less than the amount desired (? 50 - 80 ma ?) and I have need for a PWM to do another function (see below). Using an internal PWM function also mandates a certain speed to get the 38 kHz mod frequency, though I don't think that's a big design driver. (?) OTOH adding an external oscillator means more shakey hand soldering by me though it simplifies the code and takes care of any "high" LED drive current concerns. Hmmmm.

Second (once the micro has sent all the marks and spaces) I'd like the remote to audibly tell Mom what button she's pushed. These BB remotes don't have much tactile feedback and she has a hard time seeing the small channel number display on the TV. This leads her to hit 5 5 5 5 5 ... when she wants channel 55 and the TV quite naturally rejects 55555... as a valid input. I get the resulting phone call that the remote or TV is "broken". So having the remote speak to her let's her know what button she's pushed and when to stop pushing. I figure on using a PWM (see I said there was a another use) to drive a small piezo-type speaker just to say "one" or "back" or "louder", etc. Telephone quality speech shouldn't be too hard and I'm thinking 8 ksample/sec with 8 bits and perhaps 0.5 - 1.0 sec in duration for each button confirmation (22 x 8K => 176B of memory needed). This in turn means I need enough memory to store all the .wavs and I think this means using some form of external (to the micro) memory. Right now I'm thinking SF sells a SD card socket that would allow me to record and edit .wavs on my PC and easily inject/change them (via an SD card) into the project. This then requires code to handle the file system. So I'm open to other ideas as well. Thus the micro needs (another ?) PWM and output line, and I/O to interface to external memory, probably via I2C or SPI. So that's 4 more I/O lines and enough RAM to buffer the memory ?

Summing up I think the micro needs to have 1 or 2 PWM outputs (could 1 PWM's output be reassigned to a different output pin ?), 13-15 more I/O lines (buttons + ext mem interface), I2C or SPI capability, enough (I have no guess as to what's needed to read from external memory) flash to hold the button timings + program and enough (???) SRAM to buffer the .wav data. It should be able to enter and wake from a low power state, allowing it to run (intermittently) off 2-4 AA batteries for 6 months. Simple is better and I'm not planning on getting a PWB made as I'll only be making 2 of these. Lastly I think the 950 nm diode is the right one for TV remotes but ...


Man, that's one looooong post. Thx for reading it and any advice.

[itikhonov]

Open that remote you are going to use as donor first. There is a good chance that you will see there everything you need with rom micro for which pin compatible flash-based one exist.

You can use http://www.sparkfun.com/products/9578 to make it talk.

[Liencouer]

Would something like this be easier than building from scratch?

http://www.amazon.com/Functions-Univers ... =pd_cp_e_0

[Mee_n_Mac]

Open that remote you are going to use as donor first. There is a good chance that you will see there everything you need with rom micro for which pin compatible flash-based one exist.

You can use http://www.sparkfun.com/products/9578 to make it talk.

Thanks ! Alas the donor remote has it's controller covered in the usual blob of epoxy. I'll look at the SpeakJet.

[Mee_n_Mac]

Would something like this be easier than building from scratch?

http://www.amazon.com/Functions-Univers ... =pd_cp_e_0

It would indeed be easier ... but where would the fun be in that ?

Actually that remote is the same as the donor remote I'm refering to above (though with a different vendor name). The one I got was DOA (but for ~$5, who cares). The problem is that trying to do so many things (TV, DVD, sat TV, etc) requires a lot more buttons to control all the functions. These buttons tend to confuse my mother. She can't see the markings and more or less goes by feel and general location (of the button on the remote) to do what she want's accomplished. I'm thinking less buttons, grouped logically with some differing shapes (note the 0-9 and up/down keys) will make it easier for her (and thus for me ). Thanks for thought !

[itikhonov]

Thanks ! Alas the donor remote has it's controller covered in the usual blob of epoxy.

http://www.youtube.com/watch?v=kTPXKA66baQ

[Mee_n_Mac]

Thanks ! Alas the donor remote has it's controller covered in the usual blob of epoxy.

http://www.youtube.com/watch?v=kTPXKA66baQ

Very interesting ! I didn't know you could do that. I'll have to de-blob it, even it's just to see what lies underneath. Thanks !

[bill190]

I made my own IR remote control for an old Technics Amp and CD player using a Pic 16F1938 which has 8 interrupt on change pins.

I programmed it in assembly. And I use the microcontroller's PWM for 38 kHz. Then use another microcontroller pin to switch on/off the 38 kHz.

Then I use transistors to increase the output to the IR LED.

I have 1245 lines of assembly code and use my own assembly macros throughout, so not straight forward for someone else to understand my code.

There is a Pic PWM calculator here...
http://www.micro-examples.com/public/mi ... lator.html

Then the trick to all this is you need to be able to "see" what frequency you are outputting (38 kHz) with a multimeter or frequency counter.

Then you need to be able to "see" the bits sent from a working IR remote as well as what you are trying to send. Then you can see if your IR output is the "same". I used a Parallax Propeller with the "IR kit" from the Parallax Propeller object exchange.

And you need to find the specification of the IR codes sent. Get that from the LIRC database here: http://lirc.sourceforge.net/remotes/

Here are the specs for my Technics IR...

; Technics IR Timing
; bits 16
; flags SPACE_ENC - A one and a zero can be distinguished by the length of the spaces.
; eps 50 - The relative error tolerance for received signals in percent (decimal integer)
; aeps 400 - The absolute error tolerance for received signals in microseconds
;
; header 3552 1704
; one 456 1298
; zero 456 423
; ptrail 456 - A trailing pulse, immediately following the post_data
; pre_data_bits 32
; pre_data 0x40040500, 0x40040550, etc. depending on component CD, Amp, etc.
; gap 75016 - A (typically long) space which follows the trailing pulse.
; toggle_bit 0 - A bit of the pre_data, code, or post_data that is toggled between one and zero each time a button is pressed.

[bill190]

Here is what an IR remote transmission looks like using the Parallax IR Kit IR Capture and using an IR receiver...
(Volume Up for my old Technics.)

3588,1700
2,0,-21567753
1,300
2,3566,1722
2,460,429
2,460,1292
2,460,376
2,513,403
2,486,403
2,486,403
2,485,405
2,483,405
2,459,430
2,459,430
2,459,430
2,459,377
2,513,404
2,485,1265
2,487,403
2,484,405
2,483,406
2,459,430
2,459,430
2,459,430
2,459,377
2,512,1266
2,486,403
2,486,1265
2,485,405
2,483,406
2,459,430
2,459,431
2,458,430
2,459,377
2,512,405
2,484,404
2,485,404
2,483,406
2,482,407
2,458,431
2,458,431
2,458,1293
2,459,377
2,512,405
2,484,404
2,485,404
2,483,405
2,482,407
2,458,431
2,458,431
2,458,430
2,459,1239
2,513,74437

[Mee_n_Mac]

I made my own IR remote control for an old Technics Amp and CD player using a Pic 16F1938 which has 8 interrupt on change pins.

I programmed it in assembly. And I use the microcontroller's PWM for 38 kHz. Then use another microcontroller pin to switch on/off the 38 kHz.

Then I use transistors to increase the output to the IR LED.

I have 1245 lines of assembly code and use my own assembly macros throughout, so not straight forward for someone else to understand my code.

Thanks. I figured the 25 (?) ma sink limit wouldn't be enough to get a reliable, decent range. Thus some output "driver" would be required. The code size is informative. Now I have to see what's needed should I have to access the file system on an SD card.

Then the trick to all this is you need to be able to "see" what frequency you are outputting (38 kHz) with a multimeter or frequency counter.

Then you need to be able to "see" the bits sent from a working IR remote as well as what you are trying to send. Then you can see if your IR output is the "same". I used a Parallax Propeller with the "IR kit" from the Parallax Propeller object exchange.

Good point. I should get an IR decoder BB as well. That and an O-scope (or logic analyzer) that I can use at work will allow me to "see" the data and confirm a match.

How (in general) did you implement the mark/space timing ? My thought was to use a timer. A pointer would indicate which memory location is holding the desired value for the duration of the mark or space to be transmitted. When the timer timed out, an ISR would increment the pointer, pull the new value and load the timer and toggle the control bit to turn the modulated IR on/off (each burst of IR is always followed by a period of no transmission). The number of marks and spaces is a constant no matter what the code is, so the state machine just runs a fixed number of steps. FYI the NEC protocol is depicted here. A separate ISR, triggered by a button push, would simply initialize the pointer to the correct location (for that button), load the timer with the 1'st value, enable the IR output and trigger the process/state machine to run.



ps - Thanks for the links !

[bill190]

So far as the mark / space timing, that is where doing this in assembly language comes in handy...

Simply output the 38 kHz on one pin, then turn on / off another pin. And connect the IR LED to those pins.

Just calculate the timing for the on period or off period. And you can much more easily calculate / tweak timing when using assembly language.

And with your test equipment, you can see that you have the correct (or incorrect) timing.

So if you connect the negative side of the IR LED to a microcontroller output and the positive side to the 38 kHz microcontroller output, then when the negative side is switched to low, the IR LED will be sending 38 kHz. Then switch that output high and the IR LED stops sending anything.

You just need to switch that negative output pin very quickly and very accurately. (Assembly language.)

One thing to note is that IR sensors for IR reception (which I used for testing) will come in a 38 kHz ONLY model. If you stray too far from 38 kHz, suddenly you get nothing!

Other IR sensors can detect other frequencies and some will detect a wide range of frequencies. So be sure you know the part number of any IR sensors you use for testing and read the data sheet as to what range that sensor will work.

BTW - One reason my code is so long is so I could stick in the actual numbers for each function - like this...

LitIrPreData500 Equ 0x40040500 ;Amp
LitIrPreData520 Equ 0x40040520 ;Tuner
LitIrPreData538 Equ 0x40040538 ;All Power
LitIrPreData550 Equ 0x40040550 ;CD

TUNER Equ 0x494C
CD Equ 0x292C
TAPE Equ 0x696C
VCR1 Equ 0x797C
VOL_UP Equ 0x0401
etc...

...then my program then unpacks those long numbers.

Also for people who like to turn up the volume, it turns the volume all the way down, turns on muting, then sets off blinky lights and an alarm on the remote (which is a converted old phone). (HeHeHe!!!)