For my application I was looking for a very low current reset chips - supervisor and watchdog with no external components and in a small case (SO8 is too big). After searching at ti.com I only found the TPS3813 - with 10uA current consumption. Too much. But then I stumbled through my archive of this list and there was a suggestion: TI TPS3110K33 (2uA) - quite good. And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the TPS3110 (only 2 pins swapped). The drawback is: one can get it only in quantities of 2 or 2500. Does some of you know a distributor that would sell me e.g. 100pcs? Are there other low current supervisor/watchdogs available? My TOP TWO are still the MAX6864 and the TPS3110 - I did'nt find better ones. Matthias

most efficient watchdog and supervisor
Started by ●October 19, 2004
Reply by ●October 19, 20042004-10-19
I don't use one, and have never had the need. Cheapest option around.
;?}
Al
Matthias Weingart wrote:
> For my application I was looking for a very low
current reset chips -
> supervisor and watchdog with no external components and in a small case
(SO8
> is too big). After searching at ti.com I only found the TPS3813 - with 10uA
> current consumption. Too much.
>
> But then I stumbled through my archive of this list and there
> was a suggestion: TI TPS3110K33 (2uA) - quite good.
>
> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
> quantities of 2 or 2500. Does some of you know a distributor that would
sell
> me e.g. 100pcs?
>
> Are there other low current supervisor/watchdogs available? My TOP TWO are
> still the MAX6864 and the TPS3110 - I did'nt find better ones.
>
> Matthias
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Reply by ●October 19, 20042004-10-19
Al OK, I know I'm opening myself up for a "learning" experience, but here goes anyway: What do you use for brownout detection and recovery? -Bill Knight R O SoftWare On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote: >I don't use one, and have never had the need. Cheapest option around. >;?} >Al >Matthias Weingart wrote: >> For my application I was looking for a very low current reset chips - >> supervisor and watchdog with no external components and in a small case (SO8 >> is too big). After searching at ti.com I only found the TPS3813 - with 10uA >> current consumption. Too much. >> >> But then I stumbled through my archive of this list and there >> was a suggestion: TI TPS3110K33 (2uA) - quite good. >> >> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the >> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in >> quantities of 2 or 2500. Does some of you know a distributor that would sell >> me e.g. 100pcs? >> >> Are there other low current supervisor/watchdogs available? My TOP TWO are >> still the MAX6864 and the TPS3110 - I did'nt find better ones. >> >> Matthias
Reply by ●October 22, 20042004-10-22
Am I really that bad?
Why might I expect brownout to occur in the first place? If I have no
sound reason to expect it then I have no need to compensate for it. I do
monitor my supplies constantly, and do a lot of power management, but in
all of the testing I've done I've never experienced brown out once.
Al
Bill Knight wrote:
> Al
> OK, I know I'm opening myself up for a "learning"
experience, but
> here goes anyway: What do you use for brownout detection and recovery?
>
> -Bill Knight
> R O SoftWare
>
>
> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>
>
>
>>I don't use one, and have never had the need. Cheapest option
around.
>
>
>>;?}
>
>
>>Al
>
>
>>Matthias Weingart wrote:
>
>
>>>For my application I was looking for a very low current reset chips
-
>>>supervisor and watchdog with no external components and in a small
case (SO8
>>>is too big). After searching at ti.com I only found the TPS3813 -
with 10uA
>>>current consumption. Too much.
>>>
>>>But then I stumbled through my archive of this list and there
>>>was a suggestion: TI TPS3110K33 (2uA) - quite good.
>>>
>>>And there is the MAX6864 (0.2uA!). The pinout is nearly the same as
the
>>>TPS3110 (only 2 pins swapped). The drawback is: one can get it only
in
>>>quantities of 2 or 2500. Does some of you know a distributor that
would sell
>>>me e.g. 100pcs?
>>>
>>>Are there other low current supervisor/watchdogs available? My TOP
TWO are
>>>still the MAX6864 and the TPS3110 - I did'nt find better ones.
>>>
>>> Matthias
>
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Reply by ●October 22, 20042004-10-22
Sorry Al, I definitely should have inserted a <grin> or two in my message. Though your dogged support for assembly language is legendary, your experience with both the MSP and with low power, embedded systems design is equally impressive. And unlike many (myself included), you always seem ready to help those who are able to post a reasonable question. I had to ponder your response. It is not really something I had consider recently. And yes, I must admit there are probably many designs in which recovering from a brownout may not be required. However, there are systems in which it is necessary. In one instance, the design was for an inductively coupled and powered interface device that allowed non-contact reading of water meters. The reader would output a 32-40KHz "tone" into/onto 1/2 of a pot-core transformer. The device had the other half of the transformer as its input and power supply. The reader would on/off modulate the tone to send data to the device. The device would send back data by modulating the transformer when the reader was silent. All the while the device was rectifying the output of the transformer and using it for its power source. The problem came when the reader/device transformer coupling (it was positioned by the person doing the meter reading) was either insufficient or dropped out while the device was in operation. The reading could be retaken but recovering from the brownout was necessary. -Bill On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote: >Am I really that bad? >Why might I expect brownout to occur in the first place? If I have no >sound reason to expect it then I have no need to compensate for it. I do >monitor my supplies constantly, and do a lot of power management, but in >all of the testing I've done I've never experienced brown out once. >Al >Bill Knight wrote: >> Al >> OK, I know I'm opening myself up for a "learning" experience, but >> here goes anyway: What do you use for brownout detection and recovery? >> >> -Bill Knight >> R O SoftWare >> >> >> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote: >> >> >> >>>I don't use one, and have never had the need. Cheapest option around. >> >> >>>;?} >> >> >>>Al <<<< snip >>>>
Reply by ●October 22, 20042004-10-22
Hi Bill and Al,
I've done several apps where brownout protection was paramount, and
by the same token I've known an Oz based company that was exporting
critical industrial systems, such as Mains Water pollution (backflow)
monitoring,
where they were shipping F149 based designs without even as much as the use of
the
watchdog, and their USA client was very happy, no problems.
I personally found it bizarre, but maybe they were using really sound HW design
- dunno -
...which would equally support Al's assertion.
(I only did the RF for them)
My personal experience is that - ironically - brown out protection is very
important
on battery powered products, where eg. AA alkalines and the likes are replaced.
The bounce in the battery holder seems to be unfriendly to an MCU w/o BOD.
Finally, I think it's important to establish what "brown out"
means for each of us.
For me brown out includes Vcc "sagging" fast, but then eg. rise
slower, but equally
includes transients that go right through the regulator (the feedback in LDO
isn't fast
enough), and even ceramic (thru hole) bypass caps couldn't kill it enough.
Transils seem the sure fire way.
Nowdays LDOs are much better by taking care wrt ESR on eg. SMT tantalum caps.
(ie. ensuring an optimal ESR)
Example : Around 1992 or so when the XC705P9 was introduced, I had nightmare
problems with its MCU clock getting a "cardiac arrest". The WD was
clocked from the Xtal,
so nodes would occasionally fail. This was used in large Emergency lighting
monitoring networks,
(up to 6-8 K nodes in one building) - and big FL battens where a chunky relay
switched the FL
from mains-ballast to inverter (with local battery) on power loss, the relay
contacts arced like the
4th of July. (I found that the manufacturer's inverter would rise to a
600-800 V, before having
the FL (relay) connected, thus the gas hadn't fired yet - after all it will
fire at 90 Volts or so IIRC)
Certain fall/rise Vcc sequences would kill the MCU clock...
This was catastrophic, as they'd sometimes happily freeze on the RS485
while in TX @#$%!!!
(killing a subnet)
Anyhow, eventually I convinced them to use Motorola zero crossing detect optos
with a TRIAC.
Shortly after I redesigned it on PIC16C71, and the network nodes NEVER failed
again.
Back then I loved PICs, and their superior QA, finally someone put the WD on an
RC clock !!!
We'd run 3000 in one go, and NONE would fail in programming (OTP), and
average
_one_ would fail (out of 3 K) after wave soldering....
Basically, I think Al and Bill both equally make a good point.
-- Kris
> Sorry Al, I definitely should have inserted a
<grin> or two in my
> message. Though your dogged support for assembly language is legendary,
> your experience with both the MSP and with low power, embedded systems
> design is equally impressive. And unlike many (myself included), you
> always seem ready to help those who are able to post a reasonable question.
>
> I had to ponder your response. It is not really something I had consider
> recently. And yes, I must admit there are probably many designs in which
> recovering from a brownout may not be required. However, there are systems
> in which it is necessary. In one instance, the design was for an
inductively
> coupled and powered interface device that allowed non-contact reading of
> water meters. The reader would output a 32-40KHz "tone"
into/onto 1/2
> of a pot-core transformer. The device had the other half of the
transformer
> as its input and power supply. The reader would on/off modulate the tone
> to send data to the device. The device would send back data by modulating
> the transformer when the reader was silent. All the while the device was
> rectifying the output of the transformer and using it for its power source.
> The problem came when the reader/device transformer coupling (it was
positioned
> by the person doing the meter reading) was either insufficient or dropped
out
> while the device was in operation. The reading could be retaken but
recovering
> from the brownout was necessary.
>
> -Bill
>
> On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
>
>
> >Am I really that bad?
>
> >Why might I expect brownout to occur in the first place? If I have no
> >sound reason to expect it then I have no need to compensate for it. I
do
> >monitor my supplies constantly, and do a lot of power management, but
in
> >all of the testing I've done I've never experienced brown out
once.
>
> >Al
>
> >Bill Knight wrote:
>
> >> Al
> >> OK, I know I'm opening myself up for a "learning"
experience, but
> >> here goes anyway: What do you use for brownout detection and
recovery?
> >>
> >> -Bill Knight
> >> R O SoftWare
> >>
> >>
> >> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
> >>
> >>
> >>
> >>>I don't use one, and have never had the need. Cheapest
option around.
> >>
> >>
> >>>;?}
> >>
> >>
> >>>Al
>
> <<<< snip >>>>
>
>
>
>
> .
>
>
>
>
>
>
>
>
>
>
> --------
> .
>
>
Reply by ●October 23, 20042004-10-23
Hi Bill, I was only joking too, as you probbaly realise it doesn't
bother me too much what others think, unless it gets to the point where
the majority here get ticked off. Other wise I'll go on trying to be
helpful when I can. I simply still get a kick out of designing and
programming, and hope to be able to pass a little of that on. As to my
dogged support for assembler, it is simply that, these days, I usually
seem to find myself doing stuff that pushes the envelope a little. and
am so accustomed to it by now, and have so many libraries that it really
is so much easier for me than C, or speed (more often than program size)
dictates that I have no option.
I fully understand that there are odd times when brown outs can't be
avoided, as in your example, or even on mains powered designs, but, in
recent years I think only my latest project is mains powered, all the
others use switchers, battery monitors, etc. So I can perform and
orderly shut down before things get too uncomfortable.
Cheers
Al
Bill Knight wrote:
> Sorry Al, I definitely should have inserted a <grin> or two in my
> message. Though your dogged support for assembly language is legendary,
> your experience with both the MSP and with low power, embedded systems
> design is equally impressive. And unlike many (myself included), you
> always seem ready to help those who are able to post a reasonable question.
>
> I had to ponder your response. It is not really something I had consider
> recently. And yes, I must admit there are probably many designs in which
> recovering from a brownout may not be required. However, there are systems
> in which it is necessary. In one instance, the design was for an
inductively
> coupled and powered interface device that allowed non-contact reading of
> water meters. The reader would output a 32-40KHz "tone"
into/onto 1/2
> of a pot-core transformer. The device had the other half of the
transformer
> as its input and power supply. The reader would on/off modulate the tone
> to send data to the device. The device would send back data by modulating
> the transformer when the reader was silent. All the while the device was
> rectifying the output of the transformer and using it for its power source.
> The problem came when the reader/device transformer coupling (it was
positioned
> by the person doing the meter reading) was either insufficient or dropped
out
> while the device was in operation. The reading could be retaken but
recovering
> from the brownout was necessary.
>
> -Bill
>
> On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
>
>
>
>>Am I really that bad?
>
>
>>Why might I expect brownout to occur in the first place? If I have no
>>sound reason to expect it then I have no need to compensate for it. I do
>>monitor my supplies constantly, and do a lot of power management, but in
>>all of the testing I've done I've never experienced brown out
once.
>
>
>>Al
>
>
>>Bill Knight wrote:
>
>
>>>Al
>>> OK, I know I'm opening myself up for a "learning"
experience, but
>>>here goes anyway: What do you use for brownout detection and
recovery?
>>>
>>>-Bill Knight
>>>R O SoftWare
>>>
>>>
>>>On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>>>
>>>
>>>
>>>
>>>>I don't use one, and have never had the need. Cheapest
option around.
>>>
>>>
>>>>;?}
>>>
>>>
>>>>Al
>
>
> <<<< snip >>>>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Reply by ●October 23, 20042004-10-23
microbit wrote: > Hi Bill and Al, > > I've done several apps where brownout protection was paramount, and > by the same token I've known an Oz based company that was exporting > critical industrial systems, such as Mains Water pollution (backflow) monitoring, > where they were shipping F149 based designs without even as much as the use of the > watchdog, and their USA client was very happy, no problems. > I personally found it bizarre, but maybe they were using really sound HW design - dunno - > ...which would equally support Al's assertion. > (I only did the RF for them) I only speak for myself on this. I know there are certainly designs that may be prone to brownout. particularly as you state later in battery based designs where the holders are a bit suspect;. equally, to me, this is part of the design mantra. I use batteries, but I use LI-polys soldered to the PCB in 99% of cases. No contact bounce. Again, to overcome anohter problem I used to expereicne with RFM wireless stuff using coin cells I decided NOT to just use batteries, smaller batteries can droop enormously, very fast as peripherals are running, causing a brownout event. Now its switchers and adequate C to ensure that any switching loads are smoothly handled. The cost is well worth it to me. > > My personal experience is that - ironically - brown out protection is very important > on battery powered products, where eg. AA alkalines and the likes are replaced. > The bounce in the battery holder seems to be unfriendly to an MCU w/o BOD. > > Finally, I think it's important to establish what "brown out" means for each of us. > For me brown out includes Vcc "sagging" fast, but then eg. rise slower, but equally > includes transients that go right through the regulator (the feedback in LDO isn't fast > enough), and even ceramic (thru hole) bypass caps couldn't kill it enough. > Transils seem the sure fire way. > Nowdays LDOs are much better by taking care wrt ESR on eg. SMT tantalum caps. > (ie. ensuring an optimal ESR) > > Example : Around 1992 or so when the XC705P9 was introduced, I had nightmare > problems with its MCU clock getting a "cardiac arrest". The WD was clocked from the Xtal, > so nodes would occasionally fail. This was used in large Emergency lighting monitoring networks, > (up to 6-8 K nodes in one building) - and big FL battens where a chunky relay switched the FL > from mains-ballast to inverter (with local battery) on power loss, the relay contacts arced like the > 4th of July. (I found that the manufacturer's inverter would rise to a 600-800 V, before having > the FL (relay) connected, thus the gas hadn't fired yet - after all it will fire at 90 Volts or so IIRC) > Certain fall/rise Vcc sequences would kill the MCU clock... > This was catastrophic, as they'd sometimes happily freeze on the RS485 while in TX @#$%!!! > (killing a subnet) > Anyhow, eventually I convinced them to use Motorola zero crossing detect optos with a TRIAC. Most of the old HC05/HC11 HCMOS stuff was incredibly prone to latch up caused by small negative ground transients. I first discovered this in a commercial security system based on a P9 that I was functionally duplicating (the taiwanese company hired to produce the system refused to delliver the code or other design data to the company, even though they'd paid for them, and were selling to the clients competitors) I met it again on an E9 based ECU.this was when I first started using the SP720. Anything >Vcc+0.6 on Vcc or < gnd-.6 on ground would or could latch the micro. The SP720 limits these spikes to < 0.3V > > Shortly after I redesigned it on PIC16C71, and the network nodes NEVER failed again. > Back then I loved PICs, and their superior QA, finally someone put the WD on an RC clock !!! > We'd run 3000 in one go, and NONE would fail in programming (OTP), and average > _one_ would fail (out of 3 K) after wave soldering.... PICs got a LOT of things right, I was a big fan for many years, but after a while got too fed up waiting for the promised Flash/!* series etc. They were announced too soon, and delayed too often, it totally turned me off Microchip for some time. Al > > Basically, I think Al and Bill both equally make a good point. > > -- Kris > > > >>Sorry Al, I definitely should have inserted a <grin> or two in my >>message. Though your dogged support for assembly language is legendary, >>your experience with both the MSP and with low power, embedded systems >>design is equally impressive. And unlike many (myself included), you >>always seem ready to help those who are able to post a reasonable question. >> >>I had to ponder your response. It is not really something I had consider >>recently. And yes, I must admit there are probably many designs in which >>recovering from a brownout may not be required. However, there are systems >>in which it is necessary. In one instance, the design was for an inductively >>coupled and powered interface device that allowed non-contact reading of >>water meters. The reader would output a 32-40KHz "tone" into/onto 1/2 >>of a pot-core transformer. The device had the other half of the transformer >>as its input and power supply. The reader would on/off modulate the tone >>to send data to the device. The device would send back data by modulating >>the transformer when the reader was silent. All the while the device was >>rectifying the output of the transformer and using it for its power source. >>The problem came when the reader/device transformer coupling (it was positioned >>by the person doing the meter reading) was either insufficient or dropped out >>while the device was in operation. The reading could be retaken but recovering >>from the brownout was necessary. >> >>-Bill >> >>On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote: >> >> >> >>>Am I really that bad? >> >>>Why might I expect brownout to occur in the first place? If I have no >>>sound reason to expect it then I have no need to compensate for it. I do >>>monitor my supplies constantly, and do a lot of power management, but in >>>all of the testing I've done I've never experienced brown out once. >> >>>Al >> >>>Bill Knight wrote: >> >>>>Al >>>> OK, I know I'm opening myself up for a "learning" experience, but >>>>here goes anyway: What do you use for brownout detection and recovery? >>>> >>>>-Bill Knight >>>>R O SoftWare >>>> >>>> >>>>On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote: >>>> >>>> >>>> >>>> >>>>>I don't use one, and have never had the need. Cheapest option around. >>>> >>>> >>>>>;?} >>>> >>>> >>>>>Al >> >><<<< snip >>>> >> >> >> >> >>. >> >> >> >> >> >> >> >> >> >> >>-------- >>. >> >> > > > > > > > > . > > > Yahoo! Groups Links > > > > > > > >
Reply by ●October 24, 20042004-10-24
Hi Matthias,
it seems, as if there was no answer about distributor at all.
I found digikey (www.digikey.com) a good source for TI stuff. They are now
located in the Netherlands, with a 0800... phone number from Germany. And
getting stuff on account in is possible as well as sending cash on delivery,
no need for expensive valuta exchange fees as with credit cards...
Harald Wehner
"Matthias Weingart" <msp430@msp4...> schrieb:
>
> For my application I was looking for a very low current reset chips -
> supervisor and watchdog with no external components and in a small case
(SO8
> is too big). After searching at ti.com I only found the TPS3813 - with 10uA
> current consumption. Too much.
>
> But then I stumbled through my archive of this list and there
> was a suggestion: TI TPS3110K33 (2uA) - quite good.
>
> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
> quantities of 2 or 2500. Does some of you know a distributor that would
sell
> me e.g. 100pcs?
>
> Are there other low current supervisor/watchdogs available? My TOP TWO are
> still the MAX6864 and the TPS3110 - I did'nt find better ones.
>
> Matthias
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Reply by ●October 26, 20042004-10-26
Brownout is important when the power source can be momentarily disconnected or could have bouncing contacts such as changing batteries like Kris mentioned below. One glitch is enough to lockout a microprocessor. But, if the power supply is designed to eliminate any of these "brownout" or "glitches" to the rest of the circuit then there is no need to check for it. Yvon. --- In msp430@msp4..., "microbit" <microbit@c...> wrote: > Hi Bill and Al, > > I've done several apps where brownout protection was paramount, and > by the same token I've known an Oz based company that was exporting > critical industrial systems, such as Mains Water pollution (backflow) monitoring, > where they were shipping F149 based designs without even as much as the use of the > watchdog, and their USA client was very happy, no problems. > I personally found it bizarre, but maybe they were using really sound HW design - dunno - > ...which would equally support Al's assertion. > (I only did the RF for them) > > My personal experience is that - ironically - brown out protection is very important > on battery powered products, where eg. AA alkalines and the likes are replaced. > The bounce in the battery holder seems to be unfriendly to an MCU w/o BOD. > > Finally, I think it's important to establish what "brown out" means for each of us. > For me brown out includes Vcc "sagging" fast, but then eg. rise slower, but equally > includes transients that go right through the regulator (the feedback in LDO isn't fast > enough), and even ceramic (thru hole) bypass caps couldn't kill it enough. > Transils seem the sure fire way. > Nowdays LDOs are much better by taking care wrt ESR on eg. SMT tantalum caps. > (ie. ensuring an optimal ESR) > > Example : Around 1992 or so when the XC705P9 was introduced, I had nightmare > problems with its MCU clock getting a "cardiac arrest". The WD was clocked from the Xtal, > so nodes would occasionally fail. This was used in large Emergency lighting monitoring networks, > (up to 6-8 K nodes in one building) - and big FL battens where a chunky relay switched the FL > from mains-ballast to inverter (with local battery) on power loss, the relay contacts arced like the > 4th of July. (I found that the manufacturer's inverter would rise to a 600-800 V, before having > the FL (relay) connected, thus the gas hadn't fired yet - after all it will fire at 90 Volts or so IIRC) > Certain fall/rise Vcc sequences would kill the MCU clock... > This was catastrophic, as they'd sometimes happily freeze on the RS485 while in TX @#$%!!! > (killing a subnet) > Anyhow, eventually I convinced them to use Motorola zero crossing detect optos with a TRIAC. > > Shortly after I redesigned it on PIC16C71, and the network nodes NEVER failed again. > Back then I loved PICs, and their superior QA, finally someone put the WD on an RC clock !!! > We'd run 3000 in one go, and NONE would fail in programming (OTP), and average > _one_ would fail (out of 3 K) after wave soldering.... > > Basically, I think Al and Bill both equally make a good point. > > -- Kris > > > > Sorry Al, I definitely should have inserted a <grin> or two in my > > message. Though your dogged support for assembly language is legendary, > > your experience with both the MSP and with low power, embedded systems > > design is equally impressive. And unlike many (myself included), you > > always seem ready to help those who are able to post a reasonable question. > > > > I had to ponder your response. It is not really something I had consider > > recently. And yes, I must admit there are probably many designs in which > > recovering from a brownout may not be required. However, there are systems > > in which it is necessary. In one instance, the design was for an inductively > > coupled and powered interface device that allowed non-contact reading of > > water meters. The reader would output a 32-40KHz "tone" into/onto 1/2 > > of a pot-core transformer. The device had the other half of the transformer > > as its input and power supply. The reader would on/off modulate the tone > > to send data to the device. The device would send back data by modulating > > the transformer when the reader was silent. All the while the device was > > rectifying the output of the transformer and using it for its power source. > > The problem came when the reader/device transformer coupling (it was positioned > > by the person doing the meter reading) was either insufficient or dropped out > > while the device was in operation. The reading could be retaken but recovering > > from the brownout was necessary. > > > > -Bill > > > > On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote: > > > > > > >Am I really that bad? > > > > >Why might I expect brownout to occur in the first place? If I have no > > >sound reason to expect it then I have no need to compensate for it. I do > > >monitor my supplies constantly, and do a lot of power management, but in > > >all of the testing I've done I've never experienced brown out once. > > > > >Al > > > > >Bill Knight wrote: > > > > >> Al > > >> OK, I know I'm opening myself up for a "learning" experience, but > > >> here goes anyway: What do you use for brownout detection and recovery? > > >> > > >> -Bill Knight > > >> R O SoftWare > > >> > > >> > > >> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote: > > >> > > >> > > >> > > >>>I don't use one, and have never had the need. Cheapest option around. > > >> > > >> > > >>>;?} > > >> > > >> > > >>>Al > > > > <<<< snip >>>> > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > ------------------------------ -------------- > > Yahoo! Groups Links > > > > a.. To visit your group on the web, go to: > > http://groups.yahoo.com/group/msp430/ > > > > b.. . > > > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > > >
