Searching \ for 'IR code compression for storage in the PIC and lat' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ios.htm?key=ir
Search entire site for: 'IR code compression for storage in the PIC and lat'.

Truncated match.
PICList Thread
'IR code compression for storage in the PIC and lat'
1999\04\16@120445 by Jaume Aragay Badia

picon face
Hi again!

               I have a question about IR remotes. For my project at university
I'm
preparing a house control for blind people or people with cerebral palsy.
One of the items is a kind of universal remote control that learns from the
existing ones the more used codes. Now to the point...

       How would you store this IR codes information? Because in Myke Predko's
book he uses a sort of CRC to store the information recieved and just
identify it but, is there any way to *undo* this CRC to get the original
code again to send it?

       In other words, is there any way to store the codes recieved in a small
size format and to put them back to the original format later when they are
to be sent?

TIA.


Jaume.

----------------------
 Jaume Aragay Badia
  spam_OUTaragayTakeThisOuTspamemail.com
----------------------

1999\04\16@132215 by Andy Kunz

flavicon
face
>size format and to put them back to the original format later when they are
>to be sent?

The best way is to measure time between edges.  There are a variety of
different formats, and the active time vs inactive plus position of the
pulses will do that for you.

Andy


==================================================================
Montana Design - http://www.montanadesign.com - Electronics & Model Boats
==================================================================

1999\04\16@204523 by Kevin Cantrell

flavicon
face
Jaume,

In my project I've had the luxury of focusing on one brand of remote
control - Sony.  It turns out that the Sony protocol uses a distinct series
of long or short 40kHz bursts (prefaced with a ~2500 us start bit).  I
decided to interpret the short bursts (~600 us) as binary 0 and the long
bursts (~1200 us) as binary 1.  Since there are thirteen bursts in the Sony
protocol (7 for function, 5 for device), I wind up with a 13 bit binary
number that represents the code for a single button.  The OFF times are
always the same and don't need to be stored.

This approach won't work for a universal learning remote since not everyone
uses the same timing as Sony.  You may be able to acquire all of the ON and
OFF times in an array, and then group the times into long and short bursts
on the fly.  Then you could store the times (only once) along with a binary
representation of the pattern in which they are used.  I've seen some
remotes concatenate a code and the same code with the longs and shorts
inverted. I've seen others swap the ON and OFF times.  This approach allows
the times for all commands to remain constant, and would allow you to store
the data with half the bits.

Basically, to compress the codes you'll have to acquire a lot of data (all
the ON and OFF times), look for a pattern (the pulses have two possible
durations), and then store a compact representation of the pattern (binary
1 for long, 0 for short) and they key to using it (long is 1200 us, short
is 600 us).  The information in parenthesis will vary with the remote's
protocol.

Of course you could always get a big serial EEPROM and store all the ON and
OFF times!

Good luck and let me know what you find out,
Kevin


>Hi again!
>
>                I have a question about IR remotes. For my project at
university I'm
>preparing a house control for blind people or people with cerebral palsy.
>One of the items is a kind of universal remote control that learns from the
>existing ones the more used codes. Now to the point...
>
>        How would you store this IR codes information? Because in Myke
Predko's
>book he uses a sort of CRC to store the information recieved and just
>identify it but, is there any way to *undo* this CRC to get the original
>code again to send it?
>
>        In other words, is there any way to store the codes recieved in a
small
{Quote hidden}

Kevin Cantrell
Oregon State University
Department of Chemistry
153 Gilbert Hall
Corvallis, Oregon 97331-4003

1999\04\16@210203 by Wagner Lipnharski

picon face
One suggestion:
Receive the code, store in memory. Scan the received code and try to
find when a block repeats itself in the transmitted train. Save just one
complete block code. Scan this block and find the smallest piece of the
same level, zeros or ones. The quantity of bits in memory for that
particular smallest information is your key reduction. Now shrink all
the stored information based in this reduction key, so the smallest
piece found would be just one bit. The compression needs to be done at
each time you find a change from one level to another...It should use
few hundred bits for that code, don't forget to save also the reduction
key to be used as "expansion" when replaying it.  A 32k eeprom, like the
24C256, should store near a thousand of codes...

Wagner.

1999\04\18@010615 by Graeme Smith

flavicon
face
Actually what you are describing is COMPRESSION rather than a CRC.

YES there are compression schemes.

For instance, Huffman Coding....

It's really simple.

Do a Statistical Analysis of your data, (As measured in operation)
Take the highest statistical values, and using a variable length storage
unit, store them using the smallest storage element.

EG:

The highest probability event is coded 0

The next most highest probability event is coded 10,

the next most (Third probability event is coded 110... etc.

You will find that you can only code stuff about 5 levels deep this way
before it begins to expand the cost of your code. (assuming a byte
oriented coding scheme that you are trying to compress).

Then, simply use the last coding level, + the actual data, from then on.

It works best when there is a Wide variation in statistical probability,
i.E. the first element is 90% of all elements measured.... etc.

Its also a lot of bit banging.

Alternately, utilizing a coding/compression scheme based on the fact that
the range of values is less than the permutations of the data storage
element, ie 8 bits = 256, (often called "Packing") can reduce
storage to the point where you recover the difference between the packed
size of the data, and the unpacked size.

I have heard of really far out compression schemes, but, found that many
of them were ignorant of one especial rule of storage, (you can't reduce a
data element beyond the number of bits required to cover the number of
permutations that will be stored, unless you LOSE DATA, which
afterwards you won't necessarily be able to recover). You can take
advantage of the fact that you do not use the whole set of permutations,
by using a dictionary based form of compression, but again, it is based
on the concept that you do not need the same amount of data to store, the
lesser permutations, than you would if you used all the possible values.

If you have a "Dictionary" of more used terms, you can "Pack" the data,
(Possibly using Huffman coding) into a smaller space, but need to include
a reference to which "Dictionary" you are using, the more dictionaries you
need, the less effective your compression becomes.

If you have a limited number of options, it is sometimes possible to
"Approximate" the correct value, by using "Hashing" type algorythms, but
be careful, it's only an approximation, you can have "Hits" where two
values have the same "Hashing" value. In this case only the first value
will come out when you search, unless you do multiple results from your
search.

A CRC is really only a specific type of "Hashing" formula, in this manner
of compression.

When using a CRC, it is really only a one-way algorythm, because all it
is meant to do, is allow you to compare two values that are similar to
see if they are the same. It makes its own assumptions, that you wont
be comparing things that are so different as to wrap around, and have the
same CRC value.

True Compression is two way. Don't be fooled by Imitations... ;)


GRAEME SMITH                         email: grysmithspamKILLspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Fri, 16 Apr 1999, Jaume Aragay Badia wrote:

> Hi again!
>
>                 I have a question about IR remotes. For my project at universi
ty I'm
{Quote hidden}

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