Re: [beagleboard] Hardware watchdog for BBB

2018-01-23 Thread 'AVR' via BeagleBoard
Dear Harvey

Is it really means that absence of operating system on BBB eliminates 
shutdown problems from unpredictable power loss?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/089d1ade-982b-4b41-b64e-8b10351006b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
Yes.. it's been around some time,  I have used it on my UPS for desktop
computers.
worked well in that application.



On Thu, May 19, 2016 at 7:59 PM, Super Twang  wrote:

> I’m currently looking for low-hanging fruit solutions to improve the BBB’s
> reliability at the moment and came across this.
>
> This open source project aims to provide a generic API to many
> off-the-shelf UPS systems, usually via a serial/usb/ether connection.  I
> haven’t investigated this in depth yet, but it would appear that it gives
> you the software hooks to at least shut the bbb down when the mains go off,
> potentially monitoring battery levels down to a certain point first.
> There’s still be some external logic needed to do a full solution (as
> described in the rest of this thread), but it could be an interesting
> component of a system.
>
> http://networkupstools.org
>
> They seem to support loads of OTS devices.
>
> The debian metapackage name is ‘nut’ (for network ups tools), fwiw.
>
> ST
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/B7E33771-0A0A-4BB1-925A-B3DA06A21EEF%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MsqqpNHkWTX9JjBRBhARVMKd-HAP3Y8cts0UC866wdQ4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Super Twang
I’m currently looking for low-hanging fruit solutions to improve the BBB’s 
reliability at the moment and came across this.

This open source project aims to provide a generic API to many off-the-shelf 
UPS systems, usually via a serial/usb/ether connection.  I haven’t investigated 
this in depth yet, but it would appear that it gives you the software hooks to 
at least shut the bbb down when the mains go off, potentially monitoring 
battery levels down to a certain point first.  There’s still be some external 
logic needed to do a full solution (as described in the rest of this thread), 
but it could be an interesting component of a system.

http://networkupstools.org

They seem to support loads of OTS devices.

The debian metapackage name is ‘nut’ (for network ups tools), fwiw.

ST


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B7E33771-0A0A-4BB1-925A-B3DA06A21EEF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
>
>
>
>
>
>
>
>
> *All design is a trade of, if you can control your environment that is the
> best of all possible words,no lighting strike's, no one using there cell
> phone's 2 cm away from you board,  clean air,no toxic chemical attacking
> your connector's to deal with.And of course if you can afford the very best
> Mil speck parts, that's even better.But most designers are not in that
> boat, and need to do the max with the lowest cost.that where the hard work
> is.*
> *Lachlan*
>

Exactly. Plus many people would view having to replace a part every couple
years as a potential source of income - From service calls. I can say
though that for our own application. Where out boards would be deployed.
Power outages may not be impossible, but usually are dealt with
immediately. Also, backup generators are typically in place too. So a
single LiPO battery is just a low cost added bit of insurance.

On Thu, May 19, 2016 at 12:40 PM, Lachlan Audas  wrote:

> All design is a trade of, if you can control your environment that is the
> best of all possible words,
> no lighting strike's, no one using there cell phone's 2 cm away from you
> board,  clean air,
> no toxic chemical attacking your connector's to deal with.
> And of course if you can afford the very best Mil speck parts, that's even
> better.
> But most designers are not in that boat, and need to do the max with the
> lowest cost.
> that where the hard work is.
>
> Lachlan
>
>
>
>
> On Thu, May 19, 2016 at 12:25 PM, John Syne  wrote:
>
>> https://en.wikipedia.org/wiki/Supercapacitor
>>
>> If you operate the supercap at lower than max voltage and keep the
>> temperature at close to 25C, the supercap will last as much as 20 years. No
>> battery comes even close. You also need to look at lifecycle cost, not just
>> cost of components. If you have to switch out the battery every few years,
>> then the lifecycle cost for a battery will be much higher than supercaps.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
>>
>> Have a look at
>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>> Depending on current/temperature  they have much better life,  up to
>> 10,000 cycles
>> and much better fire safety than LiPo,  you may even be able to ship then
>> on flights.
>>
>> Supper caps,  don't have a good life time,  in fact they much worse then 
>> Aluminum
>> Capacitors
>> 
>> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
>> more life at 25C
>> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
>> $2  in 5k
>> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000
>> Hrs @ 70°C and cost $6.000 in 5k
>> (Digikey prices)
>> So to get the Max life,  use the step up switching reg to say 40V
>> (remember that energy on capt is = 1/2CV^2 )
>> so double the voltage is 4 times the energy)  then user a switch to step
>> down to you required voltage/current
>> So for max and life,  only switch to the backup Caps when power fail's,
>> that way they remain cool,
>> give max life,  and will give you  good hold times.  And of course all
>> under mic-controller control.
>> per my example circuit.. (example dose not have the control circuit, but
>> can be easily added )
>>
>> Lachlan
>>
>>
>>
>>
>> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:
>>
>>>
>>> > You can sum it all up into this; The problem is completely solved by
>>> using a battery and having acpid installed. Except you need a way to
>>> completely disconnect power, from the BBB's input, for a single, or perhaps
>>> two corner cases that would otherwise require a hard reset.
>>>
>>> I love the no-nonsense mentality, and quality design behind this
>>> approach for most use cases.  But, for some high-reliability use cases like
>>> mine -- a device permanently installed in a remote, client wall — batteries
>>> aren’t a great fit.
>>>
>>> For long-term accessibility:Battery maintenance, even after
>>> years of initial functionality, is extremely inconvenient or impossible.
>>> For insurance reasons:  The potential liability of
>>> installing LiPo, which is known to have potential fire issues, into a
>>> client’s wall.
>>> For shipping reasons:   The added hassle of
>>> international shipping of LiPo-based systems.
>>>
>>> > All these fancy high cost solutions are honestly ridiculous, and if
>>> you can just use an OTS UPS . . .
>>>
>>>  Hardware cost is relative.  The “high” cost (<$100) of a system
>>> design is nothing, if it will potentially save me things like panicked
>>> client calls, last-minute international plane tickets and high-pressure
>>> field repairs.  Those just aren’t fun.  Obviously every project out there
>>> isn’t heading to a NASA rover, but in some lines of work this kind of
>>> service is expected when a high-end, mission-critical system goes dow

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
All design is a trade of, if you can control your environment that is the
best of all possible words,
no lighting strike's, no one using there cell phone's 2 cm away from you
board,  clean air,
no toxic chemical attacking your connector's to deal with.
And of course if you can afford the very best Mil speck parts, that's even
better.
But most designers are not in that boat, and need to do the max with the
lowest cost.
that where the hard work is.

Lachlan




On Thu, May 19, 2016 at 12:25 PM, John Syne  wrote:

> https://en.wikipedia.org/wiki/Supercapacitor
>
> If you operate the supercap at lower than max voltage and keep the
> temperature at close to 25C, the supercap will last as much as 20 years. No
> battery comes even close. You also need to look at lifecycle cost, not just
> cost of components. If you have to switch out the battery every few years,
> then the lifecycle cost for a battery will be much higher than supercaps.
>
> Regards,
> John
>
>
>
>
> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
>
> Have a look at
> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
> Depending on current/temperature  they have much better life,  up to
> 10,000 cycles
> and much better fire safety than LiPo,  you may even be able to ship then
> on flights.
>
> Supper caps,  don't have a good life time,  in fact they much worse then 
> Aluminum
> Capacitors
> 
> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
> more life at 25C
> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
> $2  in 5k
> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs
> @ 70°C and cost $6.000 in 5k
> (Digikey prices)
> So to get the Max life,  use the step up switching reg to say 40V
> (remember that energy on capt is = 1/2CV^2 )
> so double the voltage is 4 times the energy)  then user a switch to step
> down to you required voltage/current
> So for max and life,  only switch to the backup Caps when power fail's,
> that way they remain cool,
> give max life,  and will give you  good hold times.  And of course all
> under mic-controller control.
> per my example circuit.. (example dose not have the control circuit, but
> can be easily added )
>
> Lachlan
>
>
>
>
> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:
>
>>
>> > You can sum it all up into this; The problem is completely solved by
>> using a battery and having acpid installed. Except you need a way to
>> completely disconnect power, from the BBB's input, for a single, or perhaps
>> two corner cases that would otherwise require a hard reset.
>>
>> I love the no-nonsense mentality, and quality design behind this approach
>> for most use cases.  But, for some high-reliability use cases like mine --
>> a device permanently installed in a remote, client wall — batteries aren’t
>> a great fit.
>>
>> For long-term accessibility:Battery maintenance, even after
>> years of initial functionality, is extremely inconvenient or impossible.
>> For insurance reasons:  The potential liability of
>> installing LiPo, which is known to have potential fire issues, into a
>> client’s wall.
>> For shipping reasons:   The added hassle of international
>> shipping of LiPo-based systems.
>>
>> > All these fancy high cost solutions are honestly ridiculous, and if you
>> can just use an OTS UPS . . .
>>
>>  Hardware cost is relative.  The “high” cost (<$100) of a system
>> design is nothing, if it will potentially save me things like panicked
>> client calls, last-minute international plane tickets and high-pressure
>> field repairs.  Those just aren’t fun.  Obviously every project out there
>> isn’t heading to a NASA rover, but in some lines of work this kind of
>> service is expected when a high-end, mission-critical system goes down.  In
>> the end, if I do my job right, the price is just passed on to the client
>> who is willing to pay a premium for a high reliability, maintenance-free
>> product.
>>
>> I’d like to be able to deploy those systems based on the BBB, because I
>> know it, find the platform highly versatile, and a good match for the
>> variety of projects I take on.  I think the PRUs especially make this a
>> very unique little SoC.
>>
>> Best,
>> ST
>>
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message becaus

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread John Syne
https://en.wikipedia.org/wiki/Supercapacitor 


If you operate the supercap at lower than max voltage and keep the temperature 
at close to 25C, the supercap will last as much as 20 years. No battery comes 
even close. You also need to look at lifecycle cost, not just cost of 
components. If you have to switch out the battery every few years, then the 
lifecycle cost for a battery will be much higher than supercaps. 

Regards,
John




> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
> 
> Have a look at https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery 
> 
> Depending on current/temperature  they have much better life,  up to 10,000 
> cycles 
> and much better fire safety than LiPo,  you may even be able to ship then on 
> flights.
> 
> Supper caps,  don't have a good life time,  in fact they much worse then 
> Aluminum Capacitors 
> 
> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much more 
> life at 25C
> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost $2  
> in 5k
> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs @ 
> 70°C and cost $6.000 in 5k 
> (Digikey prices)
> So to get the Max life,  use the step up switching reg to say 40V  (remember 
> that energy on capt is = 1/2CV^2 )
> so double the voltage is 4 times the energy)  then user a switch to step down 
> to you required voltage/current
> So for max and life,  only switch to the backup Caps when power fail's, that 
> way they remain cool,
> give max life,  and will give you  good hold times.  And of course all under 
> mic-controller control.
> per my example circuit.. (example dose not have the control circuit, but can 
> be easily added )
> 
> Lachlan
> 
> 
> 
> 
> 
> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  > wrote:
> 
> > You can sum it all up into this; The problem is completely solved by using 
> > a battery and having acpid installed. Except you need a way to completely 
> > disconnect power, from the BBB's input, for a single, or perhaps two corner 
> > cases that would otherwise require a hard reset.
> 
> I love the no-nonsense mentality, and quality design behind this approach for 
> most use cases.  But, for some high-reliability use cases like mine -- a 
> device permanently installed in a remote, client wall — batteries aren’t a 
> great fit.
> 
> For long-term accessibility:Battery maintenance, even after years 
> of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of installing 
> LiPo, which is known to have potential fire issues, into a client’s wall.
> For shipping reasons:   The added hassle of international 
> shipping of LiPo-based systems.
> 
> > All these fancy high cost solutions are honestly ridiculous, and if you can 
> > just use an OTS UPS . . .
> 
>  Hardware cost is relative.  The “high” cost (<$100) of a system 
> design is nothing, if it will potentially save me things like panicked client 
> calls, last-minute international plane tickets and high-pressure field 
> repairs.  Those just aren’t fun.  Obviously every project out there isn’t 
> heading to a NASA rover, but in some lines of work this kind of service is 
> expected when a high-end, mission-critical system goes down.  In the end, if 
> I do my job right, the price is just passed on to the client who is willing 
> to pay a premium for a high reliability, maintenance-free product.
> 
> I’d like to be able to deploy those systems based on the BBB, because I know 
> it, find the platform highly versatile, and a good match for the variety of 
> projects I take on.  I think the PRUs especially make this a very unique 
> little SoC.
> 
> Best,
> ST
> 
> 
> 
> --
> For more options, visit http://beagleboard.org/discuss 
> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving e

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
Oh, right, heh, so the main point I had for the above was that if you never
discharge a battery below 90%, then cycles are very likely not counted.
Which is another problem in of its self. Batteries do need to be
"exercised".

Another thing I was considering just now is that these Lithium iron
phosphate batteries are indead pretty cool. However, they would require
external circuitry to use with this board. Which is not necessarily a bad
thing, but if you're looking to keep costs at a minimum. Then they are not
the most ideal solution.

On Thu, May 19, 2016 at 12:17 PM, William Hermans  wrote:

> Certainly there wil be use cases for all. But one thing you need to be
> aware of with recharge cycles on batteries. Is that a recharge cycle is
> only counted when the battery voltage falls below a certain percentage. I
> believe this percentage is difference for every chemistry type. But I can
> say that for lead acid batteries, the recharge cycle is two fold.
>
> First of the battery discharge goes below 75% this is a normal recharge
> cycle.
> Second, if the battery goes below 60% discharge is is akin to taking away
> 100 normal discharge depth cycles.
>
> But again, other chemistries I know are going to be different as some stay
> fairly steady in voltage throughout their whole discharge cycle.
>
> On Thu, May 19, 2016 at 11:06 AM, zamek42  wrote:
>
>> Hi All,
>>
>> On 05/19/2016 05:33 PM, Super Twang wrote:
>>
>>> @Lachlan
>>> Thanks for the info Lachlan.
>>>
>>> Re: Supercap reliability…
>>> My basic understanding is that if you design with supercaps for a
>>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>>> pretty obtainable operating conditions they effectively last forever.
>>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>>> “effectively”) in the prior assertion, but...
>>>
>>> My particular use case — indoor temps but in a wall, 5v power — might
>>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>>> talking about would have to be a pretty harsh/industrial environment, no?
>>>
>>> Does anyone (who has done it, or knows how) have a sense of how
>>> straightforward it is to achieve a supercap-based system design that keeps
>>> the components in a range that’d keep them healthy for “Effectively
>>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>>> Or, do the requirements we’re looking at for a basic, indoor, power system
>>> really push the supercaps into the “Quickly-used-up” zone?
>>>
>> Yes we have some experience about supercaps.
>>
>> We have an organ controller which is working two years ago, approximately
>> 3-4 on/off  per day. Yes it is an indoor application.
>> Our second application is an industrial environment with Pandaboard which
>> is working since last september approximately 1 on/off per day. It is a
>> semi indoor environment.
>> Our third application is a timelapse camera system with Raspberry (
>> http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early
>> of march. It is an outdoor application which is working 7/24.
>>
>> In other point of view, if you checked the parameters of supercap for
>> example
>> http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922
>> you can see:
>>
>> operating temperature: -40-+60C
>> Life cycles: 50
>>
>> A simple NiCd accumulator is much more weight, and its lifecycle is much
>> more less, the operating temperature is 0-45C and lifecycle is less than
>> 1.
>>
>> So supercap seems to be  ideal for power supply to an embedded system,
>> but it needs a little bit complicated controller electronic.
>> best regards,
>>
>>
>> --
>> Zoltan (Zamek) Zidarics
>> programmer
>> email:zame...@gmail.com
>> Self Playing Pipe Organ Systems
>> http://replayorgan.eu
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> --- You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpxj0U7XkJVPDeZeBVhsBzQX%2BPVAnkKwgfoUoFTLMfnCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
Certainly there wil be use cases for all. But one thing you need to be
aware of with recharge cycles on batteries. Is that a recharge cycle is
only counted when the battery voltage falls below a certain percentage. I
believe this percentage is difference for every chemistry type. But I can
say that for lead acid batteries, the recharge cycle is two fold.

First of the battery discharge goes below 75% this is a normal recharge
cycle.
Second, if the battery goes below 60% discharge is is akin to taking away
100 normal discharge depth cycles.

But again, other chemistries I know are going to be different as some stay
fairly steady in voltage throughout their whole discharge cycle.

On Thu, May 19, 2016 at 11:06 AM, zamek42  wrote:

> Hi All,
>
> On 05/19/2016 05:33 PM, Super Twang wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might see
>> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
>> about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
> Yes we have some experience about supercaps.
>
> We have an organ controller which is working two years ago, approximately
> 3-4 on/off  per day. Yes it is an indoor application.
> Our second application is an industrial environment with Pandaboard which
> is working since last september approximately 1 on/off per day. It is a
> semi indoor environment.
> Our third application is a timelapse camera system with Raspberry (
> http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early of
> march. It is an outdoor application which is working 7/24.
>
> In other point of view, if you checked the parameters of supercap for
> example
> http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922
> you can see:
>
> operating temperature: -40-+60C
> Life cycles: 50
>
> A simple NiCd accumulator is much more weight, and its lifecycle is much
> more less, the operating temperature is 0-45C and lifecycle is less than
> 1.
>
> So supercap seems to be  ideal for power supply to an embedded system, but
> it needs a little bit complicated controller electronic.
> best regards,
>
>
> --
> Zoltan (Zamek) Zidarics
> programmer
> email:zame...@gmail.com
> Self Playing Pipe Organ Systems
> http://replayorgan.eu
>
> --
> For more options, visit http://beagleboard.org/discuss
> --- You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqq6BJwaSB8AGeZbbx%3D5ehiowL_nhLSQPVQ7XBQDasGKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread zamek42

Hi All,

On 05/19/2016 05:33 PM, Super Twang wrote:

@Lachlan
Thanks for the info Lachlan.

Re: Supercap reliability…
My basic understanding is that if you design with supercaps for a “Everyday” 
(ie not too hardcore) indoor use case, and keep them within some pretty 
obtainable operating conditions they effectively last forever.  Obviously 
there’s some ambiguity (“everyday” “pretty obtainable”, “effectively”) in the 
prior assertion, but...

My particular use case — indoor temps but in a wall, 5v power — might see a 
temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking about 
would have to be a pretty harsh/industrial environment, no?

Does anyone (who has done it, or knows how) have a sense of how straightforward 
it is to achieve a supercap-based system design that keeps the components in a 
range that’d keep them healthy for “Effectively forever?”  ie 20k+ cycles? 
(better than bats) 100k+? (effectively forever) Or, do the requirements we’re 
looking at for a basic, indoor, power system really push the supercaps into the 
“Quickly-used-up” zone?

Yes we have some experience about supercaps.

We have an organ controller which is working two years ago, 
approximately 3-4 on/off  per day. Yes it is an indoor application.
Our second application is an industrial environment with Pandaboard 
which is working since last september approximately 1 on/off per day. It 
is a semi indoor environment.
Our third application is a timelapse camera system with Raspberry ( 
http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early 
of march. It is an outdoor application which is working 7/24.


In other point of view, if you checked the parameters of supercap for 
example 
http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922

you can see:

operating temperature: -40-+60C
Life cycles: 50

A simple NiCd accumulator is much more weight, and its lifecycle is much 
more less, the operating temperature is 0-45C and lifecycle is less than 
1.


So supercap seems to be  ideal for power supply to an embedded system, 
but it needs a little bit complicated controller electronic.

best regards,


--
Zoltan (Zamek) Zidarics
programmer
email:zame...@gmail.com
Self Playing Pipe Organ Systems
http://replayorgan.eu

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
Read and you will be supersized how good they are!

Lachlan


On Thu, May 19, 2016 at 10:57 AM, William Hermans  wrote:

> Two of these
> http://www.all-battery.com/LiFePo414500Button-topCylindrical3.2V400mAhRechargeableBattery30225.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c30225&gclid=CPP-mNDa5swCFU1gfgodSBUB1w
>
> Would be good enough for around one hour up time maybe. But honestly I
> know nothing of lithium iron phosphate batteries. I'd be "worried" how many
> recharge cycles they last before turning to junk.
>
> On Thu, May 19, 2016 at 10:52 AM, William Hermans 
> wrote:
>
>> My point is, there are many different battery chemistry types. Then at
>> some point if you want to "play" you're going to have to "bargin with the
>> devil" one way or another.
>>
>> On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas 
>> wrote:
>>
>>> NiCad's are bad news..  They are extremely toxic, and nasty.
>>> I would not use them,   Have a look at
>>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>>> much better option.
>>>
>>> Lachlan
>>>
>>>
>>>
>>> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
>>> wrote:
>>>
 Oh and for those worried about the LiPO chemistry . . .
 http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg

 Problem is, you need three, maybe four of these. But cost would be
 ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
 shutdown right away. So perhaps the AA cell equivelent, and those would
 cost less. SubC is the cell type typically used in cordless drill packs . .
 .

 On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
 wrote:

> It may not be out door's.. the electronics/computer's may be inside
> near a heat source,
> I having seen electronics covered up by the end user's many times.
> (how many routers have you seen under
> a pile of books..  clothing ? ..etc ) then there is fan's breaking,
> air ventilation hole's fill with dust, cat hair etc.
> it's not just out door's  which may provide and nasty environment.
> The second problem is super cap's have high internal resistance, which
> limit's how much current you can pull
> from them.  Problem there is problem is how much of the capacity of
> the super cap are you using ?
> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
> liner reg may only give you 4.3 volts before
> the reg start's dropping the 3.3v power rail.   So there may be only
> 0.7V of the super capacity you are using.
> And to get around that, you need a SEPIC switching reg, and of course
> your drawing big currents once you start drooping to 1 or 2 volts of the
> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
> you will
> get almost all of it's capacity is not a bad trade off, when you see
> that you will have even bigger problem with supper caps and extracting
> there full capacity.   And you will be switch much higher currents to get
> your 3.3V's from it.
>
> Lachlan
>
>
> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
> wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within 
>> some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might
>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>> talking about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that 
>> keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively 
>> forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power 
>> system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
>> Best,
>> ST
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beag

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
Two of these
http://www.all-battery.com/LiFePo414500Button-topCylindrical3.2V400mAhRechargeableBattery30225.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c30225&gclid=CPP-mNDa5swCFU1gfgodSBUB1w

Would be good enough for around one hour up time maybe. But honestly I know
nothing of lithium iron phosphate batteries. I'd be "worried" how many
recharge cycles they last before turning to junk.

On Thu, May 19, 2016 at 10:52 AM, William Hermans  wrote:

> My point is, there are many different battery chemistry types. Then at
> some point if you want to "play" you're going to have to "bargin with the
> devil" one way or another.
>
> On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas  wrote:
>
>> NiCad's are bad news..  They are extremely toxic, and nasty.
>> I would not use them,   Have a look at
>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>> much better option.
>>
>> Lachlan
>>
>>
>>
>> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
>> wrote:
>>
>>> Oh and for those worried about the LiPO chemistry . . .
>>> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>>>
>>> Problem is, you need three, maybe four of these. But cost would be
>>> ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
>>> shutdown right away. So perhaps the AA cell equivelent, and those would
>>> cost less. SubC is the cell type typically used in cordless drill packs . .
>>> .
>>>
>>> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
>>> wrote:
>>>
 It may not be out door's.. the electronics/computer's may be inside
 near a heat source,
 I having seen electronics covered up by the end user's many times. (how
 many routers have you seen under
 a pile of books..  clothing ? ..etc ) then there is fan's breaking,
 air ventilation hole's fill with dust, cat hair etc.
 it's not just out door's  which may provide and nasty environment.
 The second problem is super cap's have high internal resistance, which
 limit's how much current you can pull
 from them.  Problem there is problem is how much of the capacity of the
 super cap are you using ?
 a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
 liner reg may only give you 4.3 volts before
 the reg start's dropping the 3.3v power rail.   So there may be only
 0.7V of the super capacity you are using.
 And to get around that, you need a SEPIC switching reg, and of course
 your drawing big currents once you start drooping to 1 or 2 volts of the
 super cap.  So the cost of having a Electro  running at 40 or 50V,  where
 you will
 get almost all of it's capacity is not a bad trade off, when you see
 that you will have even bigger problem with supper caps and extracting
 there full capacity.   And you will be switch much higher currents to get
 your 3.3V's from it.

 Lachlan


 On Thu, May 19, 2016 at 8:33 AM, Super Twang 
 wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within 
> some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might
> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
> talking about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because y

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
My point is, there are many different battery chemistry types. Then at some
point if you want to "play" you're going to have to "bargin with the devil"
one way or another.

On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas  wrote:

> NiCad's are bad news..  They are extremely toxic, and nasty.
> I would not use them,   Have a look at
> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
> much better option.
>
> Lachlan
>
>
>
> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
> wrote:
>
>> Oh and for those worried about the LiPO chemistry . . .
>> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>>
>> Problem is, you need three, maybe four of these. But cost would be
>> ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
>> shutdown right away. So perhaps the AA cell equivelent, and those would
>> cost less. SubC is the cell type typically used in cordless drill packs . .
>> .
>>
>> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
>> wrote:
>>
>>> It may not be out door's.. the electronics/computer's may be inside near
>>> a heat source,
>>> I having seen electronics covered up by the end user's many times. (how
>>> many routers have you seen under
>>> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
>>> ventilation hole's fill with dust, cat hair etc.
>>> it's not just out door's  which may provide and nasty environment.
>>> The second problem is super cap's have high internal resistance, which
>>> limit's how much current you can pull
>>> from them.  Problem there is problem is how much of the capacity of the
>>> super cap are you using ?
>>> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
>>> liner reg may only give you 4.3 volts before
>>> the reg start's dropping the 3.3v power rail.   So there may be only
>>> 0.7V of the super capacity you are using.
>>> And to get around that, you need a SEPIC switching reg, and of course
>>> your drawing big currents once you start drooping to 1 or 2 volts of the
>>> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
>>> you will
>>> get almost all of it's capacity is not a bad trade off, when you see
>>> that you will have even bigger problem with supper caps and extracting
>>> there full capacity.   And you will be switch much higher currents to get
>>> your 3.3V's from it.
>>>
>>> Lachlan
>>>
>>>
>>> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
>>> wrote:
>>>
 @Lachlan
 Thanks for the info Lachlan.

 Re: Supercap reliability…
 My basic understanding is that if you design with supercaps for a
 “Everyday” (ie not too hardcore) indoor use case, and keep them within some
 pretty obtainable operating conditions they effectively last forever.
 Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
 “effectively”) in the prior assertion, but...

 My particular use case — indoor temps but in a wall, 5v power — might
 see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
 talking about would have to be a pretty harsh/industrial environment, no?

 Does anyone (who has done it, or knows how) have a sense of how
 straightforward it is to achieve a supercap-based system design that keeps
 the components in a range that’d keep them healthy for “Effectively
 forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
 Or, do the requirements we’re looking at for a basic, indoor, power system
 really push the supercaps into the “Quickly-used-up” zone?

 Best,
 ST

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
NiCad's are bad news..  They are extremely toxic, and nasty.
I would not use them,   Have a look at
https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
much better option.

Lachlan



On Thu, May 19, 2016 at 10:38 AM, William Hermans  wrote:

> Oh and for those worried about the LiPO chemistry . . .
> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>
> Problem is, you need three, maybe four of these. But cost would be ~$6-$8.
> Additionally 2200mah is a bit much if all you're going ot do is shutdown
> right away. So perhaps the AA cell equivelent, and those would cost less.
> SubC is the cell type typically used in cordless drill packs . . .
>
> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas  wrote:
>
>> It may not be out door's.. the electronics/computer's may be inside near
>> a heat source,
>> I having seen electronics covered up by the end user's many times. (how
>> many routers have you seen under
>> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
>> ventilation hole's fill with dust, cat hair etc.
>> it's not just out door's  which may provide and nasty environment.
>> The second problem is super cap's have high internal resistance, which
>> limit's how much current you can pull
>> from them.  Problem there is problem is how much of the capacity of the
>> super cap are you using ?
>> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
>> reg may only give you 4.3 volts before
>> the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
>> of the super capacity you are using.
>> And to get around that, you need a SEPIC switching reg, and of course
>> your drawing big currents once you start drooping to 1 or 2 volts of the
>> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
>> you will
>> get almost all of it's capacity is not a bad trade off, when you see that
>> you will have even bigger problem with supper caps and extracting there
>> full capacity.   And you will be switch much higher currents to get your
>> 3.3V's from it.
>>
>> Lachlan
>>
>>
>> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
>> wrote:
>>
>>> @Lachlan
>>> Thanks for the info Lachlan.
>>>
>>> Re: Supercap reliability…
>>> My basic understanding is that if you design with supercaps for a
>>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>>> pretty obtainable operating conditions they effectively last forever.
>>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>>> “effectively”) in the prior assertion, but...
>>>
>>> My particular use case — indoor temps but in a wall, 5v power — might
>>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>>> talking about would have to be a pretty harsh/industrial environment, no?
>>>
>>> Does anyone (who has done it, or knows how) have a sense of how
>>> straightforward it is to achieve a supercap-based system design that keeps
>>> the components in a range that’d keep them healthy for “Effectively
>>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>>> Or, do the requirements we’re looking at for a basic, indoor, power system
>>> really push the supercaps into the “Quickly-used-up” zone?
>>>
>>> Best,
>>> ST
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https:/

Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
Oh and for those worried about the LiPO chemistry . . .
http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg

Problem is, you need three, maybe four of these. But cost would be ~$6-$8.
Additionally 2200mah is a bit much if all you're going ot do is shutdown
right away. So perhaps the AA cell equivelent, and those would cost less.
SubC is the cell type typically used in cordless drill packs . . .

On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas  wrote:

> It may not be out door's.. the electronics/computer's may be inside near a
> heat source,
> I having seen electronics covered up by the end user's many times. (how
> many routers have you seen under
> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
> ventilation hole's fill with dust, cat hair etc.
> it's not just out door's  which may provide and nasty environment.
> The second problem is super cap's have high internal resistance, which
> limit's how much current you can pull
> from them.  Problem there is problem is how much of the capacity of the
> super cap are you using ?
> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
> reg may only give you 4.3 volts before
> the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
> of the super capacity you are using.
> And to get around that, you need a SEPIC switching reg, and of course your
> drawing big currents once you start drooping to 1 or 2 volts of the super
> cap.  So the cost of having a Electro  running at 40 or 50V,  where you will
> get almost all of it's capacity is not a bad trade off, when you see that
> you will have even bigger problem with supper caps and extracting there
> full capacity.   And you will be switch much higher currents to get your
> 3.3V's from it.
>
> Lachlan
>
>
> On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might see
>> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
>> about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
>> Best,
>> ST
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqK7yJ6yEtajxN97w_%3DY3u-fMie4DT%2B3apOqrizpzBpKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread William Hermans
@Super Twang,

Sure super caps are usable, there are a few on these groups who do use them
in place of a battery. Last time I personally looked though, cost was very
prohibitive. For instance:

http://www.ebay.com/itm/like/262291173781?lpid=82&chn=ps&ul_noapp=true

$16.50 + $5.50 shipping each ? How many farads do we need to keep the board
up for 30-60 seconds ? But let's assume two of these in series( because
2.7v is not enough ).

versus something like this:

http://www.ebay.com/itm/Lipo-Battery-Replacement-battery-for-808-18-Car-Key-Camera-Mini-DVR-60-minutes-/251600381055?hash=item3a948d247f:g:vu4AAOSwRLZT1MJd

Anyway, I did not look too long, but lower capacity super caps did not sem
to drop in price much. 120 farad caps seemed to be pretty close in price
too.

So, for a one off solution maybe not too much of a big deal, but for many,
many systems. That cost is going to be far too high.

On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might see
> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
> about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrevWnDi-%2BAYvOt%3D00ws4QeuXyAQu5ejFE7ywqUY%3DYJ9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
It may not be out door's.. the electronics/computer's may be inside near a
heat source,
I having seen electronics covered up by the end user's many times. (how
many routers have you seen under
a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
ventilation hole's fill with dust, cat hair etc.
it's not just out door's  which may provide and nasty environment.
The second problem is super cap's have high internal resistance, which
limit's how much current you can pull
from them.  Problem there is problem is how much of the capacity of the
super cap are you using ?
a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
reg may only give you 4.3 volts before
the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
of the super capacity you are using.
And to get around that, you need a SEPIC switching reg, and of course your
drawing big currents once you start drooping to 1 or 2 volts of the super
cap.  So the cost of having a Electro  running at 40 or 50V,  where you will
get almost all of it's capacity is not a bad trade off, when you see that
you will have even bigger problem with supper caps and extracting there
full capacity.   And you will be switch much higher currents to get your
3.3V's from it.

Lachlan


On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might see
> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
> about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Super Twang
@Lachlan
Thanks for the info Lachlan.  

Re: Supercap reliability…
My basic understanding is that if you design with supercaps for a “Everyday” 
(ie not too hardcore) indoor use case, and keep them within some pretty 
obtainable operating conditions they effectively last forever.  Obviously 
there’s some ambiguity (“everyday” “pretty obtainable”, “effectively”) in the 
prior assertion, but...

My particular use case — indoor temps but in a wall, 5v power — might see a 
temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking about 
would have to be a pretty harsh/industrial environment, no?

Does anyone (who has done it, or knows how) have a sense of how straightforward 
it is to achieve a supercap-based system design that keeps the components in a 
range that’d keep them healthy for “Effectively forever?”  ie 20k+ cycles? 
(better than bats) 100k+? (effectively forever) Or, do the requirements we’re 
looking at for a basic, indoor, power system really push the supercaps into the 
“Quickly-used-up” zone?

Best,
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-19 Thread Lachlan Audas
Have a look at https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
Depending on current/temperature  they have much better life,  up to 10,000
cycles
and much better fire safety than LiPo,  you may even be able to ship then
on flights.

Supper caps,  don't have a good life time,  in fact they much worse
then Aluminum
Capacitors

example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
more life at 25C
and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
$2  in 5k
where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs
@ 70°C and cost $6.000 in 5k
(Digikey prices)
So to get the Max life,  use the step up switching reg to say 40V
(remember that energy on capt is = 1/2CV^2 )
so double the voltage is 4 times the energy)  then user a switch to step
down to you required voltage/current
So for max and life,  only switch to the backup Caps when power fail's,
that way they remain cool,
give max life,  and will give you  good hold times.  And of course all
under mic-controller control.
per my example circuit.. (example dose not have the control circuit, but
can be easily added )

Lachlan




On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:

>
> > You can sum it all up into this; The problem is completely solved by
> using a battery and having acpid installed. Except you need a way to
> completely disconnect power, from the BBB's input, for a single, or perhaps
> two corner cases that would otherwise require a hard reset.
>
> I love the no-nonsense mentality, and quality design behind this approach
> for most use cases.  But, for some high-reliability use cases like mine --
> a device permanently installed in a remote, client wall — batteries aren’t
> a great fit.
>
> For long-term accessibility:Battery maintenance, even after
> years of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of
> installing LiPo, which is known to have potential fire issues, into a
> client’s wall.
> For shipping reasons:   The added hassle of international
> shipping of LiPo-based systems.
>
> > All these fancy high cost solutions are honestly ridiculous, and if you
> can just use an OTS UPS . . .
>
>  Hardware cost is relative.  The “high” cost (<$100) of a system
> design is nothing, if it will potentially save me things like panicked
> client calls, last-minute international plane tickets and high-pressure
> field repairs.  Those just aren’t fun.  Obviously every project out there
> isn’t heading to a NASA rover, but in some lines of work this kind of
> service is expected when a high-end, mission-critical system goes down.  In
> the end, if I do my job right, the price is just passed on to the client
> who is willing to pay a premium for a high reliability, maintenance-free
> product.
>
> I’d like to be able to deploy those systems based on the BBB, because I
> know it, find the platform highly versatile, and a good match for the
> variety of projects I take on.  I think the PRUs especially make this a
> very unique little SoC.
>
> Best,
> ST
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MtdXLKP3VUTav_d_uGew4OAQfWT0iVSO9Zd6%2B5a0pYxUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-18 Thread William Hermans
>
> *He didn't finish his sentence.*
>

Still a useless comment. as well is this one, in the context of the desired
discussion.


On Wed, May 18, 2016 at 8:54 PM, Micka  wrote:

> He didn't finish his sentence.
>
> Le jeu. 19 mai 2016 05:47, William Hermans  a écrit :
>
>> *Be careful about taking hardware design info from computer science
>>> degree types.  John seems to understand hardware this other dude bill is a
>>> blow hard and a*
>>
>>
>> That comment, and a nickle is worth about 5 cents. . .
>>
>>
>>
>> On Wed, May 18, 2016 at 7:38 PM, 'Mark Lazarewicz' via BeagleBoard <
>> beagleboard@googlegroups.com> wrote:
>>
>>> Be careful about taking hardware design info from computer science
>>> degree types.  John seems to understand hardware this other dude bill is a
>>> blow hard and a
>>>
>>>
>>>
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Mon, May 16, 2016 at 3:34 PM, John Syne
>>>  wrote:
>>>
>>> On May 15, 2016, at 4:25 PM, evilwulfie  wrote:
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/746532426.5197607.1463625501671.JavaMail.yahoo%40mail.yahoo.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CALHSORqM8ewgB4SmnS%3DeD19i2ALwH%3D32LMMx7_VvnNdGXXwyew%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRt%3DpV4Y%3Dcg2-BrDPXoCpzUCbasDYYZ%3DTUN8T6%2BSm_vQWvQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqmPWY9sqA5VAOFx9HigVxaT-X-NMV%3Dfy9voHhZ7LP99Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-18 Thread Micka
He didn't finish his sentence.

Le jeu. 19 mai 2016 05:47, William Hermans  a écrit :

> *Be careful about taking hardware design info from computer science degree
>> types.  John seems to understand hardware this other dude bill is a blow
>> hard and a*
>
>
> That comment, and a nickle is worth about 5 cents. . .
>
>
>
> On Wed, May 18, 2016 at 7:38 PM, 'Mark Lazarewicz' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Be careful about taking hardware design info from computer science degree
>> types.  John seems to understand hardware this other dude bill is a blow
>> hard and a
>>
>>
>>
>>
>> Sent from Yahoo Mail on Android
>> 
>>
>> On Mon, May 16, 2016 at 3:34 PM, John Syne
>>  wrote:
>>
>> On May 15, 2016, at 4:25 PM, evilwulfie  wrote:
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/746532426.5197607.1463625501671.JavaMail.yahoo%40mail.yahoo.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORqM8ewgB4SmnS%3DeD19i2ALwH%3D32LMMx7_VvnNdGXXwyew%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRt%3DpV4Y%3Dcg2-BrDPXoCpzUCbasDYYZ%3DTUN8T6%2BSm_vQWvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-18 Thread William Hermans
>
> *Be careful about taking hardware design info from computer science degree
> types.  John seems to understand hardware this other dude bill is a blow
> hard and a*


That comment, and a nickle is worth about 5 cents. . .



On Wed, May 18, 2016 at 7:38 PM, 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Be careful about taking hardware design info from computer science degree
> types.  John seems to understand hardware this other dude bill is a blow
> hard and a
>
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, May 16, 2016 at 3:34 PM, John Syne
>  wrote:
>
> On May 15, 2016, at 4:25 PM, evilwulfie  wrote:
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/746532426.5197607.1463625501671.JavaMail.yahoo%40mail.yahoo.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqM8ewgB4SmnS%3DeD19i2ALwH%3D32LMMx7_VvnNdGXXwyew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-18 Thread 'Mark Lazarewicz' via BeagleBoard
Be careful about taking hardware design info from computer science degree 
types.  John seems to understand hardware this other dude bill is a blow hard 
and a



Sent from Yahoo Mail on Android 
 
  On Mon, May 16, 2016 at 3:34 PM, John Syne wrote:   

On May 15, 2016, at 4:25 PM, evilwulfie  wrote:
 
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/746532426.5197607.1463625501671.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-18 Thread Lachlan Audas
I think we need to look at the big picture,
many system's  have the same problem.Power monitor, with task
monitor... with reset and  power of/on
power back up..   be that battery or supper caps or standard caps etc.
While we are all thinking of meeting our current needs. Taking the bigger
picture will  allow much better long term fix
for the problems.   But that requires  some effort and time by good
designers, and programmer, with good doc's
to allow the average guy to make good use of it.  with out too much work or
hart burn.
but this needs a real commitment, from the developers,   not just few
mint's writing some good ideas
in some support group,  be that BBB,  or Raspberry PI  or pick your
platform.
It would also nice to have all this in Open hardware and software.  KiCad,
and GCC or SDCC,
Perhaps putting it all into a VM image, so any one can run it,  as long as
host system supports a VM player of some
sort.But who is willing to put the time and effort  to make this happen
?

Lachlan.





On Tue, May 17, 2016 at 6:25 PM, William Hermans  wrote:

> *The need to ping an Internet host just adds to the requirements.  Pinging
>> your local router IP would meet the requirement of whether the BBB
>> interface is up.  Adding Internet connectivity just added more complexity.*
>>
>
> Come now do I really have to comment on something like this ? The solution
> is pretty obvious . . .
>
> If your application does not require an internet connection, then don't
> ping an outside address. Ping your internal gateway . . .
>
> On Tue, May 17, 2016 at 5:07 PM, Mike  wrote:
>
>> On 05/17/2016 05:55 PM, William Hermans wrote:
>>
>> *William:*
>>> *That would work.  *
>>>
>>> *The only "edge case" I might see as a problem would be if your ping
>>> target went off line.  Then the BBB would reboot itself every ten minutes
>>> even though nothing was wrong with the BBB.  I guess you could ping several
>>> different targets in rotation and only reboot if they all disappeared.*
>>>
>> *This gets us back to a real cheap local watchdog.*
>>
>> You only need to ping one ip address. Your internet gateway IP. e.g. your
>> first hop outside of your local network.
>>
>> The need to ping an Internet host just adds to the requirements.  Pinging
>> your local router IP would meet the requirement of whether the BBB
>> interface is up.  Adding Internet connectivity just added more complexity.
>>
>>
>>> *As an aside: Does anyone know what test a computer runs to determine if
>>> it is connected to the internet?*
>>> *Most desktop/laptop computers have a different network icon as to
>>> whether the network/WiFi you connected to has internet connectivity.   Is
>>> the Windows computer pinging some Microsoft location that is "guaranteed"
>>> to be up?*
>>>
>>> *--- Graham*
>>
>> I'm not 100% sure, but the test Windows does is not always correct.
>> Sometimes the icon shows not connected, when in fact as soon as you try to
>> surf something on the web, it goes to the working icon . . .
>>
>> My guess is that it does some simple DNS tests, and then after a while it
>> gives up checking.
>>
>>
>> On Tue, May 17, 2016 at 2:29 PM, Graham Haddock 
>> wrote:
>>
>>> William:
>>>
>>> That would work.
>>>
>>> The only "edge case" I might see as a problem would be if your ping
>>> target went off line.  Then the BBB would reboot itself every ten minutes
>>> even though nothing was wrong with the BBB.  I guess you could ping several
>>> different targets in rotation and only reboot if they all disappeared.
>>> This gets us back to a real cheap local watchdog.
>>>
>>> As an aside: Does anyone know what test a computer runs to determine if
>>> it is connected to the internet?
>>> Most desktop/laptop computers have a different network icon as to
>>> whether the network/WiFi you connected to has internet connectivity.   Is
>>> the Windows computer pinging some Microsoft location that is "guaranteed"
>>> to be up?
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>>
>>> On Tue, May 17, 2016 at 2:30 PM, William Hermans 
>>> wrote:
>>>

 @Graham,

 What I propose is that you do not need an Ethernet Micro connected to
 the BBB. Instead, you have the BBB ping the outside world once every set
 time frame, and it a ping comes back unreachable after say 5-10 minutes.
 You just stop "kicking the dog". Which does present a potential problem
 that Your internet connection may just be down. But a remote system that
 reboots once every 5-10 minutes because the internet connection is down is
 not something I'd personally see as a bad thing. After all you're unable to
 connect to the system anyway.

>>>
>>>  ==
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this

Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread William Hermans
>
> *The need to ping an Internet host just adds to the requirements.  Pinging
> your local router IP would meet the requirement of whether the BBB
> interface is up.  Adding Internet connectivity just added more complexity.*
>

Come now do I really have to comment on something like this ? The solution
is pretty obvious . . .

If your application does not require an internet connection, then don't
ping an outside address. Ping your internal gateway . . .

On Tue, May 17, 2016 at 5:07 PM, Mike  wrote:

> On 05/17/2016 05:55 PM, William Hermans wrote:
>
> *William:*
>> *That would work.  *
>>
>> *The only "edge case" I might see as a problem would be if your ping
>> target went off line.  Then the BBB would reboot itself every ten minutes
>> even though nothing was wrong with the BBB.  I guess you could ping several
>> different targets in rotation and only reboot if they all disappeared.*
>>
> *This gets us back to a real cheap local watchdog.*
>
> You only need to ping one ip address. Your internet gateway IP. e.g. your
> first hop outside of your local network.
>
> The need to ping an Internet host just adds to the requirements.  Pinging
> your local router IP would meet the requirement of whether the BBB
> interface is up.  Adding Internet connectivity just added more complexity.
>
>
>> *As an aside: Does anyone know what test a computer runs to determine if
>> it is connected to the internet?*
>> *Most desktop/laptop computers have a different network icon as to
>> whether the network/WiFi you connected to has internet connectivity.   Is
>> the Windows computer pinging some Microsoft location that is "guaranteed"
>> to be up?*
>>
>> *--- Graham*
>
> I'm not 100% sure, but the test Windows does is not always correct.
> Sometimes the icon shows not connected, when in fact as soon as you try to
> surf something on the web, it goes to the working icon . . .
>
> My guess is that it does some simple DNS tests, and then after a while it
> gives up checking.
>
>
> On Tue, May 17, 2016 at 2:29 PM, Graham Haddock 
> wrote:
>
>> William:
>>
>> That would work.
>>
>> The only "edge case" I might see as a problem would be if your ping
>> target went off line.  Then the BBB would reboot itself every ten minutes
>> even though nothing was wrong with the BBB.  I guess you could ping several
>> different targets in rotation and only reboot if they all disappeared.
>> This gets us back to a real cheap local watchdog.
>>
>> As an aside: Does anyone know what test a computer runs to determine if
>> it is connected to the internet?
>> Most desktop/laptop computers have a different network icon as to whether
>> the network/WiFi you connected to has internet connectivity.   Is the
>> Windows computer pinging some Microsoft location that is "guaranteed" to be
>> up?
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Tue, May 17, 2016 at 2:30 PM, William Hermans 
>> wrote:
>>
>>>
>>> @Graham,
>>>
>>> What I propose is that you do not need an Ethernet Micro connected to
>>> the BBB. Instead, you have the BBB ping the outside world once every set
>>> time frame, and it a ping comes back unreachable after say 5-10 minutes.
>>> You just stop "kicking the dog". Which does present a potential problem
>>> that Your internet connection may just be down. But a remote system that
>>> reboots once every 5-10 minutes because the internet connection is down is
>>> not something I'd personally see as a bad thing. After all you're unable to
>>> connect to the system anyway.
>>>
>>
>>  ==
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 
>> https://groups.google.com/d/msgid/beagleboard/CANN_KV6MEtkBkkjA-xc3KKzeNRh6LDpoB1xrBnN%2BZo6gJgLX6w%40mail.gmail.com.
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/CALHSORrk-KSfKb%3D%2By9tCHPNQSkvfC-K7YPr8cQsvmuwDXR6DCg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you a

Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Mike

On 05/17/2016 05:55 PM, William Hermans wrote:


/William:/
/That would work. /
/
/
/The only "edge case" I might see as a problem would be if your
ping target went off line.  Then the BBB would reboot itself every
ten minutes even though nothing was wrong with the BBB.  I guess
you could ping several different targets in rotation and only
reboot if they all disappeared./

/This gets us back to a real cheap local watchdog./

You only need to ping one ip address. Your internet gateway IP. e.g. 
your first hop outside of your local network.
The need to ping an Internet host just adds to the requirements. Pinging 
your local router IP would meet the requirement of whether the BBB 
interface is up.  Adding Internet connectivity just added more complexity.


/
/
/As an aside: Does anyone know what test a computer runs to
determine if it is connected to the internet?/
/Most desktop/laptop computers have a different network icon as to
whether the network/WiFi you connected to has internet
connectivity.   Is the Windows computer pinging some Microsoft
location that is "guaranteed" to be up?/
/
/

/--- Graham/

I'm not 100% sure, but the test Windows does is not always correct. 
Sometimes the icon shows not connected, when in fact as soon as you 
try to surf something on the web, it goes to the working icon . . .


My guess is that it does some simple DNS tests, and then after a while 
it gives up checking.



On Tue, May 17, 2016 at 2:29 PM, Graham Haddock > wrote:


William:

That would work.

The only "edge case" I might see as a problem would be if your
ping target went off line.  Then the BBB would reboot itself every
ten minutes even though nothing was wrong with the BBB.  I guess
you could ping several different targets in rotation and only
reboot if they all disappeared.
This gets us back to a real cheap local watchdog.

As an aside: Does anyone know what test a computer runs to
determine if it is connected to the internet?
Most desktop/laptop computers have a different network icon as to
whether the network/WiFi you connected to has internet
connectivity.   Is the Windows computer pinging some Microsoft
location that is "guaranteed" to be up?

--- Graham

==


On Tue, May 17, 2016 at 2:30 PM, William Hermans
mailto:yyrk...@gmail.com>> wrote:


@Graham,

What I propose is that you do not need an Ethernet Micro
connected to the BBB. Instead, you have the BBB ping the
outside world once every set time frame, and it a ping comes
back unreachable after say 5-10 minutes. You just stop
"kicking the dog". Which does present a potential problem that
Your internet connection may just be down. But a remote system
that reboots once every 5-10 minutes because the internet
connection is down is not something I'd personally see as a
bad thing. After all you're unable to connect to the system
anyway.


 ==
-- 
For more options, visit http://beagleboard.org/discuss

---
You received this message because you are subscribed to the Google
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to beagleboard+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/beagleboard/CANN_KV6MEtkBkkjA-xc3KKzeNRh6LDpoB1xrBnN%2BZo6gJgLX6w%40mail.gmail.com

.


For more options, visit https://groups.google.com/d/optout.


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google 
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to beagleboard+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrk-KSfKb%3D%2By9tCHPNQSkvfC-K7YPr8cQsvmuwDXR6DCg%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.



--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ff9dc15c-5863-3d8a-ad54-f38

Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Brian Anderson
You might be interested in the Beaglebone Power Cape from Andice Labs 
(http://andicelabs.com). Ron recently posted a blog entry on using the Power 
Cape to address some of the issues you are raising. The Power Cape has an 
onboard microprocessor, battery charger, etc.

ba

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/aadf2585-68c0-449e-b08e-ebeb4c080145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread William Hermans
>
> *William:*
> *That would work.  *
>
> *The only "edge case" I might see as a problem would be if your ping
> target went off line.  Then the BBB would reboot itself every ten minutes
> even though nothing was wrong with the BBB.  I guess you could ping several
> different targets in rotation and only reboot if they all disappeared.*
>
*This gets us back to a real cheap local watchdog.*

You only need to ping one ip address. Your internet gateway IP. e.g. your
first hop outside of your local network.

>
> *As an aside: Does anyone know what test a computer runs to determine if
> it is connected to the internet?*
> *Most desktop/laptop computers have a different network icon as to whether
> the network/WiFi you connected to has internet connectivity.   Is the
> Windows computer pinging some Microsoft location that is "guaranteed" to be
> up?*
>
> *--- Graham*

I'm not 100% sure, but the test Windows does is not always correct.
Sometimes the icon shows not connected, when in fact as soon as you try to
surf something on the web, it goes to the working icon . . .

My guess is that it does some simple DNS tests, and then after a while it
gives up checking.


On Tue, May 17, 2016 at 2:29 PM, Graham Haddock 
wrote:

> William:
>
> That would work.
>
> The only "edge case" I might see as a problem would be if your ping target
> went off line.  Then the BBB would reboot itself every ten minutes even
> though nothing was wrong with the BBB.  I guess you could ping several
> different targets in rotation and only reboot if they all disappeared.
> This gets us back to a real cheap local watchdog.
>
> As an aside: Does anyone know what test a computer runs to determine if it
> is connected to the internet?
> Most desktop/laptop computers have a different network icon as to whether
> the network/WiFi you connected to has internet connectivity.   Is the
> Windows computer pinging some Microsoft location that is "guaranteed" to be
> up?
>
> --- Graham
>
> ==
>
>
> On Tue, May 17, 2016 at 2:30 PM, William Hermans 
> wrote:
>
>>
>> @Graham,
>>
>> What I propose is that you do not need an Ethernet Micro connected to the
>> BBB. Instead, you have the BBB ping the outside world once every set time
>> frame, and it a ping comes back unreachable after say 5-10 minutes. You
>> just stop "kicking the dog". Which does present a potential problem that
>> Your internet connection may just be down. But a remote system that reboots
>> once every 5-10 minutes because the internet connection is down is not
>> something I'd personally see as a bad thing. After all you're unable to
>> connect to the system anyway.
>>
>
>  ==
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CANN_KV6MEtkBkkjA-xc3KKzeNRh6LDpoB1xrBnN%2BZo6gJgLX6w%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrk-KSfKb%3D%2By9tCHPNQSkvfC-K7YPr8cQsvmuwDXR6DCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Graham Haddock
William:

That would work.

The only "edge case" I might see as a problem would be if your ping target
went off line.  Then the BBB would reboot itself every ten minutes even
though nothing was wrong with the BBB.  I guess you could ping several
different targets in rotation and only reboot if they all disappeared.
This gets us back to a real cheap local watchdog.

As an aside: Does anyone know what test a computer runs to determine if it
is connected to the internet?
Most desktop/laptop computers have a different network icon as to whether
the network/WiFi you connected to has internet connectivity.   Is the
Windows computer pinging some Microsoft location that is "guaranteed" to be
up?

--- Graham

==


On Tue, May 17, 2016 at 2:30 PM, William Hermans  wrote:

>
> @Graham,
>
> What I propose is that you do not need an Ethernet Micro connected to the
> BBB. Instead, you have the BBB ping the outside world once every set time
> frame, and it a ping comes back unreachable after say 5-10 minutes. You
> just stop "kicking the dog". Which does present a potential problem that
> Your internet connection may just be down. But a remote system that reboots
> once every 5-10 minutes because the internet connection is down is not
> something I'd personally see as a bad thing. After all you're unable to
> connect to the system anyway.
>

 ==

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV6MEtkBkkjA-xc3KKzeNRh6LDpoB1xrBnN%2BZo6gJgLX6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Super Twang
@William
You right I could be overthinking!  I’m juggling a lot of factors, and looking 
for both a quick, low-hanging-fruit, short term solution (ala off-the-shelf 
Ether-auto-ping, minimal hardware patch, or commercial product), as well as 
over the longer term a rock-solid well engineered long term solution (likely 
supercap-based).  I’m hoping what I contribute here might be as useful to 
others as all of the conversations on this topic (yours included!) that 
preceded me have been to me.  

It is admittedly hard to know when I’ve done “Enough,” esp. since I lack my own 
direct domain knowledge.  Part of the problem is being able to discern which 
design proposals in this and other threads are actually relevant to my own use 
case, and constraints.  You’ve had some great suggestions, and I like the way 
you approached your own design, but parts of it don’t work for me 
(LiPo-batteries, reasons stated prior).  Also, present in most everyone’s 
proposal is something small/cheap MCU-based.  Esp for the near term quick fix, 
the time investment required by learning a new MCU (or something like 
GreenPak), and its dev kit, (even though I’m quite interested), makes me feel 
admittedly a little desperate for alternatives.

In other news, you’re right, Graham’s dead-Ethernet scenario was something I 
hadn’t even considered!  Fortunately for my own case, most of the time my 
systems will be isolated from the greater network, with a 6 inch Ethernet run 
to a dedicated private access point.  So I won’t have as much potential 
exposure to lighting strikes on the Ethernet lines, etc, but also can’t ping 
control/watchdog from anywhere external.  Your own deployment — the “Lightning 
magnet” :) -- sounds like its dealing with a pretty gnarly environment!

My research on this is winding down so this channel will probably quiet down.  
Again, thanks for the help.  

Best,
ST



> On May 17, 2016, at 2:30 PM, William Hermans  wrote:
> 
> Super twang, 
> 
> I honestly think you're over thinking the situation. It's good to try and 
> cover all possibilities, but you're asking questions of people that have not 
> answered specific questions that were answered by others already. There are 
> several smart people on this group. Of which I'd like to count myself among 
> them, but in my own case I know I do not think of everything. Which is why my 
> buddy and I have talked at length on this subject trying to work everything 
> out.
> 
> . . .And you know what, we missed something that thanks to Graham I'm 
> thinking of now. A stale Ethernet connection is every bit as bad as a hung 
> system.
> 
> @Graham,
> 
> What I propose is that you do not need an Ethernet Micro connected to the 
> BBB. Instead, you have the BBB ping the outside world once every set time 
> frame, and it a ping comes back unreachable after say 5-10 minutes. You just 
> stop "kicking the dog". Which does present a potential problem that Your 
> internet connection may just be down. But a remote system that reboots once 
> every 5-10 minutes because the internet connection is down is not something 
> I'd personally see as a bad thing. After all you're unable to connect to the 
> system anyway. 
> 
> On Tue, May 17, 2016 at 12:12 PM, Graham  > wrote:
> Twang:
> 
> You could look at the PIC32MX5xx/6xx/7xx series or PIC32MZ series. 
> The low end starts below $5, quantity one. They will need an external 
> Ethernet phi chip.
> 32 bit MIPS core, program in C, full Ethernet stack available.
> 
> If you want to experiment, get a PIC32MX starter card.
> 
> Ti may have something equivalent on an ARM core.  I just happen to be more 
> familiar with the PICs.
> 
> --- Graham
> 
> ==
> 
> On Tuesday, May 17, 2016 at 10:34:10 AM UTC-5, Super Twang wrote:
> @Graham
> I’ll have to experiment with this. Thanks for the suggestion!  It is 
> definitely a higher level approach that could be easier to piece together 
> with low-cost OTS components.  
> 
> Do you have a specific PIC in mind?  If not, I can dig around for a good one. 
>  Last time I used a PIC it was all assembly language, with no USB ICSP and a 
> PC-only dev environment.  Has that changed? (I’m developing from a Mac)
> 
> Initially my thought was that it wouldn’t work for me because my device is 
> designed to work while disconnected from a larger network (It is connected to 
> a router broadcasting a private access point).  But, there is nothing 
> preventing me from connecting a switch to the router, and then the device and 
> an auto-ping power control to the switch.  My own little auto-ping network… 
> Hmmm!  
> 
> ST
> 
> 
>> On May 16, 2016, at 9:05 PM, Graham > wrote:
>> 
>> Twang:
>> 
>> Well, that is what the "Auto-Ping" is all about.
>> 
>> If I don't get a ping from you in the last two minutes, then you get 
>> power-cycled/rebooted.
>> 
>> There are IoT PICs that are ~$5 that can speak Ethernet and could be 
>> programmed to reset, or press the power button if 5V w

Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread William Hermans
Super twang,

I honestly think you're over thinking the situation. It's good to try and
cover all possibilities, but you're asking questions of people that have
not answered specific questions that were answered by others already. There
are several smart people on this group. Of which I'd like to count myself
among them, but in my own case I know I do not think of everything. Which
is why my buddy and I have talked at length on this subject trying to work
everything out.

. . .And you know what, we missed something that thanks to Graham I'm
thinking of now. A stale Ethernet connection is every bit as bad as a hung
system.

@Graham,

What I propose is that you do not need an Ethernet Micro connected to the
BBB. Instead, you have the BBB ping the outside world once every set time
frame, and it a ping comes back unreachable after say 5-10 minutes. You
just stop "kicking the dog". Which does present a potential problem that
Your internet connection may just be down. But a remote system that reboots
once every 5-10 minutes because the internet connection is down is not
something I'd personally see as a bad thing. After all you're unable to
connect to the system anyway.

On Tue, May 17, 2016 at 12:12 PM, Graham  wrote:

