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]

... During this Tx/Rx activity (regardless number of exchanged packets) there is no time to interact with higher layers, stack acts on its own. Now in the end of this even if there were any data received (again it can be more than one (G)ATT MTU) they are returned to higher layers for processing. So if your sensor is GAP Peripheral (= advertising device) and GATT Server at the same time (usual configuration but you can be GAP Peripheral and GATT Client as well) it typically should use Handle Value Notification (G)ATT method on some custom Characteristic (subset of custom Service). Once there is phone (or something else) connecting as GAP Central, sensortag should wait until GATT Client discovers the service and enables Notifications (there is specific command for doing it) and then it can freely and asynchronously (= without any action from mobile) start pushing data through (G)ATT API.

[endnode]

As result your mobile (= GATT Client) will start seeing data packets and if both sides support multiple MTUs per connection event it might be up to (MTU_SIZE * MTU_NUMBER_PER_EVENT * (1 / CONNECTION_INTERVAL_IN_SECONDS)) Bytes per second of effective application data throughput. In case of your default MTU size (which means 20 bytes for application in each MTU) and 1s connection interval it can be 20-160Bps (1-8 MTUs per one connection event). Again this is just typical example, I would need to see more traces to confirm the roles and throughput capabilities.

[endnode]

However if you want (or must) stick to your "pull" model then you should make sure that sensor data are always prepared in particular Value handle on sensor side so you can read them. See nice flow charts of Read without Authorization and Read with Authorization from Nordic Infocenter (authorization will waste one more connection event = interval). It can easily be the case that you are trying to read some value but sensor is only using Notify methods which don't store actual payload in the Value but send them "over" it as they come.

[john]

Ok, I think I am getting some promising results with notifications now, thanks to your explanations! One more question, if I may: you mentioned that the notification method pushes the values over as they come. Why does my chosen communication interval setting still matter with this method (I would have thought that the data would then be sent as soon as it is sampled)? Is it because the sensor will not "notify" until the communication interval time is not achieved?

[endnode]

Hi, I was again not 100% clear: Notify (and Indication) methods are available to GATT Server to send asynchronous messages BUT of course only during Connection interval. So still you cannot see anything "faster" then basic Connection interval (that's why it is sometimes better to be GAP Central because then you can choose the interval, of course the other part of the link might decide to disconnect if parameters are too "aggressive"...)