In BLE, peripheral devices are typically those that advertise their presence and offer services or data to central devices. Peripheral devices usually consume less power compared to central devices because they primarily operate in advertising and standby modes. Examples of peripheral devices include sensors, fitness trackers, and smart home devices that transmit data periodically or in response to specific events.
This application is a sample implementation of device using GAP peripheral role. It does not implement any particular profile, instead it registers couple of different services for testing purposes.
Power Consumption difference Central & peripheral
In Bluetooth Low Energy setups, the central device acts like the master, handling tasks such as managing connections and processing data. This makes it a bigger power user compared to peripherals. So, in simpler terms, IoT gadgets, which need to conserve power and have limited resources, usually play the role of peripherals. On the other hand, central devices like smartphones, which have more power to spare, take charge of managing the connection and handling data.
Please take a look at DA1459x Getting Started With The Development Kit before starting this part.
At first here we will show how to run the ble_peripheral project on DA1459x without performing any connection with different advertisement interval and different Tx power level. In the first step we would like to configure the Radio operate in high performance mode, the Tx power will be at maximum 6 dBm and the interval every 500ms.
First from the file tab choose import
Find Dialog SDK Project and select it
Import ble_peripheral project from \projects\dk_apps\features
Open custom_config_eflash.h . Add following, macro to to your code to choose high performance mode for radio.
If you open ble_peripheral_task.c , you will see we are establishing our advertisement with ble_gap_adv_start(GAP_CONN_MODE_UNDIRECTED). In general in standard ble applications we have 4 types of connectivity mode:
These modes pertain to the connection procedures in Bluetooth Low Energy (BLE) communication. let’s go through each one:
GAP_CONN_MODE_NON_CONN: This mode is non-connectable, meaning the device does not establish connections with other devices. It typically operates in a broadcasting manner, where it sends out advertising packets but doesn’t actively engage in connection establishment.Use cases for this mode include beaconing, where a device periodically broadcasts information without establishing a connection. For example, in a retail environment, beacons might broadcast product information or promotional offers to nearby smartphones.
GAP_CONN_MODE_UNDIRECTED: In undirected mode, the device advertises itself and waits for incoming connection requests from other devices. Both devices can initiate the connection process.This mode is commonly used for peer-to-peer communication scenarios where devices can establish connections with each other as needed. For instance, in a wireless sensor network, nodes might use undirected mode to communicate with each other without a central controller.
GAP_CONN_MODE_DIRECTED: Directed mode involves one device explicitly targeting another for connection establishment. The initiator knows the address of the target device and initiates the connection process directly. This mode is useful for scenarios where devices need to establish connections with specific peers, such as in a point-to-point communication setup. For example, a wearable fitness tracker might use directed mode to connect to a user’s smartphone for data synchronization.
GAP_CONN_MODE_DIRECTED_LDC: Directed Low Duty Cycle (LDC) mode is similar to directed mode, but with reduced duty cycle to conserve power. The initiating device periodically scans for the target device, reducing the frequency of connection attempts. This mode is beneficial for power-constrained devices where energy efficiency is crucial. For example, in wearable devices, directed LDC mode can be used to establish connections with smartphones while minimizing power consumption, thus extending battery life.
We will continue undirected mode but at first we don`t establish any connection. Build the project and start debugging session after downloading the binary into the flash stop the debugging session for not seeing the debugger effect in the power profiler.
Warning
To accurately measure the power consumption of your application under normal operating conditions, it’s essential to remove the effects of debugging. This means stopping the debugging session, which halts the debugging activities and allows your program to run independently without interruptions. Once the debugging session is stopped, the power consumption chart should stabilize, reflecting the true power consumption of your application without the additional overhead introduced by debugging activities.
Sleep in BLE device
In BLE devices, power efficiency is paramount to prolong battery life. One of the key strategies to achieve this is through sleep modes. When a BLE device is not actively transmitting or receiving data, it enters a low-power sleep state (Extended Sleep) to conserve energy. You will find more information about power consumption in this state in the Renesas DA1459x Datasheet
During sleep, most of the device’s components are powered down or placed in a low-power state, significantly reducing power consumption. However, the device remains capable of waking up quickly in response to external stimuli, such as incoming connection requests or sensor data.
Please take a look at Sleep Modes for more information.
You need to do the calibration before starting each measurement session. please take a look at Calibration offset (mA).
Expected events
As a preview and recap from the da1459x Devkit-P user-manual. You are expected to see the following events. Take this to your consideration that DC/DC refresh interval won’t be configurable and the M33 calibration wake up will happen every second , user can change this interval to 2 seconds but It is not recommended.
Let’s check the advertising interval first. We defined a range between 500 and 1000 ms. from Tools menu select Measure. Put the start point at the beginning of an advertisement event and the other end on the beginning of next event. You will see the interval is around 609ms which is inside our defined range.
Now let’s measure charge and energy consumption , average current and peak current in one advertisement event. Zoom in one advertisement event, select Measure and open window as wide as the event. Now It is possible to read these important parameters for each event.
In this advertisement event, we’re focusing on measuring several key parameters: charge , energy consumption, average current and peak current. Please also notice that in this test the VBAT=1.8v.
Let’s break down each measurement:
Charge and Energy Consumption: The consumed charge is measured at 6.7 microcoulombs (uC), indicating the total electric charge consumed during the event. This metric gives us an understanding of the overall energy usage for this specific advertisement event.
Average Current (Iavg): The average current drawn during the event is 2.9 milliamperes (mA). This value represents the mean current flow over the duration of the event. It’s a crucial parameter for assessing the average power consumption of the device during transmission.
Peak Current: While not explicitly mentioned in the provided excerpt, peak current refers to the maximum current drawn during the event. It’s essential for understanding the device’s power requirements during peak operational demands.
The presence of three peaks, as elaborated in the DA1459x Tutorial Advertising Concept, is attributed to the utilization of three channels during advertising, commonly referred to as the primary advertisement channels. This redundancy is established to ensure robust communication. Essentially, advertising packets are transmitted across all three primary advertising channels—namely, channels 37, 38, and 39 sequentially. Meanwhile, scanning devices are configured to scan these channels in sequentially, actively seeking advertising devices.
Now, let’s address the potential reasons why the Tx (transmit) pulses might not be of equal height:
Load Variations: Unequal pulse heights in the Tx waveform on the DA1459x devkitp may stem from load variations caused by impedance differences. The printed antenna, not optimally tuned or matched, presents varying impedances across low, mid, and high frequencies. These impedance variations are particularly pronounced across the three advertising channels (2402, 2426, and 2480 MHz), resulting in divergent Tx pulse heights.
Signal Interference: External factors such as electromagnetic interference (EMI) or noise in the RF (radio frequency) environment can influence the amplitude of transmitted pulses, leading to variations in pulse height.
Device Characteristics: Variability in device characteristics, such as component tolerances or manufacturing variations, can also contribute to differences in pulse height.
Regarding the mention of the graph looking different when a remote device answers the event, this could be due to changes in transmission patterns, altered power consumption, or variations in the received signal strength.
Lastly, conducting these measurements in an RF isolated environment is crucial for ensuring reproducible results, as external RF interference can significantly impact measurement accuracy and consistency.
Note
For not having a varying load impedance, it’s better to use a 50 Ohm load connected to the daughter-board’s RF-connector/switch (J7).
The last measurement we would like to see is to see the info table on the right side of the powerprofiler. Take this to your consideration that these values are for 5 seconds of active advertisement of the peripheral.
Now let’s see how these values can change if we reduce transmission power. Check the datasheet and ble_gap.h in order to see the possible values when the radio operation mode is HP. We would like to reduce it to 0 this time :
longer advertisement means less Radio-On period means less consumption. Compare these two last outcome and you will see difference in Charge. Take this to your consideration that this test is only happening in 5 Seconds. Longer period will make the difference more clear.
At this point let’s establish a connection between DA1459x as peripheral and your smartphone as Central. For this exercise we are going to use SmartBond application on your Android / iOS device.
open smartBond application and search for Renesas_Peripheral. Connect to it.
When two devices establish a connection in Bluetooth Low Energy, the central device initially sets the connection interval, determining how often data can be exchanged. During each interval, both devices can exchange multiple packets. However, if there’s no data to send, they still need to send empty packets to keep their clocks synchronized. If they have more data to send than fits in one interval, they split it across multiple intervals.
Once a connection is established, devices cease utilizing the advertising channels (channels 37, 38, and 39) and instead switch to the data channels (channels 0 to 36). To enhance throughput and minimize interference, Bluetooth LE employs channel hopping during data transmission, whereby the channel utilized for transmission is frequently altered. During a connection, both devices have the capability to transmit multiple packets within each connection interval if there is substantial data to be transmitted. However, when data transmission halts, they must await the subsequent connection event to resume transmission, even if no actual data is being transmitted, necessitating the exchange of empty packets to synchronize their clocks. Should the data to be transmitted exceed the available time within a single connection interval, it will be distributed across multiple connection intervals.
The figure above is showing in a very simple documentation of different types of packets in order to understand better the packets. In each connection event, both central and peripheral will send packets in order to be synchronized (first two connection event). In the third event in the figure,peripheral will send the data packets.
A good example to see an established connection with no data to be transmitted is ble_adv which also has been used explained in DA1459x Tutorial Advertising Concept
We can build the example , debug it into flash and see how is the connection in this case.
The figure below is showing the 5 seconds connection event in which the peripheral sends nothing but only empty packets. You can see that according to the connection interval both central and peripheral communicated.
Now let’s see more in depth which peak is related to Rx and which related to Tx. Zoom in one event (doesn’t matter which one). you will see two big peaks. The first one as we explained before is the Rx which has received from the central and tiny higher one is the Tx from Peripheral containing only empty packet.
There can be a difference in power consumption between using a debugger to burn the binary into the flash of an embedded system and using a dedicated flash programmer. You can take a look at the Renesas SmartBond Flash Programmer or Renesas SmartSnippets tool box Operation Guide. The measurement process is not different from what we already mentioned above.
