From PICLIST@MITVMA.MIT.EDU Thu Nov 14 02:30:11 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id AB33D850048; Thu, 14 Nov 2002 02:30:11 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007D38E7@cherry.ease.lsoft.com>; Thu, 14 Nov 2002 5:16:22 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 0635 for PICLIST@MITVMA.MIT.EDU; Thu, 14 Nov 2002 04:03:23 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 2898; Thu, 14 Nov 2002 04:01:31 -0500 Received: from mailo.vtcif.telstra.com.au [202.12.144.17] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Thu, 14 Nov 2002 04:01:29 EST X-Comment: mitvma.mit.edu: Mail was sent by mailo.vtcif.telstra.com.au Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id UAA07712 for ; Thu, 14 Nov 2002 20:01:28 +1100 (EST) Received: from webi.vtcif.telstra.com.au(202.12.142.19) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0d5_h0; Thu Nov 14 20:00:54 2002 Received: (from uucp@localhost) by webi.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA11885 for ; Thu, 14 Nov 2002 19:58:18 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0eaG4t; Thu Nov 14 19:56:23 2002 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id TAA15228 for ; Thu, 14 Nov 2002 19:58:52 +1100 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id ; Thu, 14 Nov 2002 19:59:00 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 14 Nov 2002 19:58:57 +1100 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "Richards, Justin P" Subject: Re: [EE]: DVD remote control codes To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600414 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 00000687-0000 Bob, very interesting. These are along very similar lines to the path I have taken. Some of the codes I looked at appeared to have more 'marks' and 'spaces'(M&S) than 45 so I thought I would use more to cater for all scenarios, I decided on 80 and as I have lots of EEPROM I thought later perhaps 160 M&S i.e. 320 bytes. I am using 26.2us intervals (i.e. 38 kHz) so it is easy to reconstruct with the 38khz carrier. (I intend to later work on measuring exactly what the carrier freq is and store this with the code) Then I thought I have plenty of EPROM I will record precisely the duration of the long intervals. So I would need 160 bytes,2 bytes per M&S. This presented bank selection problems so I thought no worries I will record the 80 marks and spaces over 2 passes saving the first then second chunk of 40 to the slow EEPROM successively. I have just finished all that then discovered that I cant read the EEPROM as (investigating this) quickly as I needed to regenerate the original. doh It looks like I must have it reloaded into RAM again if I want more than 80bytes used I have bank switching issues. I found I don't need a level bit as the output of the sensor is high with no signal and assume the pulses alternate. I take it that you download the entire command at 4800 baud then fire them off. I had hoped I could throw enough processor speed using a 16f628 and EEPROM that I would not have to use any tricks to encode the signal. I Just wanted whatever went in is what came out and perhaps be useful later to capture different device signals faithfully like monitoring RS bus signals. The only trick I wanted to incorporate was to use many passes and average the contents of each byte. I noticed similar results with overdriving IR sensors and found if I want to IR xfer data between two pc they should be quite some distance apart for max speed and reduce errors. Justin -----Original Message----- From: Bob Axtell [mailto:bob@EDTEC.COM] <> If I did it again, I would (1) use a 10Mhz PIC at 8Mhz, (2) store the data in an I2C memory for all the codes the client needed. Then, instead of sending am RS232 command of 46 bytes, a 2-bytes code would suffice, being an INDEX into the possible IR codes. Assuming 128bytes per code, a FRAMTRON 32Kx8 could store 256 DIFFERENT IR bursts. <> -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics