Write request and Write confirmation

[CheMax]

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

[Susheel Nuguru]

Hi CheMax,

Nice questions. Assuming these are write requests without authorization.

Q1. What behavior is considered the most expected (specification does not give an explicit answer)?

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.

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)?

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.  

Q3. Is it possible to receive a program event when confirmation is sent?

 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. 

Q4. The sniffer for analysis through a Wireshark adds an event counter. Can I get an event counter in my application?

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.

[CheMax]

Hi Susheel,

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)

[Susheel Nuguru]

CheMax said:

Doesn't the function sd_ble_gap_next_conn_evt_counter_get() (from s140 v7.x.x)  no returned the connection event number?

 Sorry CheMax, yes i missed to see this function. This will get you the event number and return the connection event number, is exactly what you needed

 

CheMax said:

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)

 How much did you set BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT to be? The number of packets that can be queued into one connection event depends on how the size of the MTU , connection event size and how many the application manage to queue the packets within the connection event.

Sometime the application queing software latency causes it to be unable to queue more than X number of packets. You should be able to identify this by toggling some gpios when you queue a packet for notification and looking at those gpio pins in the logic analyzer to see how fast your application queues the packets.

[CheMax]

ok, thanks.

at the moment there are no questions, but if new ones arise, I'll be back)