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:
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?
Should I use a function sd_ble_gap_next_conn_evt_counter_get() from s140 v7.0.1 stack for this purpose?
I made a mistake indicating the current version of the SDK. looked at the wrong branch ...
Regards,Maksim Chelobitchikov,software engineer
Nice questions. Assuming these are write requests without authorization.
I think the behavior depends on what state the softdevice is in when it gets the write request. It then need to process the incoming packet and request a timeslot from the timer to be able to schedule to write the response back. The timer module responsibile for giving the timeslot for the softdevice to send a radio packet is a complex beast. There are many variables in which it can decide that it cannot allocate a timeslot to send the packet within the same connection interval and one of the reason could be like you mentioned is that after the request came, there is no enough time left considering that the radio is already transmitting some empty packet.
I do not think so, Since this is placed in RAM either way and not in flash, the number of instructions that differ to fetch the value from user ram location should not influence this.
Yes, only if you set it to Authorize write requests and the confirmation cannot be pulled by the app instantly since the softdevice finished what it does before relinquishing the control to the app. So if you want to have some timestamps in the app event logger then the timestamps will not match the time the SD receives the response.
No. The event counter that sniffer uses means different than the events given to the application from the softdevice. There is no event counter feature in SD and the application need to track this by itself.
1 Is this regular behavior or an error in the logic of my application?
This is normal if the slave has already buffered notifications to transmit on its end before receiving the write request.
Q5.2 Does the stack have data sending priorities?
No, With respect to data, it transmits in the same sequence the data is queued to be transmitted. If there were already 7 notifications queued when it received a write request, it cannot put the write response in front of all the data that is already queued in front of it.
Nice system on crystal, nice questions about it.
Susheel Nuguru said: Yes, only if you set it to Authorize write requests and the confirmation cannot be pulled by the app instantly since the softdevice finished what it does before relinquishing the control to the app. So if you want to have some timestamps in the app event logger then the timestamps will not match the time the SD receives the response.
I looked at the messaging sequence diagram in the documentation. However, it seemed to me that this would not let me know when the client would receive a response from the server. But on the other hand, can I see when I queued up a response for sending?
Susheel Nuguru said:No. The event counter that sniffer uses means different than the events given to the application from the softdevice. There is no event counter feature in SD and the application need to track this by itself.
Doesn't the function sd_ble_gap_next_conn_evt_counter_get() (from s140 v7.x.x) no returned the connection event number?
Susheel Nuguru said:and the application need to track this by itself
By application do you understand my part of the server code? or on the client side. If this does not cause difficulties, can you elaborate on this?
Susheel Nuguru said: If there were already 7 notifications queued
I thought that this value would be limited by the size of the buffer allocated to the stack (setting BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT in ble_gatts.h) .but when tracking, I couldn’t queue more than 6-7 packets.here it turns out)