Why empty PDU is sent by slave after notification

[Umes_fln]

Hi,

I am new to forum and to Ble. sorry about my week English. I am working on a project where I am reading adc value every 1s and sending it over ble. So I have written a firmware using NRF52 where it generates interrupt every 1 sec, reads adc, and notifies to the central only if the adc value has been changed. I have set the NRF52 as follwing:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(500, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(500, UNIT_1_25_MS)  
#define SLAVE_LATENCY                        7  
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(10000, UNIT_10_MS)  

I then used Nordic sniffer to analyse the data, I can see the master getting notified every second but also empty PDU been exchanged between master and slave (attached the picture of the wireshark).

My question are: is it part of the BLE specification that after each notification the master and slave have to exchange empty PDU (looks like the slave latency resets after notificaton)? if not, how can I stop it ? if yes, then is there any other way of designing firmware low power (I mean if setting characteristic to read only is better than setting characteristic to notify in terms of energy saving?) My project requires low power consumption so I only want slave to talk to master at every 1 sec (when there is change in data) and send empt PDU at interval given by slave latency. In my case I am sending data every 500ms (1 empty PDU and adc value every 500ms )

Please help! image description

Thanks

[Eric Stutzenberger]

Hi Umes_fln,

The connection interval defines how often a connection is made. Since you have it set to 500 ms min and max, then a connection will be made every 500 ms whether or not there is any data to send or receive. Notice that every 500 ms there are packets. At each second, your device sends some data. However, at the other 500 ms interval, neither device sends any payload data, just an empty PDU. If your device had nothing to send every second, there would still be empty PDUs every 500 ms.

So, in short, yes, this is how BLE works. The best way to lower power consumption in a BLE design is to connect less often.

To lower the power use in your project, you can set your connection interval to 1000 ms instead of 500 ms.

HTH,

Eric

[RK]

Looking at that packet sequence there's more to it than that however. There's a point just after 619.11s where there are 5 packets from the master with no response. That's because slave latency on the connection is set and the slave, with nothing to do, is choosing to ignore connection events, as it's entitled to do.

In that case, since there is slave latency available, it is fair to ask why the slave bothers to listen at the connection event after each notification it sends out, it has no data to send, it has latency available, if it wanted lowest possible power it would do nothing and leave its radio off and we'd see unanswered empty PDUs from the master.

Using latency to the fullest extent is optional of course. It may well be that in real-world testing it so often happens that a notification from a slave results in new data from the master (which it doesn't in this case) that it's more performant to 'waste' one connection event and listen to the master one extra time before the slave sleeps. That has the potential of improving throughput in a fairly usual use-case for the cost of a very small amount of power.

I guess only the person who wrote the stack can answer that.

[Eric Stutzenberger]

The slave latency is a good additional point on this.

[Pål Håland]

Regarding the point where the slave wake up after sending a notification when there is slave latency: This is because we would like to have the confirmation that the packet the slave sent was indeed received by the master as soon as possible. We could have waited another 3.5 seconds before wakeing up again and noticing that the peer did not receive the packet. But this as you figures would introduce another latency to the application (it would not receive the TX complete before the peer have ACK'ed the packet)

[RK]

oh dear - that was really obvious - why didn't I think of that.