From owner-freebsd-hackers Sun Feb 4 21:12:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA01955 for hackers-outgoing; Sun, 4 Feb 1996 21:12:10 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA01714 for ; Sun, 4 Feb 1996 21:10:08 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA06529; Mon, 5 Feb 1996 15:52:27 +1030 From: Michael Smith Message-Id: <199602050522.PAA06529@genesis.atrad.adelaide.edu.au> Subject: Re: Watchdog timer To: uhclem@nemesis.lonestar.org (Frank Durda IV) Date: Mon, 5 Feb 1996 15:52:26 +1030 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Frank Durda IV" at Feb 4, 96 09:41:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk Frank Durda IV stands accused of saying: > [18]Hmm. I'd do this internally, presuming that resetting would be enough. > [18]It's not actually as simple as you make it sound though; you need a > [18]missing-pulse detector (consider the situation where the disk light stays > [18]on) and a timer that runs for longer than the 100-second maximum for the > [18]555. > > Two things: first, you must assume that if the activity light stays > on for the maximum amount of time, this is a crash. I have several > systems that crash from time to time and they can be spotted visually > because the IDE access light is stuck on. No panic, just off in la-la > land but the IDE light is on solid. The timer, however implemented, > must re-arm on rising or falling edge transitions (doesn't have to be both), > not on levels to avoid ignoring crashes while disk access was > still in progress and not completed. Assuming you're using an opto for the input (common sense), this requires two resistors, a capacitor and a diode. A nuisance to load, admittedly, but not hard to implement, and an absolute must. (Really an edge detector rather than a missing-pulse detector) > [18]This (the power cycling) would add significantly to the cost of the unit; > [18]consider a 15A relay and the extra wiring involved in terms of assembly > [18]cost. > > No doubt, and the pricing I mentioned reflects this. Probably I would > simply buy load control modules which several companies make. They are > meant for traffic control signal applications. They just look for 5V > and activate a load, usually using a 10A solid state relay which will > handle the inductive load of a switching power supply just fine. Er, I beg to vary, if not differ here. Switching power supplies have very nasty dV/dt characteristics, which quickly runs you into the more expensive SSRs. These don't compare terribly favourably cost-wise with 12V coil DPST 15A line relays, but do have the advantage of requiring less in the way of support parts. > Controlling power is clearly not a feature for everybody, but is something > that can be easily added or not added since there are so few components > and drill-outs involved in the delta. I would probably use it in > important systems that aren't staffed 24 hours a day. Certainly supporting an external power-tripping relay would be desirable. You mentioned FCC rules regarding oscillators; how fast does the osc. have to be before they get in a tizz? (eg. consider a 74HC4060 at 5Hz or so) > Frank Durda IV |"If you say bad things about -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "wherever you go, there you are" - Buckaroo Banzai [[