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

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

Einar Thorsrud — Wed, 02 Mar 2022 14:19:28 GMT

Hi,

Yes, you can test with a DK. And you can also test your firmware (on DK or custom board) against the nRF Connect apps for iOS and Android, to have another reference for that part.

(To have a simple example that push data you could perhaps use the UART/Serial Port Emulation over BLE example, and slightly modify it to send test data as fast as possible instead getting data via UART - you should adjust the NRF_SDH_BLE_GAP_EVENT_LENGTH to a higher value in that case, as the default value is low).

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

air — Wed, 02 Mar 2022 05:45:14 GMT

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.

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

Einar Thorsrud — Thu, 24 Feb 2022 14:16:44 GMT

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?

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

air — Thu, 24 Feb 2022 04:28:39 GMT

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.

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

Einar Thorsrud — Wed, 23 Feb 2022 10:14:36 GMT

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

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

air — Wed, 23 Feb 2022 09:33:29 GMT

Hello,

I attach my captured data.

thanks.

devzone.nordicsemi.com/.../packet_5F00_capture.pcapng

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

Einar Thorsrud — Tue, 22 Feb 2022 08:52:29 GMT

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.

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

air — Tue, 22 Feb 2022 00:17:34 GMT

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.

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

air — Mon, 21 Feb 2022 10:16:15 GMT

I didn't understand well. I'll get a new one.

thanks.

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

Einar Thorsrud — Mon, 21 Feb 2022 09:59:27 GMT

Hi,

The sniffer trace only shows advertising, and what we are interested in happens in the connection. So you need to make a new trace which follows the connection in order to see anything useful.

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

air — Mon, 21 Feb 2022 07:26:25 GMT

I tried to capture packets with sniffer.

I attach it and check why the malformed packet occurs.

Please tell me if there is anything wrong.

devzone.nordicsemi.com/.../packet.pcapng

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

Einar Thorsrud — Fri, 18 Feb 2022 11:33:55 GMT

Hi,

The thing is that even if you configure NRF_SDH_BLE_GAP_GAP_EVENT_LENGTH to a value, that will not necessarily be what is used on the link, that is up to the central. I assume that is the case here, and if so you need to make adjustments on the central side. A sniffer trace should show what happens on air (including the event length and if the peripheral indicates that it has more data by setting the MD bit, which should be the case here).

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

air — Fri, 18 Feb 2022 10:46:21 GMT

Do you mean the event length used on the link to NRF_SDH_BLE_GAP_GAP_EVENT_LENGTH?

Then I wrote the wrong value in the code window.

I've tested many values like 200/400/600 etc.

If not, what does it mean?

Also, what are the things to check in the APP?

I'll try a sniffer trace as you suggested. and I will inquire again.

Thanks.

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

Einar Thorsrud — Fri, 18 Feb 2022 09:49:13 GMT

Looking at the timestamp it looks like you only get one packet per connection event. What is the event length used on the link (not just what you configure in the peripheral)? Can you make a sniffer trace so that we see what is happening on air?

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

air — Fri, 18 Feb 2022 07:25:27 GMT

As you suggested, I tried to transmit after storing the transmission data in the buffer.

The results did not change significantly.

the process

Stacking the transmission data in the buffer
Send Until Fail
Listen for BLE_GATTS_EVT_HVN_TX_COMPLETE event on failure
Repeat from step 1. when receiving BLE_GATTS_EVT_HVN_TX_COMPLETE event

I attach the code I used and log data.

I'm looking for a related part, but I don't know what the particular problem is.

Please advise.

thanks.

#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 		// 400:500mS		// old : 6
#endif


#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(500, UNIT_1_25_MS)	// 100, Maximum connection interval. */
#define SLAVE_LATENCY							0											// 5, Slave latency
#define CONN_SUP_TIMEOUT						MSEC_TO_UNITS(4000, UNIT_10_MS)	// 3,000, Connection supervisory timeout. */

#define FIRST_CONN_PARAMS_UPDATE_DELAY		APP_TIMER_TICKS(1000)				// 100, 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)				// 5000, 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. */


static void packet_transmit_handler(void)
{
	uint32_t err_code __attribute__((unused)) = NRF_SUCCESS;
	ble_gatts_hvx_params_t hvx_params __attribute__((unused));
	ble_gatts_conn_cfg_t queue_size __attribute__((unused));

#if 1
	if(flagBle.txBusy == true)
	{
		if(m_tx_packet_buffer.counter)
		{
			flagBle.txDelay = true;
			m_packet_timer_start();
		}
		#ifdef MSG_BLE
			NRF_LOG_RAW_INFO("@%s() busy error !!!\r\n", M_FUNCTION);
		#endif

		return;
	}
#endif

//	CRITICAL_REGION_ENTER();
//	memset(&queue_size, 0, sizeof(queue_size));

	while(1)
	{
		if(m_tx_packet_buffer.rear_index != m_tx_packet_buffer.front_index)
		{
#if 0
			err_code = ble_dls_tx_string_send(mp_dls,
													(void *)&m_tx_packet_buffer.list[m_tx_packet_buffer.rear_index].data,
													m_tx_packet_buffer.list[m_tx_packet_buffer.rear_index].len);
#else
			uint16_t len = m_tx_packet_buffer.list[m_tx_packet_buffer.rear_index].len;
			memset(&hvx_params, 0, sizeof(hvx_params));
			hvx_params.handle = mp_dls->tx_handles.value_handle;
			hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
			hvx_params.offset = 0;
			hvx_params.p_len  = &len;
			hvx_params.p_data = (void *)&m_tx_packet_buffer.list[m_tx_packet_buffer.rear_index].data;

			err_code = sd_ble_gatts_hvx(mp_dls->conn_handle, &hvx_params);
#endif

			if(err_code == NRF_SUCCESS)
			{
				m_tx_packet_buffer.rear_index++;
				m_tx_packet_buffer.rear_index %= PACKET_BUFFER_TX_NUM;
				m_tx_packet_buffer.counter--;
			#if 1	// def _MSG_BLE
				NRF_LOG_RAW_INFO("sussess - time:%u\r\n", CURRENT_TIME_MS);
			#endif
			}
			else
			{
			#ifdef MSG_BLE
				extern uint16_t m_log_current_index;
//				NRF_LOG_RAW_INFO("@%s fail - num:%d!!! - err_code:%d, time:%u\r\n", M_FUNCTION, m_log_current_index, err_code, CURRENT_TIME_MS);
				NRF_LOG_RAW_INFO("fail!!! - err_code:%d, time:%u\r\n", err_code, CURRENT_TIME_MS);
			#endif
				flagBle.txBusy = true;
				flagBle.txDelay = true;
				break;
			}
		}
		else
		{
//NRF_LOG_RAW_INFO("@%s() same index\r\n");
			break;
		}
	}
//	CRITICAL_REGION_EXIT();

#ifdef _MSG_BLE
	NRF_LOG_RAW_INFO("%s() result:%d, time:%u\r\n", M_FUNCTION, err_code, CURRENT_TIME_MS);
#endif

	if(m_tx_packet_buffer.counter)
	{
		m_packet_timer_start();
	}
}

00> BLE_GAP_EVT_CONN_PARAM_UPDATE - conn_interval min:6, conn_interval max:6
00> sussess - time:20699
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:20714
00> sussess - time:20730
00> BLE_GAP_EVT_CONN_PARAM_UPDATE - conn_interval min:12, conn_interval max:12
00> log_flash_delete : index-0 number-0
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:20744
00> sussess - time:20775
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:20804
00> sussess - time:20805
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:20834
00> log_flash_delete : index-0 number-0
00> sussess - time:20840
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:20864
00> sussess - time:21015
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21044
00> sussess - time:21360
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21389

00> ******* log tx request *******
00>    CMD(229) : log transfer request (0 -> 90)(1, 0)=>(1, 90)
00> tx log (91, 0-1), time:21405						// log save to buffer
00> tx log (91, 0-2), time:21405
00> tx log (90, 1-1), time:21406
00> tx log (90, 1-2), time:21406
00> tx log (89, 2-1), time:21406
00> tx log (89, 2-2), time:21407
00> tx log (88, 3-1), time:21407
00> tx log (88, 3-2), time:21407
00> tx log (87, 4-1), time:21408
00> tx log (87, 4-2), time:21408
00> tx log (86, 5-1), time:21409
00> tx log (86, 5-2), time:21409
00> tx log (85, 6),   time:21409
00> tx log (84, 7-1), time:21410
00> tx log (84, 7-2), time:21410
00> sussess - time:21410								// tx to APP success
00> sussess - time:21410
00> sussess - time:21410
00> sussess - time:21410
00> fail!!! - err_code:19, time:21410				// tx fail, error code : 19
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21419	// BLE_GATTS_EVT_HVN_TX_COMPLETE event
00> tx log (83, 8-1), time:21420						// log save to buffer
00> tx log (83, 8-2), time:21420
00> tx log (82, 9-1), time:21421
00> tx log (82, 9-2), time:21421
00> sussess - time:21421								// tx to APP success
00> fail!!! - err_code:19, time:21421				// tx fail, error code : 19
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21434	// BLE_GATTS_EVT_HVN_TX_COMPLETE event
00> tx log (81, 10-1), time:21435
00> sussess - time:21435
00> fail!!! - err_code:19, time:21435
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21449
00> tx log (81, 10-2), time:21450
00> sussess - time:21450
00> fail!!! - err_code:19, time:21450
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21464
00> tx log (80, 11-1), time:21465
00> sussess - time:21465
00> fail!!! - err_code:19, time:21465
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21479
00> tx log (80, 11-2), time:21479
00> sussess - time:21479
00> fail!!! - err_code:19, time:21479
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21494
00> tx log (79, 12-1), time:21495
00> sussess - time:21495
00> fail!!! - err_code:19, time:21495
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21509
00> tx log (79, 12-2), time:21509
00> sussess - time:21509
00> fail!!! - err_code:19, time:21509
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21524
00> tx log (78, 13-1), time:21525
00> sussess - time:21525
00> fail!!! - err_code:19, time:21525
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21539
00> tx log (78, 13-2), time:21539
00> sussess - time:21539
00> fail!!! - err_code:19, time:21539
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21554
00> tx log (77, 14-1), time:21554
00> sussess - time:21554
00> fail!!! - err_code:19, time:21554
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21569
00> tx log (77, 14-2), time:21570
00> sussess - time:21570
00> fail!!! - err_code:19, time:21570
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21584
00> tx log (76, 15-1), time:21584
00> sussess - time:21584
00> fail!!! - err_code:19, time:21584
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21599
00> tx log (76, 15-2), time:21599
00> sussess - time:21599
00> fail!!! - err_code:19, time:21599
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21614
00> tx log (75, 16-1), time:21614
00> sussess - time:21614
00> fail!!! - err_code:19, time:21614
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21629
00> tx log (75, 16-2), time:21630
00> sussess - time:21630
00> fail!!! - err_code:19, time:21630
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21644
00> tx log (74, 17),   time:21645
00> sussess - time:21645
00> fail!!! - err_code:19, time:21645
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21659
00> tx log (73, 18-1), time:21659
00> sussess - time:21659
00> fail!!! - err_code:19, time:21659
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21674
00> tx log (73, 18-2), time:21675
00> sussess - time:21675
00> fail!!! - err_code:19, time:21675
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21689
00> tx log (72, 19),   time:21689
00> sussess - time:21689
00> fail!!! - err_code:19, time:21689
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21704
00> tx log (71, 20-1), time:21705
00> sussess - time:21705
00> fail!!! - err_code:19, time:21705
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21719
00> tx log (71, 20-2), time:21719
00> sussess - time:21719
00> fail!!! - err_code:19, time:21719
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21734
00> tx log (70, 21-1), time:21734
00> sussess - time:21734
00> fail!!! - err_code:19, time:21734
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21749
00> tx log (70, 21-2), time:21750
00> sussess - time:21750
00> fail!!! - err_code:19, time:21750
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21764
00> tx log (69, 22),   time:21765
00> sussess - time:21765
00> fail!!! - err_code:19, time:21765
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21779
00> tx log (68, 23-1), time:21780
00> sussess - time:21780
00> fail!!! - err_code:19, time:21780
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21794
00> tx log (68, 23-2), time:21794
00> sussess - time:21794
00> fail!!! - err_code:19, time:21794
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21809
00> tx log (67, 24-1), time:21809
00> sussess - time:21809
00> fail!!! - err_code:19, time:21809
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21824
00> tx log (67, 24-2), time:21825
00> sussess - time:21825
00> fail!!! - err_code:19, time:21825
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21839
00> tx log (66, 25),   time:21839
00> sussess - time:21839
00> fail!!! - err_code:19, time:21839
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21854
00> tx log (65, 26-1), time:21855
00> sussess - time:21855
00> fail!!! - err_code:19, time:21855
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21869
00> tx log (65, 26-2), time:21869
00> sussess - time:21869
00> fail!!! - err_code:19, time:21869
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21884
00> tx log (64, 27),   time:21885
00> sussess - time:21885
00> fail!!! - err_code:19, time:21885
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21899
00> tx log (63, 28-1), time:21899
00> sussess - time:21899
00> fail!!! - err_code:19, time:21899
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21914
00> tx log (63, 28-2), time:21914
00> sussess - time:21914
00> fail!!! - err_code:19, time:21914
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21929
00> tx log (62, 29-1), time:21930
00> sussess - time:21930
00> fail!!! - err_code:19, time:21930
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21944
00> tx log (62, 29-2), time:21945
00> sussess - time:21945
00> fail!!! - err_code:19, time:21945
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21959
00> tx log (61, 30),   time:21959
00> sussess - time:21959
00> fail!!! - err_code:19, time:21959
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21974
00> tx log (60, 31-1), time:21974
00> sussess - time:21974
00> fail!!! - err_code:19, time:21974
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:21990
00> tx log (60, 31-2), time:21990
00> sussess - time:21991
00> fail!!! - err_code:19, time:21991
00> tx log (59, 32-1), time:21991
00> @packet_transmit_handler() busy error !!!
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22004
00> sussess - time:22004
00> fail!!! - err_code:19, time:22004
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22019
00> tx log (59, 32-2), time:22019
00> sussess - time:22019
00> fail!!! - err_code:19, time:22019
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22034
00> tx log (58, 33),   time:22034
00> sussess - time:22034
00> fail!!! - err_code:19, time:22034
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22049
00> tx log (57, 34-1), time:22049
00> sussess - time:22049
00> fail!!! - err_code:19, time:22049
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22064
00> tx log (57, 34-2), time:22064
00> sussess - time:22064
00> fail!!! - err_code:19, time:22064
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22079
00> tx log (56, 35-1), time:22079
00> sussess - time:22079
00> fail!!! - err_code:19, time:22079
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22094
00> tx log (56, 35-2), time:22094
00> sussess - time:22094
00> fail!!! - err_code:19, time:22094
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22109
00> tx log (55, 36),   time:22109
00> sussess - time:22109
00> fail!!! - err_code:19, time:22109
00> BLE_GATTS_EVT_HVN_TX_COMPLETE - time:22124

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

