From PICLIST@MITVMA.MIT.EDU Thu Nov 14 11:07:42 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A47E11EA00DC; Thu, 14 Nov 2002 11:07:42 -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 <22.007D875B@cherry.ease.lsoft.com>; Thu, 14 Nov 2002 13:53:43 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 9393 for PICLIST@MITVMA.MIT.EDU; Thu, 14 Nov 2002 13:53:31 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 6891; Thu, 14 Nov 2002 13:52:50 -0500 Received: from pop015.verizon.net [206.46.170.172] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Thu, 14 Nov 2002 13:52:47 EST X-Comment: mitvma.mit.edu: Mail was sent by pop015.verizon.net Received: from djm ([151.199.99.135]) by pop015.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021114185238.YYDS28019.pop015.verizon.net@djm> for ; Thu, 14 Nov 2002 12:52:38 -0600 References: <581B2D4388B5D21197660008C79FE034022FA18E@exmyford01.stbu.com> <000b01c28c0b$c256ea00$0a01a8c0@djm> <3DD402B1.12B43A59@3mtmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop015.verizon.net from [151.199.99.135] at Thu, 14 Nov 2002 12:52:34 -0600 Message-ID: <001401c28c0e$fc3110e0$0a01a8c0@djm> Date: Thu, 14 Nov 2002 13:52:19 -0500 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "Dennis J. Murray" Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600484 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000006c9-0000 Less than 8 hours of darkness (or daylight) means that the device triggers that much AFTER dusk/dawn, rather than right at dusk/dawn. It then waits 8 hours before checking for the next event. ----- Original Message ----- From: "Josh Koffman" To: Sent: Thursday, November 14, 2002 3:08 PM Subject: Re: [PIC]:failed data location? > Shot in the dark, but maybe the device isn't seeing 8 hours of darkness. > Could something have changed about the housing? Its orientation for > instance? Or what about spill from nearby lighting? I know it's working > with the new chip, which probably means my suggestions are pointless. > > Josh > -- > A common mistake that people make when trying to design something > completely foolproof is to underestimate the ingenuity of complete > fools. > -Douglas Adams > > "Dennis J. Murray" wrote: > > The only factors I can think of is if we have a solar eclipse - might fool > > it into thinking dusk came early. The routine waits for 8 hours after > > triggering for looking for the opposite event. I.e. if we just triggered > > DUSK, willl not look for DAWN for 8 hours & vice versa. Even if we had a > > solar eclipse, it would resyncronize itself the next day. Tested that. > > > > There are no code overlaps either- looked for that early on. I use ONLY > > variable names - never direct RAM locations in code. All variables are 1 > > byte long, so none of them would overflow into the adjacent byte. > > > > Routine could care less about daylight savings time - only that 8 hours or > > more have elapsed since the last valid event (dusk or dawn). > > -- > 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 > > -- 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