• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Building an open embedded audio applicance.

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Were any definitive conclusions arrived at concerning power up/down of the BBB/Botic?
UPS/auto-shutdown options were discussed initially from post #872 (page 88) to post #908 (page 91).
I think it's fair to say there was a general consensus that backup power is important for the BBB, but there was no consensus about how it should best be implemented.
Broadly, the UPS solutions discussed so far fall into these 3 categories:

i) internally managed UPS, via the BBB's onboard TPS65217C PMIC chip, plus directly connected LiPo/Li-ion battery.
ii) external UPS at the 5VDC power input of the BBB.
iii) external UPS at the AC supply to the 5V DC converter.

Any/all of these may include some form of logic control to shut down the BBB when power outage is detected.


There's also this CW2. Pi UPS - The UPS for Raspberry Pi
which I posted before, but it seemed to go unnoticed.
That product was originally mentioned at the end of the series of posts I just mentioned: post #908 on page 91.
I don't consider it to have been overlooked. It was a similar product to the one I listed in post #874 -
BeagleBone Power Cape - AndiceLabs
The difference is that the one I mentioned is pin-compatible with the hardware that's mainly the focus of this forum thread; the BeagleBone Black.
 
UPS/auto-shutdown options were discussed initially from post #872 (page 88) to post #908 (page 91).
I think it's fair to say there was a general consensus that backup power is important for the BBB, but there was no consensus about how it should best be implemented.
Broadly, the UPS solutions discussed so far fall into these 3 categories:

i) internally managed UPS, via the BBB's onboard TPS65217C PMIC chip, plus directly connected LiPo/Li-ion battery.
ii) external UPS at the 5VDC power input of the BBB.
iii) external UPS at the AC supply to the 5V DC converter.

Any/all of these may include some form of logic control to shut down the BBB when power outage is detected.



That product was originally mentioned at the end of the series of posts I just mentioned: post #908 on page 91.
I don't consider it to have been overlooked. It was a similar product to the one I listed in post #874 -
BeagleBone Power Cape - AndiceLabs
The difference is that the one I mentioned is pin-compatible with the hardware that's mainly the focus of this forum thread; the BeagleBone Black.

Thanks linuxfan. I read through the posts you mention and concluded much the same as you with respect to ups possibilities; was just wondering if Russ had extracted a preferred solution, with maybe some Botic design implications?

With regard to power up, I'm assuming that energising the chosen power supply will boot the BBB perfectly adequately. I believe Russ is taking care of the power management between the BBB & Botic to avoid any issues.

With power down, the approach seems to be to simply turn off the power supply, go to battery backup, which triggers a shutdown command? If so, how is the shutdown command initiated - I need to read up on it. I believe the BBB power management keeps the UPS battery charged - more to read up on.

Ray
 
was just wondering if Russ had extracted a preferred solution, with maybe some Botic design implications?
Russ has facilitated the "internal" solution I mentioned above, by adding various power and battery headers/connectors to the cape. Refer to posts #876 and #881.
But you will see in post #894 that Russ now prefers an external AC UPS solution, thus negating the need for power management and LiPo battery at the BBB, itself.


With power down, the approach seems to be to simply turn off the power supply, go to battery backup, which triggers a shutdown command? If so, how is the shutdown command initiated
This will vary, depending on the UPS solution you choose. If an external UPS method is chosen (which I listed above as options ii and iii) then that external device must generate some form of trigger when power changeover occurs, which can be sent to the BBB across the USB bus, or as a GPIO event.
The AC UPS hardware that Russ recommended, for example, successfully initiates a BBB shutdown via USB. In this case apcupsd needs to be installed and running on the BBB.

If the internal UPS method is chosen, you need to run some form of daemon script on the BBB which will query the TPS65217C PMIC regarding power status, then if "battery" mode is reported (meaning main supply has failed) go ahead and issue the shutdown command.
You will see in my post #903 that I mentioned a series of such scripts, written in python, but more recently I prefer the simplicity of a single python script suggested on the Beaglebone forum by "madart9" -
BeagleBone Black: BBB - Rechargeable on-board b... | element14
I will investigate and experiment further with this script once I obtain my own BBB.
 
