Searching \ for 'IR -DE-coding' 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 -DE-coding'.

Truncated match.
PICList Thread
'IR -DE-coding'
1996\09\24@131244 by Jacob Blichfeldt

flavicon
face
As I saw a thread discussing -EN-coding of RC-5 IR-signals, somebody might also be able to help me on the following subject:

I want to make a lightdimmer that must be able to receive and 'learn' IR-codes with 36kHz carrier. I'll use a readymade IR-receiver/demodulator (SFH506-36) which outputs the demodulated received IR-code (36kHz removed).

Has anybody made a project that can 'learn' IR-codes?

If not, I really need some ideas on storing codes, and be able to compare the stored data with new received codes. The main problem is the (sometimes very big) difference in the encoding used by different brands.

I hope somebody can help.

Regards
Jacob Blichfeldt

1996\09\24@191445 by myke predko

flavicon
face
Jacob,

There are two aspects of learning the IR codes.

1.  Learning the time for the header, the bit start, and the "1" and "0".
ie the serial string usually looks like:

_________          ___    ___      __    ___      ___
        |________|   |__|   |____|  |__|   |____|     ...
        ^        ^   ^      ^    ^  ^  ^
         Header  |Strt      | "1"   |"0"

I setup the counter (TMR0) and then read it out for each transition.  I
created a simple program for reading the Sony I/R Remote (all the
transitions to the point where the timer overflowed) and displayed them on LEDs.

2.  Learning what each code means.  Actually, the same hardware was used as
for the program above, I just read each incoming packet and display them.

You're welcome to the code if you want it,

Myke
>As I saw a thread discussing -EN-coding of RC-5 IR-signals, somebody might
also be able to help me on the following subject:
>
>I want to make a lightdimmer that must be able to receive and 'learn'
IR-codes with 36kHz carrier. I'll use a readymade IR-receiver/demodulator
(SFH506-36) which outputs the demodulated received IR-code (36kHz removed).
>
>Has anybody made a project that can 'learn' IR-codes?
>
>If not, I really need some ideas on storing codes, and be able to compare
the stored data with new received codes. The main problem is the (sometimes
very big) difference in the encoding used by different brands.
>
>I hope somebody can help.
>
>Regards
>Jacob Blichfeldt
>
>

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

1996\09\24@233842 by hoss karoly

flavicon
face
what do you use for codeing ?
the old ne555 or something hybrid as the sfh ?
does siemens makes some self modulateing leds ?
- something like the blinking ones but faster ?
bye
charley

1996\09\25@020235 by nigelg

flavicon
picon face
In message  <spam_OUT01BBAA45.FE5E9F60TakeThisOuTspamppp52.her.tele.dk> .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU writes:
> As I saw a thread discussing -EN-coding of RC-5 IR-signals, somebody
> might also be able to help me on the following subject:
>
> I want to make a lightdimmer that must be able to receive and 'learn'
> IR-codes with 36kHz carrier. I'll use a readymade > IR-receiver/demodulator
>(SFH506-36) which outputs the demodulated > received IR-code (36kHz removed).
>
> Has anybody made a project that can 'learn' IR-codes?
>
> If not, I really need some ideas on storing codes, and be able to
> compare the stored data with new received codes. The main problem is the
> (sometimes very big) difference in the encoding used by different > brands.

I don't know if it'll help, but I've written 16C84 code to receive and decode
the IR signals from Sharp Electronics remote controls. All the recent ones
are based on the same coding system and have a different 'system code' for
TV, VCR and Audio. My code allows the switching on and off of various of the
PortB pins, the keys used are held in a lookup table.

Nigel.

         /----------------------------------------------------------\
         | Nigel Goodwin   | Internet : nigelgspamKILLspamlpilsley.demon.co.uk |
         | Lower Pilsley   |                                        |
         | Chesterfield    |                                        |
         | England         |                                        |
         \----------------------------------------------------------/

1996\09\25@084146 by Jacob Blichfeldt

flavicon
face
part 0 2179 bytes
1. As I wrote in another reply to this thread, there's a problem with learning from RCUs which changes it code (for the same button) each 2nd time the key is pressed. I cannot figure out a generel way of learning these code. I thought about your approach, eventually with some recognizing of (to me) known brands that uses bit-toggling.
Another question is: How long should the maximum (sample) time between transistions be? I've seen some RCU (JVC) using up to 4ms between shifts, while a RC-5 compatible RCU uses a about 800us as a minimum. And what about resolution? Should I go for 10-100us steps, and how big should the error-margin (when receiving an already stored code) be?
To overcome the problem: Resolution/max. time between transistions, I thougt about using some kind of floating point format (unsigned, and in a format easy to decode/encode by a PIC).

Is there really no special way a binary sequence can be encoded, for later comparision? Averaging or maybe some exotic mathematical way?


2. In my application I really dont need to know what the code means. I just need to (free) buttons on a remote-control, one for up and one for down. These are the only buttons the lightdimmer will have to learn, and their original  purpose (on the RCU) doesn't mean anything.

