Has anyone tested the XIAO nrf54l15 with a coin battery or something like the CR123A?
I’ve ported my matter app from the xiao nrf52840 to the xiao nrf54l15. The previous device uses a CR123 or a CR2032. Power is driven from the 3.3V pin. When I try this on the xiao nrf54l15 the current usage is around 450uA. However, if I supply power on the 5V pin with 4V (the value shown on the getting started page) I see systemOn and systemOff numbers as expected. @msfujino reported similar numbers in a comparison of multiple boards with power supplied on the VBAT pins and I think 3.8V.
When I posted on the seeed wiki that the zephyr-lowpower device tree wasn’t working correctly for low power, Bleaach responded with:
“The battery interface on the back of the device must be used for power supply. … It is recommended to use a power supply with a voltage of 3.7V - 4.2V. This range matches the hardware design of the device.”
I looked at the schematic and I didn’t see a way to disable the charging circuit, so it looks like it is meant for only a rechargeable lithium battery. Maybe I’m missing something here.
I only see the VSYS_3V3 going to the 54l15, the voltage regulator, and the logic level shifter. I don’t see any protection on the output of the voltage regulator, so maybe there is a backfeed problem consuming power when supplying power on the 3V3 pin.
I hope someone knows more here. I would be disappointed if this board doesn’t work with low power on a non-rechargable battery.
I used the settings below in the .overlay file to achieve the same thing.
This is why the board files on the zephyr branch that we discussed on the getting started comment section worked correctly for the zephyr_lowpower example. Those values are not set there, so the regulators are not on at startup. I think this is working because I see the expected low current usage when supplying voltage on the 5V pin. Without those settings, the current usage is high.
I also tried the MG24, which has nearly identical circuitry except for the level shifter, and it similarly draws around 450uA.
However, both the MG24 and nRF54 drop down to 2uA without issue when powered by 3.3V instead of 3.0V.
This might offer some insight.
SO the Nords list this in the latest info, addressing the Battery power and a couple thread scenerio’s,
Battey lifetime
Let’s consider the battery lifetime of a coin cell battery, specifically CR2032), with a nominal capacity of 225 mAh.
Bluetooth LE advertising
A Bluetooth LE beacon operates by advertising at 0 dBm every 10 seconds. It carries a payload of 31 Bytes, which is the maximum payload for an advertising packet with legacy advertising. With an average consumption of 3.8 µA, the battery can last for over 6 years.
Bluetooth LE connection
Let’s consider a scenario, in which you have a device connected to a central unit with a connection interval of 4 seconds. This setup would decrease the battery lifetime to 5 years and 4 months.
If you’re curious about the power consumption of your specific configuration, see the Online Power Profiler. It allows you to enter your connection settings and will estimate the power consumption for that connection.
Matter over Thread
Let’s consider a device running Matter over Thread on the nRF54L Series. With short idle time (SIT) and default configurations, the battery lifetime extends to 1 year and 7 months. This duration is 4 months longer compared to using the nRF52840 SoC.
In long idle time (LIT), the battery lifetime is over 6 years.
SO keep in mind this is the Silicon Package itself, the Xiao design envelope may add additional overhead, which we all know it does.
either through restrictions or requirements
to me the takeaway is the 225 mAh, I like the slightly thicker but more robust CR2450 Approximately 550 to 620 mAh, depending on the brand. (11 years)
Indeed, Leave it to marketing to get a little “Loose” with the BMS term, LOL…it’s not really, more of a glorified Battery charger.
The PMIC’s they make (Nordic) are the truth. IMO all the (2 pins) used to do the weakest battery monitoring I’ve seen to date is this half measure, using the GPIO’s I say just do the PMIC (i2c) and 1 GPIO for interrupt you gain and save at the same time. SMH but size matters in XIAO!
also worth noting the MAX versions are good too, They have them or similar in the Wio_terminal and the external Battery Pack, Now that is a BMS light!
HTH
GL PJ
BTW, Nordic sent me the PMIC dev kit, I think I posted the pics here somewhere… It comes with every possible setup one would need to fully evaluate the PMIC and the Awesome accessory it is.
the Seeedineers would do well to get one and give it a go.
Can you share how you are powering the device with a coin battery? It operates, but draws a high current. 450-480 uA.
The battery connection on the back doesn’t look appropriate for a non-rechargeable coin battery, and the high current draw is seen if powered at < 3.3V on the 3V3 pin.
Can you share a link to the dev coarse? My search didn’t turn up something obvious.
I found I had to use a “non-XIAO” based NRF54L15 radio module for a low power battery based design.
I also added significant “bulk capacitance” to support the wake and transmit/receive cycles. See this pdf for information.
The Coin Cell has caveats, I’m not using a 2032 , (2450) but it can work also if you follow the guidelines, some are here but the dev academy course has more.
the very astute, @grobasoz is correct and spot on it’s the rule one basically…
Here are the Key considerations for using a coin cell
Voltage compatibility
The nRF54L15 operates within a voltage range of 1.7 V to 3.6 V. A standard 3V lithium coin cell, such as the CR2032, is a good fit for this range.
A fresh CR2032 provides a voltage of 3V, which is well within the nRF54L15’s operational range.
The voltage from the coin cell will drop over time as it discharges, but the nRF54L15 can function until the voltage falls below 1.7 V, maximizing battery life.
Current draw limitations
The primary constraint of using a coin cell is its high internal resistance, which limits the available current.
Low average current: Coin cells are designed for low-drain devices. A standard CR2032 is typically rated for a continuous discharge current of only 0.2 mA.
Pulsed current: While the average current must be low, the battery can supply much higher short-duration currents, such as during radio transmission. The nRF54L15’s radio power consumption is far more efficient than its predecessors, making pulsed operation a good fit for coin cell batteries.
Capacitor solution: To handle high-current radio pulses, you must use a buffer capacitor to supplement the coin cell’s current during transmission peaks. The coin cell will then slowly recharge the capacitor during the device’s sleep periods.
You can configure the DK board to work with a cr2032 fwiw
I use a coin cell on the nRF52840 same caveats, works well.
Sleep,limit Xmit power, turn off ext flash, DC/DC all the trimmings.
More is coming out on the Bare Metal configs too, stay tuned it has support for single slot OTA DFU also.
Limiting factors: A coin cell’s own maximum storage time (typically 4–5 years for a CR2032) is often a limiting factor, as the battery may stop working before it is fully discharged in ultra-low-power applications.
It looks like there is a misunderstanding on the root question of this topic thread.
The question is whether it is practical to run the XIAO nrf54l15 and XIAO MG24 on a coin battery such as the CR2450 or CR2032.
We’re looking for a way to connect and configure so that the coin battery doesn’t draw high current, or confirmation that this configuration is not supported with optimal power usage.
I’m having difficulty powering a XIAO nrf54l15 from the 5v/GND pins on the header. This worked fine on a C3 based board. Any ideas what I’m doing wrong?
It simply won’t power on. I 12v->5v buck regulator is attached to the 5v and GND pins on the “right hand side” of the Xiao. It doesn’t power on at all. Connecting a 5v USB supply works fine.
as much as i believe you… I cant even get my apple watch to hold charge for one day so i am sure it can run for years on a coin cell in sleep mode but i think you are being dis genuious saying you can use it in that way for very long…IMO plus the code has to be very efficient … i just dont want the OP to get his hopes up that he is going to build a wearable that is going to last that long… they
havent invented neucular diamond b
atteries yet