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.

[john]

Hi endnode,

Thanks for your elaborate answer. Coming from a different field, my knowledge of BLE is indeed quite unstructured, so this is definitely the source of the misunderstanding. However, to follow up on your answer:

As you said, I would have expected to have 2 PDUs per communication interval (master-slave & slave-master). I've configured my slave (CC2650STK sensortag by TI) to sample the measurement data at considerably higher frequencies than 1ms communication interval seen in the snippet, so the data is definitely available for sending. Are you saying that my setup essentially cannot package raw data for sending within the ~5ms interval that exists between the master-slave slave-master outputs, thus my GATT profile fails to send in within 1 communication interval?

[endnode]

Hi again, regarding timing I had one comment in my first answer but then deleted it as it seemed irrelevant. However I was wrong as I can see so here it is: Nordic Sniffer is amazing tool BUT you need to understand that it costs ~$40 so need to have realistic expectations from it. All timing indication which goes below 10ms is rather indication then really accurate reflection of reality. If you read some presentation about how BT LE Link Layer works (or read BT SIG Core spec directly) you will see that "gaps" between Tx and Rx within one Connection event (= one or more Master->Slave exchange pairs) are 150us. More over even if stack on your sensor would manage to utilize these 150us for some higher-layer activity (which it definitely doesn't) it would mean that such "application" would need to be pushing sensor data in some agreed format to the stack in multiple basic "fragments"...

[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.

[john]

Aha, that makes a lot of sense. Huge thank you for clearing that up!!