Encoding, something to think about.

Looking at traces of a few remotes I have around the house they have
combinations of different width pulses for preambles and code bits etc
making the encoding quite challenging and appears to involve significant
overheads but still saving in storage. (trade offs trade offs trade offs...)

It would appear as mentioned in a previous post that I have no choice to
port to 16F6?? as a minimum so I can store the code to analyse.

I am going to bite the encoding bullet, may prove to be simpler than it
appears.

Thanks for the input

Justin

-----Original Message-----
From: M. Adam Davis [mailto:adampic@UBASICS.COM]
Sent: Thursday, 20 June 2002 21:01
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: IR Universal Remote Joys & Woes


The better the compression and more faithful the representation you
want, the harder the algorithm has to work.  Probably the best you can
do is store a sequence of bytes contiaining time to next transition
initially, then post process that data.  Most remote data can be
considered a simple serial stream using a very few different methods
such as straight serial, manchester encoded, etc.

You can take the bit times given and determine the encoding, then the
baud rate, then simply store a byte or two describig those variables and
decode the entire string into 4 or 5 bytes of serial data.

When it runs into a stream it can't decode then store it as the time
slices - compress it as much as you can by trying to find a common
length to all the pulses and shortening it (ie, you can probably
describe the slice time and each slice then only needs 3 or 4 bits to
describe its length.)

If you want to take in all infrared remotes you'll also need to consider
that a few use transmitting frequencies other than 38-42kHz.

You may want to look into replacing the f84 with an f6xx.  There is more
code space and eeprom storage, as well as more memory to store the
received code.

I hope this project goes well, I need a universal programmable remote.
 None of the universal remotes I've found runs my Fisher VCR's menu
system or selects inputs.  (yeah, I could get another fisher remote, I
know...)

-Adam

Richards, Justin P wrote:

>Hi folks
>
>all excited yesterday finally after much time and lots of listening to the
>LIST got my 16F84 @ 4MHz to record a Sony IR command and successfully
>retransmit.
>
>TMR0 is used to generate periodic (26us) increments of the contents of a
>memory location.  Then interrupt on change RBIF is used to point to the
next
>memory location.
>
>The result is a string of bytes containing the duration in multiples of
26us
>of each mark and space of the IR code.  This works fine for the Sony as it
>uses 13 bits therefore I use 26 bytes to record the pattern.  (I later plan
>to store this in external EEPROM)
>
>I have discovered other remotes (see
>www.users.bigpond.com/jkrichards/Pic/PicPage.htm click on trace.bmp) use up
>to 34 bits therefore I need 68 bytes, this is all of the 16F84 data memory.
>
>I have tried to think of ways to compress the data but it needs to be
>captured before it can be processed.
>
>Another idea I entertained was to generate the periodic interrupt and test
>for highs and lows and record this as a big long string of bits.  But this
>would use about 3000 bits or 375 bytes for a code 60ms in duration..
>
>Also for it to be truly universal I cant make any assumptions about
>bit/pulse width.  It should be able to faithfully record any brand.
>
>Any thoughts on a better process that does not use so much valuable data
>space will be most welcome.
>
>I am more than happy to elaborate on the existing design if anyone is
>interested in doing similar things.
>
>Justin
>
>--
>http://www.piclist.com hint: To leave the PICList
>mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>
>
>
>
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu