Always-On Battery Draw for Seeed XIAO BLE Sense nRF52840

Community
,
1

Hi!

I am making a board-game timer device using the Seeed XIAO BLE Sense nRF52840 and 19 LEDs. I can estimate the draw of the LEDs, but I have no idea how much the MCU will draw. It will be always on (no deep sleep) and it will be using the BLE to connect to a phone. It will be ready to receive data at any time, but it will actually receive or send data only every two minutes or so. Each data burst is small. It will also use the accelerometer to detect movement. I will be running CircuitPython on it.

What is the ballpark mA draw from such usage (not counting the LEDs)? Ballpark is fine. I just want to make sure I get the right size battery for a 4 hour game.

Thanks!
Gustav

PS. I did search for this info, but I only ever found discussions about deep sleep!

2

Hi there,
Spec’s with BLE connection, I see average between 20.ma and higher 40ma. ,Burst transmitions and it could go higher.
Better approach is to use the battery specs and the online battery calculator, (search links in post for PPK) you’ll find it all, a lot of onfo ,graphs and examples.
HtH
GL :smiley: PJ :v:

3

Oh great, thank you! Can you tell me where you found those numbers? Just so i know where to look for something like this in the future. You says spec, as in specifications? If the seed studio or maybe the chip?

And, 40 mA is less than I expected! Great! I can use a smaller battery.

4

Is this tool helpful?

5

Hi there,
This is from Oli over at Nordic Semi, Basically my device does use the gpio and it switches a darlington pair of FET’s to fire a solenoid so the Devices average Current was Higher in mi Graphs. YMMV but 40ma was the target I used to stay under as he recommended, Way under (sleep most of the time) is much more efficient.

"Hi,
50 mA should be enough. If you use LDO mode and use output power of 8dBm (max on nRF52840) the radio itself will draw almost 30 mA from VDD, If you add CPU run current and other miscellaneous things you will still be under 40 mA. The total peak current consumption of the nRF52840 should always be lower than this (assuming you don’t sink or source any significant current on the gpio pins). Note that this is the least efficient mode of the nRF52840 and not recommended for power efficient designs. If you enable the on-chip DCDC converter(s), the current consumption will be much lower for the same voltage on VDD.

You know that the nRF52840 has a “high voltage” DCDC converter with a maximum input voltage of 5.5V. This is in addition to the “low voltage” DCDC converter with a maximum voltage input of 3.6V, like the one on nRF52832. See the Product Specification for more information. In addition to powering the nRF52840 the high voltage regulator can supply external components with up to 25mA through VDD."

If your device is always plugged into usb, you can power the externals up to 25ma.@5V
HTH
GL :slight_smile: PJ

6

I was debating posting a topic for this, but it’s sort of the same question, so possibly worth keeping to the same thread?

I’ve been designing a smartwatch, so my usage is xiao nrf52840 or xiao nrf52840 sense connected to a linux device via bluetooth (I need to consider power draw from the accelerometer + how much more power it’ll draw to communicate step count to another device if I even want to bother with that).

I’m aiming for feature light (I’m using a 0.42” monochrome oled, so it couldn’t be feature heavy if I wanted it to be), and what I reckon is feasible is:

  1. piezo buzzers for notifications (calls/texts/emails - counter of unread notifications when it updates as the basic feature, some subject line/sender info/detail as a nice to have if it’s even legible on that small a screen)
  2. showing the daily sunset time (4 digits once a day)
  3. date (don’t need the month or year, so 1 or 2 digits once a day - you’d have thought I could have a rolling counter stored locally, but then if I’m away and it loses charge, I wasn’t planning on using an RTC ideally)
  4. step counter (optional)
  5. space invaders controlled by rotary encoder + pushbutton (essential)

These are all going to be selectable from scrolling menus ideally, but I can use morse style button shortcuts (e.g. 1 short press for select, 2 short press for back, 3 short presses for text menu e.t.c.). Of those, 1 - 3 are sent from a linux device to the nrf52, and 4 is from the nrf52 to the linux, 5 doesn’t really have any bearing on anything, but I thought it was fun. Software I can do happily, but I’ve never been great at networking, so I was wondering:

  1. for receiving notifications, what’s the most power efficient way to get them in real time on the xiao ble/ble sense? As far as “real time” goes, I can compromise about as far as maybe checking every 3-4 seconds top whack (i.e. how long does it take for a call to stop ringing), but then I’ve read all sorts on staying paired being more efficient

  2. is there a signficant difference in power draw between sending/receiving data? The pedometer is optional, more of a “nice to have”. As an extra stretch goal of sorts - if I even have room in the case, I was even considering a UART GPS module (depending on how the watch case affects the antenna - gps is for running routes, so only on when I press a button to start tracking/off again when the run ends), but this is all data that I’d have to store on the nrf52 and then send to the phone over ble. Storing I’m happy to do, and sending I’d have to do after a running route, and potentially whenever pinged for the pedometer (option 1 is: I open app to check on smart watch → device polls smartwatch for info → smartwatch sends back step count. option 2 is: every x seconds/minutes/hours, smart watch sends info to phone)

  3. I was going to use this as a starting point for my code (device_root_2), but I’m not all that familiar with ble. I know I’ll need to get back to basics and learn how to send a hello world - particularly if I’m sending info with the alerts, but is that the right starting point, or have I got the wrong end of the stick?

Strong chance I’m asking entirely the wrong questions here, and I suspect part of the answer is going to be “buy a board and try it out”, but I didn’t want to waste £15 and an innocent nrf52 until I was sure it could do at least most of the must haves on a tiny tiny battery (in my head I’m budgeting 200mah for a full day’s use :grimacing: . I’m hoping that’s going to be less to minimise charge cycles, and I know it’ll depend on radios in use, but if I could go lower for a full 24 hours so I’ve got room to spare, that’d be very good).

Do let me know if I’m asking the wrong questions here, and feel free to ask for more details if you need them. Iirc, not accounting for cpu usage, the screen I’m using supposedly uses something like 630 micro amps for 50% of pixels on (there’s no contrast options apparently, and I’ll be avoiding updating where I can), so assuming I can keep the screen on during light sleep, I should be able to keep the board at least in light sleep most of the time, add a mode for deep sleep on button press, and wake for bluetooth (assuming I’ve got that right about bluetooth, which is the risk here)

apologies for necroing

7

@debate_haver57 Your smartwatch design is feasible if you optimize power usage carefully.
Keep BLE connected using long intervals to minimize energy consumption. Avoid polling; instead use GATT notifications for efficient updates. Transmission versus reception power differences are negligible in practice. Focus on reducing how often the radio wakes, not direction. Use the accelerometer’s built-in step detection with interrupts enabled. This prevents continuous MCU wakeups and saves significant power. Your OLED display will likely dominate overall energy consumption. Limit redraws and avoid unnecessary updates to conserve battery. Keeping the display always on is acceptable but costly. GPS is extremely power-hungry and should remain optional. Use it only during short, intentional activity sessions. Store data locally and sync when the phone requests it. A pull-based model with occasional push updates works best. System ON sleep will handle most low-power operation seamlessly. BLE stack manages wakeups automatically during connection events. Your 200mAh battery target is realistic for multiple days usage. Expect several days runtime without aggressive optimization. Start BLE development with simple services before scaling complexity. Overall, your approach is sound with manageable engineering tradeoffs.

1 Like
8

Thanks, this has been extremely helpful, I’ll get a board and start messing with GATT notifications.

Screen updates should be easy enough to avoid, I can use gpio interrupts for button events, and initially have some generic catch all “refresh screen” method, which I can then optimise further to do it like a windows app and just update the necessary parts.

Wrt GPS, definitely just for runs. I’ve got a GPS on the phone, and I don’t need the redundancy, so having that manually switched on and off should be fine

This is also the first time I think I’ve had a project I’ve planned called feasible, and been told my approach is sound! Either I’ve grown over my last project, I’ve gotten more realistic with my ambitions (I have only mentioned the electronic parts of this watch here to be fair), or a bit of both (it’s probably both). The next challenge is going to be avoiding feature creep. I’ve already convinced myself I can work a light meter into it (using a veml7700 - not the adadruit one, I mean literally the IC itself + required caps/pull up resistors, I’ve done smaller chips)