Desired existing open source cape recommendation

Anyone want to nominate an open source cape to go into production via a group buy?

If I don’t get suggestions, I’ll recommend: or

I’d recommend just about any decent UPS type cape with good power management features. e.g. Features that addressed the Beaglebone’s inability to function remotely( well ).

I can recommend our Automotive Cape V2 :wink:

I like the interacto as a demonstration of clever use of the pru for image capture.

I would like to support William’s recommendation for a UPS type cape.

Something that would allow the BBB to operate directly from ~11V to ~21V
Instantly switch to an optional +12V battery if present, upon primary power loss.
Recharge and float the optional +12V battery, if present, after any use.
A couple of status outputs.

Intended for use in server or remote applications of the BBB.
Could also be used as a wide range power supply input without the optional UPS battery.

— Graham

Is the Andice cape readily available already? Is it good for the UPS function?

If someone here is really good at PCB / electronics design, I can verbally explain exactly what needs doing, Also, while I personally do prefer an external style UPS( wide input voltage ). There is probably something to be said for a cape that has an power management micro controller, plus lets say an 18650 LiPo battery holder, etc. I really think having hte ability to use 18650 style batteries would be an awesome feature.

Looks like Andice Labs has two capes of interest.

If you want to run from a single cell lithium, then their “Power Cape” looks interesting.

If you want to run from and maintain a 12V Lead-acid battery, then their “Solar Power Cape” looks interesting.

— Graham

I, and I suspect Jason would prefer to have an open source software /
hardware solution. Something that people could build for themselves, or
just buy from circuitco, or another entity if they'd prefer not to. No idea
if the andice labs solution is open sourced.

So, I'm the software guy wulf mentioned before. Our implementation is rock
solid. But the only boards we've implemented this circuitry into is in a
closed source commercial application, where an NDA is in effect. However,
the MCU source code IP is entirely mine, as well as the idea in general.
This, is for the watchdog / power management aspect. After that,
implementing the rest should be fairly trivial. One feature my design does
not have, which eventually I plan on changing. Is power management /
watchdog program-ability. Which would be super trivial once a
communications protocol was established. I'm leaning towards 1-wire, but
I2C would be just as good, except for the need of an additional data line.
However, if that was hung off one of the existing, and already used I2C
buses, I think that would be ideal. One less pin being used too I think.
The only thing that is holding me back right now aside from not having the
time. Is understanding how to implement a 1-wire, or I2C slave device in

I had thought about open sourcing my software for the MCU we're using, or
perhaps just selling programmed micro controllers. The problem with open
sourcing the software however then becomes knowing how to setup a
toolchain, then flash the binary onto the MCU. Which I'm not sure I
honestly want to get into that whole mess. For a few reasons. I've spent
literally 5-6 years working with this processor to get where I am now with
understanding all of this. So helping others to understand how all this
works, would be a pretty big burden / responsibility. Something at this
point in time I'm not prepared to deal with.

The rest, knowing how many GPIO's one needs for various features is pretty
easy though.

Pretty desparate for some sort of UPS board that would permit reliable untended startup and shutdown. I’d hoped for this with
the original BBB, but better late than never.


Hi all,

First off, I agree with the need for a UPS and power control cape - that’s why I created the Power Cape. The firmware and schematics are available online (yes, I do know that’s not truly OSH).

Back on topic, I think Jason is looking for an existing OSH design that wouldn’t otherwise get built and be generally available. Designing hardware can be fun, but manufacturing it is a pain.

I’ll second the Interacto. I also like the PRU-driven camera.