I would very much like to see your code.

Regards
Jacob Blichfeldt


Jacob,

There are two aspects of learning the IR codes.

1.  Learning the time for the header, the bit start, and the "1" and "0".
ie the serial string usually looks like:

_________          ___    ___      __    ___      ___
        |________|   |__|   |____|  |__|   |____|     ...
        ^        ^   ^      ^    ^  ^  ^
         Header  |Strt      | "1"   |"0"

I setup the counter (TMR0) and then read it out for each transition.  I
created a simple program for reading the Sony I/R Remote (all the
transitions to the point where the timer overflowed) and displayed them on LEDs.

2.  Learning what each code means.  Actually, the same hardware was used as
for the program above, I just read each incoming packet and display them.

You're welcome to the code if you want it,


1996\09\26@102949 by myke predko

flavicon
face
Hi Jacob,

>Myke
>
>1. As I wrote in another reply to this thread, there's a problem with
learning from RCUs which changes it code (for the same button) each 2nd time
the key is pressed. I cannot figure out a generel way of learning these
code. I thought about your approach, eventually with some recognizing of (to
me) known brands that uses bit-toggling.

I'll send you the code tomorrow (it's at home and I'm not).  One of the
useful references for what I/R codes mean is
ftp://hemul.nada.kth.se/home/d89-bga/files/remote/remotes.  This ftp site
contains the code and formats for a number of different manufacturers.

Warning about this site.  It is very difficult to understand what the format
of each I/R code "packet" is in because of the way the author wrote it.
And, I found the timings (for the Sony and one other manufacturer - sorry I
can't remember who - that uses the 40KHz carrier) were wrong.  Actually,
they were so consistantly different that I ended up checking the timings on
a scope here at work to figure out which was wrong, my program or the data
in the ftp site.

>Another question is: How long should the maximum (sample) time between
transistions be? I've seen some RCU (JVC) using up to 4ms between shifts,
while a RC-5 compatible RCU uses a about 800us as a minimum. And what about
resolution? Should I go for 10-100us steps, and how big should the
error-margin (when receiving an already stored code) be?

Good question.  Look at the ftp site and it should give you some ideas.
Again, note that I don't have a great deal of confidence in the timing
values given, but they should give you an idea.

The Sony Brand I/R Remote has a minimum transition time of 500 usec (The
start of each bit).  In my final code, I used the port change interrupt and
the time-out interrupt to read the transitions.  I set up TMR0 to the
maximum delay plus 100 usec - this worked really well to find
inconsistancies and only allow the correct manufacturer's code through (if
TMR0 ever times out, then the code is invalid and the waiting starts over).

The 100 usec delay was something that I found to be pretty useful.  The I/R
receivers may not pick up the first or second pulse (of the 40 KHz train)
which means on various bits you will regularly be out by 50 usec.  I
discovered this when I was setting up my application (an I/R remote tank)
with two receivers.  Even side by side, they never synched up for each bit
and the errors were never consistant.

>To overcome the problem: Resolution/max. time between transistions, I
thougt about using some kind of floating point format (unsigned, and in a
format easy to decode/encode by a PIC).

Don't bother, I found 8 Bit resolution to be fine to accurately read the data.

>Is there really no special way a binary sequence can be encoded, for later
comparision? Averaging or maybe some exotic mathematical way?

No.  You don't have the resolution in the PIC to do it.

Actually, I'm probably lying.  You probably *can* if you run a pic at 33 MHz
(ie a 17Cxx) I did all my work with a C84 running at 1MHz.

Now, just having a thought of how there *may* be another way of doing this.
It would involve a trick I saw years ago when we were building Token Ring
Adapter Cards.  We had a similar problem where we didn't want to develop a
sampler that could read ever bit going across the line (packets were 128
bytes long with several packets to make up a message).  To eliminate the
development work that would be required, the engineer put a frequency
counter on the line and learned the "frequency" at various times (we could
start the frequency counter at a time repeatable to about 100ns - this was
in 1985).  The test would be comparing a read frequency to the expected.  I
was always amazed at how well this worked.

A similar method could be used for the PIC where a TMR0 timeout Interrupt
Routine could sample periodically and add the input value (high or low) to a
counter.  The total period would be the total period of the data sending
plus the dead time between data packets.  Sample time would be 2x the data
bit start time (500 usec for Sony) to ensure that each bit was sampled.

Hmmm...  Now I'm intrigued.  I'm gonna try this out in the next day or so
and I'll post my results.  This could be a substantially easier method of
reading I/R codes (along with other types of data).

>2. In my application I really dont need to know what the code means. I just
need to (free) buttons on a remote-control, one for up and one for down.
These are the only buttons the lightdimmer will have to learn, and their
original  purpose (on the RCU) doesn't mean anything.

See my comments above, I'll post my results presently.

>I would very much like to see your code.

I'll beam it to you tomorrow.


Sorry for the dissertation on my experiences on reading I/R Codes.  But, I
have put in a fair amount of work on the subject.

Myke

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

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