nrf51822 sniffer confusing wireshark output

RE: nrf51822 sniffer confusing wireshark output

john — Mon, 24 Apr 2017 16:06:39 GMT

Hi endnode, This all makes sense now. I'm getting some pretty promising results for my setup (5 sensors running at 100Hz). Can't thank you enough for your answers!!

RE: nrf51822 sniffer confusing wireshark output

endnode — Mon, 24 Apr 2017 08:03:21 GMT

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

RE: nrf51822 sniffer confusing wireshark output

john — Mon, 24 Apr 2017 06:59:28 GMT

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?

RE: nrf51822 sniffer confusing wireshark output

endnode — Fri, 21 Apr 2017 21:23:09 GMT

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.

RE: nrf51822 sniffer confusing wireshark output

endnode — Fri, 21 Apr 2017 21:17:34 GMT

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.

RE: nrf51822 sniffer confusing wireshark output

endnode — Fri, 21 Apr 2017 21:13:41 GMT

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

RE: nrf51822 sniffer confusing wireshark output

endnode — Fri, 21 Apr 2017 21:08:57 GMT

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

RE: nrf51822 sniffer confusing wireshark output

john — Fri, 21 Apr 2017 18:52:03 GMT

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 !

RE: nrf51822 sniffer confusing wireshark output

endnode — Fri, 21 Apr 2017 14:58:23 GMT

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.

RE: nrf51822 sniffer confusing wireshark output

john — Fri, 21 Apr 2017 12:26:06 GMT

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?

RE: nrf51822 sniffer confusing wireshark output

endnode — Thu, 20 Apr 2017 23:49:52 GMT

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

RE: nrf51822 sniffer confusing wireshark output

john — Thu, 20 Apr 2017 23:46:03 GMT

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

RE: nrf51822 sniffer confusing wireshark output

endnode — Thu, 20 Apr 2017 23:36:08 GMT

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

RE: nrf51822 sniffer confusing wireshark output

endnode — Thu, 20 Apr 2017 23:30:12 GMT

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

RE: nrf51822 sniffer confusing wireshark output

john — Thu, 20 Apr 2017 23:08:50 GMT

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?

RE: nrf51822 sniffer confusing wireshark output

endnode — Thu, 20 Apr 2017 22:36:15 GMT

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.