Bluetooth: Master initiates the data transmission in Slave Notify mode. Multiple transmissions in single connection event

[vasilje]

I am trying to understand better the Bluetooth communication based on some data logs.

Master connection params:

int_min: 1000ms
int_max: 1005ms
lat: 0
timeout: 4000ms

Slave is calling function bt_gatt_notify every 20ms with new values provided. Master is subscribed to the notifications.

Here is the view from Wireshark in particular moment:

Wireshark.log

What I find strange:

1. Whenever the slave should transmit the new data, its actually Master who is sending the request first, then the slave responds.
2. No ACKs from the master after that
3. In single connection event there are 3 new values that are being sent to Master(you can understand by looking the log times). After 3 are sent, the Master is waiting for the beginning of the next connection interval.

I was expecting that there will be asynchronous data transmission initiated by the Slave as soon as the data is updated. Also what I found strange is that for some reason in one connection event there are 3 new values. How can we clarify this?

Best,

[Turbo J]

vasilje said:

I was expecting that there will be asynchronous data transmission initiated by the Slave as soon as the data is updated.

Wrong expectation. All communication is done via connection events that take place every connection interval. Notifications and indications are queued, ether in the application (nrf_ble_gq) or in the softdevice itself.

The amount of data exchanged during a connection intervall changes with softdevice config - default config can queue up to 6 or 7 notifications IIRC. The central may not be able to take that much data, though.

If you call bt_gatt_notify every 20ms you should have gotten some of those NRF_ERROR_RESOURCES return codes (if your conn params are correct).

[vasilje]

Hey, thanks for clarifications! I checked, I do not get any errors, the 3 values are queued even when I put the smaller delay between notifications. I also checked, no notifications has been lost, they are all in right sequence. Parameters are alright, since its easy to check based on the log that every connection event takes 1s. Also, after some time the peripheral is requesting the update of the connection parameters to default one, I found that interesting since I am not specifying it in my code.

[ovrebekk]

Hi

Which example are you using as a starting point?

Technically it is up to the application to request a change of connection parameters. In the nRF5 SDK we had a support module to handle this for you, so you just needed to define the desired connection parameters in the main file, but I need to check how this is handled in Zephyr. 

Best regards
Torbjørn

[vasilje]

Hi, I am using central_hr and peripheral_hr examples, but I am modifying connection params (int_max,int_min,lat,timeout). Now I wonder how I can modify other params of the connection: retransmissions, max queue lenght,...  Let me know if you get further info.

[ovrebekk]

Hi 

The Bluetooth specification mandates that the stack retransmit a packet indefinitely (or until the link is lost), so this can't be changed. 

Buffer counts and similar can be changed. I would suggest having a look at the Kconfig file in the zephyr/subsys/bluetooth/host/ directory for an overview of the various host configuration parameters available. 

Best regards
Torbjørn