Why empty PDU is sent by slave after notification

RE: Why empty PDU is sent by slave after notification

Paul — Thu, 09 Jun 2016 15:55:33 GMT

I am looking for something else, happen to see this thread. The only problem to let device sleep for what latency allows is the clock/timing auto adjustment happens at every connection event, the clock may have been shifted enough to miss the next packet. There is a clock error parameter setting in BLE at unit of PPM, which directly related to power consumption.

RE: Why empty PDU is sent by slave after notification

Pål Håland — Tue, 08 Dec 2015 09:59:05 GMT

In that case you will receive the TX_COMPLETE 1 connection interval later.

RE: Why empty PDU is sent by slave after notification

Umes_fln — Tue, 08 Dec 2015 09:31:37 GMT

Thanks Pal for comments. However what happens if I set 1s interrupt to transmit and connection interval to 1s, in that case how confirmation is done?

Thanks in advance

RE: Why empty PDU is sent by slave after notification

ovrebekk — Fri, 04 Dec 2015 08:58:58 GMT

Hi Umes If you accept one of the answers below it will register the case as closed, assuming you are happy with the answer ;)

RE: Why empty PDU is sent by slave after notification

RK — Thu, 03 Dec 2015 07:32:20 GMT

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

RE: Why empty PDU is sent by slave after notification

Pål Håland — Thu, 03 Dec 2015 07:26:29 GMT

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)

RE: Why empty PDU is sent by slave after notification

Eric Stutzenberger — Thu, 03 Dec 2015 01:06:00 GMT

The slave latency is a good additional point on this.

RE: Why empty PDU is sent by slave after notification

RK — Thu, 03 Dec 2015 00:57:54 GMT

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.

RE: Why empty PDU is sent by slave after notification

Eric Stutzenberger — Wed, 02 Dec 2015 18:20:10 GMT

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