The BlueJoule™ benchmark — EM•Scope in action
October 29, 2025 · 
6 min read
A basic Bluetooth Low Energy beacon – continually advertising the same packet on multiple channels – serves as the "Hello World" of BLE applications. So let's see what we might learn by using EM•Scope to measure and compare a representative set of BLE HW/SW platforms.
Why we need a benchmark
Bluetooth Low Energy has emerged as pervavsive technology, following its initial availability on the iPhone 4S in October 2011. With a multitude of SW stacks now running on dozens of HW platforms, we find the absence of even the most basic BLE benchmark quite telling.
Promising "5-10 years of operation on coin-cell batteries", a BLE beacon which adverties a small data packet once-per-second should certainly run for half a decade – or will it ??
MCU vendor data sheet : 3.0 V supply → 5 mA TX current @ 0 dB · 1 μA sleep current
Bluetooth 4.0 spec : 1 Mbps data rate · 37 byte packet size · 3 advertising channels
Average current consumption : ≈ ( 0.005radio + 0.001sleep ) mA
CR2032 coin-cell lifetime : 225 mAh ÷ 0.006 mA = 37,500 h ≈ 4.3 years
Well, we almost made it to five years – but in reality, this system would likely run for only half that time. Why – because our paper model hasn't accounted for the extra power consumed when awakening the MCU from deep-sleep as well as executing the BLE stack code itself.
On a personal note
I co-founded a BLE software and system design house in early 2011, working closely with Texas Instruments and others as well as stack vendors supporting these platforms.
Lacking funds for a $10,000 power analyzer, we instead relied upon our multimeter and oscilloscope to give us (crude) visibility into HW/SW power consumption over time.
Today, however, we can purchase a laboratory-grade power analyzer from JouleScope for 10× less the cost as well an entry-level analyzer from Nordic for 100× less the cost.
With power analyzers now available for any budget, let's use their capabilities to explicitly measure the overall energy consumption of a basic BLE beacon – gaining a system-level perspective on the interaction of the underlying HW/SW elements over time.
But wait there's more....
By having different BLE HW/SW platforms implement the same benchmark application, we can quantitatively score their "low-energy" claims and then rank their overall efficiency.
A true "apples-to-apples" comparision – or should we say "blueberries-to-blueberries". 
Bringing EM•Scope to bear
We've introduced EM•Scope in an earlier article – and already previewed some results found in the em-foundation/BlueJoule repository housed on GitHub. Time now for a deeper-dive.
Consistent with the EM•Scope methodology, the BlueJoule benchmark requires the platform-under-test to advertise 19-bytes of payload on all three BLE advertising channels once-per-second. Refer to this section of the BlueJoule ReadMore for more details.
We continue to benchmark a growing catalog of popular BLE devices:
Using a JS220 or PPK2 analyzer, we powered each HW/SW configuration at an "optimal" input voltage when capturing data using EM•Scope. We've also recorded captures for most configurations at a "standard" voltage ≥ 3V0.
Input voltages
The BLE devices in our catalog invariably target systems powered by batteries or harvested energy. Arguably, we should benchmark each configuration at 3V0 and 1V5 – reflecting the nominal voltage sourced by standard batteries.
Some BLE devices already integrate a DC/DC converter to buck · boost the source voltage to an appropriate internal level. In other situations, the device may require an external power-management IC to handle a 3V0 or 1V5 input source.
This approach further reinforces our belief that improving energy efficiency within resource-constrained embedded systems requires a holistic perspective. All the more power – or "all the less energy" – to those devices which can operate directly from a 1V5 input voltage.
In a number of instances, we've also benchmarked the same hardware platform executing different software stacks – with some notable differences, as we'll highlight later.
You'll find the latest set of benchmark scores in this section of the BlueJoule ReadMore.
Mining the EM•eralds
Lots of numbers here 
so let's break down the results: An earlier article introduced the EM•erald as a measure of energy efficiency. Suffice it to say, one EM•erald approximates one month of execution on a CR2032 coin-cell battery – higher score, greater efficiency.
We'll now focus on a handful of JS220 Capture scores, recorded at 3V0 using our high-precision JouleScope analyzer (sampling at 2 MHz).(1) While not necessarily their best scores, these 3V0 captures allow us to check our measurements against vendor datasheets.
- You'll also find PPK2 Capture scores, recorded at 100 kHz using the Nordic analyzer.
Let's begin with the Texas Instruments CC2340R5 · SimpleLink SDK · 3V0 configuration – labeled ti-23-lp/simplelink-3V0 and scoring 28.74 EM•eralds for the 1 s event period. A file named ABOUT.md delivered with each capture contains the next level of benchmark results.
Tip
Links within the BlueJoule Catalog and Capture tables will take you inside the corresponding About.md file for a particular HW/SW configuration.
In addition to more detailed power metrics for active execution as well as "deep-sleep", each ABOUT.md file features a screenshot depicting power consumption over time within a typical BLE advertising event.
So let's now compare the Texas Instruments results with scores captured on competitive devices from Nordic nrf-54-dk/zephyr-3V0 and Silicon Labs sil-g22e-ehk/rail-3V0 :
Right away, we see differences in power consumption when actively transmitting the same 19-bytes packet on all three BLE advertising channels. At almost 17 mW, this leaves Texas Instruments at a slight disadvantage against Nordic [≈ 15 mW] and Silicon Labs [≈ 16 mW].
But standing back and looking at the advertising event as a whole, other factors can contribute to the total amount of power consumed over this period of time:
the time for the HW to transition from "sleep" to "active" mode
the time waiting for a high-frequency radio crystal to stabilize
the time initializing the BLE stack and preparing the radio
the time in transition between one packet and the next
the time to shutdown the stack and re-enter "sleep"
Each of the HW/SW platforms benchmarked here has its own strengths and weaknesses in these areas. And since packet transmission often accounts for < 50% of the total power consumed when active, this "overhead" requires further sruntity in our hunt for more EM•eralds.
Last but not least, let's understand the impact of average sleep current on overall energy efficiency. The notable gap between Texas Instruments [0.5 μA] and Nordic [2.8 μA] will clearly help the former and hurt the latter in this sort of benchmark.
Sleep current in fact dominates as we increase our event period from one-second to ten-seconds. After measuring sleep current as well as energy consumption of a typical event, EM•Scope can extrapolate EM•erald scores for any period of interest to our application.
On a personal note
In some configurations, I've replaced the BLE stack supplied by the silicon vendor with one of my own design written in EM•Script – a novel programming platform which targets resource-constrained MCUs.
By optimizing both code size and execution time, we can potentially improve overall energy efficiency. EM•erald scores of 43.12 and 280.50 turned in by this ti-23-lp/emscript-2V2 capture should peak your interest – and will receive more attention in future articles.
Helping the cause
If nothing else, BlueJoule fills a void in the industry – not only by streamlining comparision of one "ultra-low-power" BLE device against another, but also by giving us greater insight into how these devices consume energy when executing an application workload in real-time.
To engage at the next level, the EM•Scope ReadMore shows you how to install and use this open-source tool – drawing on our ti-23-lp/simplelink-3V0 capture as a working example.
... and you don't need a power analyzer to start exploring the benchmark results !!!
The BlueJoule ReadMore provides additional information for anyone wishing to submit a new capture using EM•Scope in conjunction with a JS220 or PPK2 analyzer.
But above all, we need input from the BLE device vendors publicized by our efforts:
is BlueJoule a meaningful benchmark
have we measured your device fairly
are there other devices of interest
how do we best interact with you
Ideally, each vendor would deliver optimized bluejoule SDK projects targeting specific BLE devices within their silicon portfolio – not unlike the ever-present coremark projects we find.
On a personal note
Having prepared most of the software used in the current BlueJoule catalog, I can honestly attest to the relative difficultly of this task – given that an energy-efficient periodic advertising example should seemingly serve as the "hello world" of BLE.
I often found myself dissecting sophisticated, generalized applications to finally arrive at an elementary embodiment of the BLE broadcast role. More important, I sometimes had to add instructions to ensure the application enters the lowest-power sleep mode.
As a multi-decade veteren of this industry, I understand the challenges silicon vendors can face – and would therefore offer to work with y'all in making BlueJoule a reality.
Happy coding !!! 
