The "AC" is actually external DC supply, or whatever you have connected to the 5V input connector of the BBB. This is referenced to pin 10 of the TPS65217C PMIC chip.
Don't worry about changeover response time - the PMIC chip is claimed to react quickly, and several BBB owners with this configuration have reported successful continuation of BBB operation when the external power is cut.
Don't worry about changeover response time - the PMIC chip is claimed to react quickly, and several BBB owners with this configuration have reported successful continuation of BBB operation when the external power is cut.
The external DC PSU deliver DC to BBB. That PSU it must have some filtering devices on DC line. So, it is an important delay between the event "AC is cut/lost" and the event "DC disappear, or get under a safe level". When one pull out the DC plug, then all the system it stop, no matter how good/fast it may be the power management chip... In such case there is not any power left to be managed... BBB (as other similar systems) it should have built in its own PSU, and user should connect to it only a AC line (12v, or something). For the needs of a system like BBB a such SMPS should be quite small... But here is about design...
I suspect the TPS65217C PMIC chip does not deal with a power lose event (it can not do it anyway), but it manage the power up, and maybe down sequences, to protect the BBB components. This kind of power management is different than a complete/right power management, with AC monitoring, and some minimal back up resources to grant the necessary time to the system to run emergency routines...
Ideally and right way to be done is to monitor an AC line. But if there are reports about well functioning, as the way BBB it is ...
I suspect the TPS65217C PMIC chip does not deal with a power lose event (it can not do it anyway), but it manage the power up, and maybe down sequences, to protect the BBB components. This kind of power management is different than a complete/right power management, with AC monitoring, and some minimal back up resources to grant the necessary time to the system to run emergency routines...
Ideally and right way to be done is to monitor an AC line. But if there are reports about well functioning, as the way BBB it is ...
Last edited:
The PMIC is already providing 3.3V and under to the board. With any fast-acting low current drain to drop the voltage faster than the board's capacitors lose their voltage, detecting power loss and swapping over could be done quickly enough to not cause any issues. When +5V is lost, there will be a short time between that event, and going too far below +3.3V, to swap. While the time frame is very small, the PMIC is designed to handle that very scenario (just not configured for it by default).
But, it's only 3.3V and lower, to my knowledge. If you want to add any USB devices, you are into unknown territory when power is lost (like a lock-up, long freeze while something times out, or kernel panic). With any peripherals that need their own graceful shutdowns, as well as the BBB, you'll need to handle the whole system. In that case, you'll want a UPS that does not rely on the BBB.
But, it's only 3.3V and lower, to my knowledge. If you want to add any USB devices, you are into unknown territory when power is lost (like a lock-up, long freeze while something times out, or kernel panic). With any peripherals that need their own graceful shutdowns, as well as the BBB, you'll need to handle the whole system. In that case, you'll want a UPS that does not rely on the BBB.
Excellent suggestion for power management Russ, thanks.
I did not understand though what to do with a USB HDD connected to the BBB in case of power off ? Just let it down ?
Another issue btw for USB : in case a USB output to DAC is required for signal, as there is only one contrarily to the new RPi revision and it is additional costs, space and worries for powering an additional USB hub, would it be possible to have a second USB port on the cape or à header at least? Hope i am clear...
BR
Jean-Louis
I did not understand though what to do with a USB HDD connected to the BBB in case of power off ? Just let it down ?
Another issue btw for USB : in case a USB output to DAC is required for signal, as there is only one contrarily to the new RPi revision and it is additional costs, space and worries for powering an additional USB hub, would it be possible to have a second USB port on the cape or à header at least? Hope i am clear...
BR
Jean-Louis
In fairness, Russ did not make the suggestion, he facilitated it. The suggestion was made by two members of the BeagleBone forum; Michel and Gernot, based on an earlier less safe method proposed by shabaz.
Whenever the BBB is running on 3.7V battery power, no power is fed to the BBB's USB connector.
So in the event of a 5V power outage, and subsequent switchover to battery input, the USB connector will (obviously) lose power. Most USB hard drives should tolerate this power loss without harm, especially if they are just reading data from the drive, not writing to it, as will be the common situation with a music server.
Test it, over and, over, an over again, with read and write loads (reads being more important). If USB going down is no worse on than unplugging it, all will be well. If you can get lockups or panics (the HDD is not a concern, Linux's response to USB unexpectedly going down is), then you'll either want another USB/SATA converter, or to have a system-wide UPS. Definitely get a 5V powered 2.5" drive. The behavior in this situation is unknown, to my knowledge, since it is not the same as unplugging the device. In theory, it should work fine. I've seen enough problems with that theory, on mounted file systems, over the years, to want to verify it with experiments.
Should it be a problem, a 12V AGM battery standby-charged by a linear reg, with the BBB powered by a regulator after that, would be the simplest solution, if you need to keep USB devices alive for a shutdown.
Code:
[FONT=Courier New]>=18VDC->LM317(13.xVDC (check battery datasheet))
|
+->battery
|
+->LM7805(5VDC)-> BBB[/FONT]
Last edited:
Battery failover worked just fine for me, even with a USB drive and Wifi in use (of course these powered down and became unusable - but with no damage) . Accoring to my measurements current draw on the battery was < 500ma - meaning 3-4 hours on backup should be possible - but I would suggest we simply power down - either immediately or after some configured time. If power good is detected again we could init again as necessary.
I have not tested an automatic shutdown hook yet, but I successfully tested cutting AC power to powerd USB hub and the BBB - and then was able to perform normal `shutdown -h now` and then reboot normally after power restore.
Of course one could also just use a plain vanilla UPS with USB alert capability. This actually what I would strongly suggest as the best option.
Something like this is only $60
Amazon.com: APC BE550G Back-UPS ES 8 Outlet 550VA 120V: Electronics
I have not tested an automatic shutdown hook yet, but I successfully tested cutting AC power to powerd USB hub and the BBB - and then was able to perform normal `shutdown -h now` and then reboot normally after power restore.
Of course one could also just use a plain vanilla UPS with USB alert capability. This actually what I would strongly suggest as the best option.
Something like this is only $60
Amazon.com: APC BE550G Back-UPS ES 8 Outlet 550VA 120V: Electronics
Last edited:
I would think apcupsd would work fine:
Linux: Configure and Control APC SmartUPS During a Power Failure
Linux: Configure and Control APC SmartUPS During a Power Failure
I only just received enough parts to start testing it, and still need to round up a spare 2.5" HDD.
Used true sine AVR SmartUPSes can be had used to $100-140, typically (tested, and new batteries put in).
Most UPSes have a switching time around 10ms. They are battery backups, rather than truly being uninterruptible. That switching time is sometimes listed in the specs, or if not, in a datasheet. ATX PSUs are expected to handle 16ms of power loss before going out of spec, so it works out fine for PCs. That may or may not be fine for whatever PSU(s) you use for the BBB and peripherals.
A local DC UPS, be it encompassing the whole system, or just the BBB (like the single LiPo cell), is the way to go, IMO. Even handling more than just the BBB (what if you're using an SSD without power loss protection, or a display that needs soft shutdown, or an amp that needs a slow shutdown to not give you crazy output signals?), there's no shortage of easy and cost-efficient to implement means, especially with low-resistance supercaps getting cheap (not sure about how fast that FET detection actually works? Supercaps! Need to handle the 3-5ms of a relay? Supercaps! Only need a few seconds of dropping voltage? Supercaps!).
I don't mean to say the LiPo cell on the BBB is a bad idea at all. But as an IT guy, I've seen enough unceremonious shutdowns of hot-pluggable devices (things can go screwy with unexpected voltage losses, that don't go screwy when unplugging as designed), with commodity hardware that has gotten much more testing than BBBs ever will, not work right, to the end result of lockups, BSODs, and kernel panics, to caution that any such system should be tested (each user's total system is its own different appliance). If anything seems off, or there is good reason to not take the risk, there are plenty of affordable and easy to implement options to keep the whole system, or at least the +5V side of it, running uninterrupted.
Used true sine AVR SmartUPSes can be had used to $100-140, typically (tested, and new batteries put in).
Most UPSes have a switching time around 10ms. They are battery backups, rather than truly being uninterruptible. That switching time is sometimes listed in the specs, or if not, in a datasheet. ATX PSUs are expected to handle 16ms of power loss before going out of spec, so it works out fine for PCs. That may or may not be fine for whatever PSU(s) you use for the BBB and peripherals.
A local DC UPS, be it encompassing the whole system, or just the BBB (like the single LiPo cell), is the way to go, IMO. Even handling more than just the BBB (what if you're using an SSD without power loss protection, or a display that needs soft shutdown, or an amp that needs a slow shutdown to not give you crazy output signals?), there's no shortage of easy and cost-efficient to implement means, especially with low-resistance supercaps getting cheap (not sure about how fast that FET detection actually works? Supercaps! Need to handle the 3-5ms of a relay? Supercaps! Only need a few seconds of dropping voltage? Supercaps!).
I don't mean to say the LiPo cell on the BBB is a bad idea at all. But as an IT guy, I've seen enough unceremonious shutdowns of hot-pluggable devices (things can go screwy with unexpected voltage losses, that don't go screwy when unplugging as designed), with commodity hardware that has gotten much more testing than BBBs ever will, not work right, to the end result of lockups, BSODs, and kernel panics, to caution that any such system should be tested (each user's total system is its own different appliance). If anything seems off, or there is good reason to not take the risk, there are plenty of affordable and easy to implement options to keep the whole system, or at least the +5V side of it, running uninterrupted.
Last edited:
That is a good point, but I think most DC power supplies will tolerate 20ms of power loss without issues. Especially if you are using a linear supply and not a switching type. But even a switcher with a decent cap on the rail with do OK with 20ms.
I will test that option out today using several supplies for the BBB.
I will test that option out today using several supplies for the BBB.
I suspect the BBB system alone will likely fine, so long as it's using a PSU that has somewhat more than the minimum voltage drop it requires. I would be more concerned with a whole resulting appliance with more than the BBB sharing the same mains input, for which you can't predict and test enough variables for the user, nor should you.
Each user's end result will be a bit different, and they need to plan for and be able to handle, their appliance as an embedded computer, just as much as a piece of audio equipment. Also, ensuring either good behavior, a need to change, beef up, or separate PSUs, to change settings in the OS (in case it hangs during shutdown, or will not allow software shutdown), or a need to add a UPS, early on, will all be much easier, and generally better, than finding out that it didn't quite work right many months later, after forgetting half of what's inside.
Each user's end result will be a bit different, and they need to plan for and be able to handle, their appliance as an embedded computer, just as much as a piece of audio equipment. Also, ensuring either good behavior, a need to change, beef up, or separate PSUs, to change settings in the OS (in case it hangs during shutdown, or will not allow software shutdown), or a need to add a UPS, early on, will all be much easier, and generally better, than finding out that it didn't quite work right many months later, after forgetting half of what's inside
.
I think to suggest you a very simple, but efficient UPS, or backup solution, which may fit well for the currents used in this project.
Actually there is not exactly an UPS, but more a backup solution to sustain the system while it shutdown.
The absence of 8v can be detected and initiate shutdown sequence. The battery will deliver power to the system at once the diode is unblocked by the absence or too low 8v rail. An quite small cap at the output of the 7805 regulator it can compensate for diode`s switching time. Here is however about very short switching time...
It may be added a charger circuit for the battery and all this "design" put it on a PCB (same dimensions as BBB). A backup cape...
As the battery will be in use very short time, its power can be delivered very long time without charging, but a very simple charging device it can be added.
Actually there is not exactly an UPS, but more a backup solution to sustain the system while it shutdown.
The absence of 8v can be detected and initiate shutdown sequence. The battery will deliver power to the system at once the diode is unblocked by the absence or too low 8v rail. An quite small cap at the output of the 7805 regulator it can compensate for diode`s switching time. Here is however about very short switching time...
It may be added a charger circuit for the battery and all this "design" put it on a PCB (same dimensions as BBB). A backup cape...
As the battery will be in use very short time, its power can be delivered very long time without charging, but a very simple charging device it can be added.
Attachments
Is there a I2S connector on the cape? I'm thinking about connecting a micro controller to read the sample frequency or the meta data of audio stream to display it on a display. Thanks in advance.
Hi Coris, can you please explain that ? How does IT work when you are using Runeaudio like myself or Volumio ? Need to change the source code I guess and use a GPIO ?
By The way, we have been explained several solutions with 60$ To >140 $ add ons. On a 45$ device, that is nonsense for me : better to get a more powerful used netbook, no ? So to stay in the BBB philosophy, imho, we can only afford a 10 to 25$ spent on correcting what appears to be a design problem ?
BR
Jean-Louis
While you could do that, you then to have to deal with fans, greater risk of noise entering your audio, and have lots of space (or substantially higher cost, and still more space, with new fanless parts). A BBB-based device will be passive, not have nearly as much onboard interfacing and regulating to risk noises, and be small enough to tuck behind your receiver, if you so desire, or even inside of it. It's a player, to be put as close as you can to the rest of your playback devices. But, there's no reason a battery backup for the BBB, a DAC, and a low-voltage preamp, combined, should cost even $40, and it could all fit in a small enclosure. Just the BBB should be no more than $25, including shipping, and should be available for less, if you're willing to take your time looking on eBay.
But even so, consider that the BBB itself is a routing device. It can do more, but it's there to take audio from a local disk, or your network, or the internet, and route it to a DAC, while giving you a decent user interface to choose what goes where and when...like a Squeezebox on steroids, that you can customize.
To meet their price points, the BBB and RPi both have lots of less than desirable design choices. But, by meeting those price points, with what they could include at them, they fall at desirable intersections of, "worse is better," "less is more," and, "good enough." So, they are popular, which makes them better than unpopular boards, due to software support; and they are cheap enough for DIY, in that performance failure or device destruction doesn't lead to a very hurt wallet.
But even so, consider that the BBB itself is a routing device. It can do more, but it's there to take audio from a local disk, or your network, or the internet, and route it to a DAC, while giving you a decent user interface to choose what goes where and when...like a Squeezebox on steroids, that you can customize.
To meet their price points, the BBB and RPi both have lots of less than desirable design choices. But, by meeting those price points, with what they could include at them, they fall at desirable intersections of, "worse is better," "less is more," and, "good enough." So, they are popular, which makes them better than unpopular boards, due to software support; and they are cheap enough for DIY, in that performance failure or device destruction doesn't lead to a very hurt wallet.
I agree. Regardless of whether we use external UPS or onboard UPS, the missing piece of the puzzle is shutdown logic.
I had read that some users were already running appropriate code on their BBB to query the onboard power controller ...
and drum roll ... I just found the code here -
https://github.com/pehrtree/beaglebone_snippets/tree/master/power
This is a group of python modules; safe_shutdown.py, powerstatus.py, and daemon.py
If you look at powerstatus.py you will see that the critical command is:
Code:
i2cget -y -f 0 0x24 0xAAs I understand it, for these scripts to work our BBB's Linux distribution needs to include:
- python
- python-smbus
- i2c-dev kernel module
- i2c-tools, particularly i2cget
Can anyone with the requisite skills please check if these utilities can be incorporated into Miero's Debian image?
Or maybe even devise a better version?
I don't understand python, but I suspect that this combination of python scripts is overly complicated. I would have imagined that the critical code from all 3 python scripts could be run from a single bash script?
Hi Jean-Louis
Well, there is illustrated here the idea back a such solution. There are not all the hardware details. But, in my opinion is a cheap, effective and safe solution. It need only to be a little bit more elaborated.
The principle here is that the diode is blocked when it have a higher positive tension level on its cathode, than on its anode. When the higher tension disappear, or goes lower than another one (anode), then the current flows in the desired direction (become open). Using a resistor divider on 8v DC rail one can get a 5v level which it can be detected (as 1/0) further in the BBB system. A "0" on this line, will start a shutdown sequence, or it can simulate pressing of the power down button for BBB, or something else.
At once the 8v rail get lower than 7v on another side of the diode, this it open it, and the battery is connected to the system. Time response in this is as low as the diode time response (extremely low). I`m not sure if the system can actually "feel" this interruption/pulse in DC power...
When battery is coupled (or just after that), the system it runs already its shutdown routine. This mean the system it will be on battery only few seconds, before it stop. The shutdown sequence it can be also elaborated and developed more to cover some other needs, as the time for run it is plenty... It can be run it f. ex. a voice syntheses software which may say:Good bye, I`m shooting down...
When the 8v rail is back, the diode is blocked again and all is all right.
The 8v Dc rail it can well be 9v DC from a very usual 1A wall power device. A reasonable balance it may be in the choice of the higher tension than the battery one, to not load unnecessary the 5v regulator, and increase its dissipation. For 0,5A and 8v-9v on its input, such regulator it feel very conformable with, and an heat sink it should be minimal (natural cooling).
It may be also added a charger solution to this device. for the two flat phone batteries serial connected.
A such solution is defiantly not difficult to put it on a PCB (backup cape). I have some other priorities right now, else I could present a full functioning solution. But maybe someone else it could go further to hardware develop this idea (if necessary...)
Last edited:
I have to agree here. Russ does everything he can to minimise cost and complexity. Many forum members may be wealthy, but some of us have to count every penny.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.