> Twang:
>
> You could look at the PIC32MX5xx/6xx/7xx series or PIC32MZ series.
> The low end starts below $5, quantity one. They will need an external
> Ethernet phi chip.
> 32 bit MIPS core, program in C, full Ethernet stack available.
>
> If you want to experiment, get a PIC32MX starter card.
>
> Ti may have something equivalent on an ARM core.  I just happen to be more
> familiar with the PICs.
>
> --- Graham
>
> ==
>
> On Tuesday, May 17, 2016 at 10:34:10 AM UTC-5, Super Twang wrote:
>>
>> @Graham
>> I’ll have to experiment with this. Thanks for the suggestion!  It is
>> definitely a higher level approach that could be easier to piece together
>> with low-cost OTS components.
>>
>> Do you have a specific PIC in mind?  If not, I can dig around for a good
>> one.  Last time I used a PIC it was all assembly language, with no USB ICSP
>> and a PC-only dev environment.  Has that changed? (I’m developing from a
>> Mac)
>>
>> Initially my thought was that it wouldn’t work for me because my device
>> is designed to work while disconnected from a larger network (It is
>> connected to a router broadcasting a private access point).  But, there is
>> nothing preventing me from connecting a switch to the router, and then the
>> device and an auto-ping power control to the switch.  My own little
>> auto-ping network… Hmmm!
>>
>> ST
>>
>>
>> On May 16, 2016, at 9:05 PM, Graham  wrote:
>>
>> Twang:
>>
>> Well, that is what the "Auto-Ping" is all about.
>>
>> If I don't get a ping from you in the last two minutes, then you get
>> power-cycled/rebooted.
>>
>> There are IoT PICs that are ~$5 that can speak Ethernet and could be
>> programmed to reset, or press the power button if 5V was present, and they
>> had not heard from the BBB lately.
>>
>> More appropriate monitoring for a server, than watching some GPIO wiggle.
>>
>> --- Graham
>>
>>
>> On Monday, May 16, 2016 at 8:08:01 PM UTC-5, Super Twang wrote:
>>>
>>> @Graham
>>> Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart
>>> from the (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d
>>> guess you could solve this with the onboard watchdog timer.  Run some kind
>>> of daemon that periodically “Checks for good ethernet” (a bit vague, I
>>> know), if found, it tickles the watchdog, if not, it provokes a reboot.
>>> But yes, the problem remains that the reboot doesn’t always complete.
>>>
>>> Of course if your ethernet got fried, that’d turn into a reboot cycle
>>> without some logic to notify you of the problem, and stop after a number of
>>> cycles.
>>>
>>>
>>>
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/73c0f3ff-43b7-433c-8a9

Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Graham
Twang:

You could look at the PIC32MX5xx/6xx/7xx series or PIC32MZ series. 
The low end starts below $5, quantity one. They will need an external 
Ethernet phi chip.
32 bit MIPS core, program in C, full Ethernet stack available.

If you want to experiment, get a PIC32MX starter card.

Ti may have something equivalent on an ARM core.  I just happen to be more 
familiar with the PICs.

--- Graham

==

On Tuesday, May 17, 2016 at 10:34:10 AM UTC-5, Super Twang wrote:
>
> @Graham
> I’ll have to experiment with this. Thanks for the suggestion!  It is 
> definitely a higher level approach that could be easier to piece together 
> with low-cost OTS components.  
>
> Do you have a specific PIC in mind?  If not, I can dig around for a good 
> one.  Last time I used a PIC it was all assembly language, with no USB ICSP 
> and a PC-only dev environment.  Has that changed? (I’m developing from a 
> Mac)
>
> Initially my thought was that it wouldn’t work for me because my device is 
> designed to work while disconnected from a larger network (It is connected 
> to a router broadcasting a private access point).  But, there is nothing 
> preventing me from connecting a switch to the router, and then the device 
> and an auto-ping power control to the switch.  My own little auto-ping 
> network… Hmmm!  
>
> ST
>
>
> On May 16, 2016, at 9:05 PM, Graham > 
> wrote:
>
> Twang:
>
> Well, that is what the "Auto-Ping" is all about.
>
> If I don't get a ping from you in the last two minutes, then you get 
> power-cycled/rebooted.
>
> There are IoT PICs that are ~$5 that can speak Ethernet and could be 
> programmed to reset, or press the power button if 5V was present, and they 
> had not heard from the BBB lately.
>
> More appropriate monitoring for a server, than watching some GPIO wiggle.
>
> --- Graham
>
>
> On Monday, May 16, 2016 at 8:08:01 PM UTC-5, Super Twang wrote:
>>
>> @Graham
>> Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart from 
>> the (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d guess 
>> you could solve this with the onboard watchdog timer.  Run some kind of 
>> daemon that periodically “Checks for good ethernet” (a bit vague, I know), 
>> if found, it tickles the watchdog, if not, it provokes a reboot.  But yes, 
>> the problem remains that the reboot doesn’t always complete.
>>
>> Of course if your ethernet got fried, that’d turn into a reboot cycle 
>> without some logic to notify you of the problem, and stop after a number of 
>> cycles.
>>
>>
>>
>>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/73c0f3ff-43b7-433c-8a9a-783162c7fef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Super Twang
Hi y’all,

Below is a snippet of an offline email exchange between myself and Gerald of 
Beagleboard.org … I’m reposting it here because I 
think it further clarifies some of the subtleties of what is being discussed 
here, specifically how brown-outs are what throw the wrench into a simple 
solution with existing hardware.  It also illustrates some real-world 
constraints Gerald et al are facing around a potential solution at the board 
level.  I hope this helps the bring anyone new to the discussion up to speed, 
as it helped me.

Best,
ST

> As I understand it, the crux of the problem -- what prevents the use of 
> existing off-the-shelf protection gear (like a stock UPS unit) — is the 
> necessity to physically close the reset switch to reliably reboot the board.  
> To be honest, I’m not even sure if this is even a real “Issue" (although it 
> is listed as such in the wiki), or just the upshot from a design decision you 
> consciously made (say, to reduce costs).  I think there is broad agreement 
> that this is a problem.  You’ve already built in some nice power management 
> hooks (interrupts, watchdog and such) that ought to allow the system to be 
> shut down gracefully when mains power is lost, it just can’t restart itself.
> 
> Sort of. If you close the rest switch, you can trash the file system. What 
> you need is an interrupt to allow the processor to close the file system. 
> That exists today. Having the super cap or battery gives enough power for the 
> processor to complete that task and power down. When the DC is restored it 
> powers back up. The issue is if it is a brown out, that is where things get 
> messed up because it is not a clean shutdown and power up. 
> 
> Is the elimination of this particular physical switching requirement by 
> itself, a tough problem to solve?  
> No
>  
> Would it take a lot of (cost-increasing) new hardware?  
> 
> Yes. At least $3.
>  
> Would it need anything new in the kernel?  
> 
> No.
>  
> Any software support?  Wouldn’t it “Just work” as hardware outside of the OS?
> 
> It can if it is done right. 
> 
> The more complete, robust “Reliability system," such as is being discussed in 
> the forum, is a whole different thing -- less issue, more feature 
> --effectively designed to replace the UPS with a custom backup power system 
> tailored for/integrated with the BBB, that also happens to mitigate the core 
> switching issue.  You’re right, there there are a lot of opinions, and a lot 
> of different use cases here.
> 
> Super Cap works fine.  It is just the corner cases that need to be handled.
> 
> If my reasoning is good, it would imply the overall “Reliability system" is a 
> good match for external solutions, whereas eliminating the physical switching 
> requirement would be a good thing to add to the mainline board.  
> 
> Yes as long as these additions are free or would actually reduce the cost.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/20438005-A221-4DD1-A20F-EDF3998F152B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Lachlan Audas
No problems,,you can have the design files.. in eagle or kicad,
it's just a example..   but if you think about it,  it uses a old trick
from aircraft,   thou in this case it's a complete power cycle.
They would save what the CPU was doing in NV memory of some sort(I assume
core memory)..
reset the CPU and reload the data..check it, and continue..
so there may have 5  reset a second.. etc..
remember airplanes can have many light  strikes..  etc..
and if your life is dependent's on  those chips getting it correct,
you wont to use every trick in the book!

I was on  a flight  (747-400)  bad day it was Sept 11, it was from
Australia to USA,  the pilot come on the PA and said there was some
problems with some on board systems and resetting it did not fix the
problem.
So had to pull the circuit breakers.. for the part of the plain, and wait..
and reactivate them fix the problem,  so reset's don't always fix the
problem..
even on a 747-400 power cycale was the only thing which work.

Lachlan.


Lachlan


On Tue, May 17, 2016 at 8:36 AM, Super Twang  wrote:

> @Lachlan
> Thank you for sharing your design.  I’m definitely learning from it and
> I’m sure others will too.
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/86973270-CDD1-4AC3-9AB5-F0A13951BBAB%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MvSQobXOh80yKGZ%2Bnkv4QmVbJy9PtDzcKm0pDg_ttqRSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Super Twang
@Lachlan
Thank you for sharing your design.  I’m definitely learning from it and I’m 
sure others will too.
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/86973270-CDD1-4AC3-9AB5-F0A13951BBAB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-17 Thread Super Twang
@Graham
I’ll have to experiment with this. Thanks for the suggestion!  It is definitely 
a higher level approach that could be easier to piece together with low-cost 
OTS components.  

Do you have a specific PIC in mind?  If not, I can dig around for a good one.  
Last time I used a PIC it was all assembly language, with no USB ICSP and a 
PC-only dev environment.  Has that changed? (I’m developing from a Mac)

Initially my thought was that it wouldn’t work for me because my device is 
designed to work while disconnected from a larger network (It is connected to a 
router broadcasting a private access point).  But, there is nothing preventing 
me from connecting a switch to the router, and then the device and an auto-ping 
power control to the switch.  My own little auto-ping network… Hmmm!  

ST


> On May 16, 2016, at 9:05 PM, Graham  wrote:
> 
> Twang:
> 
> Well, that is what the "Auto-Ping" is all about.
> 
> If I don't get a ping from you in the last two minutes, then you get 
> power-cycled/rebooted.
> 
> There are IoT PICs that are ~$5 that can speak Ethernet and could be 
> programmed to reset, or press the power button if 5V was present, and they 
> had not heard from the BBB lately.
> 
> More appropriate monitoring for a server, than watching some GPIO wiggle.
> 
> --- Graham
> 
> 
> On Monday, May 16, 2016 at 8:08:01 PM UTC-5, Super Twang wrote:
> @Graham
> Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart from the 
> (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d guess you 
> could solve this with the onboard watchdog timer.  Run some kind of daemon 
> that periodically “Checks for good ethernet” (a bit vague, I know), if found, 
> it tickles the watchdog, if not, it provokes a reboot.  But yes, the problem 
> remains that the reboot doesn’t always complete.
> 
> Of course if your ethernet got fried, that’d turn into a reboot cycle without 
> some logic to notify you of the problem, and stop after a number of cycles.
> 
> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7E0D1F7D-2542-4BF4-9F22-739A19E91EF4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread zamek42

Hi All,

We have a power supply like this. We use it for a Wandboard.

Technical parameters:

input voltage:9-32VDC
output voltage: 5VDC/2500mA
there is a 25F supercapacity which can hold the power up to 30s after 
the power broken.

There is an input GPIO for watchdog and an output GPIO to power ok signal.
We can make it for Beagleboard.

Please write me, if you interest.

--

thx
Zoltan (Zamek) Zidarics
programmer
email:zame...@gmail.com
Self Playing Pipe Organ Systems
http://replayorgan.eu

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/29065523-1e21-5cf4-0c8e-8f26b330ba18%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Graham
Twang:

Well, that is what the "Auto-Ping" is all about.

If I don't get a ping from you in the last two minutes, then you get 
power-cycled/rebooted.

There are IoT PICs that are ~$5 that can speak Ethernet and could be 
programmed to reset, or press the power button if 5V was present, and they 
had not heard from the BBB lately.

More appropriate monitoring for a server, than watching some GPIO wiggle.

--- Graham


On Monday, May 16, 2016 at 8:08:01 PM UTC-5, Super Twang wrote:
>
> @Graham
> Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart from 
> the (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d guess 
> you could solve this with the onboard watchdog timer.  Run some kind of 
> daemon that periodically “Checks for good ethernet” (a bit vague, I know), 
> if found, it tickles the watchdog, if not, it provokes a reboot.  But yes, 
> the problem remains that the reboot doesn’t always complete.
>
> Of course if your ethernet got fried, that’d turn into a reboot cycle 
> without some logic to notify you of the problem, and stop after a number of 
> cycles.
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
Ethernet has always been a point of failure as much as Telephone lines have
been in the past. Except for Ethernet it is usually less drastic as many
networks are not physically accessible to the elements. Like ours, where we
have two external WDS routers that are point to point 1/2 miles distance in
between, with a power transformer connected to a house on one end that
loves to be struck by lightning . . .;)

On Mon, May 16, 2016 at 6:07 PM, Super Twang  wrote:

> @Graham
> Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart from
> the (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d guess
> you could solve this with the onboard watchdog timer.  Run some kind of
> daemon that periodically “Checks for good ethernet” (a bit vague, I know),
> if found, it tickles the watchdog, if not, it provokes a reboot.  But yes,
> the problem remains that the reboot doesn’t always complete.
>
> Of course if your ethernet got fried, that’d turn into a reboot cycle
> without some logic to notify you of the problem, and stop after a number of
> cycles.
>
>
>
> On May 16, 2016, at 7:56 PM, Graham  wrote:
>
> It all depends on what you are worried about.
>
> I have several BBBs that I use as servers, and I want them to be robust.
>
> So while working through power backup and an external hardware watchdog
> per all the previous discussions, we have a thunderstorm roll through the
> area.
>
> No close strikes, but the Ethernet network interface went catatonic, would
> not send or receive, but didn't throw any errors.
>
> I could not SSH into the command line.
>
> But the local serial port/command line worked fine.  The kernel seemed to
> be happily running, and not worried about anything in particular.
>
> The system logs looked like someone had disconnected the Ethernet cable
> during the storm, but the network was still physically connected, with the
> RJ-45 socket lights blinking.
>
> A power cycle reestablished everything.
>
> So, probably some kind of transient flipped a few configuration register
> bits and stopped the Ethernet interface.
> No physical damage.
>
> This kind of thing can not be unique, because I note that there are
> Ethernet controlled power strips with "Auto-Ping."
> Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
> AP, router, VoIP phone, server, camera. or other device automatically.
>
> Web Power Switch 7.http://www.digital-loggers.com/lpc.html
>
> So either I can go buy a $115 smart AC power switch, or use an
> Ethernet-PIC instead of the MSP430.
>
> --- Graham
>
> ==
>
>>
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/AA5B0956-374D-45E8-9336-22899699F9E7%40gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrFS7Ayqy7H7nQ0FJtkiMvyuU05OK3fBkBUpO_aazSz%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Gerald Coley
I am no longer with TI. You would need to ask Jason as to the level of
commitment that TI has toward doing something like this.

If there is a decently robust need for a platform based on the BBB, but
with some more robust and desired features, I would be open to making that
happen.

Gerald


On Mon, May 16, 2016 at 8:03 PM, William Hermans  wrote:

> *This kind of thing can not be unique, because I note that there are
>> Ethernet controlled power strips with "Auto-Ping."*
>>
> *Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
> AP, router, VoIP phone, server, camera. or other device automatically.*
>
> This isn't unique to the Beaglebones. We get close strikes here all the
> time during the summer, and in fact decapped a realtech ethernet bridge
> chip in a PoE switch last year . . . But my personal equipment gets reset
> all the time from static discharges from close strike several times a year.
> Mostly it's just a GbE switch I have in my bedroom, but other devices get
> messes up from time to time as well. Once or twice our PoE WDS routers have
> too . . .
>
>
> On Mon, May 16, 2016 at 5:56 PM, Graham  wrote:
>
>> It all depends on what you are worried about.
>>
>> I have several BBBs that I use as servers, and I want them to be robust.
>>
>> So while working through power backup and an external hardware watchdog
>> per all the previous discussions, we have a thunderstorm roll through the
>> area.
>>
>> No close strikes, but the Ethernet network interface went catatonic,
>> would not send or receive, but didn't throw any errors.
>>
>> I could not SSH into the command line.
>>
>> But the local serial port/command line worked fine.  The kernel seemed to
>> be happily running, and not worried about anything in particular.
>>
>> The system logs looked like someone had disconnected the Ethernet cable
>> during the storm, but the network was still physically connected, with the
>> RJ-45 socket lights blinking.
>>
>> A power cycle reestablished everything.
>>
>> So, probably some kind of transient flipped a few configuration register
>> bits and stopped the Ethernet interface.
>> No physical damage.
>>
>> This kind of thing can not be unique, because I note that there are
>> Ethernet controlled power strips with "Auto-Ping."
>> Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
>> AP, router, VoIP phone, server, camera. or other device automatically.
>>
>> Web Power Switch 7.http://www.digital-loggers.com/lpc.html
>>
>> So either I can go buy a $115 smart AC power switch, or use an
>> Ethernet-PIC instead of the MSP430.
>>
>> --- Graham
>>
>> ==
>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORqTdBG2XVL52pvECedfZvLEjtwv5KE0GovH4E6LP9z2mw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Be81bA01%2BO6mfwxXSTVGZzy9v_XFrDhP_4yPnqFzNFKWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Super Twang
@Graham
Wow!  I hadn’t yet thought of Ethernet as a point of failure.  Apart from the 
(“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d guess you 
could solve this with the onboard watchdog timer.  Run some kind of daemon that 
periodically “Checks for good ethernet” (a bit vague, I know), if found, it 
tickles the watchdog, if not, it provokes a reboot.  But yes, the problem 
remains that the reboot doesn’t always complete.

Of course if your ethernet got fried, that’d turn into a reboot cycle without 
some logic to notify you of the problem, and stop after a number of cycles.



> On May 16, 2016, at 7:56 PM, Graham  wrote:
> 
> It all depends on what you are worried about.  
> 
> I have several BBBs that I use as servers, and I want them to be robust.
> 
> So while working through power backup and an external hardware watchdog per 
> all the previous discussions, we have a thunderstorm roll through the area.
> 
> No close strikes, but the Ethernet network interface went catatonic, would 
> not send or receive, but didn't throw any errors.  
> 
> I could not SSH into the command line.
> 
> But the local serial port/command line worked fine.  The kernel seemed to be 
> happily running, and not worried about anything in particular.
> 
> The system logs looked like someone had disconnected the Ethernet cable 
> during the storm, but the network was still physically connected, with the 
> RJ-45 socket lights blinking.
> 
> A power cycle reestablished everything.
> 
> So, probably some kind of transient flipped a few configuration register bits 
> and stopped the Ethernet interface. 
> No physical damage.
> 
> This kind of thing can not be unique, because I note that there are Ethernet 
> controlled power strips with "Auto-Ping."
> Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up AP, 
> router, VoIP phone, server, camera. or other device automatically.
> 
> Web Power Switch 7.http://www.digital-loggers.com/lpc.html
> 
> So either I can go buy a $115 smart AC power switch, or use an Ethernet-PIC 
> instead of the MSP430.
> 
> --- Graham
> 
> ==
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/AA5B0956-374D-45E8-9336-22899699F9E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
@Dave loomis

Fine, if something does not work for you then by all means don't use it.
But the high cost rediculous stuff I was speaking to all uses batteries . .
.so you're SoL there too.


Also, if LiPO is not good for you, think about switching to a different
battery chemistry. Get crazy, think out side the box.

On Mon, May 16, 2016 at 6:03 PM, William Hermans  wrote:

> *This kind of thing can not be unique, because I note that there are
>> Ethernet controlled power strips with "Auto-Ping."*
>>
> *Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
> AP, router, VoIP phone, server, camera. or other device automatically.*
>
> This isn't unique to the Beaglebones. We get close strikes here all the
> time during the summer, and in fact decapped a realtech ethernet bridge
> chip in a PoE switch last year . . . But my personal equipment gets reset
> all the time from static discharges from close strike several times a year.
> Mostly it's just a GbE switch I have in my bedroom, but other devices get
> messes up from time to time as well. Once or twice our PoE WDS routers have
> too . . .
>
>
> On Mon, May 16, 2016 at 5:56 PM, Graham  wrote:
>
>> It all depends on what you are worried about.
>>
>> I have several BBBs that I use as servers, and I want them to be robust.
>>
>> So while working through power backup and an external hardware watchdog
>> per all the previous discussions, we have a thunderstorm roll through the
>> area.
>>
>> No close strikes, but the Ethernet network interface went catatonic,
>> would not send or receive, but didn't throw any errors.
>>
>> I could not SSH into the command line.
>>
>> But the local serial port/command line worked fine.  The kernel seemed to
>> be happily running, and not worried about anything in particular.
>>
>> The system logs looked like someone had disconnected the Ethernet cable
>> during the storm, but the network was still physically connected, with the
>> RJ-45 socket lights blinking.
>>
>> A power cycle reestablished everything.
>>
>> So, probably some kind of transient flipped a few configuration register
>> bits and stopped the Ethernet interface.
>> No physical damage.
>>
>> This kind of thing can not be unique, because I note that there are
>> Ethernet controlled power strips with "Auto-Ping."
>> Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
>> AP, router, VoIP phone, server, camera. or other device automatically.
>>
>> Web Power Switch 7.http://www.digital-loggers.com/lpc.html
>>
>> So either I can go buy a $115 smart AC power switch, or use an
>> Ethernet-PIC instead of the MSP430.
>>
>> --- Graham
>>
>> ==
>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrohCOWt7P4MCCabgbX0zkVuZrGZiW2_O9%3D%2BcEfV9MCTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
>
> *This kind of thing can not be unique, because I note that there are
> Ethernet controlled power strips with "Auto-Ping."*
>
*Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
AP, router, VoIP phone, server, camera. or other device automatically.*

This isn't unique to the Beaglebones. We get close strikes here all the
time during the summer, and in fact decapped a realtech ethernet bridge
chip in a PoE switch last year . . . But my personal equipment gets reset
all the time from static discharges from close strike several times a year.
Mostly it's just a GbE switch I have in my bedroom, but other devices get
messes up from time to time as well. Once or twice our PoE WDS routers have
too . . .


On Mon, May 16, 2016 at 5:56 PM, Graham  wrote:

> It all depends on what you are worried about.
>
> I have several BBBs that I use as servers, and I want them to be robust.
>
> So while working through power backup and an external hardware watchdog
> per all the previous discussions, we have a thunderstorm roll through the
> area.
>
> No close strikes, but the Ethernet network interface went catatonic, would
> not send or receive, but didn't throw any errors.
>
> I could not SSH into the command line.
>
> But the local serial port/command line worked fine.  The kernel seemed to
> be happily running, and not worried about anything in particular.
>
> The system logs looked like someone had disconnected the Ethernet cable
> during the storm, but the network was still physically connected, with the
> RJ-45 socket lights blinking.
>
> A power cycle reestablished everything.
>
> So, probably some kind of transient flipped a few configuration register
> bits and stopped the Ethernet interface.
> No physical damage.
>
> This kind of thing can not be unique, because I note that there are
> Ethernet controlled power strips with "Auto-Ping."
> Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up
> AP, router, VoIP phone, server, camera. or other device automatically.
>
> Web Power Switch 7.http://www.digital-loggers.com/lpc.html
>
> So either I can go buy a $115 smart AC power switch, or use an
> Ethernet-PIC instead of the MSP430.
>
> --- Graham
>
> ==
>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqTdBG2XVL52pvECedfZvLEjtwv5KE0GovH4E6LP9z2mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Graham
It all depends on what you are worried about.  

I have several BBBs that I use as servers, and I want them to be robust.

So while working through power backup and an external hardware watchdog per 
all the previous discussions, we have a thunderstorm roll through the area.

No close strikes, but the Ethernet network interface went catatonic, would 
not send or receive, but didn't throw any errors.  

I could not SSH into the command line.

But the local serial port/command line worked fine.  The kernel seemed to 
be happily running, and not worried about anything in particular.

The system logs looked like someone had disconnected the Ethernet cable 
during the storm, but the network was still physically connected, with the 
RJ-45 socket lights blinking.

A power cycle reestablished everything.

So, probably some kind of transient flipped a few configuration register 
bits and stopped the Ethernet interface. 
No physical damage.

This kind of thing can not be unique, because I note that there are 
Ethernet controlled power strips with "Auto-Ping."
Stated feature is “Auto-Ping” feature to intelligently reboot a locked-up 
AP, router, VoIP phone, server, camera. or other device automatically.

Web Power Switch 7.http://www.digital-loggers.com/lpc.html

So either I can go buy a $115 smart AC power switch, or use an Ethernet-PIC 
instead of the MSP430.

--- Graham

==

>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/47e04409-af30-4c62-9b3b-445a82036380%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Super Twang

@Gerald
I’m a bit new on this forum; forgive me if you’re not the right person to ask… 
(please, anyone else, respond if you are) Its just that I’ve heard other people 
request and defer to your opinion on things, and, well, you have a pretty 
official looking email address! :)  

I understand the goal of keeping the BBB cost low (part of what attracted me to 
it over the RPi in the first place).  I agree, it is good to keep it 
competitive and within the reach of hobbyists.  I realize it may not be as much 
of an issue to the use-cases of others, but it’d seem that an inability to keep 
a BBB reliably running without physically pressing its reset button is a bit of 
an Achilles Heel for the platform (speaking here not generally of UPS-style 
Mains protection, but specifically of the issue that sometimes prevents its 
restart without physically pressing the button.  IE you can’t simply use a OTS 
UPS, without some additional logic. )  It’d seem that anyone who wants to leave 
their device running for an extended period of time would be impacted by this.

Do you know folks at TI who are as invested as you are in the success of the 
BBB platform?  In my own research, I’ve come to understand that TI makes many 
of the components that might form the basis of a rock solid “Reliability 
System” (as discussed in this thread).  (Things like supercap chargers, 
buck-boost chips, etc)  It’d seem that this problem would be a natural fit for 
someone at TI to solve in the form of a TI Reference Design, or Application 
Notes for their product line on their end.  Such an effort would be a win-win.  
TI would be able to sell more TI components, support the BBB user community and 
open the device to new use cases, and their resulting markets.  The BBB 
community would be able to implement (or purchase) the TI/BBB reliability 
circuit, and focus on their primary designs, without having to solve the same 
basic reliability issue over and over.

Is there someone at TI, I could present this idea to?  Is this the kind of 
thing that’d even get considered and resourced?  Is TI nimble enough to care, 
and responsive to the BBB user community?

Thanks for your thoughts,
ST




> On May 16, 2016, at 7:12 PM, Gerald Coley  wrote:
> 
> Sounds good to me!
> 
> Gerald
> 
> 
> On Mon, May 16, 2016 at 6:52 PM, Dave Loomis  > wrote:
> 
> > You can sum it all up into this; The problem is completely solved by using 
> > a battery and having acpid installed. Except you need a way to completely 
> > disconnect power, from the BBB's input, for a single, or perhaps two corner 
> > cases that would otherwise require a hard reset.
> 
> I love the no-nonsense mentality, and quality design behind this approach for 
> most use cases.  But, for some high-reliability use cases like mine -- a 
> device permanently installed in a remote, client wall — batteries aren’t a 
> great fit.
> 
> For long-term accessibility:Battery maintenance, even after years 
> of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of installing 
> LiPo, which is known to have potential fire issues, into a client’s wall.
> For shipping reasons:   The added hassle of international 
> shipping of LiPo-based systems.
> 
> > All these fancy high cost solutions are honestly ridiculous, and if you can 
> > just use an OTS UPS . . .
> 
>  Hardware cost is relative.  The “high” cost (<$100) of a system 
> design is nothing, if it will potentially save me things like panicked client 
> calls, last-minute international plane tickets and high-pressure field 
> repairs.  Those just aren’t fun.  Obviously every project out there isn’t 
> heading to a NASA rover, but in some lines of work this kind of service is 
> expected when a high-end, mission-critical system goes down.  In the end, if 
> I do my job right, the price is just passed on to the client who is willing 
> to pay a premium for a high reliability, maintenance-free product.
> 
> I’d like to be able to deploy those systems based on the BBB, because I know 
> it, find the platform highly versatile, and a good match for the variety of 
> projects I take on.  I think the PRUs especially make this a very unique 
> little SoC.
> 
> Best,
> ST
> 
> 
> 
> --
> For more options, visit http://beagleboard.org/discuss 
> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
>  
> .
> For more op

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Gerald Coley
Sounds good to me!

Gerald


On Mon, May 16, 2016 at 6:52 PM, Dave Loomis  wrote:

>
> > You can sum it all up into this; The problem is completely solved by
> using a battery and having acpid installed. Except you need a way to
> completely disconnect power, from the BBB's input, for a single, or perhaps
> two corner cases that would otherwise require a hard reset.
>
> I love the no-nonsense mentality, and quality design behind this approach
> for most use cases.  But, for some high-reliability use cases like mine --
> a device permanently installed in a remote, client wall — batteries aren’t
> a great fit.
>
> For long-term accessibility:Battery maintenance, even after
> years of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of
> installing LiPo, which is known to have potential fire issues, into a
> client’s wall.
> For shipping reasons:   The added hassle of international
> shipping of LiPo-based systems.
>
> > All these fancy high cost solutions are honestly ridiculous, and if you
> can just use an OTS UPS . . .
>
>  Hardware cost is relative.  The “high” cost (<$100) of a system
> design is nothing, if it will potentially save me things like panicked
> client calls, last-minute international plane tickets and high-pressure
> field repairs.  Those just aren’t fun.  Obviously every project out there
> isn’t heading to a NASA rover, but in some lines of work this kind of
> service is expected when a high-end, mission-critical system goes down.  In
> the end, if I do my job right, the price is just passed on to the client
> who is willing to pay a premium for a high reliability, maintenance-free
> product.
>
> I’d like to be able to deploy those systems based on the BBB, because I
> know it, find the platform highly versatile, and a good match for the
> variety of projects I take on.  I think the PRUs especially make this a
> very unique little SoC.
>
> Best,
> ST
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Bf%3Dk5zSYuJ95pf03BFrVxC5%3Dqm0YUguSZ%2B2_y1mwiSDkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Dave Loomis

> You can sum it all up into this; The problem is completely solved by using a 
> battery and having acpid installed. Except you need a way to completely 
> disconnect power, from the BBB's input, for a single, or perhaps two corner 
> cases that would otherwise require a hard reset.

I love the no-nonsense mentality, and quality design behind this approach for 
most use cases.  But, for some high-reliability use cases like mine -- a device 
permanently installed in a remote, client wall — batteries aren’t a great fit.

For long-term accessibility:Battery maintenance, even after years 
of initial functionality, is extremely inconvenient or impossible.
For insurance reasons:  The potential liability of installing 
LiPo, which is known to have potential fire issues, into a client’s wall.
For shipping reasons:   The added hassle of international 
shipping of LiPo-based systems.

> All these fancy high cost solutions are honestly ridiculous, and if you can 
> just use an OTS UPS . . . 

 Hardware cost is relative.  The “high” cost (<$100) of a system design 
is nothing, if it will potentially save me things like panicked client calls, 
last-minute international plane tickets and high-pressure field repairs.  Those 
just aren’t fun.  Obviously every project out there isn’t heading to a NASA 
rover, but in some lines of work this kind of service is expected when a 
high-end, mission-critical system goes down.  In the end, if I do my job right, 
the price is just passed on to the client who is willing to pay a premium for a 
high reliability, maintenance-free product.  

I’d like to be able to deploy those systems based on the BBB, because I know 
it, find the platform highly versatile, and a good match for the variety of 
projects I take on.  I think the PRUs especially make this a very unique little 
SoC.

Best,
ST



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Gerald Coley
There are a lot of cheap power supplies out there that do not like any
drops on the mains, not very well filtered or robust. These can play havoc
on the HW.

The BBB is a low cost board, with people trying to make it cheaper all the
time. To make it cheap something had to go. What you are talking about
here, is one of the things that went. An Atmel Tiny would be perfect as a
power monitor. It can shut it down and wake it up once the power comes
back. Even if it goes down for a moment, you can play it safe and shut it
down and wait a while. Your call

All you have to do is add it to the board.


Gerald




On Mon, May 16, 2016 at 3:08 PM, William Hermans  wrote:

> *Add a a battery or super CAP. When the DC voltage goes away, the
>> processor gets and interrupt. When SW get interrupt unmount the Flash and
>> power down.*
>>
> When a battery is connected to the battery test points, this is exactly
> what happens now when you have the debian package acpid installed( *sudo
> apt-get install acpid* )
>
> *Invest in a real 5V power supply.*
>
>
> Would you mind elaborating further on what you mean by that Gerald ?
>
> Gerlad
>
> On Mon, May 16, 2016 at 12:54 PM, Gerald Coley 
> wrote:
>
>> Add a a battery or super CAP. When the DC voltage goes away, the
>> processor gets and interrupt. When SW get interrupt unmount the Flash and
>> power down.
>> Invest in a real 5V power supply.
>>
>> Gerlad
>>
>> On Mon, May 16, 2016 at 2:51 PM, Micka  wrote:
>>
>>> Gerald what is your opinion on this subject ?
>>>
>>>
>>> Le lun. 16 mai 2016 21:46, evilwulfie  a écrit :
>>>
 spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.



 On 5/16/2016 12:34 PM, John Syne wrote:


 On May 15, 2016, at 4:25 PM, evilwulfie < 
 evilwul...@gmail.com> wrote:

 msp430 has an internal watchdog

 And so does the AM3358, so I’m not sure whats your point? If it is a
 micro-controller, it is not guaranteed to boot up successfully every time,
 given an unstable power supply. To start with, you need to make the power
 supply more predictable so that brown outs, dips and sags are not seen by
 the micro-controller and that power down only occurs if the input power
 fails for more than a specified time. Also, if you do start a shutdown,
 then a full power cycle is needed in a controlled manner. When input power
 returns, don’t boot until the input power looks reliable.

 This is where you need an understanding of how the power utility
 network operates, which includes understanding how protection operates,
 what an ARC (Automatic Reclosure Relays) do, etc. For example, when a large
 breaker trips due to a protective signal, the ARC will attempt to reclose
 that breaker, sometimes more than once. At night, in a storm, you will see
 your lights dim for a second or two; that is an ARC operation. When a
 transformer has water in the oil or when a insulator is arching, or a power
 line is arching on the ground, these all result in very strange power
 behavior. In summary, power failure isn’t just an on or off problem, but a
 multitude of more problematic cases.

 Regards,
 John


 On 5/15/2016 3:37 PM, John Syne wrote:


 On May 15, 2016, at 3:14 PM, evilwulfie  wrote:

 We use an external msp430 for our intelligent watchdog

 So who or what monitors the MSP430? Since it is a micro-controller, it
 is easy to get it into a lock situation. All you need is a programable
 power supply which will ramp up and down the voltage into the
 micro-controller at predefined times and it will lock and become completely
 unresponsive. Granted this will rarely happen, but in our applications
 where 100K or more devices are installed, we cannot accept some devices
 locking up because of a power failure.

 Regards,
 John



 On 5/15/2016 1:07 PM, Super Twang wrote:



 I've just come across this conversation in my own search for a
 rock-solid, embeddable configuration for the BeagleBone Black.  I’m trying
 to develop an embedded controller device that needs to live behind walls,
 in ceilings and in other inaccessible places. ( It is for the automation of
 art & other electronic installations.)

 From what I gather here, the BBB is not quite up to the task, without
 an external watchdog circuit (please correct me if I’m misreading this
 thread).

 @John3909: Your suggestion of the GreenPak prompted my own discovery of
 that tech — it looks great, esp the ecosystem of tools around the platform.

 In looking around, I found some Silego application notes that implement
 a hardware watchdog for MCUs.
 http://www.silego.com/products/352/312/AN-1058.html  This might be a
 useful starting point for anyone using GreenPak for a hardware watchdog.

 @John3

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
>
> *Add a a battery or super CAP. When the DC voltage goes away, the
> processor gets and interrupt. When SW get interrupt unmount the Flash and
> power down.*
>
When a battery is connected to the battery test points, this is exactly
what happens now when you have the debian package acpid installed( *sudo
apt-get install acpid* )

*Invest in a real 5V power supply.*


Would you mind elaborating further on what you mean by that Gerald ?

Gerlad

On Mon, May 16, 2016 at 12:54 PM, Gerald Coley 
wrote:

> Add a a battery or super CAP. When the DC voltage goes away, the processor
> gets and interrupt. When SW get interrupt unmount the Flash and power down.
> Invest in a real 5V power supply.
>
> Gerlad
>
> On Mon, May 16, 2016 at 2:51 PM, Micka  wrote:
>
>> Gerald what is your opinion on this subject ?
>>
>>
>> Le lun. 16 mai 2016 21:46, evilwulfie  a écrit :
>>
>>> spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.
>>>
>>>
>>>
>>> On 5/16/2016 12:34 PM, John Syne wrote:
>>>
>>>
>>> On May 15, 2016, at 4:25 PM, evilwulfie < 
>>> evilwul...@gmail.com> wrote:
>>>
>>> msp430 has an internal watchdog
>>>
>>> And so does the AM3358, so I’m not sure whats your point? If it is a
>>> micro-controller, it is not guaranteed to boot up successfully every time,
>>> given an unstable power supply. To start with, you need to make the power
>>> supply more predictable so that brown outs, dips and sags are not seen by
>>> the micro-controller and that power down only occurs if the input power
>>> fails for more than a specified time. Also, if you do start a shutdown,
>>> then a full power cycle is needed in a controlled manner. When input power
>>> returns, don’t boot until the input power looks reliable.
>>>
>>> This is where you need an understanding of how the power utility network
>>> operates, which includes understanding how protection operates, what an ARC
>>> (Automatic Reclosure Relays) do, etc. For example, when a large breaker
>>> trips due to a protective signal, the ARC will attempt to reclose that
>>> breaker, sometimes more than once. At night, in a storm, you will see your
>>> lights dim for a second or two; that is an ARC operation. When a
>>> transformer has water in the oil or when a insulator is arching, or a power
>>> line is arching on the ground, these all result in very strange power
>>> behavior. In summary, power failure isn’t just an on or off problem, but a
>>> multitude of more problematic cases.
>>>
>>> Regards,
>>> John
>>>
>>>
>>> On 5/15/2016 3:37 PM, John Syne wrote:
>>>
>>>
>>> On May 15, 2016, at 3:14 PM, evilwulfie  wrote:
>>>
>>> We use an external msp430 for our intelligent watchdog
>>>
>>> So who or what monitors the MSP430? Since it is a micro-controller, it
>>> is easy to get it into a lock situation. All you need is a programable
>>> power supply which will ramp up and down the voltage into the
>>> micro-controller at predefined times and it will lock and become completely
>>> unresponsive. Granted this will rarely happen, but in our applications
>>> where 100K or more devices are installed, we cannot accept some devices
>>> locking up because of a power failure.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>> On 5/15/2016 1:07 PM, Super Twang wrote:
>>>
>>>
>>>
>>> I've just come across this conversation in my own search for a
>>> rock-solid, embeddable configuration for the BeagleBone Black.  I’m trying
>>> to develop an embedded controller device that needs to live behind walls,
>>> in ceilings and in other inaccessible places. ( It is for the automation of
>>> art & other electronic installations.)
>>>
>>> From what I gather here, the BBB is not quite up to the task, without an
>>> external watchdog circuit (please correct me if I’m misreading this thread).
>>>
>>> @John3909: Your suggestion of the GreenPak prompted my own discovery of
>>> that tech — it looks great, esp the ecosystem of tools around the platform.
>>>
>>> In looking around, I found some Silego application notes that implement
>>> a hardware watchdog for MCUs.
>>> http://www.silego.com/products/352/312/AN-1058.html  This might be a
>>> useful starting point for anyone using GreenPak for a hardware watchdog.
>>>
>>> @John3909: Does this design look like it might be a good fit for the
>>> BBB? (Not knowing how to read GreenPak internals, it is not obvious to me)
>>>
>>> Alternately, I'm wondering in the two years that have passed since this
>>> thread started, if anyone has developed a hardware watchdog design for the
>>> BBB they'd be willing to share.  An open-source hardware watchdog for the
>>> BBB would go a long way towards ameliorating the hardware issues with the
>>> PMIC on RevC, and allow it to prosper as a base for applications where
>>> long-term reliability matters.
>>>
>>> Although I’m first and foremost a software engineer, I've got some
>>> electronics chops (albeit mostly digital), but (sadly) very limited
>>> hardware design equipment (oscilloscope, etc).  [That said, I have iron,
>>

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread evilwulfie
yes correct. but as for powering the BBB back on you need a bit more
there than a user pressing the power button
a nice external micro works great. Remember if you have a LIPO battery
the BBB will not repower on after power is reapplied.



On 5/16/2016 12:54 PM, Gerald Coley wrote:
> Add a a battery or super CAP. When the DC voltage goes away, the
> processor gets and interrupt. When SW get interrupt unmount the Flash
> and power down.
> Invest in a real 5V power supply.
>
> Gerlad
>
> On Mon, May 16, 2016 at 2:51 PM, Micka  > wrote:
>
> Gerald what is your opinion on this subject ? 
>
>
> Le lun. 16 mai 2016 21:46, evilwulfie  > a écrit :
>
> spend 50 bux on a power supply to solve a 5 dollar problem 
> yeah right.
>
>
>
> On 5/16/2016 12:34 PM, John Syne wrote:
>>
>>> On May 15, 2016, at 4:25 PM, evilwulfie
>>> mailto:evilwul...@gmail.com>> wrote:
>>>
>>> msp430 has an internal watchdog
>> And so does the AM3358, so I’m not sure whats your point? If
>> it is a micro-controller, it is not guaranteed to boot up
>> successfully every time, given an unstable power supply. To
>> start with, you need to make the power supply more
>> predictable so that brown outs, dips and sags are not seen by
>> the micro-controller and that power down only occurs if the
>> input power fails for more than a specified time. Also, if
>> you do start a shutdown, then a full power cycle is needed in
>> a controlled manner. When input power returns, don’t boot
>> until the input power looks reliable. 
>>
>> This is where you need an understanding of how the power
>> utility network operates, which includes understanding how
>> protection operates, what an ARC (Automatic Reclosure Relays)
>> do, etc. For example, when a large breaker trips due to a
>> protective signal, the ARC will attempt to reclose that
>> breaker, sometimes more than once. At night, in a storm, you
>> will see your lights dim for a second or two; that is an ARC
>> operation. When a transformer has water in the oil or when a
>> insulator is arching, or a power line is arching on the
>> ground, these all result in very strange power behavior. In
>> summary, power failure isn’t just an on or off problem, but a
>> multitude of more problematic cases. 
>>
>> Regards,
>> John
>>>
>>> On 5/15/2016 3:37 PM, John Syne wrote:

> On May 15, 2016, at 3:14 PM, evilwulfie
> mailto:evilwul...@gmail.com>> wrote:
>
> We use an external msp430 for our intelligent watchdog
 So who or what monitors the MSP430? Since it is a
 micro-controller, it is easy to get it into a lock
 situation. All you need is a programable power supply which
 will ramp up and down the voltage into the micro-controller
 at predefined times and it will lock and become completely
 unresponsive. Granted this will rarely happen, but in our
 applications where 100K or more devices are installed, we
 cannot accept some devices locking up because of a power
 failure. 

 Regards,
 John
>
>
> On 5/15/2016 1:07 PM, Super Twang wrote:
>>
>>
>> I've just come across this conversation in my own search
>> for a rock-solid, embeddable configuration for the
>> BeagleBone Black.  I’m trying to develop an embedded
>> controller device that needs to live behind walls, in
>> ceilings and in other inaccessible places. ( It is for
>> the automation of art & other electronic installations.)
>>
>> From what I gather here, the BBB is not quite up to the
>> task, without an external watchdog circuit (please
>> correct me if I’m misreading this thread).
>>
>> @John3909: Your suggestion of the GreenPak prompted my
>> own discovery of that tech — it looks great, esp the
>> ecosystem of tools around the platform. 
>>
>> In looking around, I found some Silego application notes
>> that implement a hardware watchdog for MCUs.
>>  http://www.silego.com/products/352/312/AN-1058.html 
>> This might be a useful starting point for anyone using
>> GreenPak for a hardware watchdog.
>>
>> @John3909: Does this design look like it might be a good
>> fit for the BBB? (Not knowing how to read GreenPak
>> internals, it is not obvious to me)
>>
>> Alternately, I'm wondering in the two years that have
>> passed since this thread started, if anyone has deve

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Gerald Coley
Add a a battery or super CAP. When the DC voltage goes away, the processor
gets and interrupt. When SW get interrupt unmount the Flash and power down.
Invest in a real 5V power supply.

Gerlad

On Mon, May 16, 2016 at 2:51 PM, Micka  wrote:

> Gerald what is your opinion on this subject ?
>
>
> Le lun. 16 mai 2016 21:46, evilwulfie  a écrit :
>
>> spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.
>>
>>
>>
>> On 5/16/2016 12:34 PM, John Syne wrote:
>>
>>
>> On May 15, 2016, at 4:25 PM, evilwulfie < 
>> evilwul...@gmail.com> wrote:
>>
>> msp430 has an internal watchdog
>>
>> And so does the AM3358, so I’m not sure whats your point? If it is a
>> micro-controller, it is not guaranteed to boot up successfully every time,
>> given an unstable power supply. To start with, you need to make the power
>> supply more predictable so that brown outs, dips and sags are not seen by
>> the micro-controller and that power down only occurs if the input power
>> fails for more than a specified time. Also, if you do start a shutdown,
>> then a full power cycle is needed in a controlled manner. When input power
>> returns, don’t boot until the input power looks reliable.
>>
>> This is where you need an understanding of how the power utility network
>> operates, which includes understanding how protection operates, what an ARC
>> (Automatic Reclosure Relays) do, etc. For example, when a large breaker
>> trips due to a protective signal, the ARC will attempt to reclose that
>> breaker, sometimes more than once. At night, in a storm, you will see your
>> lights dim for a second or two; that is an ARC operation. When a
>> transformer has water in the oil or when a insulator is arching, or a power
>> line is arching on the ground, these all result in very strange power
>> behavior. In summary, power failure isn’t just an on or off problem, but a
>> multitude of more problematic cases.
>>
>> Regards,
>> John
>>
>>
>> On 5/15/2016 3:37 PM, John Syne wrote:
>>
>>
>> On May 15, 2016, at 3:14 PM, evilwulfie  wrote:
>>
>> We use an external msp430 for our intelligent watchdog
>>
>> So who or what monitors the MSP430? Since it is a micro-controller, it is
>> easy to get it into a lock situation. All you need is a programable power
>> supply which will ramp up and down the voltage into the micro-controller at
>> predefined times and it will lock and become completely unresponsive.
>> Granted this will rarely happen, but in our applications where 100K or more
>> devices are installed, we cannot accept some devices locking up because of
>> a power failure.
>>
>> Regards,
>> John
>>
>>
>>
>> On 5/15/2016 1:07 PM, Super Twang wrote:
>>
>>
>>
>> I've just come across this conversation in my own search for a
>> rock-solid, embeddable configuration for the BeagleBone Black.  I’m trying
>> to develop an embedded controller device that needs to live behind walls,
>> in ceilings and in other inaccessible places. ( It is for the automation of
>> art & other electronic installations.)
>>
>> From what I gather here, the BBB is not quite up to the task, without an
>> external watchdog circuit (please correct me if I’m misreading this thread).
>>
>> @John3909: Your suggestion of the GreenPak prompted my own discovery of
>> that tech — it looks great, esp the ecosystem of tools around the platform.
>>
>> In looking around, I found some Silego application notes that implement a
>> hardware watchdog for MCUs.
>> http://www.silego.com/products/352/312/AN-1058.html  This might be a
>> useful starting point for anyone using GreenPak for a hardware watchdog.
>>
>> @John3909: Does this design look like it might be a good fit for the BBB?
>> (Not knowing how to read GreenPak internals, it is not obvious to me)
>>
>> Alternately, I'm wondering in the two years that have passed since this
>> thread started, if anyone has developed a hardware watchdog design for the
>> BBB they'd be willing to share.  An open-source hardware watchdog for the
>> BBB would go a long way towards ameliorating the hardware issues with the
>> PMIC on RevC, and allow it to prosper as a base for applications where
>> long-term reliability matters.
>>
>> Although I’m first and foremost a software engineer, I've got some
>> electronics chops (albeit mostly digital), but (sadly) very limited
>> hardware design equipment (oscilloscope, etc).  [That said, I have iron,
>> and will solder!]  I’d be happy to develop & contribute the software
>> components for such a system (I’d envision a library + device tree overlay)
>> if someone(s) else would like to partner up to design the hardware side.
>>
>> Best,
>>
>> ST
>>
>> --
>> For more options, visit 
>> http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discus

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread John Syne
I guess it is all about prospective. Perhaps for your application you are 
right. However, if you have 10K or 100K or more devices installed, and now you 
have to recall them all because they keep on going offline, then it isn’t a $5 
problem.

Regards,
John




> On May 16, 2016, at 12:46 PM, evilwulfie  wrote:
> 
> spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.
> 
> 
> On 5/16/2016 12:34 PM, John Syne wrote:
>> 
>>> On May 15, 2016, at 4:25 PM, evilwulfie < 
>>> evilwul...@gmail.com 
>>> > wrote:
>>> 
>>> msp430 has an internal watchdog
>> And so does the AM3358, so I’m not sure whats your point? If it is a 
>> micro-controller, it is not guaranteed to boot up successfully every time, 
>> given an unstable power supply. To start with, you need to make the power 
>> supply more predictable so that brown outs, dips and sags are not seen by 
>> the micro-controller and that power down only occurs if the input power 
>> fails for more than a specified time. Also, if you do start a shutdown, then 
>> a full power cycle is needed in a controlled manner. When input power 
>> returns, don’t boot until the input power looks reliable. 
>> 
>> This is where you need an understanding of how the power utility network 
>> operates, which includes understanding how protection operates, what an ARC 
>> (Automatic Reclosure Relays) do, etc. For example, when a large breaker 
>> trips due to a protective signal, the ARC will attempt to reclose that 
>> breaker, sometimes more than once. At night, in a storm, you will see your 
>> lights dim for a second or two; that is an ARC operation. When a transformer 
>> has water in the oil or when a insulator is arching, or a power line is 
>> arching on the ground, these all result in very strange power behavior. In 
>> summary, power failure isn’t just an on or off problem, but a 
>> multitude of more problematic cases. 
>> 
>> Regards,
>> John
>>> 
>>> On 5/15/2016 3:37 PM, John Syne wrote:
 
> On May 15, 2016, at 3:14 PM, evilwulfie  > wrote:
> 
> We use an external msp430 for our intelligent watchdog
 So who or what monitors the MSP430? Since it is a micro-controller, it is 
 easy to get it into a lock situation. All you need is a programable power 
 supply which will ramp up and down the voltage into the micro-controller 
 at predefined times and it will lock and become completely unresponsive. 
 Granted this will rarely happen, but in our applications where 100K or 
 more devices are installed, we cannot accept some devices locking up 
 because of a power failure. 
 
 Regards,
 John
> 
> 
> On 5/15/2016 1:07 PM, Super Twang wrote:
>> 
>> 
>> I've just come across this conversation in my own search for a 
>> rock-solid, embeddable configuration for the BeagleBone Black.  I’m 
>> trying to develop an embedded controller device that needs to live 
>> behind walls, in ceilings and in other inaccessible places. ( It is for 
>> the automation of art & other electronic installations.)
>> 
>> From what I gather here, the BBB is not quite up to the task, without an 
>> external watchdog circuit (please correct me if I’m misreading this 
>> thread).
>> 
>> @John3909: Your suggestion of the GreenPak prompted my own discovery of 
>> that tech — it looks great, esp the ecosystem of tools around the 
>> platform. 
>> 
>> In looking around, I found some Silego application notes that implement 
>> a hardware watchdog for MCUs.  
>> http://www.silego.com/products/352/312/AN-1058.html 
>>   This might be a 
>> useful starting point for anyone using GreenPak for a hardware watchdog.
>> 
>> @John3909: Does this design look like it might be a good fit for the 
>> BBB? (Not knowing how to read GreenPak internals, it is not obvious to 
>> me)
>> 
>> Alternately, I'm wondering in the two years that have passed since this 
>> thread started, if anyone has developed a hardware watchdog design for 
>> the BBB they'd be willing to share.  An open-source hardware watchdog 
>> for the BBB would go a long way towards ameliorating the hardware issues 
>> with the PMIC on RevC, and allow it to prosper as a base for 
>> applications where long-term reliability matters.
>> 
>> Although I’m first and foremost a software engineer, I've got some 
>> electronics chops (albeit mostly digital), but (sadly) very limited 
>> hardware design equipment (oscilloscope, etc).  [That said, I have iron, 
>> and will solder!]  I’d be happy to develop & contribute the software 
>> components for such a system (I’d envision a library + device tree 
>> overlay) if someone(s) else would like to partner up to design the 
>> hardware

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Micka
Gerald what is your opinion on this subject ?

Le lun. 16 mai 2016 21:46, evilwulfie  a écrit :

> spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.
>
>
>
> On 5/16/2016 12:34 PM, John Syne wrote:
>
>
> On May 15, 2016, at 4:25 PM, evilwulfie < 
> evilwul...@gmail.com> wrote:
>
> msp430 has an internal watchdog
>
> And so does the AM3358, so I’m not sure whats your point? If it is a
> micro-controller, it is not guaranteed to boot up successfully every time,
> given an unstable power supply. To start with, you need to make the power
> supply more predictable so that brown outs, dips and sags are not seen by
> the micro-controller and that power down only occurs if the input power
> fails for more than a specified time. Also, if you do start a shutdown,
> then a full power cycle is needed in a controlled manner. When input power
> returns, don’t boot until the input power looks reliable.
>
> This is where you need an understanding of how the power utility network
> operates, which includes understanding how protection operates, what an ARC
> (Automatic Reclosure Relays) do, etc. For example, when a large breaker
> trips due to a protective signal, the ARC will attempt to reclose that
> breaker, sometimes more than once. At night, in a storm, you will see your
> lights dim for a second or two; that is an ARC operation. When a
> transformer has water in the oil or when a insulator is arching, or a power
> line is arching on the ground, these all result in very strange power
> behavior. In summary, power failure isn’t just an on or off problem, but a
> multitude of more problematic cases.
>
> Regards,
> John
>
>
> On 5/15/2016 3:37 PM, John Syne wrote:
>
>
> On May 15, 2016, at 3:14 PM, evilwulfie  wrote:
>
> We use an external msp430 for our intelligent watchdog
>
> So who or what monitors the MSP430? Since it is a micro-controller, it is
> easy to get it into a lock situation. All you need is a programable power
> supply which will ramp up and down the voltage into the micro-controller at
> predefined times and it will lock and become completely unresponsive.
> Granted this will rarely happen, but in our applications where 100K or more
> devices are installed, we cannot accept some devices locking up because of
> a power failure.
>
> Regards,
> John
>
>
>
> On 5/15/2016 1:07 PM, Super Twang wrote:
>
>
>
> I've just come across this conversation in my own search for a rock-solid,
> embeddable configuration for the BeagleBone Black.  I’m trying to develop
> an embedded controller device that needs to live behind walls, in ceilings
> and in other inaccessible places. ( It is for the automation of art & other
> electronic installations.)
>
> From what I gather here, the BBB is not quite up to the task, without an
> external watchdog circuit (please correct me if I’m misreading this thread).
>
> @John3909: Your suggestion of the GreenPak prompted my own discovery of
> that tech — it looks great, esp the ecosystem of tools around the platform.
>
> In looking around, I found some Silego application notes that implement a
> hardware watchdog for MCUs.
> http://www.silego.com/products/352/312/AN-1058.html  This might be a
> useful starting point for anyone using GreenPak for a hardware watchdog.
>
> @John3909: Does this design look like it might be a good fit for the BBB?
> (Not knowing how to read GreenPak internals, it is not obvious to me)
>
> Alternately, I'm wondering in the two years that have passed since this
> thread started, if anyone has developed a hardware watchdog design for the
> BBB they'd be willing to share.  An open-source hardware watchdog for the
> BBB would go a long way towards ameliorating the hardware issues with the
> PMIC on RevC, and allow it to prosper as a base for applications where
> long-term reliability matters.
>
> Although I’m first and foremost a software engineer, I've got some
> electronics chops (albeit mostly digital), but (sadly) very limited
> hardware design equipment (oscilloscope, etc).  [That said, I have iron,
> and will solder!]  I’d be happy to develop & contribute the software
> components for such a system (I’d envision a library + device tree overlay)
> if someone(s) else would like to partner up to design the hardware side.
>
> Best,
>
> ST
>
> --
> For more options, visit 
> http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/d/optout.
>
>
>
> --
> For more

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread evilwulfie
spend 50 bux on a power supply to solve a 5 dollar problem  yeah right.


On 5/16/2016 12:34 PM, John Syne wrote:
>
>> On May 15, 2016, at 4:25 PM, evilwulfie > > wrote:
>>
>> msp430 has an internal watchdog
> And so does the AM3358, so I’m not sure whats your point? If it is a
> micro-controller, it is not guaranteed to boot up successfully every
> time, given an unstable power supply. To start with, you need to make
> the power supply more predictable so that brown outs, dips and sags
> are not seen by the micro-controller and that power down only occurs
> if the input power fails for more than a specified time. Also, if you
> do start a shutdown, then a full power cycle is needed in a controlled
> manner. When input power returns, don’t boot until the input power
> looks reliable. 
>
> This is where you need an understanding of how the power utility
> network operates, which includes understanding how protection
> operates, what an ARC (Automatic Reclosure Relays) do, etc. For
> example, when a large breaker trips due to a protective signal, the
> ARC will attempt to reclose that breaker, sometimes more than once. At
> night, in a storm, you will see your lights dim for a second or two;
> that is an ARC operation. When a transformer has water in the oil or
> when a insulator is arching, or a power line is arching on the ground,
> these all result in very strange power behavior. In summary, power
> failure isn’t just an on or off problem, but a multitude of more
> problematic cases. 
>
> Regards,
> John
>>
>> On 5/15/2016 3:37 PM, John Syne wrote:
>>>
 On May 15, 2016, at 3:14 PM, evilwulfie  wrote:

 We use an external msp430 for our intelligent watchdog
>>> So who or what monitors the MSP430? Since it is a micro-controller,
>>> it is easy to get it into a lock situation. All you need is a
>>> programable power supply which will ramp up and down the voltage
>>> into the micro-controller at predefined times and it will lock and
>>> become completely unresponsive. Granted this will rarely happen, but
>>> in our applications where 100K or more devices are installed, we
>>> cannot accept some devices locking up because of a power failure. 
>>>
>>> Regards,
>>> John


 On 5/15/2016 1:07 PM, Super Twang wrote:
>
>
> I've just come across this conversation in my own search for a
> rock-solid, embeddable configuration for the BeagleBone Black.
>  I’m trying to develop an embedded controller device that needs to
> live behind walls, in ceilings and in other inaccessible places. (
> It is for the automation of art & other electronic installations.)
>
> From what I gather here, the BBB is not quite up to the task,
> without an external watchdog circuit (please correct me if I’m
> misreading this thread).
>
> @John3909: Your suggestion of the GreenPak prompted my own
> discovery of that tech — it looks great, esp the ecosystem of
> tools around the platform. 
>
> In looking around, I found some Silego application notes that
> implement a hardware watchdog for MCUs.
>  http://www.silego.com/products/352/312/AN-1058.html  This might
> be a useful starting point for anyone using GreenPak for a
> hardware watchdog.
>
> @John3909: Does this design look like it might be a good fit for
> the BBB? (Not knowing how to read GreenPak internals, it is not
> obvious to me)
>
> Alternately, I'm wondering in the two years that have passed since
> this thread started, if anyone has developed a hardware watchdog
> design for the BBB they'd be willing to share.  An open-source
> hardware watchdog for the BBB would go a long way towards
> ameliorating the hardware issues with the PMIC on RevC, and allow
> it to prosper as a base for applications where long-term
> reliability matters.
>
> Although I’m first and foremost a software engineer, I've got some
> electronics chops (albeit mostly digital), but (sadly) very
> limited hardware design equipment (oscilloscope, etc).  [That
> said, I have iron, and will solder!]  I’d be happy to develop &
> contribute the software components for such a system (I’d envision
> a library + device tree overlay) if someone(s) else would like to
> partner up to design the hardware side.
>
> Best,
>
> ST
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com.
> For more options, visit https://g

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
The thing is: The PMIC already sends an interrupt when input voltage drops
under 5V.  Same as when the power button is pressed. Aside from losing USB
until you reboot, this is not the problem. Then problem is when you have
power connected, and issue a shutdown now -h( or halt ). The board will be
stuck until it is hard reset. This also occasionally happen when issuing
shutdown now -r( reboot ). There is no pin out for the hard reset line on
the processor. So we're forced to make due by completely disconnecting
power.

In cases where power goes away all together, this again is not a problem.
But when one uses a battery, the board will have power for hours. So a
bullet proof solution needs a GPIO + power relay to completely disconnect
power good for a few seconds. Otherwise you'll be stuck for up to several
hours without a running system.

So again, the smart move is to use a low cost, low power MCU to handle all
of this automatically. For remote applications. If the board is sitting on
your desk, then the application is no big deal anyway, as well as giving
you the ability to physically remove power yourself. At a remote site
however . . .

Anyway, you all can debate all this until you're blue in the face. I know
what the issues are because we've discussed, and have tested for all these
situations. So do as you please.

On Mon, May 16, 2016 at 12:09 PM, evilwulfie  wrote:

> not enough time for a clean shutdown
>
>
>
> On 5/16/2016 9:41 AM, 'Mark Lazarewicz' via BeagleBoard wrote:
>
> Exactly.  These cheap external chips have a rc time constant and are
> pulsed by a GPIO . Output can generate an Interrupt back to Bbb to save
> important data.
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, May 16, 2016 at 3:50 AM, Micka
>   wrote:
> You dont need an external microcontroller  Some watchdog from Texas do
> a good job like the uccx946.
>
> Le lun. 16 mai 2016 09:01, arsi  a écrit :
>
>> Hi,
>>
>> I use this:
>>
>>
>>
>>
>>
>> PIC 10F200 source code:
>>
>> /*
>>File:   main.c
>>Author: arsi
>>
>>Created on May 22, 2015, 10:32 AM
>>  */#include #include #include #define _XTAL_FREQ 
>> 400#pragma config WDTE = ON// Watchdog Timer (WDT 
>> enabled)#pragma config CP = OFF // Code Protect (Code protection 
>> off)#pragma config MCLRE = OFF  // Master Clear Enable (GP3/MCLR pin 
>> fuction is digital I/O, MCLR internally tied to VDD)
>> void delay1() {
>> __delay_ms(1000);
>> }bool flag = false;int counter = 0;
>> void main(void) {#asm
>> CLRWDT
>> CLRF TMR0
>> CLRWDT
>> MOVLW 0b
>> OPTION#endasm
>> CLRWDT();
>> TRIS = 0b1110;
>> CLRWDT();
>> GP0 = 0;
>> __delay_ms(500);
>> CLRWDT();
>> TRIS = 0b;
>> CLRWDT();
>> //pause for BBB boot up
>> for (int i = 0; i < 120; i++) {
>> delay1();
>> CLRWDT();
>> }
>> counter = 0;
>> while (true) {
>> delay1();
>> if (counter < 120) {
>> CLRWDT();
>> }
>> if (flag != GP1) {
>> counter = 0;
>> flag = GP1;
>> } else {
>> counter++;
>> }
>>
>> }
>> }
>>
>>
>>
>> ***
>> wd script on BBB:
>>
>> #!/bin/bash
>> sleep 10
>> echo 60 > /sys/class/gpio/export
>> echo "out" > /sys/class/gpio/gpio60/directionwhile :do
>> echo "0" > /sys/class/gpio/gpio60/value
>> sleep 1
>> echo "1" > /sys/class/gpio/gpio60/value
>> sleep 1
>>
>> done
>>
>>
>>
>> ***
>>
>> Arsi
>>
>> --
>>
>> *From:* Kb2pnm
>> *Sent:* Saturday, March 22, 2014 6:08PM
>> *To:* Beagleboard
>> *Subject:* [beagleboard] Hardware watchdog for BBB
>>
>>
>> HI, I have been working for a wile on safe power supply for BBB with
>> backup power provided by supercapacitors. In case of power failure there
>> is  just enough  time to safely and nicely shut down BBB. For some reason
>> BBB does not always wake up fully. I need hardware dogwatch. Did anybody
>> design such a thing? I was able to find some design for ardunio:
>> http://www.playwitharduino.com/?p=291.
>> Anybody has any experience with hardware dogwatch for BBB??
>> Thanks in advance
>> Robert
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe fr

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread John Syne

> On May 15, 2016, at 4:25 PM, evilwulfie  wrote:
> 
> msp430 has an internal watchdog
And so does the AM3358, so I’m not sure whats your point? If it is a 
micro-controller, it is not guaranteed to boot up successfully every time, 
given an unstable power supply. To start with, you need to make the power 
supply more predictable so that brown outs, dips and sags are not seen by the 
micro-controller and that power down only occurs if the input power fails for 
more than a specified time. Also, if you do start a shutdown, then a full power 
cycle is needed in a controlled manner. When input power returns, don’t boot 
until the input power looks reliable. 

This is where you need an understanding of how the power utility network 
operates, which includes understanding how protection operates, what an ARC 
(Automatic Reclosure Relays) do, etc. For example, when a large breaker trips 
due to a protective signal, the ARC will attempt to reclose that breaker, 
sometimes more than once. At night, in a storm, you will see your lights dim 
for a second or two; that is an ARC operation. When a transformer has water in 
the oil or when a insulator is arching, or a power line is arching on the 
ground, these all result in very strange power behavior. In summary, power 
failure isn’t just an on or off problem, but a multitude of more problematic 
cases. 

Regards,
John
> 
> On 5/15/2016 3:37 PM, John Syne wrote:
>> 
>>> On May 15, 2016, at 3:14 PM, evilwulfie < 
>>> evilwul...@gmail.com 
>>> > wrote:
>>> 
>>> We use an external msp430 for our intelligent watchdog
>> So who or what monitors the MSP430? Since it is a micro-controller, it is 
>> easy to get it into a lock situation. All you need is a programable power 
>> supply which will ramp up and down the voltage into the micro-controller at 
>> predefined times and it will lock and become completely unresponsive. 
>> Granted this will rarely happen, but in our applications where 100K or more 
>> devices are installed, we cannot accept some devices locking up because of a 
>> power failure. 
>> 
>> Regards,
>> John
>>> 
>>> 
>>> On 5/15/2016 1:07 PM, Super Twang wrote:
 
 
 I've just come across this conversation in my own search for a rock-solid, 
 embeddable configuration for the BeagleBone Black.  I’m trying to develop 
 an embedded controller device that needs to live behind walls, in ceilings 
 and in other inaccessible places. ( It is for the automation of art & 
 other electronic installations.)
 
 From what I gather here, the BBB is not quite up to the task, without an 
 external watchdog circuit (please correct me if I’m misreading this 
 thread).
 
 @John3909: Your suggestion of the GreenPak prompted my own discovery of 
 that tech — it looks great, esp the ecosystem of tools around the 
 platform. 
 
 In looking around, I found some Silego application notes that implement a 
 hardware watchdog for MCUs.   
 http://www.silego.com/products/352/312/AN-1058.html
    This might be a 
 useful starting point for anyone using GreenPak for a hardware watchdog.
 
 @John3909: Does this design look like it might be a good fit for the BBB? 
 (Not knowing how to read GreenPak internals, it is not obvious to me)
 
 Alternately, I'm wondering in the two years that have passed since this 
 thread started, if anyone has developed a hardware watchdog design for the 
 BBB they'd be willing to share.  An open-source hardware watchdog for the 
 BBB would go a long way towards ameliorating the hardware issues with the 
 PMIC on RevC, and allow it to prosper as a base for applications where 
 long-term reliability matters.
 
 Although I’m first and foremost a software engineer, I've got some 
 electronics chops (albeit mostly digital), but (sadly) very limited 
 hardware design equipment (oscilloscope, etc).  [That said, I have iron, 
 and will solder!]  I’d be happy to develop & contribute the software 
 components for such a system (I’d envision a library + device tree 
 overlay) if someone(s) else would like to partner up to design the 
 hardware side.
 
 Best,
 
 ST
 
 -- 
 For more options, visit http://beagleboard.org/discuss 
 
 --- 
 You received this message because you are subscribed to the Google Groups 
 "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard+unsubscr...@googlegroups.com 
 .
 To view this discussion on the web visit  
 https://gro

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread evilwulfie
not enough time for a clean shutdown


On 5/16/2016 9:41 AM, 'Mark Lazarewicz' via BeagleBoard wrote:
> Exactly.  These cheap external chips have a rc time constant and are
> pulsed by a GPIO . Output can generate an Interrupt back to Bbb to
> save important data. 
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, May 16, 2016 at 3:50 AM, Micka
>  wrote:
>
> You dont need an external microcontroller  Some watchdog from
> Texas do a good job like the uccx946. 
>
> Le lun. 16 mai 2016 09:01, arsi  > a écrit :
>
> Hi,
>
> I use this:
>
>
>
>
>
> PIC 10F200 source code:
>
> /* File: main.c Author: arsi Created on May 22, 2015, 10:32 AM */
> #include 
> #include 
> #include 
> #define _XTAL_FREQ 400
> #pragma config WDTE = ON// Watchdog Timer (WDT enabled)
> #pragma config CP = OFF // Code Protect (Code protection off)
> #pragma config MCLRE = OFF  // Master Clear Enable (GP3/MCLR pin 
> fuction is digital I/O,
> MCLR internally tied to VDD)
>
> void delay1() {
> __delay_ms(1000);
> }
> bool flag = false;
> int counter = 0;
>
> void main(void) {
> #asm
> CLRWDT
> CLRF TMR0
> CLRWDT
> MOVLW 0b
> OPTION
> #endasm
> CLRWDT();
> TRIS = 0b1110;
> CLRWDT();
> GP0 = 0;
> __delay_ms(500);
> CLRWDT();
> TRIS = 0b;
> CLRWDT();
> //pause for BBB boot up 
> for (int i = 0; i < 120; i++) {
> delay1();
> CLRWDT();
> }
> counter = 0;
> while (true) {
> delay1();
> if (counter < 120) {
> CLRWDT();
> }
> if (flag != GP1) {
> counter = 0;
> flag = GP1;
> } else {
> counter++;
> }
>
> }
> }
>
>
> 
> ***
> wd script on BBB:
>
> #!/bin/bash
> sleep 10
> echo 60 > /sys/class/gpio/export
> echo "out" > /sys/class/gpio/gpio60/direction
> while :
> do
> echo "0" > /sys/class/gpio/gpio60/value
> sleep 1
> echo "1" > /sys/class/gpio/gpio60/value
> sleep 1
>
> done
>
>
> 
> ***
>
> Arsi
>
> 
> 
>
> *From:* Kb2pnm
> *Sent:* Saturday, March 22, 2014 6:08PM
> *To:* Beagleboard
> *Subject:* [beagleboard] Hardware watchdog for BBB
>
>
> HI, I have been working for a wile on safe power supply for
> BBB with backup power provided by supercapacitors. In case of
> power failure there is  just enough  time to safely and nicely
> shut down BBB. For some reason BBB does not always wake up
> fully. I need hardware dogwatch. Did anybody design such a
> thing? I was able to find some design for ardunio:
> http://www.playwitharduino.com/?p=291.
> Anybody has any experience with hardware dogwatch for BBB??
> Thanks in advance
> Robert
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to beagleboard+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
>
>
>  
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/57397009.205%40chello.sk
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "Beagle

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread 'Mark Lazarewicz' via BeagleBoard
Exactly.  These cheap external chips have a rc time constant and are pulsed by 
a GPIO . Output can generate an Interrupt back to Bbb to save important data. 

