How to shorten the data transmission cycle using sd_ble_gatts_hvx()?

[air]

 Hello.

Log data is transmitted to APP(phone) using sd_ble_gatts_hvx().

The length of one packet is 20 bytes, and the expected total number of packets is about 3,200.

The connection interval I set is min. 7.5mS as shown below log.

The connection interval sent from the APP(phone) after connection is 12 (15mS).

This connection interval is not updated.

If you look at the log below, the log data is transmitted after the BLE_GATTS_EVT_HVN_TX_COMPLETE event every 15mS.

It seems to follow the setting of the APP(phone).

I wonder if there is any way to shorten this cycle.

 

The development environment is as follows.

- MCU : nRF52833

- SD : s140

- SDK : 17.1.0

 

Below is the log data.

 

 Thanks.

// *** my setting *** //
#define MIN_CONN_INTERVAL						MSEC_TO_UNITS(7.5, UNIT_1_25_MS)	// 7.5, Minimum connection interval */
#define MAX_CONN_INTERVAL						MSEC_TO_UNITS(100, UNIT_1_25_MS)	// Maximum connection interval. */
#define SLAVE_LATENCY							10											// 5, Slave latency
#define CONN_SUP_TIMEOUT						MSEC_TO_UNITS(5000, UNIT_10_MS)	// 3,000, Connection supervisory timeout. */

#define FIRST_CONN_PARAMS_UPDATE_DELAY		APP_TIMER_TICKS(100)					// 200, Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY		APP_TIMER_TICKS(5000)				// 3000, Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAM_UPDATE_COUNT			3											/**< Number of attempts before giving up the connection parameter negotiation. */



// *** after connect with APP(phone) *** //
00> BLE_GAP_EVT_CONN_PARAM_UPDATE - conn_interval min:6, conn_interval max:6		// from APP(phone), I don't update comm_params.
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:13815
00> BLE_GAP_EVT_CONN_PARAM_UPDATE - conn_interval min:12, conn_interval max:12	// from APP(phone), I don't update comm_params.
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:13845
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:13905
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:13965
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:13995
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14175
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14535
00> tx log (58, 0-1), time:14566							// I transmit my 1 log packet every 30mS.
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14595		// I receive BLE_GATTS_EVT_HVN_TX_COMPLETE event every 30mS.
00> tx log (58, 0-2), time:14596
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14625
00> tx log (57, 1-1), time:14626
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14655
00> tx log (57, 1-2), time:14656
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14685
00> tx log (56, 2),   time:14686
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14715
00> tx log (55, 3),   time:14716
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14745
00> tx log (54, 4),   time:14746
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14775
00> tx log (53, 5),   time:14776
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14805
00> tx log (52, 6),   time:14806
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14835
00> tx log (51, 7),   time:14836
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14865
00> tx log (50, 8),   time:14866
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14895
00> tx log (49, 9),   time:14896
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14925
00> tx log (48, 10),   time:14926
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14955
00> tx log (47, 11),   time:14956
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:14985
00> tx log (46, 12-1), time:14986
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15015
00> tx log (46, 12-2), time:15016
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15045
00> tx log (45, 13),   time:15046
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15075
00> tx log (44, 14-1), time:15076
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15105
00> tx log (44, 14-2), time:15106							// I transmit my 1 log packet every 15mS.
00> tx log (43, 15),   time:15122
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15135			// I receive BLE_GATTS_EVT_HVN_TX_COMPLETE event every 15mS.
00> tx log (42, 16-1), time:15136
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15150
00> tx log (42, 16-2), time:15151
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15166
00> tx log (41, 17-1), time:15166
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15181
00> tx log (41, 17-2), time:15181
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15196
00> tx log (40, 18-1), time:15196
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15211
00> tx log (40, 18-2), time:15211
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15226
00> tx log (39, 19),   time:15226
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15241
00> tx log (38, 20-1), time:15241
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15255
00> tx log (38, 20-2), time:15256
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15271
00> tx log (37, 21-1), time:15271
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15285
00> tx log (37, 21-2), time:15286
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15301
00> tx log (36, 22-1), time:15301
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15315
00> tx log (36, 22-2), time:15316
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15330
00> tx log (35, 23),   time:15331
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15346
00> tx log (34, 24-1), time:15346
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15361
00> tx log (34, 24-2), time:15361
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15376
00> tx log (33, 25),   time:15376
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15390
00> tx log (32, 26),   time:15391
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15405
00> tx log (31, 27),   time:15406
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15420
00> tx log (30, 28),   time:15421
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15436
00> tx log (29, 29),   time:15436
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15450
00> tx log (28, 30),   time:15451
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15466
00> tx log (27, 31),   time:15466
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15481
00> tx log (26, 32),   time:15481
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15495
00> tx log (25, 33),   time:15496
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15510
00> tx log (24, 34),   time:15511
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15526
00> tx log (23, 35-1), time:15526
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15540
00> tx log (23, 35-2), time:15541
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15555
00> tx log (22, 36),   time:15556
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15570
00> tx log (21, 37-1), time:15571
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15585
00> tx log (21, 37-2), time:15586
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15600
00> tx log (20, 38-1), time:15601
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15615
00> tx log (20, 38-2), time:15616
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15630
00> tx log (19, 39),   time:15631
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15646
00> tx log (18, 40-1), time:15646
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15661
00> tx log (18, 40-2), time:15661
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15676
00> tx log (17, 41-1), time:15676
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15690
00> tx log (17, 41-2), time:15691
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15706
00> tx log (16, 42-1), time:15706
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15720
00> tx log (16, 42-2), time:15721
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15736
00> tx log (15, 43),   time:15736
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15750
00> tx log (14, 44-1), time:15751
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15766
00> tx log (14, 44-2), time:15766
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15781
00> tx log (13, 45),   time:15782
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15795
00> tx log (12, 46-1), time:15796
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15810
00> tx log (12, 46-2), time:15811
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15825
00> tx log (11, 47),   time:15826
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15841
00> tx log (10, 48-1), time:15842
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15856
00> tx log (10, 48-2), time:15856
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15871
00> tx log (9, 49-1), time:15872
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15885
00> tx log (9, 49-2), time:15886
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15900
00> tx log (8, 50-1), time:15901
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15915
00> tx log (8, 50-2), time:15916
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15931
00> tx log (7, 51),   time:15932
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15945
00> tx log (6, 52-1), time:15946
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15961
00> tx log (6, 52-2), time:15962
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15975
00> tx log (5, 53),   time:15976
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:15991
00> tx log (4, 54-1), time:15992
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16006
00> tx log (4, 54-2), time:16007
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16021
00> tx log (3, 55-1), time:16022
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16036
00> tx log (3, 55-2), time:16037
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16051
00> tx log (2, 56-1), time:16052
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16066
00> tx log (2, 56-2), time:16067
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16081
00> tx log (1, 57),   time:16082
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16095
00> LOG TX DONE 1														// all tx done
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16111
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:16141

