Hello,
When we analyzing the traffic of our application (many thanks to the team developing the sniffer), we have several questions about sending write confirmation.
for example, I will use the captured traffic between the sensor and our dongle. Device parameters are listed below:
Hardware | Stack | Gatt role | Connection interval | MTU | |
Sensor | BLE module ublox-Nina-B302 (nrf52840) | Nordic, s140 6.1.1, sdk v15.3.0, freeRTOS | server | 7.5 - 400 | 243 |
Dongle | BLE module ublox-Nina-B302 (nrf52840) | Apache, mynewt | client | 37.5 | 243 |
sending confirmation of a write request often occurs at the next connection interval and rarely at the same. for example:
Client sent write request in 67.377s, server sent response in 67.417s. dt = 67.417 - 67.377 = 0.040s > 0.0375s (connection interval). That is, in this case it can be seen that the connection was temporarily disconnected, since the server did not have data to transmit. at the time of the next connection interval, the server sent a confirmation to the client.
in this case, the sending occurred at the same connection interval, which is visible both in time and in the value of the event counter.
It is also possible that a much longer time passes between the request and the confirmation than the connection interval.
I would like to understand what caused the difference in behavior.
Q1. What behavior is considered the most expected (specification does not give an explicit answer)?
Q2. Is it possible to artificially influence the process of transmitting confirmation (placing characteristics data on the stack (use BLE_GATTS_VLOC_STACK), for example)?
Q3. Is it possible to receive a program event when confirmation is sent?
Q4. The sniffer for analysis through a Wireshark adds an event counter. Can I get an event counter in my application?
Q5. I also noticed that notifications are always sent first, and then confirmation of the record.
in this picture, it is clear that after the write request, the data was first transmitted (it can be seen that the notifications from the 0x0027 and 0x002C handle were repeated twice) and only then the confirmation was transmitted.
Q5.1 Is this regular behavior or an error in the logic of my application?
Q5.2 Does the stack have data sending priorities?
Edit:
Q4. The sniffer for analysis through a Wireshark adds an event counter. Can I get an event counter in my application?
Should I use a function sd_ble_gap_next_conn_evt_counter_get() from s140 v7.0.1 stack for this purpose?
Edit 2:
I made a mistake indicating the current version of the SDK. looked at the wrong branch ...
Regards,
Maksim Chelobitchikov,
software engineer