Sent from Yahoo Mail on Android 
 
  On Mon, May 16, 2016 at 3:50 AM, Micka wrote:   You 
dont need an external microcontroller  Some watchdog from Texas do a good 
job like the uccx946. 
Le lun. 16 mai 2016 09:01, arsi  a écrit :

  Hi,
 
 I use this:
 
 
 
 
 
 PIC 10F200 source code:
 
  /*
   File:   main.c
   Author: arsi

   Created on May 22, 2015, 10:32 AM
 */
#include 
#include 
#include 
#define _XTAL_FREQ 400
#pragma config WDTE = ON// Watchdog Timer (WDT enabled)
#pragma config CP = OFF // Code Protect (Code protection off)
#pragma config MCLRE = OFF  // Master Clear Enable (GP3/MCLR pin fuction is 
digital I/O, MCLR internally tied to VDD)

void delay1() {
__delay_ms(1000);
}
bool flag = false;
int counter = 0;

void main(void) {
#asm
CLRWDT
CLRF TMR0
CLRWDT
MOVLW 0b
OPTION
#endasm
CLRWDT();
TRIS = 0b1110;
CLRWDT();
GP0 = 0;
__delay_ms(500);
CLRWDT();
TRIS = 0b;
CLRWDT();
//pause for BBB boot up 
for (int i = 0; i < 120; i++) {
delay1();
CLRWDT();
}
counter = 0;
while (true) {
delay1();
if (counter < 120) {
CLRWDT();
}
if (flag != GP1) {
counter = 0;
flag = GP1;
} else {
counter++;
}

}
} 
 
***
 wd script on BBB:
 
 #!/bin/bash
sleep 10
echo 60 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio60/direction
while :
do
echo "0" > /sys/class/gpio/gpio60/value
sleep 1
echo "1" > /sys/class/gpio/gpio60/value
sleep 1

done 
***
 
 Arsi
 
 
 From: Kb2pnm
 Sent: Saturday, March 22, 2014 6:08PM
 To: Beagleboard
 Subject: [beagleboard] Hardware watchdog for BBB
 
 
  HI, I have been working for a wile on safe power supply for BBB with backup 
power provided by supercapacitors. In case of power failure there is  just 
enough  time to safely and nicely shut down BBB. For some reason BBB does not 
always wake up fully. I need hardware dogwatch. Did anybody design such a 
thing? I was able to find some design for ardunio: 
http://www.playwitharduino.com/?p=291. 
 Anybody has any experience with hardware dogwatch for BBB??
 Thanks in advance 
 Robert 
  -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
email to beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 
 
 
 
   

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57397009.205%40chello.sk.
For more options, visit https://groups.google.com/d/optout.



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtmfNSrCXk-egMpz-gGqzjt%3D8qRgsrzv2FbrQUqrLAw0Lw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/587089779.3315783.1463416888133.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread William Hermans
Last time we bought MSP430G2553's we paid $1.35 USD each for 10. Right now,
it lots of 1ku they sell for around $1 USD each. So I would imagine $2 USD
each for lots less than 100 would not be unreasonable.

So, I do not know what the UCCx946 is capable of. But we looked into using
an external watch dog, and it was not good enough.

#1 a watch dog can not tell if input power is 5V or not.

#2 You need to completely disconnect power, especially when having a
battery hooked up. To get the beaglebone to "hard reset". A watch dog can
not do this.

#3 perhaps a watch dog can toggle reset, but either way this is required.


On Mon, May 16, 2016 at 1:05 AM, arsi  wrote:

> Hi,
>
> The difference is  in the price UCC2946 3.35 EUR and PIC10F200T-I/OT
> 0.462 EUR
>
> And microprocessor can be programmed just like I need..
>
> --
>
> *From:* Micka
> *Sent:* Monday, May 16, 2016 9:50AM
> *To:* Beagleboard, Gerald Coley
> *Subject:* Re: [beagleboard] Hardware watchdog for BBB
>
>
> You dont need an external microcontroller  Some watchdog from Texas do
> a good job like the uccx946.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/57397F2C.80609%40chello.sk
> <https://groups.google.com/d/msgid/beagleboard/57397F2C.80609%40chello.sk?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpWsrLY2cgD7_qZzGCbaprQS%3DeLUQwnHMUz%2B5z%3DDZSE5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread arsi

Hi,

The difference is in the price UCC2946 3.35 EUR and PIC10F200T-I/OT 
0.462 EUR


And microprocessor can be programmed just like I need..



*From:* Micka
*Sent:* Monday, May 16, 2016 9:50AM
*To:* Beagleboard, Gerald Coley
*Subject:* Re: [beagleboard] Hardware watchdog for BBB


You dont need an external microcontroller  Some watchdog from Texas 
do a good job like the uccx946.


--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57397F2C.80609%40chello.sk.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Micka
The UCCx946 is designed to provide accurate microprocessor supervision,
including reset and watchdog functions. During power up, the device asserts
a reset signal RES with VDD as low as 1 V. The reset signal remains
asserted until the VDD voltage rises and remains above the reset threshold
for the reset period. Both reset threshold and reset period are
programmable by the user.

The UCCx946 is also resistant to glitches on the VDD line. Once RES has
been deasserted, any drops below the threshold voltage need to be of
certain time duration and voltage magnitude to generate a reset signal.
These values are shown in Figure 1. An I/O line of the microprocessor may
be tied to the watchdog input (WDI) for watchdog functions. If the I/O line
is not toggled within a set watchdog period, programmable by the user, WDO
is asserted. The watchdog function is disabled during reset condition

Le lun. 16 mai 2016 09:50, Micka  a écrit :

> You dont need an external microcontroller  Some watchdog from Texas do
> a good job like the uccx946.
>
> Le lun. 16 mai 2016 09:01, arsi  a écrit :
>
>> Hi,
>>
>> I use this:
>>
>>
>>
>>
>>
>> PIC 10F200 source code:
>>
>> /*
>>File:   main.c
>>Author: arsi
>>
>>Created on May 22, 2015, 10:32 AM
>>  */#include #include #include #define _XTAL_FREQ 
>> 400#pragma config WDTE = ON// Watchdog Timer (WDT 
>> enabled)#pragma config CP = OFF // Code Protect (Code protection 
>> off)#pragma config MCLRE = OFF  // Master Clear Enable (GP3/MCLR pin 
>> fuction is digital I/O, MCLR internally tied to VDD)
>> void delay1() {
>> __delay_ms(1000);
>> }bool flag = false;int counter = 0;
>> void main(void) {#asm
>> CLRWDT
>> CLRF TMR0
>> CLRWDT
>> MOVLW 0b
>> OPTION#endasm
>> CLRWDT();
>> TRIS = 0b1110;
>> CLRWDT();
>> GP0 = 0;
>> __delay_ms(500);
>> CLRWDT();
>> TRIS = 0b;
>> CLRWDT();
>> //pause for BBB boot up
>> for (int i = 0; i < 120; i++) {
>> delay1();
>> CLRWDT();
>> }
>> counter = 0;
>> while (true) {
>> delay1();
>> if (counter < 120) {
>> CLRWDT();
>> }
>> if (flag != GP1) {
>> counter = 0;
>> flag = GP1;
>> } else {
>> counter++;
>> }
>>
>> }
>> }
>>
>>
>>
>> ***
>> wd script on BBB:
>>
>> #!/bin/bash
>> sleep 10
>> echo 60 > /sys/class/gpio/export
>> echo "out" > /sys/class/gpio/gpio60/directionwhile :do
>> echo "0" > /sys/class/gpio/gpio60/value
>> sleep 1
>> echo "1" > /sys/class/gpio/gpio60/value
>> sleep 1
>>
>> done
>>
>>
>>
>> ***
>>
>> Arsi
>>
>> --
>>
>> *From:* Kb2pnm
>> *Sent:* Saturday, March 22, 2014 6:08PM
>> *To:* Beagleboard
>> *Subject:* [beagleboard] Hardware watchdog for BBB
>>
>>
>> HI, I have been working for a wile on safe power supply for BBB with
>> backup power provided by supercapacitors. In case of power failure there
>> is  just enough  time to safely and nicely shut down BBB. For some reason
>> BBB does not always wake up fully. I need hardware dogwatch. Did anybody
>> design such a thing? I was able to find some design for ardunio:
>> http://www.playwitharduino.com/?p=291.
>> Anybody has any experience with hardware dogwatch for BBB??
>> Thanks in advance
>> Robert
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/57397009.205%40chello.sk
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtkm9n5fjiJsnABYL%2BJ%3DGiJO91RM_uKAwE8Lxa4b-osnBg%40mail.gmail.com.
For mo

Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread Micka
You dont need an external microcontroller  Some watchdog from Texas do
a good job like the uccx946.

Le lun. 16 mai 2016 09:01, arsi  a écrit :

> Hi,
>
> I use this:
>
>
>
>
>
> PIC 10F200 source code:
>
> /*
>File:   main.c
>Author: arsi
>
>Created on May 22, 2015, 10:32 AM
>  */#include #include #include #define _XTAL_FREQ 
> 400#pragma config WDTE = ON// Watchdog Timer (WDT enabled)#pragma 
> config CP = OFF // Code Protect (Code protection off)#pragma config 
> MCLRE = OFF  // Master Clear Enable (GP3/MCLR pin fuction is digital I/O, 
> MCLR internally tied to VDD)
> void delay1() {
> __delay_ms(1000);
> }bool flag = false;int counter = 0;
> void main(void) {#asm
> CLRWDT
> CLRF TMR0
> CLRWDT
> MOVLW 0b
> OPTION#endasm
> CLRWDT();
> TRIS = 0b1110;
> CLRWDT();
> GP0 = 0;
> __delay_ms(500);
> CLRWDT();
> TRIS = 0b;
> CLRWDT();
> //pause for BBB boot up
> for (int i = 0; i < 120; i++) {
> delay1();
> CLRWDT();
> }
> counter = 0;
> while (true) {
> delay1();
> if (counter < 120) {
> CLRWDT();
> }
> if (flag != GP1) {
> counter = 0;
> flag = GP1;
> } else {
> counter++;
> }
>
> }
> }
>
>
>
> ***
> wd script on BBB:
>
> #!/bin/bash
> sleep 10
> echo 60 > /sys/class/gpio/export
> echo "out" > /sys/class/gpio/gpio60/directionwhile :do
> echo "0" > /sys/class/gpio/gpio60/value
> sleep 1
> echo "1" > /sys/class/gpio/gpio60/value
> sleep 1
>
> done
>
>
>
> ***
>
> Arsi
>
> --
>
> *From:* Kb2pnm
> *Sent:* Saturday, March 22, 2014 6:08PM
> *To:* Beagleboard
> *Subject:* [beagleboard] Hardware watchdog for BBB
>
>
> HI, I have been working for a wile on safe power supply for BBB with
> backup power provided by supercapacitors. In case of power failure there
> is  just enough  time to safely and nicely shut down BBB. For some reason
> BBB does not always wake up fully. I need hardware dogwatch. Did anybody
> design such a thing? I was able to find some design for ardunio:
> http://www.playwitharduino.com/?p=291.
> Anybody has any experience with hardware dogwatch for BBB??
> Thanks in advance
> Robert
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
>
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/57397009.205%40chello.sk
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtmfNSrCXk-egMpz-gGqzjt%3D8qRgsrzv2FbrQUqrLAw0Lw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-16 Thread arsi

Hi,

I use this:





PIC 10F200 source code:

