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]

the same as Arduino pins

[Edvin]

SaeedZadeh said:

I apologize for the confusion. The IMU_simulation value should be set to 1. This is the only change that needs to be made,

RTT logging was also disabled. This makes me think there may be other changes as well.

Regarding the video. Are you saying that the text in the UART terminal on the left is increasing when you enable RTT? It didn't look like it. 

The amount of logs on RTT is higher, yes. Is that what you are saying? That doesn't mean that the sampling is higher. That just depends what you are logging. Also, RTT has a higher throughput than UART. 

I think the video clarified that I am not looking at the same thing as you, so I need some more details on what you mean the issue is.

BR,
Edvin

[SaeedZadeh]

Thank you for your attention, Edvin! To clarify, please take a look at the system's block diagram. There are two DK boards.

Also, to be more intuitive, I'm trying to toggle a pin in a while(1) loop every 20ms. I've noticed that the timing significantly increases when the RTT is not connected but normalizes once I connect the RTT. I've attached a video for your reference.

	while (1) {

		ret = gpio_pin_toggle_dt(&signal_pin);
		if(ret < 0){
			return 0;
		};
		k_msleep(20);
		//k_sleep(K_FOREVER);
	}

Best,

[Edvin]

Hello,

SaeedZadeh said:

please take a look at the system's block diagram. There are two DK boards

Yes. I used nRF Connect for Dekstop -> Bluetooth Low Energy as my central. 

Please zip a project that replicates the issue with the sensor simulation set to true, and RTT logging enabled, and try to unzip it to check that it still replicates the issue using nRF connect for Desktop as the central. If it only reproduces with your specific central application, please upload that as well.

Then upload the zipped application that requires no modifications to reproduce the issue.

Best regards,

Edvin

[SaeedZadeh]

Thank you Edvin! I have followed your advice but even with the nRF Connect for Desktop the problem is there. I have uploaded both files here.

Best,

Saeed

8664.nrf5340_imu_adc_led_ble.zip5584.central_uart.zip

[Edvin]

Are you able to build the application from the zip folder that you sent? I tried (in an unmodified nRF Connect SDK v2.2.0, but I can't make it build without changing stuff. Can you please try the same?

BR,
Edvin

[SaeedZadeh]

Hi Edvin,

I use SDK v2.5.2, and there is no problem.

Bests,

[SaeedZadeh]

Hi Edvin,

I tried to build it with SDK v2.2.0, but I couldn't make it.

As I mentioned above, I use SDK v2.5.2, and there is no problem. 

Do you have SDK v2.5.2 by any chance?

Bests,

[Edvin]

Ah, sorry. I didn't see any mentions of versions other than a reference to 2.2.0 from the beginning of the ticket. But that was not by you. I am sorry.

Ok, so now I am actually able to see what you are seeing. 

I have not seen behavior like this before, but it turns out that it was the deferred logging that caused this issue. So basically these two:

CONFIG_LOG_MODE_DEFERRED=n
CONFIG_LOG_MODE_IMMEDIATE=y

When the log is not read out, then the logging is blocking. I didn't test combinations of these, but deferred logging turned off makes the logging blocking, and I guess that something timed out allowing the CPU to continue every 178ms. 

So turn on deferred logging, unless you need it, and intend to read the log. Turning off the logging also works.

Best regards,

Edvin

[SaeedZadeh]

Thank you, Edvin. Your solution resolved the problem, but afterwards, the IMU stopped working for some reason. Therefore, I kept those lines unchanged and made the following adjustments, and everything worked perfectly. However, the IMU's INT2 doesn't work in this situation. Do you have any idea?
Best,

CONFIG_RTT_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=n