• 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.
The cape does have the ability to pull PWR_BTN low and does monitor "power good" from the charger. The cape is normally passive here - just presenting the information via I2C for Linux applications and responding to I2C commands. However, it'd be an easy change to have it hold the power button for 8 seconds after some programmable duration of power loss.
 
Hmmm...

I power my current Linux server (Mobo, small flash drive for OS, 1.5 HD for storage, and an SOtM USB out card) with an internal LiFePO4 battery supply, using a separately filtered and regulated leg for the SOtM card. It is set up so that the server can run while the charger is active or disconnected.
Why not power a BBB/Botic the same way? This way you avoid a possibility of power interruption as long as you keep the battery in a decent charge state, and you get the further benefit of mot having any computer connected to the mains and spewing noise bakc into your other components. The current draw of the BBB is so low you will not even need a really big pack.
For critical listening you disconnect, and unplug from the wall, the charger, the rest of the time you can just leave the charger connected.
 
Member
Joined 2003
Paid Member
Barrows, I saw your postings on that server on Computer Audiophile...

<SNIP>Why not power a BBB/Botic the same way? This way you avoid a possibility of power interruption as long as you keep the battery in a decent charge state, and you get the further benefit of mot having any computer connected to the mains and spewing noise bakc into your other components. The current draw of the BBB is so low you will not even need a really big pack.
For critical listening you disconnect, and unplug from the wall, the charger, the rest of the time you can just leave the charger connected.

+1 as a way of integrating a battery with the BBB

Greg in Mississippi
 
I power my current Linux server (Mobo, small flash drive for OS, 1.5 HD for storage, and an SOtM USB out card) with an internal LiFePO4 battery supply
...

It is set up so that the server can run while the charger is active or disconnected.
No different from the "option i" under discussion here (first mentioned in post #874).
The only limitation with the BBB's onboard battery management system is a maximum LiPo battery size of 3000mAh. This should get about 7 hours run time between charges - assuming the Botic cape is powered separately.
 
Trying to pull these various elements together in my thinking I've arrived here...


  • Use the BBB as an appliance, 'permanently' running. As it's network connected it can be administered/shutdown/etc. remotely via a tool like puTTy with only a little inconvenience.
  • For serious listening, power the BBB with a suitable battery only (6-7hrs duration would generally work for me).
  • At all other times use a suitable (linear) power supply to run the BBB, using the BBB's internal power management to recharge the battery.

It shouldn't be too hard to implement a 'standby' switch arrangement that turns on the power supplies for the DAC and I/V and disconnects the BBB's linear supply at the start of a listening session and then reverses it at the end of a session.

I believe that running the BBB from a circa 4V battery means USB power will not be available on the BBB so assume USB storage devices won't function - not a problem for me.

I'm guessing that Botic will need it's own 5V supply to run its onboard regulators?

As the Botic will be providing clocking to the Botic are there any implications of powering the Botic up/down with the BBB still running - care to comment Russ/miero?

Ray
 
The 5V line on BBB and Botic cape are shared.

BBB can power the Botic up/down via GPIO pin - there is voltage regulator with a switch on the cape.

Cape will have battery pin for BBB, but only for powering BBB and not for cape - because 5V is not available when BBB is running on battery.
 
BBB

Hi.

I have been reading through this thread roughly. Hope that i can get this answered, cause it's not all clear to me!

The issue with the batteri/shutdown-script, isen't it just because, one want to make the BBB shutdown gracefully, even when power is unplugged?
Or is there other isues.

Shutdown gracefully, makes the read-write filesystems on the mmc card, sync and write data, before power is cut/standby, right?

Ideally, would it then be, booting into initrd, and newer leave that?,
Soo that most filefsystems remains readonly? (Usr/ ... /lib ... Etc...)

Just a thought

Regards Jesper
 
Hi.

I have been reading through this thread roughly. Hope that i can get this answered, cause it's not all clear to me!

The issue with the batteri/shutdown-script, isen't it just because, one want to make the BBB shutdown gracefully, even when power is unplugged?
Or is there other isues.

Shutdown gracefully, makes the read-write filesystems on the mmc card, sync and write data, before power is cut/standby, right?

Ideally, would it then be, booting into initrd, and newer leave that?,
Soo that most filefsystems remains readonly? (Usr/ ... /lib ... Etc...)

Just a thought

Regards Jesper

My understanding is that just pulling the plug risks killing the BBB device.

Ray
 
Hi.

My understanding is that just pulling the plug risks killing the BBB device.

Ray

I find it hard to understand (not that i did not read that somewhere!),
that it's possible to damage the "hardware", by just pulling the plug!

Is this something, which is confirmed?
My guess is, that it's only kernel/files etc... which is corrupted when unplugging power...

The case is, that if everything is run from initrd, and kernel/usr etc... is RO(Readonly), corruption cannot occour!

Hope, we can discuss this a bit here, as i find it very interessting :cool:

Jesper.
 
Think i found something in BBB manual :)

5.10 Power Button
A power button is provided near the reset button close to the Ethernet connector. This
button takes advantage of the input to the PMIC for power down features. While a lot of
capes have a button, it was decided to add this feature to the board to ensure everyone
had access to some new features. These features include:
 Interrupt is sent to the processor to facilitate an orderly shutdown to save files and
to un-mount drives.
 Provides ability to let processor put board into a sleep mode to save power.
 Can alert processor to wake up from sleep mode and restore state before sleep was
entered.
If you hold the button down longer than 8 seconds, the board will power off if you release
the button when the power LED turns off. If you continue to hold it, the board will power
back up completing a power cycle.
We recommend that you use this method to power down the board. It will also help
prevent contamination of the SD card or the eMMC.
If you do not remove the power jack, you can press the button again and the board will
power up.
]

Contamination, does not mean "destroy" Right ???

I also read about some powerdown sequenze, where some pins with voltage, can destroy board... find it hard to understand though !

Jesper.
 
Member
Joined 2006
Paid Member
It would make sense if there were a choice in the streamer software build providing a method to shut down the rPi or BBB, when you are going to power down the appliance that the device is embedded in.

An example would be a menu choice or icon on the remote control program to send a shut down command to the rPi/BBB. When finished the music session, push the shutdown button, then turn the DAC, or whatever off.

This would be useful more for an embedded rPi/BBB, and of course still not optimal. Certainly there could be provisions for an onboard capacitor, or outboard battery/capacitor, that would provide power for orderly shutdown in the case of loss of main power.
 
Hi...

Glad to see, software / hardware shutdown is discussed :)

Is the cape software debian based, or another distro like ? (Sry did not read that anywhere)

Regarding the RPI, there is no problems, when OS are run entirely on RAM, to just cutoff power (SD card can only corrupt, when filesystem is readwrite)
I have been cutting the power, at my diy piCore RPI player for months, without any problems, and i have both LCD, and IR reciever attached at GPIO pins.
Filesystem is run entirely from RAM (initrd)

I think, for embedded, that kind of distro is perfect (tinycore / picore)

Just another thought

Best regards... Jesper
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.