/*
   File:   main.c
   Author: arsi

   Created on May 22, 2015, 10:32 AM
 */
#include  
#include  
#include  
#define  _XTAL_FREQ 400
#pragma  config WDTE = ON// Watchdog Timer (WDT enabled)
#pragma  config CP = OFF// Code Protect (Code protection off)
#pragma  config MCLRE = OFF// Master Clear Enable (GP3/MCLR pin fuction is 
digital I/O, MCLR internally tied to VDD)

void  delay1() {
__delay_ms(1000);
}
bool  flag =false;
int  counter = 0;

void  main(void) {
#asm
CLRWDT
CLRF TMR0
CLRWDT
MOVLW 0b
OPTION
#endasm
CLRWDT();
TRIS = 0b1110;
CLRWDT();
GP0 = 0;
__delay_ms(500);
CLRWDT();
TRIS = 0b;
CLRWDT();
//pause for BBB boot up  
for  (int  i = 0; i < 120; i++) {

delay1();
CLRWDT();
}
counter = 0;
while  (true) {
delay1();
if  (counter < 120) {
CLRWDT();
}
if  (flag != GP1) {
counter = 0;
flag = GP1;
}else  {
counter++;
}

}
}


***
wd script on BBB:

#!/bin/bash
sleep 10
echo 60 > /sys/class/gpio/export
echo"out"  > /sys/class/gpio/gpio60/direction
while  :
do
echo"0"  > /sys/class/gpio/gpio60/value
sleep 1
echo"1"  > /sys/class/gpio/gpio60/value
sleep 1

done


***

Arsi



*From:* Kb2pnm
*Sent:* Saturday, March 22, 2014 6:08PM
*To:* Beagleboard
*Subject:* [beagleboard] Hardware watchdog for BBB


HI, I have been working for a wile on safe power supply for BBB with 
backup power provided by supercapacitors. In case of power failure there 
is  just enough  time to safely and nicely shut down BBB. For some 
reason BBB does not always wake up fully. I need hardware dogwatch. Did 
anybody design such a thing? I was able to find some design for ardunio: 
http://www.playwitharduino.com/?p=291.

Anybody has any experience with hardware dogwatch for BBB??
Thanks in advance
Robert
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google 
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to beagleboard+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.







--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57397009.205%40chello.sk.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread William Hermans
ooops, I forgot the main concern. The MSP430 could also be use as an
external smart watchdog. Just by poking a GPIO pin once in a while from a
beagelbone. In code  this would be very easy, and not processor intensive
at all.


   - BBB twiddles GPIO pin
   - Pin interrupt fires on MSP430, and toggles a bit flag.
   - timer period ends, and sees bit toggled, or not.
   - if toggled, repeat cycle.
   - if not toggled disconnect / reconnect power to the Beaglebone, and
   then toggle the reset switch.

Another nicety of the G2553 MCU is that it has an on die temp sensor. Then
since the MCU will spend 90% + of it's time in sleep mode, core temperature
will not be above ambient temperature by very much, if at all. So you get a
temperature sensor for free, if you care to hook up UART, SPI, or I2C back
to the beaglebone.

I think that honestly, the MSP430G2553 is even too much hardware for the
particular use case. But it's the only MCU I know of that uses so little
power, costs so little, nd has all the required features for an external
smart watchdog that can "physically" interact with an SBC, as well as
monitor power on it's own.

On Sun, May 15, 2016 at 7:46 PM, William Hermans  wrote:

> *What the BBB needs is not so much a watchdog timer, but an intelligent*
>> * power monitor.  If that processor (and it could be very simple) does*
>> * *not* have an operating system but simply runs embedded firmware, then*
>> * it will not suffer from shutdown problems as does the BBB.*
>>
>> * It could have an operating system, but should not depend on file*
>> * systems being set up properly (a la windows or linux, I think).*
>>
>> * You could use something as simple as an Arduino.*
>>
>> * Harvey*
>>
>
> I would probably never use an Arduino for this purpose. The cost is too
> high for starters.
>
> An MSP430G2553 is perfect for this usage because it is an extremely low
> power MCU, that has hardware SPI, UART, I2C, WDT, ADC, PWM . . . and at
> least 14-16s pin available for use after the bare minimum are used for
> power, gnd, reset, etc. This MCU is also well supported in CCS, as well as
> through gcc, and the MCP430 MCUs are well known, and proven.
>
> So, the G2553 has it's own WDT in case it ever get's stuck. It has it's
> own hardware ADC so it can monitor input power it's self. Then it has
> GPIO's which can be used to power down a BBB though toggling the power
> button, or reset the board by disconnecting power from input as needed.
> Plus it has it's own POR, and BOR features built in. As well as being an
> MCU with internal flash for storage it is for all intents and purposes
> immune to power loss.
>
> Trust me though. My buddy and I have discussed this a lot over the coarse
> of the last 3 or so years, and even more lately as we've realized that
> reset on the BBB is essentially broken since it's only a soft reset. That
> requires the input power to be completely disconnected for a short amount
> of time.
>
> Anyway, if I knew PIC, or NXP MCU's as well as the value line MSP430's, I
> might consider one of those too. But seriously, beating the power usage of
> a valueline MSP430 would be really hard. They can operate on a single
> button cell for over 10 years.
>
>
> On Sun, May 15, 2016 at 6:00 PM, Harvey White 
> wrote:
>
>> On Sun, 15 May 2016 17:08:40 -0700 (PDT), you wrote:
>>
>> >
>> >Sorry guys.  I might be confusing my terms here, or misusing the phrase
>> >'watchdog timer'.  Would 'hardware watchdog circuit' fit?  "Intelligent
>> >power switch?"  I'm not quite sure what to search for!
>>
>> I generally call a watchdog timer (and it can be external if desired)
>> as a timer that must be continually refreshed, if it times out, it
>> resets the microprocessor.  However, the processor remembers that it
>> has been reset by a watchdog (most of them ought to), and then your
>> bootup routine will know that the program hung somewhere and didn't
>> reset the watchdog timer in time.
>>
>> What the BBB needs is not so much a watchdog timer, but an intelligent
>> power monitor.  If that processor (and it could be very simple) does
>> *not* have an operating system but simply runs embedded firmware, then
>> it will not suffer from shutdown problems as does the BBB.
>>
>> It could have an operating system, but should not depend on file
>> systems being set up properly (a la windows or linux, I think).
>>
>> You could use something as simple as an Arduino.
>>
>> Harvey
>>
>> >
>> >The circuit I'm looking for is what John3909 is describing; something to
>> >address the corner-cases around power and ensure graceful, and hands-off,
>> >system recovery amidst all of the corner cases (brownouts, drop+restart
>> >(incl at 'inconvenient' times, ie during shutdown, etc)).
>> >
>> >Fwiw, my application is already kicking the onboard watchdog, and relying
>> >on its reboot if the software system fails.  I need to make sure that
>> that
>> >reboot ALWAYS happens, no matter what the power throws at it, as the
>> system
>> >wil

Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread William Hermans
>
> *What the BBB needs is not so much a watchdog timer, but an intelligent*
> * power monitor.  If that processor (and it could be very simple) does*
> * *not* have an operating system but simply runs embedded firmware, then*
> * it will not suffer from shutdown problems as does the BBB.*
>
> * It could have an operating system, but should not depend on file*
> * systems being set up properly (a la windows or linux, I think).*
>
> * You could use something as simple as an Arduino.*
>
> * Harvey*
>

I would probably never use an Arduino for this purpose. The cost is too
high for starters.

An MSP430G2553 is perfect for this usage because it is an extremely low
power MCU, that has hardware SPI, UART, I2C, WDT, ADC, PWM . . . and at
least 14-16s pin available for use after the bare minimum are used for
power, gnd, reset, etc. This MCU is also well supported in CCS, as well as
through gcc, and the MCP430 MCUs are well known, and proven.

So, the G2553 has it's own WDT in case it ever get's stuck. It has it's own
hardware ADC so it can monitor input power it's self. Then it has GPIO's
which can be used to power down a BBB though toggling the power button, or
reset the board by disconnecting power from input as needed. Plus it has
it's own POR, and BOR features built in. As well as being an MCU with
internal flash for storage it is for all intents and purposes immune to
power loss.

Trust me though. My buddy and I have discussed this a lot over the coarse
of the last 3 or so years, and even more lately as we've realized that
reset on the BBB is essentially broken since it's only a soft reset. That
requires the input power to be completely disconnected for a short amount
of time.

Anyway, if I knew PIC, or NXP MCU's as well as the value line MSP430's, I
might consider one of those too. But seriously, beating the power usage of
a valueline MSP430 would be really hard. They can operate on a single
button cell for over 10 years.


On Sun, May 15, 2016 at 6:00 PM, Harvey White 
wrote:

> On Sun, 15 May 2016 17:08:40 -0700 (PDT), you wrote:
>
> >
> >Sorry guys.  I might be confusing my terms here, or misusing the phrase
> >'watchdog timer'.  Would 'hardware watchdog circuit' fit?  "Intelligent
> >power switch?"  I'm not quite sure what to search for!
>
> I generally call a watchdog timer (and it can be external if desired)
> as a timer that must be continually refreshed, if it times out, it
> resets the microprocessor.  However, the processor remembers that it
> has been reset by a watchdog (most of them ought to), and then your
> bootup routine will know that the program hung somewhere and didn't
> reset the watchdog timer in time.
>
> What the BBB needs is not so much a watchdog timer, but an intelligent
> power monitor.  If that processor (and it could be very simple) does
> *not* have an operating system but simply runs embedded firmware, then
> it will not suffer from shutdown problems as does the BBB.
>
> It could have an operating system, but should not depend on file
> systems being set up properly (a la windows or linux, I think).
>
> You could use something as simple as an Arduino.
>
> Harvey
>
> >
> >The circuit I'm looking for is what John3909 is describing; something to
> >address the corner-cases around power and ensure graceful, and hands-off,
> >system recovery amidst all of the corner cases (brownouts, drop+restart
> >(incl at 'inconvenient' times, ie during shutdown, etc)).
> >
> >Fwiw, my application is already kicking the onboard watchdog, and relying
> >on its reboot if the software system fails.  I need to make sure that that
> >reboot ALWAYS happens, no matter what the power throws at it, as the
> system
> >will be installed in walls, ceilings and such.
> >
> >Does anyone know of a good public-domain/open-source external circuit
> >design that might work around the BBB (or something close -- a good
> >starting point)?  Or, even better, would anyone be able & willing to share
> >their circuit design?  I realize that this kind of circuit requires some
> >solid engineering to get right.  The EE part is a stretch for me,
> >capability-wise, but I can offer software services in trade for hardware
> >help.
> >
> >I'm personally blocked by this issue, and just trying to work out the best
> >path forward, but I'd love to see this problem definitively solved for
> >everyone using the BBB.  It is such a great platform. I'd love to ensure
> >it'll always be online and ready for what we all throw at it.
> >
> >Best,
> >ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/pg6ijb17s4ie0fs5rv13vi67hdcd1fsf10%404ax.com
> .
> For more options, visit https://groups.google.com/d/o

Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread Harvey White
On Sun, 15 May 2016 17:08:40 -0700 (PDT), you wrote:

>
>Sorry guys.  I might be confusing my terms here, or misusing the phrase 
>'watchdog timer'.  Would 'hardware watchdog circuit' fit?  "Intelligent 
>power switch?"  I'm not quite sure what to search for!

I generally call a watchdog timer (and it can be external if desired)
as a timer that must be continually refreshed, if it times out, it
resets the microprocessor.  However, the processor remembers that it
has been reset by a watchdog (most of them ought to), and then your
bootup routine will know that the program hung somewhere and didn't
reset the watchdog timer in time.

What the BBB needs is not so much a watchdog timer, but an intelligent
power monitor.  If that processor (and it could be very simple) does
*not* have an operating system but simply runs embedded firmware, then
it will not suffer from shutdown problems as does the BBB.

It could have an operating system, but should not depend on file
systems being set up properly (a la windows or linux, I think).  

You could use something as simple as an Arduino.

Harvey

>
>The circuit I'm looking for is what John3909 is describing; something to 
>address the corner-cases around power and ensure graceful, and hands-off, 
>system recovery amidst all of the corner cases (brownouts, drop+restart 
>(incl at 'inconvenient' times, ie during shutdown, etc)).  
>
>Fwiw, my application is already kicking the onboard watchdog, and relying 
>on its reboot if the software system fails.  I need to make sure that that 
>reboot ALWAYS happens, no matter what the power throws at it, as the system 
>will be installed in walls, ceilings and such.
>
>Does anyone know of a good public-domain/open-source external circuit 
>design that might work around the BBB (or something close -- a good 
>starting point)?  Or, even better, would anyone be able & willing to share 
>their circuit design?  I realize that this kind of circuit requires some 
>solid engineering to get right.  The EE part is a stretch for me, 
>capability-wise, but I can offer software services in trade for hardware 
>help. 
>
>I'm personally blocked by this issue, and just trying to work out the best 
>path forward, but I'd love to see this problem definitively solved for 
>everyone using the BBB.  It is such a great platform. I'd love to ensure 
>it'll always be online and ready for what we all throw at it.
>
>Best,
>ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/pg6ijb17s4ie0fs5rv13vi67hdcd1fsf10%404ax.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread Super Twang

Sorry guys.  I might be confusing my terms here, or misusing the phrase 
'watchdog timer'.  Would 'hardware watchdog circuit' fit?  "Intelligent 
power switch?"  I'm not quite sure what to search for!

The circuit I'm looking for is what John3909 is describing; something to 
address the corner-cases around power and ensure graceful, and hands-off, 
system recovery amidst all of the corner cases (brownouts, drop+restart 
(incl at 'inconvenient' times, ie during shutdown, etc)).  

Fwiw, my application is already kicking the onboard watchdog, and relying 
on its reboot if the software system fails.  I need to make sure that that 
reboot ALWAYS happens, no matter what the power throws at it, as the system 
will be installed in walls, ceilings and such.

Does anyone know of a good public-domain/open-source external circuit 
design that might work around the BBB (or something close -- a good 
starting point)?  Or, even better, would anyone be able & willing to share 
their circuit design?  I realize that this kind of circuit requires some 
solid engineering to get right.  The EE part is a stretch for me, 
capability-wise, but I can offer software services in trade for hardware 
help. 

I'm personally blocked by this issue, and just trying to work out the best 
path forward, but I'd love to see this problem definitively solved for 
everyone using the BBB.  It is such a great platform. I'd love to ensure 
it'll always be online and ready for what we all throw at it.

Best,
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2fe26902-1078-4558-812f-b496984e2bee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread evilwulfie
msp430 has an internal watchdog

On 5/15/2016 3:37 PM, John Syne wrote:
>
>> On May 15, 2016, at 3:14 PM, evilwulfie > > wrote:
>>
>> We use an external msp430 for our intelligent watchdog
> So who or what monitors the MSP430? Since it is a micro-controller, it
> is easy to get it into a lock situation. All you need is a programable
> power supply which will ramp up and down the voltage into the
> micro-controller at predefined times and it will lock and become
> completely unresponsive. Granted this will rarely happen, but in our
> applications where 100K or more devices are installed, we cannot
> accept some devices locking up because of a power failure. 
>
> Regards,
> John
>>
>>
>> On 5/15/2016 1:07 PM, Super Twang wrote:
>>>
>>>
>>> I've just come across this conversation in my own search for a
>>> rock-solid, embeddable configuration for the BeagleBone Black.  I’m
>>> trying to develop an embedded controller device that needs to live
>>> behind walls, in ceilings and in other inaccessible places. ( It is
>>> for the automation of art & other electronic installations.)
>>>
>>> From what I gather here, the BBB is not quite up to the task,
>>> without an external watchdog circuit (please correct me if I’m
>>> misreading this thread).
>>>
>>> @John3909: Your suggestion of the GreenPak prompted my own discovery
>>> of that tech — it looks great, esp the ecosystem of tools around the
>>> platform. 
>>>
>>> In looking around, I found some Silego application notes that
>>> implement a hardware watchdog for MCUs.
>>>  http://www.silego.com/products/352/312/AN-1058.html  This might be
>>> a useful starting point for anyone using GreenPak for a hardware
>>> watchdog.
>>>
>>> @John3909: Does this design look like it might be a good fit for the
>>> BBB? (Not knowing how to read GreenPak internals, it is not obvious
>>> to me)
>>>
>>> Alternately, I'm wondering in the two years that have passed since
>>> this thread started, if anyone has developed a hardware watchdog
>>> design for the BBB they'd be willing to share.  An open-source
>>> hardware watchdog for the BBB would go a long way towards
>>> ameliorating the hardware issues with the PMIC on RevC, and allow it
>>> to prosper as a base for applications where long-term reliability
>>> matters.
>>>
>>> Although I’m first and foremost a software engineer, I've got some
>>> electronics chops (albeit mostly digital), but (sadly) very limited
>>> hardware design equipment (oscilloscope, etc).  [That said, I have
>>> iron, and will solder!]  I’d be happy to develop & contribute the
>>> software components for such a system (I’d envision a library +
>>> device tree overlay) if someone(s) else would like to partner up to
>>> design the hardware side.
>>>
>>> Best,
>>>
>>> ST
>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to beagleboard+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to beagleboard+unsubscr...@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/976bd440-2729-5157-8692-3357a8d607a0%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/E00049D5-E39B-42CB-8A5E-A19F4E51199F%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it,

Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread John Syne

> On May 15, 2016, at 3:14 PM, evilwulfie  wrote:
> 
> We use an external msp430 for our intelligent watchdog
So who or what monitors the MSP430? Since it is a micro-controller, it is easy 
to get it into a lock situation. All you need is a programable power supply 
which will ramp up and down the voltage into the micro-controller at predefined 
times and it will lock and become completely unresponsive. Granted this will 
rarely happen, but in our applications where 100K or more devices are 
installed, we cannot accept some devices locking up because of a power failure. 

Regards,
John
> 
> 
> On 5/15/2016 1:07 PM, Super Twang wrote:
>> 
>> 
>> I've just come across this conversation in my own search for a rock-solid, 
>> embeddable configuration for the BeagleBone Black.  I’m trying to develop an 
>> embedded controller device that needs to live behind walls, in ceilings and 
>> in other inaccessible places. ( It is for the automation of art & other 
>> electronic installations.)
>> 
>> From what I gather here, the BBB is not quite up to the task, without an 
>> external watchdog circuit (please correct me if I’m misreading this thread).
>> 
>> @John3909: Your suggestion of the GreenPak prompted my own discovery of that 
>> tech — it looks great, esp the ecosystem of tools around the platform. 
>> 
>> In looking around, I found some Silego application notes that implement a 
>> hardware watchdog for MCUs.   
>> http://www.silego.com/products/352/312/AN-1058.html
>>    This might be a 
>> useful starting point for anyone using GreenPak for a hardware watchdog.
>> 
>> @John3909: Does this design look like it might be a good fit for the BBB? 
>> (Not knowing how to read GreenPak internals, it is not obvious to me)
>> 
>> Alternately, I'm wondering in the two years that have passed since this 
>> thread started, if anyone has developed a hardware watchdog design for the 
>> BBB they'd be willing to share.  An open-source hardware watchdog for the 
>> BBB would go a long way towards ameliorating the hardware issues with the 
>> PMIC on RevC, and allow it to prosper as a base for applications where 
>> long-term reliability matters.
>> 
>> Although I’m first and foremost a software engineer, I've got some 
>> electronics chops (albeit mostly digital), but (sadly) very limited hardware 
>> design equipment (oscilloscope, etc).  [That said, I have iron, and will 
>> solder!]  I’d be happy to develop & contribute the software components for 
>> such a system (I’d envision a library + device tree overlay) if someone(s) 
>> else would like to partner up to design the hardware side.
>> 
>> Best,
>> 
>> ST
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit  
>> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/976bd440-2729-5157-8692-3357a8d607a0%40gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/E00049D5-E39B-42CB-8A5E-A19F4E51199F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread John Syne
I haven’t worked on this in a while, but the circuitry I proposed was for a 
voltage monitoring and safe shutdown and startup. The AM3358 already has a 
watchdog timer and will reset the board if the watchdog is not serviced in a 
predefined period. My proposed circuit included supercaps to power the board 
during power failure so that the board can shutdown safely. You need a state 
machine to deal with all the corner cases, such as 
1) what happens if you have a power fail, you trigger a shutdown and then the 
power is back on before the shutdown completes. In that case, you have to power 
off the BBB, wait for the supercaps to charge and then reapply the power to the 
BBB. 
2) what happens if the power is on and the board begins to boot, but then the 
power fails before the board has completed it’s bootup. 

There are several more corner cases when you think through all the scenarios.

Also, you need a supercap charging circuit since supercaps are normally rated 
at 2.7V so you have to put them in series but one supercap may have lower 
impedance than the other so one supercap may exceed it’s max voltage and may in 
fact go negative during discharge. Your charge circuit must prevent both 
conditions. 

You will also need a boost regulator to keep the voltage on the processor 
constant as the supercaps discharge.

Lithium batteries would be easier, but then you are faced with the limited 
number of charge cycles and the limit life expectancy of these batteries. 

Just some ideas to think about. 

Regards,
John




> On May 15, 2016, at 1:07 PM, Super Twang  wrote:
> 
> 
> 
> I've just come across this conversation in my own search for a rock-solid, 
> embeddable configuration for the BeagleBone Black.  I’m trying to develop an 
> embedded controller device that needs to live behind walls, in ceilings and 
> in other inaccessible places. ( It is for the automation of art & other 
> electronic installations.)
> 
> From what I gather here, the BBB is not quite up to the task, without an 
> external watchdog circuit (please correct me if I’m misreading this thread).
> 
> @John3909: Your suggestion of the GreenPak prompted my own discovery of that 
> tech — it looks great, esp the ecosystem of tools around the platform. 
> 
> In looking around, I found some Silego application notes that implement a 
> hardware watchdog for MCUs.  
> http://www.silego.com/products/352/312/AN-1058.html 
>   This might be a useful 
> starting point for anyone using GreenPak for a hardware watchdog.
> 
> @John3909: Does this design look like it might be a good fit for the BBB? 
> (Not knowing how to read GreenPak internals, it is not obvious to me)
> 
> Alternately, I'm wondering in the two years that have passed since this 
> thread started, if anyone has developed a hardware watchdog design for the 
> BBB they'd be willing to share.  An open-source hardware watchdog for the BBB 
> would go a long way towards ameliorating the hardware issues with the PMIC on 
> RevC, and allow it to prosper as a base for applications where long-term 
> reliability matters.
> 
> Although I’m first and foremost a software engineer, I've got some 
> electronics chops (albeit mostly digital), but (sadly) very limited hardware 
> design equipment (oscilloscope, etc).  [That said, I have iron, and will 
> solder!]  I’d be happy to develop & contribute the software components for 
> such a system (I’d envision a library + device tree overlay) if someone(s) 
> else would like to partner up to design the hardware side.
> 
> Best,
> 
> ST
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5F4B57BD-6AB4-4DFF-ACDB-66C038778EC3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread evilwulfie
We use an external msp430 for our intelligent watchdog


On 5/15/2016 1:07 PM, Super Twang wrote:
>
>
> I've just come across this conversation in my own search for a
> rock-solid, embeddable configuration for the BeagleBone Black.  I’m
> trying to develop an embedded controller device that needs to live
> behind walls, in ceilings and in other inaccessible places. ( It is
> for the automation of art & other electronic installations.)
>
> From what I gather here, the BBB is not quite up to the task, without
> an external watchdog circuit (please correct me if I’m misreading this
> thread).
>
> @John3909: Your suggestion of the GreenPak prompted my own discovery
> of that tech — it looks great, esp the ecosystem of tools around the
> platform. 
>
> In looking around, I found some Silego application notes that
> implement a hardware watchdog for MCUs.
>  http://www.silego.com/products/352/312/AN-1058.html  This might be a
> useful starting point for anyone using GreenPak for a hardware watchdog.
>
> @John3909: Does this design look like it might be a good fit for the
> BBB? (Not knowing how to read GreenPak internals, it is not obvious to me)
>
> Alternately, I'm wondering in the two years that have passed since
> this thread started, if anyone has developed a hardware watchdog
> design for the BBB they'd be willing to share.  An open-source
> hardware watchdog for the BBB would go a long way towards ameliorating
> the hardware issues with the PMIC on RevC, and allow it to prosper as
> a base for applications where long-term reliability matters.
>
> Although I’m first and foremost a software engineer, I've got some
> electronics chops (albeit mostly digital), but (sadly) very limited
> hardware design equipment (oscilloscope, etc).  [That said, I have
> iron, and will solder!]  I’d be happy to develop & contribute the
> software components for such a system (I’d envision a library + device
> tree overlay) if someone(s) else would like to partner up to design
> the hardware side.
>
> Best,
>
> ST
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/976bd440-2729-5157-8692-3357a8d607a0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2016-05-15 Thread Super Twang


I've just come across this conversation in my own search for a rock-solid, 
embeddable configuration for the BeagleBone Black.  I’m trying to develop 
an embedded controller device that needs to live behind walls, in ceilings 
and in other inaccessible places. ( It is for the automation of art & other 
electronic installations.)

>From what I gather here, the BBB is not quite up to the task, without an 
external watchdog circuit (please correct me if I’m misreading this thread).

@John3909: Your suggestion of the GreenPak prompted my own discovery of 
that tech — it looks great, esp the ecosystem of tools around the platform. 

In looking around, I found some Silego application notes that implement a 
hardware watchdog for MCUs.  
http://www.silego.com/products/352/312/AN-1058.html  This might be a useful 
starting point for anyone using GreenPak for a hardware watchdog.

@John3909: Does this design look like it might be a good fit for the BBB? 
(Not knowing how to read GreenPak internals, it is not obvious to me)

Alternately, I'm wondering in the two years that have passed since this 
thread started, if anyone has developed a hardware watchdog design for the 
BBB they'd be willing to share.  An open-source hardware watchdog for the 
BBB would go a long way towards ameliorating the hardware issues with the 
PMIC on RevC, and allow it to prosper as a base for applications where 
long-term reliability matters.

Although I’m first and foremost a software engineer, I've got some 
electronics chops (albeit mostly digital), but (sadly) very limited 
hardware design equipment (oscilloscope, etc).  [That said, I have iron, 
and will solder!]  I’d be happy to develop & contribute the software 
components for such a system (I’d envision a library + device tree overlay) 
if someone(s) else would like to partner up to design the hardware side.

Best,

ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c7fb39d8-84ef-4127-9db8-cd65a6965e31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread John Syn

From:  William Hermans 
Reply-To:  
Date:  Tuesday, March 25, 2014 at 10:02 PM
To:  
Subject:  Re: [beagleboard] Hardware watchdog for BBB

> Hi John,
> 
> Yeah, the MSP430G2553 can go down to at least 1.8v, and I am thinking a good
> bit lower. I am thinking perhaps 1.2V at minimal clock / periph's( I'd have to
> read the datasheet again ) Now just because I am relatively new to embedded
> devices, and I know the MSP430's fairly well, I would choose these for myself.
> The MSP430 value line products can not beat or even meet that price by a long
> shot in small quantities. I think the lowest my buddy got a tube of 10 for
> ~$1.35 each a bit over a year ago. One or two off, personally I think this
> price is fair enough.
> 
> I haven't heard of the devices you're linking to, and the link doesn't work
> for me. So i can not even look to see exactly what it is. I would assume the
> MSP430G2553 would be overkill by comparison, feature wise.
> 
> So, I am not much of an EE, but my buddy is. Perhaps I could get him to design
> something up while I'll tie things together in software. This is something I
> personally have interest in as well.
Hi William,

Strange, I just clicked on the link below and it works for me. Search Google
for silego and greenpak. It¹s really like a miniature mixed signal FPGA.
They have a really nice software tool/simulator and dev board. I use these
all the time instead of using discrete logic. They are really good for small
state machines with inputs from timers, counters, analog comparators, lookup
tables, macrocells, etc.

Regards,
John
> 
> 
> 
> On Tue, Mar 25, 2014 at 5:44 PM, John Syn  wrote:
>> 
>> From:  William Hermans 
>> Reply-To:  
>> Date:  Tuesday, March 25, 2014 at 3:41 PM
>> 
>> To:  
>> Subject:  Re: [beagleboard] Hardware watchdog for BBB
>> 
>>> Yeah after I thought about it, after making my post I realized I did not
>>> include a way to bring the BBB back up.
>>> 
>>> For bringing the BBB back up after input power is back up I suppose I would
>>> use an MSP430 to monitor the input power, and a "keep alive" signal from the
>>> BBB to the MSP430. A Value line MSP430 such as the MSP430G2553 is low cost (
>>> ~$2.5 in quantities of 1 ) can run off a single button cell for years. the
>>> MSP430G2553 also has SPI, I2C, GPIO's, and UART, as well as a few other
>>> niceties( hardware WDT, and Timer(s).)
>>> 
>>> So perhaps more complex than I originally led on, but perfectly doable, and
>>> not really all that complex. Just off the top of my head, I would use either
>>> a regular timer, or perhaps even use the hardware watchdog timer to cycle a
>>> reset on the BBB through a GPIO. With the keep alive signal being sent out
>>> over either SPI or UART.
>>> 
>>> Is this on track with what you had in mind, or are you thinking of something
>>> else, or is this too complex for your application ?
>> Hi William,
>> 
>> I like your solution. I used a GreenPak from http://www.silego.com/ which are
>> really low cost $0.35 in small quantities. They are tiny (about 2mm square)
>> and very robust; no need for WDT. Also, they work down to 1.8V, which is
>> required when working with supercaps.
>> 
>> Regards,
>> John
>>> 
>>> 
>>> 
>>> On Tue, Mar 25, 2014 at 12:50 PM, John Syn  wrote:
>>>> 
>>>> From:  Timbo 
>>>> Reply-To:  
>>>> Date:  Tuesday, March 25, 2014 at 6:12 AM
>>>> 
>>>> To:  
>>>> Subject:  Re: [beagleboard] Hardware watchdog for BBB
>>>> 
>>>>> 
>>>>>> What happens when you have 10K, 100K or even 1 Million devices running.
>>>>> 
>>>>> Now we know where all the BBBs went!
>>>> Very funny. BBB wouldn¹t work for my application but I do draw from
>>>> Gerald¹s brilliance ;-)
>>>>> 
>>>>> 
>>>>> For home use I've rigged two BBBs together so that each can monitor and
>>>>> reset the other.  Every 5 minutes each board tries to send itself a
>>>>> message via an ssh connection to the other board.  If it fails to receive
>>>>> that message, it assumes the other board has crashed somehow and sends a
>>>>> reset.  If it still fails to get a response it carries out a power cycle.
>>>>> 
>>>>> In conjunction with a simple UPS such as the OP describes, this would
>>>>> probably be enough for normal use.
>>>>> 
>>>

Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread William Hermans
Hi John,

Yeah, the MSP430G2553 can go down to at least 1.8v, and I am thinking a
good bit lower. I am thinking perhaps 1.2V at minimal clock / periph's( I'd
have to read the datasheet again ) Now just because I am relatively new to
embedded devices, and I know the MSP430's fairly well, I would choose these
for myself. The MSP430 value line products can not beat or even meet that
price by a long shot in small quantities. I think the lowest my buddy got a
tube of 10 for ~$1.35 each a bit over a year ago. One or two off,
personally I think this price is fair enough.

I haven't heard of the devices you're linking to, and the link doesn't work
for me. So i can not even look to see exactly what it is. I would assume
the MSP430G2553 would be overkill by comparison, feature wise.

So, I am not much of an EE, but my buddy is. Perhaps I could get him to
design something up while I'll tie things together in software. This is
something I personally have interest in as well.



On Tue, Mar 25, 2014 at 5:44 PM, John Syn  wrote:

>
> From: William Hermans 
> Reply-To: 
> Date: Tuesday, March 25, 2014 at 3:41 PM
>
> To: 
> Subject: Re: [beagleboard] Hardware watchdog for BBB
>
> Yeah after I thought about it, after making my post I realized I did not
> include a way to bring the BBB back up.
>
> For bringing the BBB back up after input power is back up I suppose I
> would use an MSP430 to monitor the input power, and a "keep alive" signal
> from the BBB to the MSP430. A Value line MSP430 such as the MSP430G2553 is
> low cost ( ~$2.5 in quantities of 1 ) can run off a single button cell for
> years. the MSP430G2553 also has SPI, I2C, GPIO's, and UART, as well as a
> few other niceties( hardware WDT, and Timer(s).)
>
> So perhaps more complex than I originally led on, but perfectly doable,
> and not really all that complex. Just off the top of my head, I would use
> either a regular timer, or perhaps even use the hardware watchdog timer to
> cycle a reset on the BBB through a GPIO. With the keep alive signal being
> sent out over either SPI or UART.
>
> Is this on track with what you had in mind, or are you thinking of
> something else, or is this too complex for your application ?
>
> Hi William,
>
> I like your solution. I used a GreenPak from http://www.silego.com/ which
> are really low cost $0.35 in small quantities. They are tiny (about 2mm
> square) and very robust; no need for WDT. Also, they work down to 1.8V,
> which is required when working with supercaps.
>
> Regards,
> John
>
>
>
>
> On Tue, Mar 25, 2014 at 12:50 PM, John Syn  wrote:
>
>>
>> From: Timbo 
>> Reply-To: 
>> Date: Tuesday, March 25, 2014 at 6:12 AM
>>
>> To: 
>> Subject: Re: [beagleboard] Hardware watchdog for BBB
>>
>>
>> What happens when you have 10K, 100K or even 1 Million devices running.
>>>
>>
>> Now we know where all the BBBs went!
>>
>> Very funny. BBB wouldn't work for my application but I do draw from
>> Gerald's brilliance ;-)
>>
>>
>>
>> For home use I've rigged two BBBs together so that each can monitor and
>> reset the other.  Every 5 minutes each board tries to send itself a message
>> via an ssh connection to the other board.  If it fails to receive that
>> message, it assumes the other board has crashed somehow and sends a reset.
>> If it still fails to get a response it carries out a power cycle.
>>
>> In conjunction with a simple UPS such as the OP describes, this would
>> probably be enough for normal use.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@g

Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread John Syn

From:  William Hermans 
Reply-To:  
Date:  Tuesday, March 25, 2014 at 3:41 PM
To:  
Subject:  Re: [beagleboard] Hardware watchdog for BBB

> Yeah after I thought about it, after making my post I realized I did not
> include a way to bring the BBB back up.
> 
> For bringing the BBB back up after input power is back up I suppose I would
> use an MSP430 to monitor the input power, and a "keep alive" signal from the
> BBB to the MSP430. A Value line MSP430 such as the MSP430G2553 is low cost (
> ~$2.5 in quantities of 1 ) can run off a single button cell for years. the
> MSP430G2553 also has SPI, I2C, GPIO's, and UART, as well as a few other
> niceties( hardware WDT, and Timer(s).)
> 
> So perhaps more complex than I originally led on, but perfectly doable, and
> not really all that complex. Just off the top of my head, I would use either a
> regular timer, or perhaps even use the hardware watchdog timer to cycle a
> reset on the BBB through a GPIO. With the keep alive signal being sent out
> over either SPI or UART.
> 
> Is this on track with what you had in mind, or are you thinking of something
> else, or is this too complex for your application ?
Hi William,

I like your solution. I used a GreenPak from http://www.silego.com/ which
are really low cost $0.35 in small quantities. They are tiny (about 2mm
square) and very robust; no need for WDT. Also, they work down to 1.8V,
which is required when working with supercaps.

Regards,
John
> 
> 
> 
> On Tue, Mar 25, 2014 at 12:50 PM, John Syn  wrote:
>> 
>> From:  Timbo 
>> Reply-To:  
>> Date:  Tuesday, March 25, 2014 at 6:12 AM
>> 
>> To:  
>> Subject:  Re: [beagleboard] Hardware watchdog for BBB
>> 
>>> 
>>>> What happens when you have 10K, 100K or even 1 Million devices running.
>>> 
>>> Now we know where all the BBBs went!
>> Very funny. BBB wouldn¹t work for my application but I do draw from Gerald¹s
>> brilliance ;-)
>>> 
>>> 
>>> For home use I've rigged two BBBs together so that each can monitor and
>>> reset the other.  Every 5 minutes each board tries to send itself a message
>>> via an ssh connection to the other board.  If it fails to receive that
>>> message, it assumes the other board has crashed somehow and sends a reset.
>>> If it still fails to get a response it carries out a power cycle.
>>> 
>>> In conjunction with a simple UPS such as the OP describes, this would
>>> probably be enough for normal use.
>>> 
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread William Hermans
Yeah after I thought about it, after making my post I realized I did not
include a way to bring the BBB back up.

For bringing the BBB back up after input power is back up I suppose I would
use an MSP430 to monitor the input power, and a "keep alive" signal from
the BBB to the MSP430. A Value line MSP430 such as the MSP430G2553 is low
cost ( ~$2.5 in quantities of 1 ) can run off a single button cell for
years. the MSP430G2553 also has SPI, I2C, GPIO's, and UART, as well as a
few other niceties( hardware WDT, and Timer(s).)

So perhaps more complex than I originally led on, but perfectly doable, and
not really all that complex. Just off the top of my head, I would use
either a regular timer, or perhaps even use the hardware watchdog timer to
cycle a reset on the BBB through a GPIO. With the keep alive signal being
sent out over either SPI or UART.

Is this on track with what you had in mind, or are you thinking of
something else, or is this too complex for your application ?


On Tue, Mar 25, 2014 at 12:50 PM, John Syn  wrote:

>
> From: Timbo 
> Reply-To: 
> Date: Tuesday, March 25, 2014 at 6:12 AM
>
> To: 
> Subject: Re: [beagleboard] Hardware watchdog for BBB
>
>
> What happens when you have 10K, 100K or even 1 Million devices running.
>>
>
> Now we know where all the BBBs went!
>
> Very funny. BBB wouldn't work for my application but I do draw from
> Gerald's brilliance ;-)
>
>
>
> For home use I've rigged two BBBs together so that each can monitor and
> reset the other.  Every 5 minutes each board tries to send itself a message
> via an ssh connection to the other board.  If it fails to receive that
> message, it assumes the other board has crashed somehow and sends a reset.
> If it still fails to get a response it carries out a power cycle.
>
> In conjunction with a simple UPS such as the OP describes, this would
> probably be enough for normal use.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread John Syn

From:  Timbo 
Reply-To:  
Date:  Tuesday, March 25, 2014 at 6:12 AM
To:  
Subject:  Re: [beagleboard] Hardware watchdog for BBB

> 
>> What happens when you have 10K, 100K or even 1 Million devices running.
> 
> Now we know where all the BBBs went!
Very funny. BBB wouldn¹t work for my application but I do draw from Gerald¹s
brilliance ;-)
> 
> 
> For home use I've rigged two BBBs together so that each can monitor and reset
> the other.  Every 5 minutes each board tries to send itself a message via an
> ssh connection to the other board.  If it fails to receive that message, it
> assumes the other board has crashed somehow and sends a reset.  If it still
> fails to get a response it carries out a power cycle.
> 
> In conjunction with a simple UPS such as the OP describes, this would probably
> be enough for normal use.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread Timbo


> What happens when you have 10K, 100K or even 1 Million devices running.
>

Now we know where all the BBBs went!

For home use I've rigged two BBBs together so that each can monitor and 
reset the other.  Every 5 minutes each board tries to send itself a message 
via an ssh connection to the other board.  If it fails to receive that 
message, it assumes the other board has crashed somehow and sends a reset.  
If it still fails to get a response it carries out a power cycle.

In conjunction with a simple UPS such as the OP describes, this would 
probably be enough for normal use.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread John Syn

From:  William Hermans 
Reply-To:  
Date:  Tuesday, March 25, 2014 at 12:04 AM
To:  
Subject:  Re: [beagleboard] Hardware watchdog for BBB

> I am still not sure why anyone would need / want all this complexity.
> 
> Living offgrid, powered by solar panels which charge a battery bank, which
> then powers our home via an Inverter . . .  I am not sure why the same concept
> can not be used on the BBB.
> 
> 1) Power the BBB via a small rechargeable ~5V power source.
> 2) charge this ~5V power source via AC mains, solar power, whatever.
> 3) Monitor power on the charge input, and when absent send a message to the
> kernel to shutdown / hybernate.
> 
> Then, all you need is to make sure your power source can work a few minutes
> with no input power applied. Perhaps even double this value for "safety".
> 
> The way I see things, there is nothing to complex about all this at all.
Not a problem when you are there to push the on button or reset your BBB
when it locks up. What happens when there is no human intervention and the
BBB is in some remote location? What happens during brown outs, power
surges, power fluctuations, auto reclosure operations, power bypass, etc?
What happens when you have 10K, 100K or even 1 Million devices running. Even
a 0.1% failure rate will be a disaster.

Cost is a primary factor so you cannot spend 10x on the power supply
(batteries, solar panels; really?). Batteries are expensive and have a
limited number of charge cycles, typically less than 1,000 cycles (less than
3 years). Actually, the circuit is even more complex because supercaps have
a max voltage of 2.5 or 2.7 volts, so you have to stack them. Now you need
an energy balance circuit to make sure all caps in series maintain an equal
charge. During power fail, the voltage across these supercaps decrease, but
you need to maintain a constant voltage, so you need a boost switching
supply. The switcher cannot start until the supercaps have a minimum charge.
I could go on, but yes the complexity is necessary to ensure a reliable
supply. 

Your solution may be perfect for your requirements, but I think we are
talking about a different operating environment.

Regards,
John  
> 
> 
> 
> 
> On Mon, Mar 24, 2014 at 10:41 AM, John Syn  wrote:
>> 
>> From:  
>> Reply-To:  
>> Date:  Saturday, March 22, 2014 at 10:08 AM
>> To:  
>> Subject:  [beagleboard] Hardware watchdog for BBB
>> 
>>> HI, I have been working for a wile on safe power supply for BBB with backup
>>> power provided by supercapacitors. In case of power failure there is  just
>>> enough  time to safely and nicely shut down BBB. For some reason BBB does
>>> not always wake up fully. I need hardware dogwatch. Did anybody design such
>>> a thing? I was able to find some design for ardunio:
>>> http://www.playwitharduino.com/?p=291.
>>> Anybody has any experience with hardware dogwatch for BBB??
>>> Thanks in advance
>>> Robert
>> Hi Robert,
>> 
>>>  
>> Developing a power supply that ensures a reliable shutdown down in the event
>> of a power failure isn¹t a simple design. You really need to monitor the
>> input power supply and the state of the kernel to determine when to remove
>> and reapply power to the BBB. You have to consider the corner cases such as:
>> 1. power failure could occur during the boot up sequence
>> 2. power failure occurred, triggering a shutdown sequence and then power is
>> restored during the shutdown sequence.
>> With Linux, you cannot arbitrarily remove power during the boot up sequence
>> and you cannot simply reapply power during the power down sequence. In the
>> first case, when would it be safe to simply remove power to the BBB and in
>> the second case, when would it be safe to recycle the power to the BBB.
>> Currently there is no external info to determine the state of the kernel so
>> you would have to add a kernel driver which will control a GPIO to signal
>> when the kernel is in a safe mode (all volatile info written to non-volatile
>> memory) and also monitor a GPIO used to interrupt the kernel when a power
>> failure occurs. 
>> 
>> So now, you need an external state machine which tracks the input power
>> supply, state-of-kernel and charge state of super caps. Timers are also
>> required to ensure a proper power recycle.
>> 
>> I hope I have covered everything you need to consider in your design, but
>> perhaps others has some insights I haven¹t considered.
>> 
>> Regards,
>> John
>>>   -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google Gr

Re: [beagleboard] Hardware watchdog for BBB

2014-03-25 Thread William Hermans
I am still not sure why anyone would need / want all this complexity.

Living offgrid, powered by solar panels which charge a battery bank, which
then powers our home via an Inverter . . .  I am not sure why the same
concept can not be used on the BBB.

1) Power the BBB via a small rechargeable ~5V power source.
2) charge this ~5V power source via AC mains, solar power, whatever.
3) Monitor power on the charge input, and when absent send a message to the
kernel to shutdown / hybernate.

Then, all you need is to make sure your power source can work a few minutes
with no input power applied. Perhaps even double this value for "safety".

The way I see things, there is nothing to complex about all this at all.



On Mon, Mar 24, 2014 at 10:41 AM, John Syn  wrote:

>
> From: 
> Reply-To: 
> Date: Saturday, March 22, 2014 at 10:08 AM
> To: 
> Subject: [beagleboard] Hardware watchdog for BBB
>
> HI, I have been working for a wile on safe power supply for BBB with
> backup power provided by supercapacitors. In case of power failure there
> is  just enough  time to safely and nicely shut down BBB. For some reason
> BBB does not always wake up fully. I need hardware dogwatch. Did anybody
> design such a thing? I was able to find some design for ardunio:
> http://www.playwitharduino.com/?p=291.
> Anybody has any experience with hardware dogwatch for BBB??
> Thanks in advance
> Robert
>
> Hi Robert,
>
> Developing a power supply that ensures a reliable shutdown down in the
> event of a power failure isn't a simple design. You really need to monitor
> the input power supply and the state of the kernel to determine when to
> remove and reapply power to the BBB. You have to consider the corner cases
> such as:
>
>1. power failure could occur during the boot up sequence
>2. power failure occurred, triggering a shutdown sequence and then
>power is restored during the shutdown sequence.
>
> With Linux, you cannot arbitrarily remove power during the boot up
> sequence and you cannot simply reapply power during the power down
> sequence. In the first case, when would it be safe to simply remove power
> to the BBB and in the second case, when would it be safe to recycle the
> power to the BBB. Currently there is no external info to determine the
> state of the kernel so you would have to add a kernel driver which will
> control a GPIO to signal when the kernel is in a safe mode (all volatile
> info written to non-volatile memory) and also monitor a GPIO used to
> interrupt the kernel when a power failure occurs.
>
> So now, you need an external state machine which tracks the input power
> supply, state-of-kernel and charge state of super caps. Timers are also
> required to ensure a proper power recycle.
>
> I hope I have covered everything you need to consider in your design, but
> perhaps others has some insights I haven't considered.
>
> Regards,
> John
>
>   --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Hardware watchdog for BBB

2014-03-24 Thread John Syn

From:  
Reply-To:  
Date:  Saturday, March 22, 2014 at 10:08 AM
To:  
Subject:  [beagleboard] Hardware watchdog for BBB

> HI, I have been working for a wile on safe power supply for BBB with backup
> power provided by supercapacitors. In case of power failure there is  just
> enough  time to safely and nicely shut down BBB. For some reason BBB does not
> always wake up fully. I need hardware dogwatch. Did anybody design such a
> thing? I was able to find some design for ardunio:
> http://www.playwitharduino.com/?p=291.
> Anybody has any experience with hardware dogwatch for BBB??
> Thanks in advance
> Robert
Hi Robert,

>  
Developing a power supply that ensures a reliable shutdown down in the event
of a power failure isn¹t a simple design. You really need to monitor the
input power supply and the state of the kernel to determine when to remove
and reapply power to the BBB. You have to consider the corner cases such as:
1. power failure could occur during the boot up sequence
2. power failure occurred, triggering a shutdown sequence and then power is
restored during the shutdown sequence.
With Linux, you cannot arbitrarily remove power during the boot up sequence
and you cannot simply reapply power during the power down sequence. In the
first case, when would it be safe to simply remove power to the BBB and in
the second case, when would it be safe to recycle the power to the BBB.
Currently there is no external info to determine the state of the kernel so
you would have to add a kernel driver which will control a GPIO to signal
when the kernel is in a safe mode (all volatile info written to non-volatile
memory) and also monitor a GPIO used to interrupt the kernel when a power
failure occurs. 

So now, you need an external state machine which tracks the input power
supply, state-of-kernel and charge state of super caps. Timers are also
required to ensure a proper power recycle.

I hope I have covered everything you need to consider in your design, but
perhaps others has some insights I haven¹t considered.

Regards,
John
>   -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.