why: empty PDU after every notify packet in BLE trace

[klaus1234]

Hi

Can someone help out?

Why is there an empty PDU after every notification(length shown in trace with 277, my payload is 244).
Are all packets with the same EVENT COUNT (in the Event count row of wiresharc) in the same connection interval?

I doubt you need to open the wiresharc capture. Image should be enough!

[tesc]

Hi,

Why is there an empty PDU after every notification

A BLE connection event consist of packets getting sent back and forth between central and peripheral. If one side has nothing more to send, it still sends an empty PDU as long as it received a non-empty PDU form the peer, in order to keep the connection event going (in case the peer has more to send.)

You will see from the logs, that the notification is sent in one direction, and then the empty PDU is the response (acknowledging that the notification was received, but containing no payload.) The device sending the notifications has more notifications to send, so the connection event continues with notifications in one direction and empty PDUs in the other, until either the device sending notifications has no more notifications to send, or the event times out (due to event length reached.)

Are all packets with the same EVENT COUNT (in the Event count row of wiresharc) in the same connection interval?

The "Event counter" is counting connection events, so packets with the same event counter number all belong to the same connection event, yes. The start of the next connection event will happen one connection interval after the start of the current connection event. The connection event starts with the central sending the first packet of the event.

Regards,
Terje

[klaus1234]

Hi,

one further question here: I have a high throughput application using DLE. All data is sent as notfication. If every packet is acknowledged by the central with an empty PDU, then I am loosing bandwifth. This is the way BLE works, correct?

[tesc]

Hi,

As in, the time slots for the central when sending the empty PDUs? You are correct that the way Bluetooth LE connections work, the two communicating devices take turns sending packets. In the case of only one device transferring data, the other device would spend some time sending empty PDUs back, yes.

This is the overhead for acknowledging transfers in BLE. If the transfer is not acked, the connection event is considered over, and the unacked transfer is retried on the next connection event. It's basically how the flow control works for BLE connections.

Regards,
Terje

[klaus1234]

Hi 

so when looking at datarates, this means:

given I use 1 MPhy, lets for get about packet overhead and so on, only half of bandwidth may be used for central to perpheral and the pther half for peripheral to central. Is that correct?