Post by thread:[PIC]: IR Universal Remote Joys & Woes

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 http://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 spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

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: {Quote hidden}>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 >http://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 >.....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu > > > > > > > -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

Here is an idea: 1: Create a data structure, called 'dictionary' of 16 bytes. Initialize it to all zeros 2. Assume you won't see more than 16 different pulse widths 2. Measure each mark and space as you do now 3. Compare the time of the mark or space to the entries in the dictionary. Find the 'nearest' value in the dictionary. If there is an entry 'close' to this value then: Modify the dictionary entry to be ( 3 * dict_entry + new_value) / 4. This step will hopefully help the dictionary entry be closer to the exact correct time. otherwise allocate an unused dictionary entry and store this time in it. 4. Record the three-bit index (0..15) of the dictionary entry that was found or added. Now you can store 2 times (one mark, one space) in each byte of memory. Now, for a 34 bit code you will need: 16 bytes for the dictionary 34 bytes for the time codes --- 50 bytes total Bob Ammerman RAm Systems -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

----- Original Message ----- From: "Bob Ammerman" <rammermanspam_OUTADELPHIA.NET> To: <@spam@PICLISTKILLspamMITVMA.MIT.EDU> Sent: Thursday, June 20, 2002 4:24 PM Subject: Re: [PIC]: IR Universal Remote Joys & Woes {Quote hidden}> Here is an idea: > > 1: Create a data structure, called 'dictionary' of 16 bytes. Initialize it > to all zeros > > 2. Assume you won't see more than 16 different pulse widths > > 2. Measure each mark and space as you do now > > 3. Compare the time of the mark or space to the entries in the dictionary. > Find the 'nearest' value in the dictionary. If there is an entry 'close' to > this value then: > > Modify the dictionary entry to be ( 3 * dict_entry + new_value) / 4. > This step will hopefully help the dictionary entry be closer to > the exact correct time. > > otherwise allocate an unused dictionary entry and store this time in it. > > 4. Record the three-bit index (0..15) of the dictionary entry that was found ....er, that is 'four-bit index', not 'three-bit index' {Quote hidden}> or added. Now you can store 2 times (one mark, one space) in each byte of > memory. > > Now, for a 34 bit code you will need: > > 16 bytes for the dictionary > 34 bytes for the time codes > --- > 50 bytes total > > Bob Ammerman > RAm Systems > > -- > http://www.piclist.com hint: To leave the PICList > KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

On Fri, 21 Jun 2002, Richards, Justin P wrote: >That's a great idea. > >Pulse widths I have measured are like 10, 0E, 3E,3F etc. So I guess >'nearest' would be perhaps (+/- 2) and the decoders would have a tolerance >range. I will experiment to see how far out a pulse width can actually be. > >Thanks > >Justin Usually you have at most 4 pulse widths in a IR word. One is for the 'zeros' one for the 'ones', the third for the start pulse and the fourth for a sometimes different start gap. You could actively correct the values in the bins to match the actual value of the measured pulse. Like say, you find 3E, the difference vs. the bin containing 3F is smallest, so you write down the code of that bin in the stream and then bin = (bin+new)/2. If you start with 4 bins containing values spaced out a little, say, 10, 40, 80, c0 and apply this algorythm for several words then the bins should converge to the real values after a while. You could measure errors (err=[bin-new]) and consider the code learned when the errors become smaller than a certain margin (say +/- 2 counts). Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads