Searching \ for 'IR Programable Remote' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/irs.htm?key=ir
Search entire site for: 'IR Programable Remote'.

Truncated match.
PICList Thread
'IR Programable Remote'
1997\01\05@213134 by John Griffiths

flavicon
face
I'm looking at using a PIC in a IR transmitter / receiver project to
learn commands sent from my existing remotes, store the codes in
eeprom, to be later re-transmitted on demand by another PIC device.
(Basically an IR remote that can be programed with other remotes
codes, which can be controlled by other devices).

Has anyone done this before, or have any suggestions ?

Cheers
John Griffiths
(New Zealand)

1997\01\05@225451 by Prashant Bhandary

flavicon
picon face
At 03:31 PM 6/01/97 +1200, you wrote:
>I'm looking at using a PIC in a IR transmitter / receiver project to
>learn commands sent from my existing remotes, store the codes in
>eeprom, to be later re-transmitted on demand by another PIC device.
>(Basically an IR remote that can be programed with other remotes
>codes, which can be controlled by other devices).
>
>Has anyone done this before, or have any suggestions ?

I have done bits and pieces... I've used a Sharp module connected to
a PIC 16C84. I've not yet tried IR output but that looks easy especially
if you use an external 555 to provide the 40 KHz signal. What I've got
so far is :-

1. A PIC circuit with a Sharp module and a serial out. It decodes Sony
   IR codes and sends it to a PC. The PC runs a Visual Basic program
   which reads the serial port and displays the function activated.
2. A PIC circuit with a Sharp module and a serial out. It senses any
   IR signal, does crude compression and sends it out on the serial
   port to a PC. The PC runs a Visual Basic program which displays the
   waveform like an oscilloscope trace. What the PIC does is to time
   each mark/space and send a byte corresponding to the time period.
   To keep the time period count down to 1 byte, I sacrifice accuracy
   for higher counts e.g. 1-4 -> 1-4, (5,6)-(11,12) -> 5-8,
   (12,13,14,15)-(24,25,26,27) -> 9-12 i.e. time periods 5 and 6 are
   sent as 5, 7 and 8 are sent as 6, so on. Anybody have suggestions
   for a better compression scheme? This was used just to get a rough
   idea of the signal rather than to actually store and send signals.


There have been assorted posts on this subject on the list over time.
You've touched upon a favourite topic of many a PIC list residents.

Regards

Prashant
--------------------------------+---------------------------------
 Prashant Bhandary             | Tel:  +61-2-9662 5299
 Spatial Information Solutions | Fax:  +61-2-9662 5348
 Roads and Traffic Authority   | Email: spam_OUTprashbTakeThisOuTspamrta.nsw.gov.au
 Rosebery NSW 2018, AUSTRALIA  | "2b|!2b" - William Shakespeare
--------------------------------+---------------------------------

1997\01\06@055314 by Michael S. Hagberg

flavicon
face
At 03:31 PM 1/6/97 +1200, you wrote:
>I'm looking at using a PIC in a IR transmitter / receiver project to
>learn commands sent from my existing remotes, store the codes in
>eeprom, to be later re-transmitted on demand by another PIC device.
>(Basically an IR remote that can be programed with other remotes
>codes, which can be controlled by other devices).
>
>Has anyone done this before, or have any suggestions ?
>
>Cheers
>John Griffiths
>(New Zealand)
>

i belive that circuit cellar did a project like this a number of years
ago. i know it wasn't with a pic.  i do remember talk of how codes are
repeated and a way to store them so only a few bytes per command need be
stored to recreate the ir signal.  if you need more info i could dig up
the article.

michael
>

1997\01\06@103236 by myke predko

flavicon
face
Hi John,

>I'm looking at using a PIC in a IR transmitter / receiver project to
>learn commands sent from my existing remotes, store the codes in
>eeprom, to be later re-transmitted on demand by another PIC device.
>(Basically an IR remote that can be programed with other remotes
>codes, which can be controlled by other devices).
>
>Has anyone done this before, or have any suggestions ?

I suspect that you're going to have problems with doing this.  One of the
problems that I found when I dinked around with I/R Remotes is that you do
not get consistant timings in the signals from an I/R receiver.

For example, if you were running with a device that had a 40 KHz carrier
(and they all don't) the receiver may miss one or two of the initial pulses.
If you have a scope and an I/R Receiver, hook them up and take a look at
what you get; you'll see an awful lot of jitter.

Loosing the none, one or two initial pulses translates to a possible 25 or
50 usec error, which will make it very difficult for your device to "learn"
what the actual timings are.  And, if they are retransmitted verbatim, the
next receiver may miss a few pulses and suddenly you have a huge error and
an incorrect signal at the final signal destination.


I don't want to discourage you (I've done a few things other people on the
List have said are impossible) but I suspect you will have an uphill battle.
Instead, what you may want to do is find out what the timings are for all
your different remotes and then transmit the signals directly.

Please keep us apprised of your progress - New ways of handling I/R
Receivers is a topic that always finds a big audience here.

myke
>
>Cheers
>John Griffiths
>(New Zealand)
>
>

"There are only three kinds of economists in the world.  Those who can count
and those who can't." - Eddy George, governor of the Bank of England

1997\01\06@114000 by Inge Arnesen
flavicon
face
> I have done bits and pieces... I've used a Sharp module connected to
> a PIC 16C84.

Which Sharp module did you use and how did you connect it to the PIC ?
I've bought some samples of IS1U621, but havn't looked at them
yet.

Still, I feel that using receiver modules restricts your freedom
when it comes to decoding IR remotes. You will probably only get
signals modulated in the 36-42KHz range and miss those outside these
frequencies (that will cover most remotes, but still...). Also,
you might have problems with some of the very long
headers as well as headerless protocols, but that might depend on
the receiver. Given that you have enough RAM storage available,
an idea would be to sample the raw IR signal, and demodulate it
in software later. A sample rate of 100KHz would be enough for
most IR remotes, provided the processor can trigger on the start
of the IR sequence as it's being received. I assume sampling can be
performed with the remote to be sampled very close to the IR receiver
diode and with little other IR noise. That way it should be possible
to get good samples with a crude transistor amp and without a proper
filter.

On a PIC you will have to have a few K (2K) of external RAM to hold
the samples before analysis and a 1K or 2K EEPROM to hold the resulting
values for all the commands, but the program will be a tight fit on a
16C84. Whether analysis should only find the end of the IR command
sequence and remove the carrier and store the demodulated signal
or try to reduce it further is up to the programmer and the available
program/data space.

During playback one might let the PIC handle the modulation, since
you will at least be able to vary the modulation to a certain
degree (your accuracy will improve with CPU speed, but so your
current consumption will go up). This has been done and if the
receiver you transmit to is flexible enough, neither of you will miss
the 555.

I've never implemented raw IR capture on a PIC (and I don't intend to),
but I've done it on PCs and Amigas and it does work. PIC capture of
totally unknown remotes without IR receiver/demodulators can
probably be done, but I've never seen the need in my applications.

>    What the PIC does is to time
>    each mark/space and send a byte corresponding to the time period.
>    To keep the time period count down to 1 byte, I sacrifice accuracy
>    for higher counts e.g. 1-4 -> 1-4, (5,6)-(11,12) -> 5-8,
>    (12,13,14,15)-(24,25,26,27) -> 9-12 i.e. time periods 5 and 6 are
>    sent as 5, 7 and 8 are sent as 6, so on. Anybody have suggestions
>    for a better compression scheme? This was used just to get a rough
>    idea of the signal rather than to actually store and send
>    signals.

What unit are these values ? A good base value would be 25uS, since
that the modulation carrier speed. According to
http://falcon.arts.cornell.edu/~dnegro/IR/REMOTES/TABLE.HTML, the
longest signal from a Sony Remote is the 2.2mS header pulse, which
would correspond to 88 40KHz units. That should indicate that you may
send all values below 128 uncompressed and values between 128 and 200
divided by two, between 201 and 254 divided by 50 and 255 as any
longer period. According to the table, no remote will send
any signals (low or high) longer than (200 * 2 * 25)= 10000 uS,
so longer values are only of value to detect retransmission speed and
are (to my knowledge) not critical (a compression factor of 50 on
retransmission delay would pose no problem with any remotes I know
of).

Using this scheme, you will not loose any accuracy on the IR
signal (except for the actual modulation frequency which is lost in
the receiver), but loose some accuracy on the retransmission delays.

But, the IR remote overview table might be wrong and/or I might be wrong.


Regards,

Bob (tm)