Einar Thorsrud — Thu, 17 Feb 2022 12:22:22 GMT

How did you try? Sending multiple packets per connection event is a common practice, and you do it by configuring a long event and sending multiple packets. Note that they must be consecutive, if there is no more packets to send, the event will be closed and you will have to wait for the next. So you need to ensure that you call sd_ble_gatts_hvx() fast enough.

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

air — Thu, 17 Feb 2022 09:28:10 GMT

I tried as your suggestion.

Of course, other phones were also used.

The results were unchanged.

Sure, I’ll check my code more and retry.

If same, I wonder if there is no other way than to send multiple packets at once.

thanks.

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 400

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

Einar Thorsrud — Thu, 17 Feb 2022 07:32:23 GMT

Hi,

I have not found the minimum connection interval for the LG V35 ThinQ, but it is not unusual for a phone to limit it to minimum 15 ms.

[quote user="air"]I wonder if multi notification is possible in one connection interval.[/quote]

Yes, that is possible. That depends on the event length. From the nRF side, you should set a long event length (up to as long as the connection interval). You do this by adjusting NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h. If the phone and nRF agrees on the long event length, then you can send multiple packet during that event. You simply queue more notifications using sd_ble_gatts_hvx() and if there is more data and still time in the evnet, the next packet is sent, and so on.

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

air — Thu, 17 Feb 2022 00:10:38 GMT

My phone condition is as below picture and I use custom APP.

If I cannot adjust the connection interval

I wonder if multi notification is possible in one connection interval.

If this is possible, which part should I refer to?

If 1. is not possible, there seems to be a way to combine several packets into one packet and send them.

Please comment on this.

thanks.

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

Einar Thorsrud — Wed, 16 Feb 2022 13:35:49 GMT

Hi,

I don't know exactly what the first BLE_GAP_EVT_CONN_PARAM_UPDATE is for and why there is a new shortly after, but the last interval seems to be 12 (15 ms), so that matches what you are seeing. In BLE it is always the central (phone in this case) that decides the connection interval, though the peripheral can make changes. And iOS and Android will normally limit the connection interval unless for some specific services (like HID). Which phone are you testing with (model and OS version), and are you using your custom App?