Compatibility of Puck.js with Rechargeable Coin Batteries

Hello everyone,

I tried reaching out to Espruino Support about this a week ago but didn't get a response, so I'm hoping someone here can help.

I'm curious about using rechargeable coin batteries with the Puck.js. I know it's designed for standard coin cell batteries that provide around 3V, but I want to use rechargeable ones, which often have a higher voltage.

Here are my questions:

• Does the Puck.js support the use of rechargeable coin batteries with a voltage higher than 3V?

• If so, what is the maximum voltage that the Puck.js can safely handle without risking damage to the device?

• Are there any specific recommendations or precautions I should be aware of when using rechargeable batteries with the Puck.js?

Thanks in advance for any help!

Best regards,
Cyyy

Hi,

Sorry you didn't get a response - how did you try and contact us?

The Puck has a voltage range of up to 3.6v - although the absolute maximum is a little higher, so going 0.1v or so above that isn't a big deal.

However if you're talking about the LR2032 type batteries, these are marked as 3.6v but since they're LiPo when they come off the charger they can be near 4.2v, which is way too high.

Potentially you could use those if you ensured they were run down a bit so the voltage was lower, but it's a big risk.

However it looks like Maxwell do the ML2032 which uses a different chemistry and has a voltage that's well within range, so you can use that: https://www.maxell.com.tw/images/uploads/2015/05/ML2032_DataSheet_table.pdf

Also I'm not even sure if they exist, but if you could get a LiFePO4 based CR2032 cell, that would have a voltage that'd work great as well.

Earlier Puck.js versions did actually have a PCB trace you could cut and the ability to add an SMD diode to drop the voltage for LR2032, but there was so little interest it got removed for all the most recent ones

Sorry you didn't get a response - how did you try and contact us?

I did send a Email to contact@espruino.com since that was the support email adress i found over google.

However if you're talking about the LR2032 type batteries, these are marked as 3.6v but since they're LiPo when they come off the charger they can be near 4.2v, which is way too high.

I was looking on Amazon for rechargable CR2032 alternatives, and found as an example the LIR2032 (the package says they are 3.7v). I have also found others who say they are 3.6v from random companys, but i was unsure if they are really 3.6v & if my Puck.js would break from those since it usually only has to deal with 3v from normal CR2032's.

However it looks like Maxwell do the ML2032 which uses a different chemistry and has a voltage that's well within range

That's nice to hear! The ML2032 was one of the types i was looking at and wondered if it would work.

My Main Application for my Puck.js uses daily around 30-60 Minutes of running code which is requesting Accelerometer Data once a second. This results in one battery only lasting around a month, and i wanted to prevent having to buy always new batterys all the time. So i thought getting rechargeable alternatives for the CR2032 would be smarter since it is easier to just recharge than buying new ones all the time. That's mainly why i wanted to know this.

So thanks for the quick response & for helping me :)!
Hearing that the ML2032 should work is good, because i was really worried i destroy my puck.js by accident if i just test it out myself.

I wish you a nice day,
Cyyy

Sorry about that - I'll check if it got marked as spam or something.

