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

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

ovrebekk — Thu, 03 Dec 2020 10:25:06 GMT

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

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

vasilje — Wed, 02 Dec 2020 13:56:50 GMT

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.

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

ovrebekk — Tue, 01 Dec 2020 08:12:27 GMT

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

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

vasilje — Mon, 30 Nov 2020 12:52:55 GMT

It was just for the sake of experimenting and trying to understand better how low level stack handles such events. I checked-no data is being lost, its just that the slave is not able to send the notifications, but once it is, the data is arriving in right order. Slave also doesnt throw any errors.

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

vasilje — Mon, 30 Nov 2020 12:49:55 GMT

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.

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

Dmitry — Sat, 28 Nov 2020 14:34:50 GMT

I would like to add that your conn parameters are strange - you're trying to send a notification every 20ms knowing that an exchange will occur not frequently than once a second - so 47 messages of 50 are lost. If you would like to save power, configure 20-ms conn interval and set slave latency to 50 (to skip events while no data is ready).

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

Turbo J — Sat, 28 Nov 2020 13:30:32 GMT

[quote userid="95479" url="~/f/nordic-q-a/68871/bluetooth-master-initiates-the-data-transmission-in-slave-notify-mode-multiple-transmissions-in-single-connection-event"]I was expecting that there will be asynchronous data transmission initiated by the Slave as soon as the data is updated. [/quote]

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