Issue with IMU Sensor (LSM6DSV16X) Sample Rate in Sensor Hub Mode

[SaeedZadeh]

I am using an IMU sensor in sensor hub mode (LSM6DSV16X, LIS2MDL) with the FIFO interrupt interval set at 30 Hz. The data is sent over BLE. It works perfectly when using RTT, but when I disable debug mode, the sample rate drops to around 1 Hz.

Could someone please help me resolve this issue?

Thank you.

[SaeedZadeh]

Thank you for your reply. When the IMU's FIFO is full, an interrupt will occur on the interrupt pin. The interrupt rate will decrease to 1 Hz as if something changes or is missed when I disable the RTT configuration.

[Edvin]

So what triggers the IMU readings in the first place? Do you have a timer set up at 30Hz or something?

What HW are you running this on? nRF5340DK? Or do you have a custom board?

[SaeedZadeh]

It is input.

I also realized that even when I activated the IMU_SIMULATION mode, my problem persisted. This means that the nRF kept sending the ADC value through BLE to the BLE central at the same rate, whether the IMU was activated and RTT was connected or not. (my judgment reference is the serial output of the central BLE that I monitor on the PC.)

[Edvin]

Ok, why the sensor behaves differently I don't know. You have to refer to it's data sheet or contact the manufacturers. 

SaeedZadeh said:

I also realized that even when I activated the IMU_SIMULATION mode, my problem persisted. This means that the nRF kept sending the ADC value through BLE to the BLE central at the same rate, whether the IMU was activated and RTT was connected or not.

I don't understand. You say that the issue persisted, and that the ADV values are sent at the same rate? Isn't the issue that the ADV values are sent at a slower rate when you disconnect RTT?

Is it an option to use a k_timer to trigger the readings at a given frequency, and a work handler to actually read the samples from your sensor:

https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/kernel/services/timing/timers.html#using_a_timer_expiry_function

Try this and see if this is able to keep the timing consistent.

Best regards,

Edvin

[SaeedZadeh]

Edvin said:

Isn't the issue that the ADV values are sent at a slower rate when you disconnect RTT?

Yes, correct. 

Edvin said:

Is it an option to use a k_timer to trigger the readings at a given frequency, and a work handler to actually read the samples from your sensor:

https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/kernel/services/timing/timers.html#using_a_timer_expiry_function

I am actually a bit confused about it; I would appreciate it if you could kindly give me more details.

I mean, basically, when RTT is connected, the system should be slower as it takes time to process, but in my case, there is something in opposition, which is weird.

Bests,

Saeed

[Edvin]

When the RTT is connected, the nRF is running a debug session, meaning that the clocks on the nRF will be always on, which is not the case when you are not running a debug session. Then they will be on based on needs (requests). 

What I struggle to understand is the flow of how the sensor reports are being read out. The sensor is an I2C slave, so it is not able to push data through I2C. It needs to be actively read by the I2C master, the nRF. If you base the readings on some interrupt pin that the sensor is controlling, then I don't know why it would start interrupting at a slower speed. But that wouldn't be the case if the issue also is persistent if you set the IMU_SIMULATION to true. When this is set to true, then the interrupt pin shouldn't control anything, right?

Best regards,

Edvin

[SaeedZadeh]

Thank you for your explanation. As you mentioned, the problem remains even when the IMU_SIMULATION is true, even though there is no dependency on the interrupt pin. However, the data will be sent once the ADC's interrupt occurs.

Bests,

Saeed

[Edvin]

Do you mean the nRF's ADC? In that case, what triggers the ADC interrupts?

BR,

Edvin

[SaeedZadeh]

Yes, it is nRF's ADC. Whenever the conversion is finished, the interrupt will occur.

static void analog_sample_work_handler(struct k_work *work)
{
	int ret = 0;
	
	
	/* Start ADC */
	ret = analog_read();
	if (ret) {
		LOG_ERR("Cannot read analog signals(err: %d)", ret);		
	} else {
		for(uint8_t i = 0; i < 4; i++) {
			ret = analog_get_raw(i, &adc_raw[i]);
			if (ret) {
				LOG_ERR("Cannot get raw analog values(err: %d)", ret);
				break;
			}
		}
	}
	
	
		
	if(!ret) {		
			
		memset(tx_ble_buffer, 0, sizeof(tx_ble_buffer));  
		sprintf((char *)tx_ble_buffer, "ADC:A1=%d,A2=%d,A3=%d,A4=%d\r\nLED:L1=%d,L2=%d,L3=%d,L4=%d\r\n",
      	adc_raw[0],adc_raw[1],adc_raw[2],adc_raw[3],led_state[0],led_state[1],led_state[2],led_state[3]);
				
		LOG_INF("BLE Tx data : %s", tx_ble_buffer);	
			
		ret = ble_send(tx_ble_buffer, strlen(tx_ble_buffer));	
		if (ret) {
			LOG_ERR("Cannot send ADC/LED data via BLE");	
		}		
	}

	k_work_reschedule(k_work_delayable_from_work(work), K_MSEC(ANALOG_SAMPLE_INTERVAL));
}

static void on_nus_connect(struct k_work *item)
{
	ARG_UNUSED(item);	

	
	
#if !(IMU_SIMULATION)

	gpio_pin_interrupt_configure_dt(&tap_int, GPIO_INT_EDGE_TO_ACTIVE);
	gpio_pin_interrupt_configure_dt(&fifo_int, GPIO_INT_EDGE_TO_ACTIVE);
	

	/* IMU out of low power mode */
	int ret = imu_set_low_power(false);
	if (ret) {
		LOG_ERR("Cannot get IMU out of low power(err: %d)", ret);		
	}
#endif	
	
	
	/* Schedule analog signal processing */
	k_work_schedule(&analog_sample_work, K_MSEC(ANALOG_SAMPLE_INTERVAL));
		
}

[Edvin]

Can you set up the application so that it shows the issue that you are seeing without the actual sensor, then .zip it and upload it here?

Best regards,

Edvin

[SaeedZadeh]

Please find attached your requested file. If you run and connect to the BLE central, you can see the data rate difference on the BLE central's output on the terminal when RTT is connected and disconnected.

Thank you,

Saeed

nrf5340_imu_adc_led_ble_Apr5.zip

[Edvin]

Hello,

The project that you sent doesn't have RTT logging enabled. Are you sure that you are seeing the issue with that exact application, without any modifications? It also seems like IMU_SIMULATION was set to 0. Either way, closing the RTT viewer didn't impact the rate at which the notifications are coming in, as you can tell from the timestamps here, from after closing the RTT window.