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?

[Edvin]

Hello,

SaeedZadeh said:

There is no signal on this pin in any configuration.

Did you connect to the device with a BLE central? It will not start toggling until ble_send() is called.

I struggle to understand your snippets from the logic analyzer. I am sorry. What is the D2 line in your plot? If it isn't already, can you please try to toggle a pin every time you call ble_send()?

BR,
Edvin

[SaeedZadeh]

Yes, I connected to the BLE central. 

D2 is the interrupt pin of the IMU, which is connected to the nrf53dk.

[Edvin]

What direction does that pin go? Is it an input or output for the nRF53?

Edvin said:

If it isn't already, can you please try to toggle a pin every time you call ble_send()?

[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));
		
}