Design, design, design ;@}
Funnily enough I've just been tinkering with a design idea that
intentionally induces brown out, which can be viewed by the micro, while
the power supplied to it is quite safe. The budget is so tight that I
have been forced to look at some unusual solutions, this being one
possible option. Going to a bigger micro isn't on. My absolute cheapest
hardware design is 10 cents over the original budget already, and that
may be enough to kill the deal so I might end up with a brown out
detector in a machine which relies on brown outs to operate correctly.
Al
yvon_hache wrote:
>
> 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.
>
>>>
>>
>
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
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.
> >
> >
>
>
Reply by hara...@...●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 onestone●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 onestone●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 microbit●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 Bill Knight●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 onestone●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 Bill Knight●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 onestone●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
>
>
>
>
>
>
>
>