1997\01\06@150204 by Tim Kerby

picon face
Hi
Same here - i have always wanted to do this but never known how.  The casio
watches that act as remotes can learn and are great at annoying sales
assistants in shops but even better would be a pic which could learn and
randomly repeat commands.  It could even sit on the windowsill outside -
they would never know what had happened.

On a more serious note I have also wanted to use a similar system to yours
including robot control.  On pressing a learn button a series of ir
sequences could be picked up and translated to events.  The tv remote with
the numbers would make an excellent direction control.

Could you send me any info on the subject (personally if you dont want to
jam up the list.

Thanks and a happy new year

Tim


At 15:31 06/01/97 +1200, you wrote:
{Quote hidden}

1997\01\07@075946 by Chaipi Wijnbergen

flavicon
picon face
Hi,

I have been folowing the discussion about IR Programable Remote, It is
interesting how similiar the design that some peaple on this list
suggested is similar to my design. It works well, it can recieve in
comming IR signal and regenerate it.

- instead of using an IR module, you should better use a IR led with an
 amplifier that would trigger the PIC.

> On a PIC you will have to have a few K (2K) of external RAM to hold
> the samples before analysis

I do it with alot less ram. number of samples will not fill that much
memory, BUT, it need to be fast access memory (parallel SRAM).

> and a 1K or 2K EEPROM to hold the resulting values for all the commands,

This depends on how you want to save data and what you want to do with the
recieved IR commands, if it only to do an action then you do not need to
save it. If you need to retransmit it then again you would probably not
need to save it.

> but the program will be a tight fit on a
> 16C84. Whether analysis should only find the end of the IR command
> sequence and remove the carrier and store the demodulated signal
> or try to reduce it further is up to the programmer and the available
> program/data space.

I am using 16C74 at 20MHz. 16MHz was not fast enoght for some of the
things I do.

> During playback one might let the PIC handle the modulation, since
> you will at least be able to vary the modulation to a certain
> degree (your accuracy will improve with CPU speed, but so your
> current consumption will go up). This has been done and if the
> receiver you transmit to is flexible enough, neither of you will miss
> the 555.

I do the modulation using one of the PWM modules, but, for this you need
to know the carrier frequency.

> I've never implemented raw IR capture on a PIC (and I don't intend to),
> but I've done it on PCs and Amigas and it does work. PIC capture of
> totally unknown remotes without IR receiver/demodulators can
> probably be done, but I've never seen the need in my applications.

It works well for me.

Chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : .....chaipiKILLspamspam@spam@tohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

1997\01\07@110039 by Brian Lane

flavicon
face
On Mon, 6 Jan 1997 15:31:38 +1200, you wrote:

>I'm looking at using a PIC in a IR transmitter / receiver project to
>learn commands sent from my existing remotes, store the codes in
>eeprom, to be later re-transmitted on demand by another PIC device.
>(Basically an IR remote that can be programed with other remotes
>codes, which can be controlled by other devices).
>
>Has anyone done this before, or have any suggestions ?

 A friend of mine at school has been doing some experimentation with
a IR receiver hooked up to the serial port. It appears that a number
of the IR formats are 1200 baud, and can be decoded using a simple
2n2222 amplifier on the IR detector with the output buffered by a
schmitt trigger to the serial port (yes, its not a RS-232 voltage, but
it works).

 I've got a RCA systemlink 4+ remote here I've been meaning to play
with (I lost the instructions) and build a PIC receiver for one of the
more popular codes. I think the best way to go about control is to
find a 1200 baud code (or one that you can decode consistently) that
is widely supported by the universal remotes available. This saves you
the trouble of trying to support everything under the sun.

 Brian

---
 Nexus Computing        nexusspamKILLspameskimo.com        http://www.eskimo.com/~nexus
 Brian Lane       embedded systems programmer                         KC7TYU

1997\01\07@225111 by Prashant Bhandary

flavicon
picon face
At 05:40 PM 6/01/97 GMT, you wrote:
>> I have done bits and pieces... I've used a Sharp module connected to
>> a PIC 16C84.
>
>Which Sharp module did you use and how did you connect it to the PIC ?
>I've bought some samples of IS1U621, but havn't looked at them
>yet.

The module is GP1U52X(the only thing, IMHO, worth buying at Tandy/Radio
Shack). The circuit must have been the simplest PIC circuit I've ever
built. The module just connects to an input line with a pullup.
The Tx from the PC has a resistor in series. That leaves just the crystal
and the caps on either side. The PC and the VB program did the rest.

>
>Still, I feel that using receiver modules restricts your freedom
>when it comes to decoding IR remotes. You will probably only get
>signals modulated in the 36-42KHz range and miss those outside these
>frequencies (that will cover most remotes, but still...). Also,

There probably aren't many that have a different frequency. At least
the stuff I buy is one of the common brands and they all seem to operate
in that band.

{Quote hidden}

Part of the problem might be to isolate the IR signal from other IR clutter
tough I have heard of people decoding it. The Sharp module seems to do a
pretty good job of detecting the signal. I suspect it uses one of those
single chip units where the whole thing is built into a TO-126 type of
package using an IR transparent plastic and has three pins - Vcc, Gnd and
output. The metal box does the all important job of shielding.

>I've never implemented raw IR capture on a PIC (and I don't intend to),
>but I've done it on PCs and Amigas and it does work. PIC capture of
>totally unknown remotes without IR receiver/demodulators can
>probably be done, but I've never seen the need in my applications.

Me neither.

{Quote hidden}

As luck would have it, I had bought a cheap, old Phillips remote which was
to be the transmitter. It wasn't the usual RC5. It was a signal where the
time periods were really long - I don't remember what it was. Besides, I was
trying to squeeze the mark and space timings into the same byte. This gave me
a value from 0 to 15 to play around with. The compression wasn't uniform -
the level of loss of accuracy was not always in ranges of 4. Most of details
are a little hazy right now but I have the code somewhere... As the whole point
was to display a waveform on the screen, accuracy was not very important as
long the general pattern was discernable.

>Bob (tm)
Is that bob the process or Bob the name?
:-)--------------------------------+---------------------------------
 Prashant Bhandary             | Tel:  +61-2-9662 5299
 Spatial Information Solutions | Fax:  +61-2-9662 5348
 Roads and Traffic Authority   | Email: .....prashbKILLspamspam.....rta.nsw.gov.au
 Rosebery NSW 2018, AUSTRALIA  | "2b|!2b" - William Shakespeare
--------------------------------+---------------------------------

1997\01\07@225706 by fastfwd

face
flavicon
face
Prashant Bhandary <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> The Sharp module seems to do a pretty good job of detecting the
> signal. I suspect it uses one of those single chip units where the
> whole thing is built into a TO-126 type of package using an IR
> transparent plastic and has three pins - Vcc, Gnd and output. The
> metal box does the all important job of shielding.

Prashant and others:

By the way... Since the shielding is, as you say, all-important,
it's NECESSARY to ground the metal case.

-Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com                 ===
=== Fast Forward Engineering - Vista, California          ===
===                                                       ===
=== Custodian of the PICLIST Fund -- For more info, see:  ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===

1997\01\09@003409 by Bill Rodgers

picon face
For a $50 good logic analyzer kit ($65 assembled), see Electronics Now,
Jan 97.  Sampling rates up to 1 Mega Samples per second and a built in
calibrator for your computer.  Very happy with mine.


                   Bill

1997\01\09@043916 by Mohamad Shalan

flavicon
face
hi,
can u send me the address of the supplier of such kit.

thanks

@spam@shalanKILLspamspamshams.en.eg

1997\01\11@090328 by e

flavicon
face
Michael S. Hagberg wrote:
>
> At 03:31 PM 1/6/97 +1200, you wrote:
> >I'm looking at using a PIC in a IR transmitter / receiver project to
> >learn commands sent from my existing remotes, store the codes in
> >eeprom, to be later re-transmitted on demand by another PIC device.
> >(Basically an IR remote that can be programed with other remotes
> >codes, which can be controlled by other devices).
> >
> >Has anyone done this before, or have any suggestions ?
...

I am also interessted in recieving and storing IR commands.

I am planing to build a IR controlled dimmer. Since I don't have the
place for separate reciever, controller and PWM dimmer IC, I would try
to implement all functions in an 16C84 PIC and to story the programmed
IR code in EEPROM.

There are such devices sold here, but they have to be reprogrammed every
time the power fails ...

In an other IR project i have used a Siemens SFH506 reciever. There are
devices with a Bandpass for 30, 34, 40 and 56 kHz. What reciever should
I
use to be able to learn commands from different IR remotes, operating
with different modulation frequency ?

