In this topic, we will look at the specific data points that matter most when monitoring Bluetooth LE devices remotely. For each data point, we will explain what it tells you, why it matters for power consumption or connection stability, and how it connects to the optimization techniques from earlier lessons.
The Memfault SDK automatically collects these data points using Zephyr’s Bluetooth connection APIs. Understanding what is being collected and why will help you interpret the data when you see it in the nRF Cloud dashboard.
Connection parameters
As we covered in Lesson 4, the negotiated connection parameters directly determine how much time the radio spends active and therefore, how much current the device consumes during a connection.
Connection interval. This is the time between consecutive connection events, reported in microseconds. A 30 ms interval means the radio wakes up roughly 33 times per second, while a 1000 ms interval means it wakes up once per second. In Lesson 4, we saw that increasing the connection interval from 30 ms to 1000 ms reduced average current from approximately 74 µA to 5-6 µA. When monitoring a fleet, if you see devices reporting unexpectedly short connection intervals, it means the central either requested a short interval or rejected your peripheral’s parameter update request. This is one of the most common causes of higher-than-expected field power consumption.
Peripheral latency. This is the number of connection events the peripheral is allowed to skip when it has no data to send. A peripheral latency of 4 with a 100 ms connection interval means the peripheral only needs to wake up every 500 ms when idle, while still being able to respond within 100 ms when it has data. If this value is 0 across your fleet, the peripheral is waking up at every connection event even when there is nothing to send.
Supervision timeout. This is the maximum time allowed between successful packet exchanges before the connection is considered lost, reported in units of 10 ms. A very short supervision timeout can cause unnecessary disconnections in noisy RF environments, while a very long timeout delays detection of a genuinely lost connection. You may have encountered the required supervision timeout minimum recommended by the CONFIG_BT_PERIPHERAL_PREF_TIMEOUT symbol in Lesson 4: Supervision Timeout > (1 + Peripheral Latency) * Connection Interval * 2. For more headroom and to prevent spurious disconnects in unknown RF environments, it is also worth considering a practical minimum of Supervision timeout >= (Peripheral Latency + 1) × Connection Interval.
PHY and data length
These parameters determine how efficiently data moves over the air, which directly affects radio-on time and therefore power consumption.
PHY mode. The physical layer mode in use for both TX and RX. As covered in Lesson 4, 2M PHY transmits data in roughly half the time compared to 1M PHY, reducing radio-on time and power consumption. Coded PHY extends range at the cost of higher power consumption per byte. If your firmware requests 2M PHY or Coded PHY but your fleet data shows devices running on 1M PHY, it likely means the central does not support 2M PHY or Coded PHY, or it rejected the PHY update request.
Data length (TX and RX). The maximum link layer payload size in bytes and the corresponding time in microseconds. The default is 27 bytes. With Data Length Extension enabled, this can increase to 251 bytes. As we demonstrated in Lesson 4 Exercise 2, enabling DLE reduced average current by 35% when sending large packets, because the same data could be transmitted in fewer packets with less protocol overhead. Monitoring data length across your fleet reveals whether DLE negotiation is succeeding with the centrals your devices connect to in practice.
GATT MTU size
The ATT Maximum Transmission Unit determines how many bytes of application data can be sent in a single GATT operation. The default is 23 bytes. When the MTU is larger than the data length, the application data gets segmented into multiple link layer packets. When both MTU and data length are increased together, as covered in Lesson 4, you get the maximum benefit: complete application messages sent in single packets with minimal overhead. Seeing the negotiated MTU value across your fleet tells you whether the MTU exchange is completing successfully with different central devices.
Knowing what your device is connecting to is critical for diagnosing interoperability issues.
Peer vendor name. The manufacturer of the remote device’s Bluetooth controller, derived from the manufacturer identifier in the link layer version exchange. This tells you whether you are connecting to an Apple, Qualcomm, MediaTek, or other vendor’s Bluetooth stack. If stability issues cluster around a specific vendor, you have a clear direction for investigation.
Peer core version. The Bluetooth link layer version supported by the remote device (for example, 5.0, 5.3, or 6.0). This determines which features the central supports. A peer running an older Bluetooth stack will not support the newer Bluetooth features like 2M PHY and DLE, which means your device will fall back to less power-efficient settings when connected to that peer. Fleet-wide data on peer core versions helps you understand what percentage of your user base benefits from newer Bluetooth features and whether you need fallback handling for older peers.
Remote information string. The combined manufacturer identifier and subversion, which can help identify the specific Bluetooth stack revision running on the peer. This is useful for tracking down issues tied to a particular firmware version on a popular phone model.
Disconnection and connection events
Disconnect count. The number of disconnections observed over a heartbeat period. Frequent disconnections waste power because the device must re-enter advertising and re-establish the connection each time, including the advertising current, connection setup overhead, and any security re-establishment. A rising disconnect count on a subset of devices points to either environmental RF issues or interoperability problems with specific centrals.
Connection event count. The total number of connection events during a heartbeat period. Combined with the connection interval, this lets you calculate the actual connected time and verify that the connection is behaving as expected.
Connected time. The total time in milliseconds that the device spent in a connected state during the heartbeat period. This helps you assess the overall duty cycle of the Bluetooth LE connection and its contribution to the power budget.
Data length updated count and subrate changed count. These counters tell you how many times the data length or connection subrating parameters were renegotiated during the heartbeat period. Frequent renegotiations could indicate instability in the connection or a central that keeps changing parameters.
The received signal strength indicator, measured in dBm. RSSI gives you a rough indication of the RF link quality between the peripheral and the central. A low RSSI value (for example, below -80 dBm) indicates a weak signal, which can lead to missed packets, retransmissions, and ultimately disconnections if the supervision timeout is exceeded. Correlating RSSI with disconnection events helps distinguish between firmware-level issues and environmental RF problems. If disconnections happen primarily when RSSI is low, the root cause is likely range or interference rather than a software bug.
Battery state of charge
While not a Bluetooth LE parameter, battery state of charge is an important companion metric. Tracking battery SoC over time across your fleet lets you validate your power budget estimates from Lesson 1. If your power budget predicted 1.25 years of battery life from a CR2032, but fleet data shows devices reaching 50% SoC after only 4 months, something in the field is consuming more power than expected. You can then look at the connection parameter metrics to determine whether the radio duty cycle matches your assumptions.
How these data points work together
No single metric tells the full story. The value of remote observability comes from correlating multiple data points. For example, a device showing high average disconnect counts, low RSSI, and a peer vendor known to have aggressive supervision timeouts gives you a clear picture: the device is at the edge of range with a central that drops connections quickly. A device showing normal RSSI and low disconnect counts but unexpectedly high battery drain might reveal a connection interval that is shorter than intended, or a data length that never negotiated up from the default 27 bytes.
In the next topic, we will walk through integrating the Memfault SDK into an nRF Connect SDK project so that all of these data points are collected and transmitted automatically.
