Sky Remote Control

With a certain degree of irony, today's 'nothing on TV' project turned into the start of designing a remote control which can control the TV and various units which each need their own remotes.

Uses a PICAXE-20X2 and the trick of placing the IR LED + R between PWM and another pin to modulate the IR signal so not a great deal of range as I played safe with a 220R and not sure if the IR LED is designed for 36kHz but it does work so far to control a Sky Satellite Receiver's channel up and down.

Lots of tweaking, much more to do and not sure when I'll be working on that, but thought the code might be useful to someone.

No comments as happens with proof of concept. The main principle is specifying the time periods between toggling the bits. The list of bit times is placed in scratchpad and spooled out. The 'SendIr' routine is at the top of the program so it never changes and nor does its timing.

IR TV Control (off topic)

This reminds me of a project I made around 1990 using a Commodore C=128 (with 640K RAM!) sending IR commands to a SONY TV and VCR.

I worked out the bit patterns by reading them into the C=128 (with ML program, IR detector on the User port) and looking for patterns of 1111111s and 000000s with a memory monitor.
Trial and error with a ML program for timing spat them out under a BASIC timer program that could turn on the TV and change channel. The VCR was set to record on power-up.

I'd like to try this on a 28x1, do you think I could get anywhere near the frequency running at a much lower clock speed?

Cheers

Miles
________
Suzuki GSX-R Series

I doubt this will work below 32MHz. In fact, to cater for additional remotes I've now moved to 64MHz operation.

The problem comes in trying to create delay periods which will cater for both short and long bit times. I ended up storing a bit stream in the scratchpad to indicate long or short pauses before toggle, an IF-THEN-ELSE to handle how long each pause is, pause times specified by word values rather than bytes, and optimising the code to be as fast as possible ...

The thing I've found is that apart from some complexities in the software design the biggest problem with the project is the physical side of things. A PICAXE controlling a number of things via serial control is relatively easy, making an actual hand held remote more of a challenge.

Trying to find a remote control which can easily be modified to use the 20X2 is hard. Not just size, but in getting a keypad layout which will allow a universal remote to be created how I want it. Most universal remotes allocate the keys all over the place. The ideal solution seems to be an actual Sky Remote modified so TV, Sky and Power buttons select between TV, Sky and a Virgin STB, a two second push sends an appropriate power on-off signal ( not an absolute necessity ).

The 20X2 can handle a 5x8, 6x7 or 7x8 keypad but not sure how the Sky Remote ( or any other ) maps its keys onto a matrix. That could involve quite a lot of circuit hacking. Not sure how the 20X2 is going to handle 64MHz operation at 3V - something I ought to test.

Another thing I don't know is what the Sky+ remote protocol is but can find out. The Virgin STB protocol is different and needed its own version of the IR bit streaming routines to be written.

Latest code attached which has grown somewhat !

Oh poo, I hoped that wouldn't be the answer, I thought doing a wireless to IR blaster for SKY+ would have made a nice little pixaxe project to write up. You could then have used wifi on windows mobile/iphone as the interface. I'll give it some thought another day, I know software PWM works for us at 38Khz on an 8Mhz 16F688 (sister to 14M) but then it's not Picaxe BASIC we are forced to use to achieve it, what a shame, life is never easy

You have been busy, nice work
________
extreme vaporizer review

Hippy. I think the big boys get better range simply by shortening the 38KHz pulses and increasing the current. LEDs can be driven with surprisingly high currents for very brief periods.

I once built a strobe with a 5mm super bright white LED, probably rated max 40mA continuous or there ‘bouts. It was driven from a 556 + transistor DIRECTLY from a 9v pp3. No ballast resistor. Current was obviously limited by the batteries internal resistance and stray capacitances, but it must have been at least 10 or more times the max rated. When designing it, I just started with extremely short pulses and slowly lengthened them until the LED was producing roughly (by eye) the same brightness as when driven from nominal continuous current. Also had a resistor across the LED to help discharge the junction capacitance and ‘square up’ the light pulse a little. Worked great. Took it everywhere for a while. Even ‘froze’ my pee stream once while camping

I haven't started maximising range yet but it has been one of those things I've been thinking about. The IR LED is only ever on for only half its time ( pulsed at 36kHz-38kHz, 50% duty ) so the average current can notionally rise to twice the I/O pin capability. As nothing ( no active IR ) is being transmitted for half the time it could perhaps double again.

This is not recommended practice, may shorten the life of the PICAXE and even destroy it, but I have used the technique of no resistors when multiplexing LED displays without any apparent damage or problems. As you note, it's mainly the average current which is important, twice as much for half as long is nearly the same as a fixed amount permanently.

Hippy. Thanks for the concise code. A whole lotta good work right there to build on.

As I'm a poor programmer and a worse typist C&P are the two most important commands in my OS.

A small focusing lens might be added to the LED and adjusted to narrow the beam enough to greatly increase the effective range without making the pointing too fussy. That would help ensure the active devices are kept safe and reliable.

I'm a great fan of passive solutions for electronics problems. They help keep the magic smoke from getting out of the active devices.

thanks for this code, it's very useful