Have sombody ready procedures for decoding the RC5 code ?

St.


--
     _______________________________________________________
    |                                      _____________    |
    | Dipl.-Ing. Stefan M. Ranguelov      /____________/|   |
    |                                     |||||||||||||     |
    | tel.:    +49 (30) 20 181 251                          |
    | priv.:   +49 (30) 513 66 23                           |
    | s-mail:  D-10319 Berlin, Mellenseestr. 39/10          |
    | ----------------------------------------------------  |
    | e-mail:  KILLspamrangueloKILLspamspaminformatik.hu-berlin.de             |
   /) WWW:     http://www.informatik.hu-berlin.de/~ranguelo (\
  / ) PGP key: on request or from WWW-page                  ( \
_( (|_______________________________________________________|) )  />
(((\ \)  /,)                                            / )  / //))/
(\\\\ \_/ /                                             \ \_/ /////
\       /                                               \       /
 \    _/

1997\01\11@222437 by Martin McCormick

flavicon
face
In message <RemoveME32D78F60.1333D6F5TakeThisOuTspaminformatik.hu-berlin.de>, "spamBeGoneranguelospamBeGonespaminformatik.hu
-berlin.de" writes:
>In an other IR project i have used a Siemens SFH506 reciever. There are
>devices with a Bandpass for 30, 34, 40 and 56 kHz. What reciever should
>I
>use to be able to learn commands from different IR remotes, operating
>with different modulation frequency ?

       One of each.

       There have been a couple of people say that they have programmed
PIC's to time the various pulses from the remotes.  I did that when I was
experimenting with the HP28 infrared link previously discussed as well as
a few other remotes.  One thing I noticed from the HP28 was that the process
of timing the pulses was made more complex because there was occasionally
a very short glitch between two successive on times such as when there is a
transition between a 0 bit and a 1.  At other times, one got an on time which
was twice as long as a single on time and no glitch.  I used a Sharp module
for this system and it may be that there is always a glitch but the time
is so short that the resonator in the Sharp module rings enough to fill in
the gap.  Since proper readings are taken in the middle of a pulse, this
isn't really a problem, but it is if you are not sure of the signal format
and are paying attention to everything at once.

       One question I have for the list.  Are any of those IR detectors
fast enough to handle a .1 MS pulse or a 10 KHZ pulse train?  The Sharp
detector is good up to about 1400 or 1500 pulses per second at which point
it starts to miss them.  I need a detector that would work at 9600 baud.
I don't care if a bit gets mangled occasionally as long as most make it
through.  I do not care about the carrier frequency since I will make the
transmitter to match the receiver.

       Thanks for any detector suggestions.

Martin McCormick WB5AGZ  Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group

1997\01\12@055512 by Chaipi Wijnbergen

flavicon
picon face
On Sat, 11 Jan 1997, TakeThisOuTrangueloEraseMEspamspam_OUTinformatik.hu-berlin.de wrote:

> In an other IR project i have used a Siemens SFH506 reciever. There are
> devices with a Bandpass for 30, 34, 40 and 56 kHz. What reciever should
> I
> use to be able to learn commands from different IR remotes, operating
> with different modulation frequency ?

I use Texas Instruments TSL262, it translate the IR signal to voltage at
the carrier frequency, you would need to detect the signal your self.

> Have sombody ready procedures for decoding the RC5 code ?

I have it running on a PC. I think that it would be long for an 84.

chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc..  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : RemoveMEchaipispamTakeThisOuTtohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

1997\01\12@055514 by Chaipi Wijnbergen

flavicon
picon face
On Sat, 11 Jan 1997, Martin McCormick wrote:

>         One question I have for the list.  Are any of those IR detectors
> fast enough to handle a .1 MS pulse or a 10 KHZ pulse train?  The Sharp
> detector is good up to about 1400 or 1500 pulses per second at which point
> it starts to miss them.  I need a detector that would work at 9600 baud.
> I don't care if a bit gets mangled occasionally as long as most make it
> through.  I do not care about the carrier frequency since I will make the
> transmitter to match the receiver.

Try TI TSL262 or even better TSL260 or TSL261 which can detect lower
frequency but can detect a smaller IR signal.

chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : chaipiEraseMEspam.....tohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...