From PICLIST@MITVMA.MIT.EDU Fri Nov 15 07:41:37 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A5B1116600AC; Fri, 15 Nov 2002 07:41:37 -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.007DC944@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 10:27:31 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 3917 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 10:27:23 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 1945; Fri, 15 Nov 2002 10:25:19 -0500 Received: from *unknown [64.69.111.211] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with ESMTP ; Fri, 15 Nov 2002 10:25:18 EST X-Warning: mitvma.mit.edu: Host *unknown claimed to be imtrant1.imtra.com Received: from maxengineering1 ([192.168.1.9]) by imtrant1.imtra.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 15 Nov 2002 10:23:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 15 Nov 2002 15:23:36.0718 (UTC) FILETIME=[F7B11AE0:01C28CBA] Message-ID: Date: Fri, 15 Nov 2002 10:23:35 -0500 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Paul Hutchinson Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU In-Reply-To: X-RCPT-TO: Status: R X-UIDL: 277600683 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 0000077e-0000 > -----Original Message----- > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Dale Botkin > Sent: Friday, November 15, 2002 9:18 AM > > Oh ferheavenssake. ONE $3 chip fails. You KNOW it failed (worked fine > > If you're using the chip within the power, temperature, humidity, I agree 100% with you Dale but, he is _not_ following the specification for temperature range. He has a PIC rated for 0 degC and is using it at lower temperatures probably as low as -5 degC. Whether or not this is the cause of the failure it is still a _major problem_ for anything other than a hobbyist one off. Oh and with PIC's the price difference between 0degC parts and -40degC parts is tiny. There is a very common misconception among the general public and to a smaller extent among engineers. They seem to believe that only high temperatures are a problem for electronic components. I am always hearing statements like "colder is always better for electronics". Earlier this year I even had an FAE from Linx Technologies (RF module maker) insist that even though the specs for one of their modules clearly stated 0 degC as the low temperature spec it would be fine to -40 deg. The FAE had the contract consultant and our management convinced to simply ignore the temperature specification. I asked for more details and heard that there is one part in the module rated only to 0C by Phillips and the FAE said he was 100% confident it would be OK to -40. I replied, fine change the spec sheet or give us a letter saying that this module is OK to -40. The FAE said the engineering manager would not allow either option and we would have to take his word for it. We have released the product but using modules from RF monolithics that are rated for -40deg operation instead of the Linx module. I've been designing meteorological instruments for a living for over 20 years now and a few times every year I run up against this misconception. Paul ========================================= Paul Hutchinson Chief Engineer Maximum Inc., 30 Samuel Barnet Blvd. New Bedford, MA 02745 phutchinson@imtra.com http://www.maximum-inc.com ========================================= > vibration and other limits specified in the data sheet, you can reasonably > expect the performance specified by Microchip or whatever manufacturer. > If you're outside any or all of these limits, all bets are off. QA and > testing data are available on their web site. Using THIS information to > determine what the chances are of the same thing happening to other units > in the field is what "any responsible engineer" should be doing. > > Component failures are a fact of life that we have to deal with, no matter > spacecraft, weapons systems) a single failure is pretty much a non-event. > > Dale > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.