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]

Glad to help;) Thanks for accepting the right answer...

[john]

Hi endnode, To follow up on what you explained yesterday: I've looked deeper into the BLE stack from the TI and I'm still left somewhat confused why my setup is not working as intended: The side of data that I am sampling is 4 Bytes. According to the TI setup, the size of one MTU for data is 20 (23-3) Bytes. So as far as I understand it should easily fit my data into one MTU. It appears that stack wise everything is lining up nicely and should be transmittable over one connection interval. Am I getting something wrong here?

[endnode]

You are right and there is one point I've missed in your screenshot originally: you (or your devices) are using Read with Response (and probably also Write with Response) (G)ATT methods instead of faster Write (without Response) and Notify (or simple Read). That costs you another connection interval for explicit response (basically just ACK without real value for data transfer). Would that clear your question? Otherwise I cannot see the data in your screenshot so I cannot verify how many bytes are in actual payload, if your sensortag at least sends multiple of 4-byte blocks within one (G)ATT MTU etc.

[john]

I think I got it now. Basically, the only way for the Read with Response mode to work within one connection interval is to have it package the data and have it fully ready and send within the 150+-2 us interval, right? That will probably be somewhat challenging with the current TI stack that I have, notifications might indeed be a way to do it then!:) Thank you !

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