From PICLIST@MITVMA.MIT.EDU Thu Nov 14 10:55:09 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A18DEEF00EA; Thu, 14 Nov 2002 10:55:09 -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 <19.007D856D@cherry.ease.lsoft.com>; Thu, 14 Nov 2002 13:41:14 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 9240 for PICLIST@MITVMA.MIT.EDU; Thu, 14 Nov 2002 13:41:04 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 6605; Thu, 14 Nov 2002 13:39:55 -0500 Received: from mail.3mtmp.com [141.117.25.187] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Thu, 14 Nov 2002 13:39:54 EST X-Comment: mitvma.mit.edu: Mail was sent by mail.3mtmp.com Received: from s25-20.resnet.ryerson.ca ([141.117.25.20] helo=3mtmp.com) by mail.3mtmp.com with esmtp (Exim 3.12 #1 (Debian)) id 18CPOL-0007fq-00 for ; Thu, 14 Nov 2002 14:11:05 -0500 X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <581B2D4388B5D21197660008C79FE034022FA18E@exmyford01.stbu.com> <000b01c28c0b$c256ea00$0a01a8c0@djm> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DD402B1.12B43A59@3mtmp.com> Date: Thu, 14 Nov 2002 14:08:17 -0600 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Josh Koffman Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600481 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000006c6-0000 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