Single command IR transmitter?

I've done a fair bit with IR using PICs. I've used a 12F683 to drive a transistor which in turn turns on and off an IR LED.

The 12F683 has a HPWM module, this means you can turn on and off the modulated signal very easily. All you need to do is program a few registers with values that result in the correct modulation and duty cycle for the signal you're sending. This PIC also has an internal clock so there is no need to worry about external crystals etc.

The software then needs to turn the HPWM output on and off with the data signal its trying to send, and you have a modulated signal going straight to the IR circuit.

The HPWM output pin needs to be connected to the base of the transistor. The IR LED, resistor and transistor (collector/emitter) connected in series to complete the signal circuit. The reason for driving it from a transistor is that the IRLEDs draw more than the 25mA that PICs allow. I've used a BC549, but there are probably better parts around as the BC549 has a maximum of 100mA while the TSAL6400 (IR LED) can easily draw 100mA. The resistor values needs to be calculated based on the supply voltage and the rating of the IR LED you use.

I've run this type of circuit off a tiny battery for many many presses and it works fine. My design caused the power circuit to complete when a button was pressed so there was no need for standby/sleep modes on the PIC. It took the form of a 3 button car remote style device, each sent a different signal series. Combined with a TSOP4837 (I think) receiver for learning new signals this proved a handy device for a lot of people.

There are loads of articles on the net around IR signals, RC5 codes etc, so you need to find out what signal type this TV uses. Also remember that a lot signals are toggles, the only exception being power which often has an on, off and toggle signal.. allowing more flexibility in the way its used.

Components:

PIC 12F683 =A31.30 TSAL6400 =A30.25 BC549 =A30.10

Yes its possible but complicated for a novice. The protocol links are needed but I didn't see the actual transmit data for the individual functions I.E they tell you HOW to send the bits but not WHICH bits to send. I compiled the list for Samsung last year using an IR module into a Tek TDS-3000 scope and can now receive and trasnsmit any function (it is used for transcoding the monitor and set top box commands). Its definitely easier to transmit than to receive. BUT, since you only want mute, wouldn't it be easier to re-package a universal remote that already works? Building your own can be a good learning experience but will use a chunk of time. Good luck GG

Thanks guys!

I see a list on the LIRC site of nine 8bit Mitsubishi files-

I'm not sure if >wouldn't it be easier to re-package a universal remote that already works?

Yes, but I don't mind the extra knowledge from a full DIY. I'm trying to hone up my PIC skills as well. MJT's project doesn't sound overly intimidating either, nor does the IR transmitter section of that jap.hu page Ken pointed out.

MJT- If it's not too much hassle, I may end up needing to fish out a couple more details on that circuit you built. It sounds good, and is probably two commands bigger than what I'll need.

A few immediate brief questions, if it's OK-

• Was the total battery and circuit size something that could fit in a really small space? I'm trying to get something easier to access and less cumbersome than the full blown TV remote and don't want to be adding another one.

• Does the switch activated "power-up/application-start" circuit start and stop reliably and is it as fast as a normal remote's response time?

• I've only dealt with small PICs (16F84, 12C50x, and some big 18Fxxx code which was written by someone else) and I've never had to deal with any HPWM output from one. If you're big on PICs, is your 12F683 a proper chip for my needs, or is there a better one around now? Don't yet know if this type of output is a multiple of the PIC's clock, but the features section of the datasheet states a frequency range of 8MHz to 32kHz. Don't know why they've got it reversed like that either, but with some googling, it looks like that's some config. setting for the clock range options of the internal osc. I'm guessing I can scale that somehow and adjust my code for something in the upper 40k range or whatever this TV wants. (??)

-Take Care All! (and sorry for all the text) George

PS- I'm also suspecting that it might be wise to try to pick out a simple version of one of those comm port transmitters first. That way maybe I could be sure that a certain string of IR would trigger that mute, before I start wondering why my PIC app. doesn't work. ; )

You should be able to build this into a key fob, running directly from a single lithium battery, and using a 6 or 8-pin PIC. The delay routines are trivial and easily simulated. Not much required besides the micro, a resonator, a BJT and a couple resistors.