That product was originally mentioned at the end of the series of posts I just mentioned: post #908 on page 91.
I don't consider it to have been overlooked. It was a similar product to the one I listed in post #874 -
BeagleBone Power Cape - AndiceLabs
The difference is that the one I mentioned is pin-compatible with the hardware that's mainly the focus of this forum thread; the BeagleBone Black.

Yes, I mentioned it. It certainly is similar to that device, but much cheaper for those outside the US. It also says that it's compatible with the BBB.
 
Well I would really prefer that the BBB would tolerate power outages without harm to the filesystem, and require no UPS at all!!

But in the real world, yes, I'm leaning towards the internal UPS method. A small concern here is the potential processing impost created by running daemon scripts on the BBB. Before anyone laughs at me for this, I'm used to running Linux on ancient hardware, such as a Pentium2-350, where such daemon processes can/do have a noticeable impact.

External 5V UPS units would seem to be ideal, except that I know they rely on buck–boost converters, which add significant noise to their DC power output. Yes, I know, this may be of little concern to an embedded computer, which has noisy onboard regulators, itself. But if you believe the stories about the SqueezeBox sounding better when fed with a good linear 5V supply, then such a benefit for the BBB would be effectively sabotaged if you were to put a 5V UPS unit in series with such a DC supply.

Regarding AC UPS units, I think of these as "industrial strength" devices, and I can't help thinking that such an approach is overkill for a small computer which draws less than 500mA at 5V.
 
Sorry for jumping in here but I can help with the topic of the PowerCape (it's mine). It does use a buck-boost regulator out of necessity due to the voltages involved. But, the regulator runs at 2.4MHz which should minimize ripple and noise in the audio frequencies. Plus, it's upstream from the PMIC's linear regulators so there should be plenty of filtering downstream.

Monitoring power loss in the cape or PMIC case would be an infrequent I2C transaction to determine the state of AC power so I wouldn't worry too much about it. However, I'd personally be wary of inviting USB to the party...

-Ron
 
Thanks linuxfan, I prefer the same approach of an internal 'UPS' and will be interested in your deliberations.

A small concern here is the potential processing impost created by running daemon scripts on the BBB.

I don't think this will address your specific concern as I think the polling processes will still be required but I came across this statement in the Beaglebone Forum thread you referenced a few posts back (post by Shabaz on April 8 2014);

"For the scenario that a backup supply is needed momentarily for when main power is removed (for a graceful shutdown), I've noticed the recent debian images will initiate a shutdown automatically, assuming that a LiPo is directly connected. Power-up occurs when the main supply is reconnected, or via the switch on the BBB (for battery-only power, or if the BBB was shutdown using the switch rather than accidental main power disconnect). "

Is this functionality in miero's distribution? It would seem to remove the scripting requirement and may mean that those already running BBB renderers, sans Botic, are absorbing the processing overhead? I already have a BBB so I could order a battery pack and try it but I'm reluctant to risk terminating my BBB through an uncontrolled shutdown without at least knowing that it is supposed to work as described.

Ray
 
nautibuoy, yes, I'm aware of the auto-shutdown function you referenced. In fact I mentioned it in post #883.
It's not a standard feature, per se. It's a specific modification to the kernel, which the developers of the BBB release of Debian have chosen to include.

Is this functionality in miero's distribution?
Well you could ask miero, but I don't think so, because miero doesn't use the "normal" Debian kernel, he compiles his own modified kernel for DSD support.
I, for one, don't believe that this auto-shutdown modification should be enabled, because it "hard-codes" the auto-shutdown feature. I believe the feature should be enabled only if the end-user chooses to do so.
 
It does use a buck-boost regulator out of necessity due to the voltages involved. But, the regulator runs at 2.4MHz which should minimize ripple and noise in the audio frequencies.
Thanks Ron. This information is assuring.
Regarding functionality, we would need the Power Cape to activate a switch closure for exactly 8 seconds between the BBB's P9.9 (PWR_BTN) and P9.1 (GND) when input power loss is detected ...
... however, I believe that a brief period of power outage - let's say 5 seconds or less - is acceptable, so I would prefer the Power Cape to activate this switch event only if the power outage is sustained for 5 seconds.
Is this easy to achieve? Or would the code for your device need to be custom-written for such a situation?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.