nrf51822 sniffer confusing wireshark output

[john]

Hi all,

I'm trying to use the nRF51822 sniffer to troubleshoot my TI CC2650STK sensortag ble communication and the output is slightly confusing. The problem I am having with the sensortag is that the output I am getting from the sensor is always exactly 2 times the communication interval I set via BlueZ on my Raspberry Pi. The wireshark output looks like this:

I'm struggling to fully understand what exactly is the sequence here: which line exactly signifies the beginning of a new communication interval? Is is line 2351 ("ping" the sensor by sending an empty data PDU) or line 2353 (Rcvd Read Request, Handle : 0x003C)? Additionally, I'm a little confused why it takes two times 1(s) - my chosen connection interval - to get the data out? It looks like the slave and master always exchange empty data pdu's between each other, which isn't something I would expect - shouldn't it just be the following sequence:

Master->Slave: read request

Slave->Master: data

Thank you!

p.s. I use BluePy library (linux BlueZ stack based library) on my master device (Raspberry Pi 3B)with the following communication interval setting:

hcitool lecup --handle $HANDLE --min 800 --max 800 --latency 0 --timeout 1000

[endnode]

Hi,

I'm not sure you do appreciate how BT LE Link layer works during connection. There are typically PDU pairs each interval (so normally there is one Master->Slave and one Slave->Master), under some circumstances there can be several of them (typically if one side of the link has several packets ready to go through and both sides of the link support it) or Slave answer can be missing (if there is empty PDU from Master, Slave has nothing to say and Slave Latency is set to more then 1). So your trace is actually complete and as expected.

Finally to your expectations of how the exchange should flow. Data on higher layers (APP/GATT/ATT/L2CAP) must typically be ready before the connection interval starts to go through. During tiny window between Master->Slave and Slave->Master packets stack cannot manage to throw data up, wait for them being processed and receive new data for output. So if you communicate on higher layers and it's not asynchronous full-duplex stream of data you will always be limited by connection interval between one complete message going there and response coming back.

[endnode]

... (called "MTUs" on ATT/GATT layer). So whatever you set on your toy from TI it's not saying that it pushes some data to BLE stack continuously in order to be able to achieve more then 1 MTU exchange when Connection event happens. So if you expect more data or packets seen during each event it typically depends on 3 factors: application must be designed to do it, BLE stack underneath must support more then one PDU exchange during connection event and the same must apply to BLE stack (at least LL) on the other side. Also note that shortest Connection interval allowed by BT SIG Core specification for GAP compliant devices is 7.5ms so even if you would sample some data faster they would come only at this rate and also most of the devices don't support multiple PDUs in one Connection event when it comes down to 7.5ms so amount of data will be limited by PDU size.