Nikolai Golovchenko has written a cute little delay generation routine if you want to use it:

but you'd probably learn more programming the CCP module (if you use a PIC that has one).

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Hi. Try:

and or even: (etc) Use the keywords 'remote control','pic' and 'schematic' for searching.

Cheers.

Ken

The philips RC5 protocol has been hacked a long time ago. I have a 8051 based reciever, that worked well at the time. It is a learning experiance, very little hardware.

Cheers

The PIC that I used I selected because it has the builtin hardware PWM. This allows you to generate many different output frequencies no matter what speed you clock it at. It also has a reliable built-in clock source so no need for external crystals or resonators.

The circuit is tiny (when on a PCB). For the project I used the following case available from

- search for 451-0674 or just the word Keyfob and you'll find it!

I didn't have any problems with power-up delays because the PIC has its own power-on delay to ensure its stable so that wasn't a worry. Powerdown was instant, just as on a remote. My circuit went something like this:

+---------------+ | | | PIC 12F683 | | | +---------------+ [ ] [ ] [ ] | | | | | --- | | - | | | | ___ | ___ IR LED RED LED +v ----o o----+---/ \\----->|------->|----+ | --- -

Sorry - first try at ASCII circuit diagrams! The red LED was used as a confidence thing, and depending on the LEDs used depends on if you need a resistor or not. The whole circuit works off a 3v cell (lithium). The cases I've mentioned take a 12v cell unfortunately, so in that case I used a very low powered 7805 to take it down to 5v which works well. I did try and find a 3 to 5v cell in the same size, but couldn't find one.

I typically clock my projects at 4Mhz unless I have a reason to need the other frequencies. You use various registers to calculate out the PWM frequency you need for the clock speed you're running at. So for example, so you need a 38Khz modulation you'd take 4Mhz = 4000000, divide by 4 = 1000000. Divide this number by the frequency you need,

38000, this gives you 26 (when rounded). Load this in to the PR1 register (I think). Obviously because of the rounding you'll be generating a slight offset, you'll generate 38461Hz. Thats close enough not to make any noticable difference to the range or sensitivty. If you play around with the pre/post scalers on the time you might be able to get something more accurate.

You'll also need to configure a duty cycle, I think most remotes are about 20%. You need to work out the number of bits available for your clock and duty cycle. Its in the datasheet... so work it out and from there you look at the: I've got 6bit resolution (for example), the lower two bits sit in one of the PWM register, the remaining upper 4 bits sit in their own register. Be sure to clear the upper bits of the that register when you configure it, otherwise it can do odd things. If we're looking at a 20% duty cycle at 6 bits you need to store the decimal value 12. Zeros in the lower two bits, and the number 3 in the upper byte. I hope all that makes sense, but unless I know the exact frequencies I can't give you precise values.

Then only timing you need to work out is the one for the real signal, which can be done in most high-level languages rather than worry about asm. If you needed to do the whole modulation in software you'd need to asm only otherwise the high level language will screw up your timing.

Comm port serials i'd be careful of.... they don't typically use basic IR they're normally Irda or something else....

If you want to work out what the IR signal is, the way I did it was to buy a Vishay TSOPxxxx part. That has a logic output that you can connect on to a PIC. Then all I did was have a timer routine, it starts a timer, waits for a state-change on the pin, stores the timer value at that point, clears it and restarts the timer, then sends the result via the serial port (in ASCII). Run a terminal program at the other end, this will dump a load of numbers out giving you the timings for the signal received. Its how I reverse engineered a proprietry system that didn't use standard codes. Obviously you have to repeat the codes a few times to get reliable results but it should give you a good idea of what to generate. As a test I just too the timer figures, put them in a table, then altered the code to turn on and off the IR output in line with the table and the timer - resulting in the signal I needed.

I hope that makes sense! For the record I use Proton+ to write PIC apps in... its a bit faster than using asm (which I have used for things like the 68HC705C8 - old process now!)

Mike

George wrote:

If absolute size is not utterly critical - what's wrong with a 'one for all' or learning remote?