I’m looking at changing from the Gemma to the Beetle for wearable work based on FastLED, and I am looking into power switches and power supplies (easily rechargable!) for this. Dan suggested I ask here, specifically @Robert_Atkins1
Anyone have luck with 3.7v lipoly batteries on the theoretically-5v Beetle?
Any recommendations for power switches that are good for wearable, not super heavy or annoying to work with, and don’t toggle when you look at them askance? Thanks!
A semi-related data point: I’ve run the Beetle on 3xAA cells (4.5v or less as the batteries die) in many different projects. So we know for a fact that it doesn’t need “5.0 volts” exactly. I haven’t tried on 3.7.
Might have to / want to drop the clock speed to 8MHZ?
As for switches for wearables, I really like https://www.adafruit.com/products/1092
You could try one of these 5V power packs:
with a short cable:
I have an Anker 4500mAh one and it powered a Teensy 3.0 and LPD8806 strip of 32 pixels at a low (~25) brightness level for 8 hours, and there was still battery left.
That’s so obvious @marmil … thanks!
I have used the AA Boost Module V2 from DFRobot with the Beetle (http://www.dfrobot.com/index.php?route=product/product&path=48&product_id=991) . I learned about the AA Boost Module V2 in a post by @Mark_Kriegsman . It works well with the Beetle and it is very small. Also, I have used the Limefuel 15000mAh External Battery Pack with the Beetle, too. I was powering a string of 50 WS2811 pixels or the 8X8 NeoPixel Matrix with either battery source.
Re: phone charger power bank:
Oh yeah! That!
For what it’s worth (possibly nothing), that’s a pretty inefficient battery setup. The boost from the native 3.7(ish) volts on ‘phone charger power banks’ is relatively ineffiencient-- because mostly: who cares how efficient it is as long as it charges your phone?
On the other hand, it’s dead simple to buy and integrate and use. It just winds up being physically larger for the available power than a ‘native’ 3.7v solution.
I also love the DF Robot boost module; much more efficient than most phone chargers. A native 3.7v solution is most efficient of all.
I don’t know if anyone else has shared this experience, but I got a whole mess of beetle boards a while back and found that the bootloaders were crap. I could upload code once or maybe twice and after that the beetle wouldn’t accept any new code. This happened on all 8 od the boards I tried. I might have gotten a bad batch but I’d say don’t use them for prototyping, wait until your code is perfect before uploading anything.
The three Beetle boards I’ve used didn’t have that problem. I uploaded code to each a few dozen times.
Sorry to hear you had that mess Erin. Did DFRobot send you new ones or give you a refund or anything?
So for a couple of technical reasons, it’s much easier to “brick” a Leonardo-family MCU (using the ATmega32U4) versus an UNO (using the ATmega328p) in such a way that the only recourse is to reprogram it via the six little pins on the ICSP header.
I have bricked Beetles and plain Leonardos like this aplenty, and it’s not hard. If your code causes a hard lockup or reset, you may not be able to UNlock it without a second Arduino and reflashing via the (annoying) ICSP port.
So as usual, @Erin_St_Blaine is quite right: do your code development on an UNO, and get the bugs all out first. THEN port it over and use the Leonardo or Beetle in the final installation.
I’m guessing bricking it in a way that you need to actually reprogram it via ICSP port is different from the fix of just resetting it as noted on the wiki page here?
http://www.dfrobot.com/wiki/index.php/Beetle_SKU:DFR0282#Trouble_shooting
So sometimes that does help, absolutely. But if you’ve loaded a sketch that basically locks up the MCU as soon as it boots … it’s hard to get out of that loop. That’s one of the reasons why often we’ll often start sketches with a three-second delay: to help get in to reflash before it locks up again.
As Nico Hood will tell you, the UNO has TWO MCUs: one that runs your sketch and one that deals with reflashing and updating. Even if you lock the main MCU, the reflasher MCU can still force new code into it.
On the Leonardo (or Beetle), there’s only one MCU that runs your sketch AND deals with communication and reflashing. If you put code on it that one MCU that locks it up on boot, you need a second MCU to flash new code into it via the ICSP port… ew.
I do generally use an Uno for prototyping, if for no other reason than I can plug leads into it without needing to solder or use a breadboard; but I haven’t had any problems with the Beetles aside from the one I accidentally offered 12VDC to…