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]

Thank you for your reply.

Edvin said:

you see the same behavior when setting IMU_SIMULATION to 1 as well?

yes

Edvin said:

When you say "disable logging", you mean setting these two in your prj.conf?

I meant, when I connect to RTT. When it connects, I receive a proper signal; once I disconnect it, the frequency of interrupts significantly drops. Here:

Now, during testing, I just realized that the same behaviour is present even in simulation mode.

Edvin said:

Can you please test the attached project, and measure pin P0.05 using the logic analyzer?

There is no signal on this pin in any configuration.

Edvin said:

r does the issue only occur when you set IMU_SIMULATION to 0?

As I mentioned above, yes, it occurred in both modes. I can see the data rate changes on another device connected to this device through BLE.

Best,

[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