[air]

I installed it using the version below.

• sniffer : _for_bluteooth_le_4.1.0
• wireshark : 3.6.2

 

There is no information about communication after the connection.

Only advertising packets are shown.

There was a similar case while I was looking for related content.

So I followed it, but I still see only advertising packets.

 First of all, can you give me some advice on this?

 

thanks.

[Einar Thorsrud]

Hi,

You need to select a specific device while it is advertising, and then the sniffer will attempt to follow the connection once it is established. See nRF Sniffer usage for details.

[air]

 Hello,

I attach my captured data.

thanks.

packet_capture.pcapng

[Einar Thorsrud]

Hi,

Thanks. This shows that the connection interval is 7,5 ms in the beginning, and then it is updated to 15 ms. It also shows that the nRF always has the more data flag set, indicating that it has more packets to send. However, if you look at the empty packets from the master in between and the NESN/SN indicates a lot of retransmissions for some reason. A retransmission always happens on the next connection event, so this expected given that.

What I do not understand is why you have all these requests for retransmissions/retransmissions. What device is the central in this case? Which phone model, OS version, etc.? Have you tested with a different central?

(If this issue persists, or actually in any case, another good way to increase the throughput is to increase the packet lengt using data length extension - if that is supported by the central.)

[air]

Other phones have a similar result too.

The current configuration is 1-tx / 1-rx characteristic.

I want to check once again whether multi notification is possible even in this configuration.

I am talking about this with the APP part (android / ios).

If possible, I would like to ask for advice on which parts of the APP to be checked.

Of course, there is a way to increase the data length, but due to various restrictions such as compatibility

between existing field products and APPs, I want to keep the current configuration.

 

thanks.

[Einar Thorsrud]

Hi,

I must admit I am no iOS developer, and generally DevZone is not staffed by mobile developers. That said, I know iOS is capable of exchanging multiple packets per connection event so it is interesting that you see this. What do you see if you test with nRF Connect for iOS instead of your custom app?

[air]

I understand.

If so, is there a way to configure and test my app environment in DK etc?

Of course, I know that I need test code, etc.

I want to check the difference.

I'm looking for it.

I'd like some help on which part to refer to.

 thanks.