2. Background

There are several factors that can affect the performance and power consumption of the chip. Some of them are BLE operation mode, sleep mode, sleep duration, wake-up mode, low power clock choice among others. Based on these factors, a test plan is proposed which depends on frequent use cases.

2.1. Consumption Factors

2.1.1. Advertising

An advertising device sends packets to potential listeners, broadcasting information. This could be achieved through connectable packets or non-connectable packets.

When non-connectable packets are used, the device is not listening for any scan requests. This can save power but takes away the opportunity of another device connecting to the advertising device.

On the other hand, connectable packets allow peers to connect to the device as well as allow them to issue a scan request to which the advertising device might opt to answer in order to transmit more data to the peer that requested it. While this scenario can be very convenient it also consumes more power.

Power consumption can also be affected by the advertising interval. Advertising interval is the time lapsed between two advertising events. The shorter the advertising interval is, the more frequent the transmissions, which in turn translates to more time that Radio is in use per time unit.

2.1.2. Connecting

After a connection is established between two BLE devices, the devices either exchange data or the central device issues empty keep alive packets in order to maintain the connection with the peripheral. The frequency of these events happening is dictated by the connection interval which ranges from 7.5 milliseconds to 4 seconds. The shorter the connection interval is, the more power is consumed as the radio is active more often.

For a similar reason, the power consumption is lower in the case of keep alive packets compared to data transfering packets. When no data are required to be sent then the radio will be active for less time and since no data have to be processed, ARM M33 processor does not wake up. This can lead to a significant discrepancy in power consumption between the two cases.

Additionally depending on the ATT operation, the power consumption might differ. For example let us consider the case of a Write and a Write no Response operation. The Write operation issues a write request to the server and expects a response while the Write no Response operation does not expect a response from the server. In the second case the lack of response can reduce power consumption for the server but the tradeoff is that there is no way to know if anything was written at all.

2.1.3. Maximum Transmission Unit

The maximum number of bytes that an ATT packet can contain is dictated by the Maximum Transmission Unit (MTU) that the connected devices agreed on during ATT protocol MTU exchange operation. DA14690 devices support Data Length Extension(DLE) of 251 bytes and it is enabled by default by the SDK. The following example will help illustrate how does MTU affect power consumption.

To begin with, let us examine what a Link Layer packet looks like in order to understand how many extra bytes are added per ATT packet.

Link Layer Packet

Figure 1 Link Layer packet format. Preamble is 1 octet when LE 1M PHY is used or 2 octets if LE 2M PHY is used

As shown, other than PDU (payload) 8 to 9 octets are added depending on the LE PHY type. Additionally, PDU comes from the L2CAP layer which also adds its own header. An L2CAP header is 4 bytes long.

L2CAP_header

Figure 2 L2CAP header format.

Additionally every ATT packet contains its own header which is 3 bytes long. So there is an overhead of 15-16 octets per packet sent.

Let us consider a characteristic of 490 byte size, transfered over LE 2M PHY and an MTU of 65 which is the default for DA1469x products. An ATT packet consists of data and the ATT header which is 3 bytes long. This means that the maximum number of actual data bytes that an ATT data packet can contain is 62 (65-3) in this case. Now considering that DLE allows up to 251 bytes packets, the 490 bytes characteristic will be read in 8 chunks (7 packets of 62 bytes of actual data and 1 of 56). This means that the characteristic value will have to be fragmented into 8 ATT packets (7 packets of 62 actual data bytes and 1 more of 56 bytes). So, since every packet sent contains 16 octets of extra information, for these 8 packets 16*8=128 extra octets will be added and the total size transfered is 618 bytes.

Now let us consider the same characteristic and operation, over 512 MTU. Since 490 bytes is less than 512-3, the MTU forms only one ATT packet. However since according to the DLE only packets of 251 or less can be sent, the ATT packet will be be split into two packets in order to be tranfered over the link layer. Of these two packets only the first one contains ATT and L2CAP headers. This results into 3 bytes for ATT header, 4 bytes for L2CAP header. In this case, 16+9=25 extra octets have to be added and a total of 515 bytes will be sent.

Comparing the two cases it is evident that for the same operation, using the maximum MTU allowed by the devices always results in better energy utilization since the radio will stay on for a shorter period of time.

2.1.4. Sleep Mode

DA1469x family devices offer four different options for sleep. Depending on the sleep mode the device turns off a different subset of circuits.

  • Hibernation mode. This is the “shipping mode”. There is no RAM retained, no clocks running (so no RTC), all domains are off, the system can only be woken up by POR, HW reset or a GPIO trigger. This mode consumes the least power.

  • Deep Sleep mode. Nothing is retained, XTAL32K is running (so RTC is on), all domains are off, the system can only be woken up by POR, RTC alarm or a GPIO trigger. In this mode, the device consumes just a little more than Hibernation.

  • Extended Sleep mode. Programmable RAM can be retained, XTAL32K/RCX is running (so RTC is ON or OFF depending on the sleep clock), all domains are OFF, the system can only be woken up by POR, RTC alarm (if XTAL32K is used), MAC timer, other Timer or a GPIO trigger. This sleep mode involves a lot more systems that stay functional which increases its power consumption further. Extended sleep mode is typically used in between active radio events (Advertising/Connection).

  • Active/Idle. System is up and running, with a number of power domains enabled depending on the use case. For Sensor Node, for instance, PD_COM and the PD_MEM is enabled. If ARM M33 processing power is needed, for example, then all domains might be enabled. Note that there is no state retention at the CPU, so it will always wake up in reset state. Required registers will have to be saved and restored to/from RAM upon waking up. This is the most energy consuming sleep mode of all of them.

2.1.5. Wake-up Mode

DA-1469x family devices use a crystal oscillator (XTAL32M) as the default system clock. This crystal oscillator requires some time from the moment it is provided power until the moment that it settles to the desired frequency. Thus before the system can recover from sleep mode this crystal will have to be settled. There are three wake-up modes as they are called. It is advised to use Fast Wake-up Mode as in the majority of the use cases, it will have the most optimal results.

  • Slow Wake-up Mode : During this wake-up mode, the device has subtracted from sleep time the time that the XTAL32M requires to be settled and takes extra time to assert that it has settled. The device is supplied with 0.75V during sleep. This mode is ideal for sleep periods over 4 seconds.

  • Fast Wake-up Mode : Similarly here the device is supplied with 0.75V during sleep but it is assumed that by the time the switch to XTAL32M has to be performed the XTAL32M will already be settled and thus no extra time is taken off sleep for the crystal settlement. The power consumption in this mode is not significantly less than slow wake-up mode.

  • Ultra Fast Wake-up Mode: In this mode, the device requires 0.9V supply during sleep in order to maintain the XTAL32M in a semi settled state. In this mode, all LDOs are started at the same state in hardware FSM and it is assumed that all are immediately ready but the power consumption is higher than the other modes and can be useful only in cases where the wakeup time is comparable to the sleep time.

2.1.6. Low Power Clock

2.1.6.1. General

During all modes of sleep except Hibernation, the device switches to a low power clock in order to maintain some timers and Real Time Clock.

  • XTAL32K : This is a crystal oscillator with a frequency of 32768 Hz. It is highly accurate and is the least power hungry option.

  • RCX : This is an internal oscillator with a nominal frequency of 10.5 KHz yet it can fluctuate depending on environmental conditions. In general, RCX consumes less power during sleep but significantly more, the more frequently the device has to wake up.

2.1.6.2. The effect of Window Widening

At each connection event the peripheral/slave has to resynchronize with the central/master. Due to Sleep Clock Accuracy (SCA) of both the master and the slave, the time that RF is listening(thus ON) has to be increased. For example, let us examine the following case:

Both the master and the slave’s clocks have certain clock accuracy. BLE specification dictates that the maximum drift of any clock used for BLE events is 500 parts per million. If the connection interval would be 1000000 low power clock cycles and the master’s clock accuracy is 50 parts per million(ppm) then the earliest the event could arrive would be 50 low power clock cycles before the projected time while the latest would be 50 low power clock cycles after. Since the slave could also have clock accuracy of 100 ppm, it might finish counting clock cycles to the earliest point in time that a BLE event could arrive, 100 low power clock cycles earlier than expected and start listening from that point on. For the same reason it would have to listen for 100 cycles longer as well.

This is called Window Widening and can be calculated as: Window_Widening = ((masterSCA + slaveSCA)/1000000) * lp_cycles_since_last_sync.

When DA1469x devices use XTAL32K as low power clock their Sleep Clock Accuracy is 50ppm while when they use RCX they can drift up to 500ppm. This results into longer periods that the RF is active listening.

Window Widening

Figure 3 RX Window Widening Demonstration. Left :Keep Alive Packets XTAL32K(0.553ms) Right :Keep Alive Packets RCX(3.338ms).

2.1.6.3. ARM M33 wake-up process and Low Power Clock

When ARM M33 is about to go to sleep while some tasks are scheduled to take place in the future, M33 calculates for how long it can sleep. Initially, the time that the system will need in order to go to sleep mode is subtracted from the time that the scheduled event is going to take place. If t is the point in time that ARM M33 will have to wake up at, so it will have ample time to restore its status to what it was before going to sleep as well as time for the adapters to make every peripheral operational again, M33 will have to wake up on the Low Power Clock rising edge prior to point t. Consequently, since RCX’s frequency fluctuates, it can be ~2-4 times lower than the XTAL32K frequency.

Furthermore, when the system is waking up, it takes a few low power clock cycles for system clock to be switched from the low power clock to RC32M resulting in M33 having to wake up even earlier due to the slower low power clock, so it can capture the event.

LP Clock wake-up comparison

Figure 4 LP Clock wake-up comparison. Sleeping [Left of hollow rectangle - Red] . Powered-up [Right of hollow rectangle - Green].

Wake-up timings

Figure 5 Wake-up process timings. Stages WAKEUP_SLOW, LDO_SUPPLY, BG_RC32M use Low-Power clock [Red Sections] . All other stages are unaffected by the Low Power clock choice[Green Sections].

2.1.7. Flash Powered Down

It is strongly advised to set #define dg_configFLASH_POWER_DOWN ( 1 ) in custom_config_qspi.h file of the measured device in order to explicitly state that the flash will also enter low power mode during sleep. The difference can be larger than 5μΑ in average.

Note

Dialog supports three different flash devices for the DA1469x family products that are guaranteed to work.

  • Macronix MX25U3235F

  • Winbond W25Q32FW

  • GigaDevice GD25LE32

However, most of the flash devices are likely to work provided a proper driver exists or is developed for them. There are several low power consumption flash devices (e.g. Macronix MX25R3235F ) that when properly set, they can have an impact on the device’s power consumption. While this is something that could reduce the power consumption, it is up to the reader to successfully install the flash and develop the drivers for it.

A tutorial on how to write a custom Flash Driver for DA1469x is provided by Dialog and can be found here

2.1.8. Processors

DA1469x products are comprised of three different processors. Sensor Node Controller (SNC) which is responsible for everything sensor related, ARM M0+ also known as CMAC which plays the role of the BLE controller and an ARM M33 which is responsible for the application, OS and processing of the data collected.

While a BLE application is running , CMAC and SNC have their own schedule. Minimizing the number of times as well as the duration of M33 staying awake can result in better power consumption measurements.

CMAC wakes ARM M33 every time an ATT operation is finished and there are data that need to be handled. Certain BLE operations do not require ARM M33 to interfere. Such operations are all types of advertising and empty packets sent by the central device in order to keep the connection alive. Additionally, when a read transaction takes more than one connection interval to be completed, ARM M33 will not be woken up until it is finished. For example when a characteristic longer than the negotiated MTU is being read, CMAC will handle the operation and when all the packets that comprise the characteristic are read, only then will ARM M33 wake up in order to handle the result. On the other hand, write operations require M33 to wake up in order to send a confirmation to the BLE stack for every ATT packet received.