But yes, all the 3.6/3.7v batteries are going to be Li-ion/Lipo which have the kind of discharge curve you see attached (image from https://www.dnkpower.com/lithium-polymer-battery-guide/) - so unfortunately just a little too much voltage.

But those ML2032 should be just the ticket (although each one is 65mAh vs the ~@220mAh for a CR2032 so will need changing more regularly). You'll just have to be careful you get the right charger for them. I guess you might be able to put a connector on the Puck and then charge it up without having to take the battery out, which would be a neat addition.

1 Attachment

• discharging-curve-lipo-battery.webp

Thank you for your helpful response!

I've been closely monitoring my battery levels, especially considering my specific usage pattern. To provide more context, my usage primarily involves requesting an accelerometer reading once a second (with Puck.accel()) and utilizing the LED lights as status indicators.

The LED lights are used solely as status indicators to reflect the activation or deactivation of certain functions in my code. This is achieved through specific button presses of varying lengths, which then trigger LED patterns and colors to signify the enabled functions.

Overall, my usage scenario involves relatively light activity, with the accelerometer readings and LED indicators (on button presses, which don't happen often) active for about 1-2 hours a day at most.

Despite this usage pattern, I've noticed a significant discrepancy in the battery readings provided by E.getBattery(). According to it, my battery seems to be depleting quite rapidly, dropping from 100% to 40% in just around 6-7 days.

While I understand that E.getBattery() is an estimation, I find it a bit extreme for the battery to deplete from 100% to 40% in such a short span of time - even if its just a rough estimation. I'm currently using LiCB CR2032 batteries purchased from Amazon. Could you kindly confirm if E.getBattery() is accurate to indicate how much % is left in the battery in scenarios like mine or if there might be other factors influencing the readings? Your insights would be immensely helpful!

EDIT: My Battery Charge just drained from 40-45% yesterday over night down to 15%.. without actively executing any code. Something is really weird.

Greetings,
Cyyy

E.getBattery() is a useful finger in the air measure, but it's not super accurate because it uses voltage and the voltage of the cells doesn't vary that much with how depleted they are until right at the end. Maybe trust it within ~20%...

You can use E.getPowerUsage() in 2v22 firmware to get an idea of instantaneous power draw.

But just some notes:

• If you want acceletometer once a second, use Puck.accelOn(1.6) and Puck.on('accel', fn) - that will be 1.6 times a second, but will be a lot more efficient keeping the accelerometer on than repeatedly turning on on and off like you were doing (even if you run it faster than than and throw readings away)
  
• LED lights draw a lot of power 8mA vs 0.04mA for the accelerometer - try blinking them for ~100ms or so, or use pinMode(LED1,"input_pullup") to turn them on very dim rather than leaving them lit (if that's what you were doing)
  
  

Also if you're staying connected to the Puck via Bluetooth consider using NRF.setConnectionInterval(100) - it slows down data transfer but forces the Puck to use a lower power bluetooth mode.

Thanks a lot!

I checked with E.getPowerUsage() what my PowerUsage was, and BLE took around 600-700, while the cpu was around 100-200 or so. I have now set NRF.setConnectionInterval() to 50 - it is now slower for uploading code, but reduced the PowerUsage to only around 50-100~ compared with 600-700 it took before (i also implemented a "switching bluetooth off / on by pressing the button 15 seconds" to save battery even more if i don't actively need bluetooth).

I also found out that the PMW was eating continous 200 Power, and it seems to go away if i reset each LED after using the LEDs. So i don't know if this added to the battery drain if it did run 24/7 all the time without me noticing (and even after setting the Leds brightness all to 0).

Before i did this fixes, it was around 1000-1400 Power Useage overall. Now it's way way less.

If you want acceletometer once a second, use Puck.accelOn(1.6) and Puck.on('accel', fn) - that will be 1.6 times a second, but will be a lot more efficient keeping the accelerometer on than repeatedly turning on on and off like you were doing (even if you run it faster than than and throw readings away)

I assumed that just requesting one reading a second would be more performant than having the accelerometer readings run all the time. It's good to know that this is not the case and i can save more energy if i do it this way. Thanks for this tip!

LED lights draw a lot of power 8mA vs 0.04mA for the accelerometer - try blinking them for ~100ms or so, or use pinMode(LED1,"input_pullup") to turn them on very dim rather than leaving them lit (if that's what you were doing)

I have written me a function to switch on & off the leds like this:

function SetLights(r, g, b)
{
 //RED, GREEN, BLUE
 var LED_R   = LED1;
 var LED_G = LED2;
 var LED_B  = LED3;	
	
 analogWrite(LED_R, r);
 analogWrite(LED_G, g);
 analogWrite(LED_B, b);
}

i use it normally by SetLights(1,0,0); as an example. But i also need a red light that adjusts in brightness to indicate the value of a variable as a visual feedback, so i also use SetLights(0.3,0,0); as an example. To reset the LEDs i did just set the value for the analogWrite() to 0. But it seems this did let the PMW run in background 24/7 from what i see in the E.PowerUseage. I have fixed this now thought by resetting the LEDs each time after i used the LEDs.

The Battery which had yesterday 40-45% and then today only 15% left was completly drained after reach around 2volt. So seems E.getBattery() was accurate.

Thanks again for the helpful advice!
Cyyy

Ok, great! It may be that E.getPowerUsage() is wrong about analogWrite(LED_R, 0); - I believe that does shut off PWM and so doesn't use power - but anything between 0 and 1 will use PWM.

Even so it doesn't hurt to do LED_R.reset()/digitalWrite(LED_R,0)/etc

I just wanted to give a quick update. The changes i made in my code have helped a lot. The battery i had replaced 8 days ago is still at 100%. So disabling bluetooth announcing while i don't need it, resetting the LEDs and the other things you recommended really helped a lot!

Thanks again for the help :)!