This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf51822 sniffer confusing wireshark output

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:

image description

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

Parents
  • 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.

  • 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"...

Reply
  • 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"...

Children
No Data
Related