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]

Hi John, I'm afraid there is still some misunderstanding;) Normally application on top of the stack (= sensor) should prepare data (in your case one or more 4-byte strings) and map them on top of GATT Characteristics (their Value handles and protocols agreed). Once you have data ready you push them to the stack through vendor specific GATT API (Client or Server depending on what role you run). If it means more packets then stack will get ready with more packets (depending how many buffers it has configured, typically during init). Then once connection interval occurs it tries to push as many "cached" packets as possible in Tx frames. There is normally at least one but depending on interval used and stack capabilities (on both sides of the link!!!) there can be more, the best devices are able of 6-8 per one connection event...