Furhtermore, SNC takes a measurement of the internal temperature and if it is not the same as it was during the previous iteration, it wakes ARM M33 up in order to issue a recalibration request. Additionally ARM M33 wakes up to process the change in RCX oscillator’s frequency (if RCX is chosen as the Low Power clock) and to re-evaluate the number of cycles that the system can stay in sleep with RCX’s Frequency new value.

Last but not least, any interrupt can wake ARM M33 up, be it a state changed on a GPIO being monitored, or a timer (provided it can work with the LP clock or that there is a clock to begin with).

Keeping the above points in mind while programming an application can lead to noteworthy difference in power consumption.

Note

If in a service created, several characteristics need to be processed often, it might be better to combine them into one big characteristic(up to 512 bytes) and manipulate the data received to separate them. If MTU is the minimum, the packets will be read and acknowledged by CMAC and when the full package is received only then will ARM M33 wake up to process is thus conserving more power and battery life. If everything can fit into one package and the MTU and connection interval allows for it, ARM M33 will wake up to process all of the data a lot faster with less overhead thus conserving power again.

2.1.9. Programming Practices

Every extra clock cycle spent active can make an impact on the power consumption of the device. So it is of paramount importance to minimize and optimize the code if the lowest possible consumption is the goal of the user. It is recommended to avoid printf functions on production code as they take a long time, keep the system awake and utilize UART which consumes some power.

Compiling in Release mode produces less code and performs several execution optimizations. Furthermore Dialog offers the option to ommit certain code that should be utilized for debug purposes in most cases in the SDK. Compiling in Production mode will result in ASSERT macros to be optimized out. In order to compile in Production mode, the following definitions should be added in custom_config_qspi.h file under config folder:

#define dg_configIMAGE_SETUP                    PRODUCTION_MODE
#define dg_configSKIP_MAGIC_CHECK_AT_START      ( 1 )

Finally, if sleep power consumption needs to be measured, then the following entry should be set to one in custom_config_qspi.h file as well in order for the the device to not wake up after it enters sleep mode.

#define dg_configTESTMODE_MEASURE_SLEEP_CURRENT ( 1 )

For any scenario that involves activity, the above entry should be set to zero.

2.2. Test Cases

The tests performed for this tutorial, check the power consumption for a variety of values of the parameters relevant to the aforementioned factors. These values try to accommodate many possible scenarios, some widely utilized and others used in order to check the connection interval limits as dictated by the protocol.

These parameters include:

  • Advertisement Interval: The advertising interval values measured are 400ms, 1000ms, and 1500ms.

  • Advertisement Data : There is a predefined string that gets advertised but it can be altered as seen proper by the user.

  • Connection Interval : The connection interval values measured are 30ms, 400ms, 2000ms, 4000ms.

  • Data Packet Size : The Data Packets measured are 0, 20 and 509 Bytes.

  • Sleep Mode : Three possible choices, extended sleep, deep sleep, hibernation.

  • Low Power Clock : XTAL32K, RCX

There are also some use cases that are being examined.

  • Advertising using Connectable/Non Connectable packets.

  • Connected Keep Alive Packets.

  • Connected 20 Bytes long Characteristic Read Request.

  • Connected 20 Bytes long Characteristic Write Request.

  • Connected 20 Bytes long Characteristic Write no Response Request.

  • Connected 509 Bytes long Characteristic Read Request with default MTU(65) compared to max supported MTU(512).

  • Characteristic 20 Byte value auto-change and notify peers every 2 seconds.

  • Sleep Mode - extended sleep power consumption.

  • Sleep Mode - deep sleep power consumption.

  • Sleep Mode - hibernation power consumption.