• State Verified Answer
  • Replies 49 replies
  • Subscribers 66 subscribers
  • Views 1857 views
  • Users 0 members are here
Attachments (6) Download All
Nordic Case Info
  • Case ID: 327644
Options

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.

Parents Reply
  • +1 in reply to SaeedZadeh

    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

Children
  • 0 in reply to Edvin

    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

  • 0 in reply to SaeedZadeh

    I don't know what the IMU's INT2 is used for. I assume it is an interrupt pin, but what do you mean by "doesn't work"? Does it not trigger, or does the nRF not detect it?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Sorry for the confusion. INT1 and INT2 are the interrupts of the IMU. INT1 triggers the nRF whenever the IMU's FIFO is full, and INT2 is for special actions, such as a tap or a free fall. Here is the entire situations' conclusion:

    1. In the original code where I first encountered the problem, the system worked perfectly with RTT, but when RTT was disconnected, there was a timing delay.
    2. After applying your provided changes, the timing issue was resolved. However, the IMU couldn't trigger the interrupt on the nRF.
      CONFIG_LOG_MODE_DEFERRED=n
CONFIG_LOG_MODE_IMMEDIATE=n
    3. I have modified the overlay through trial and error. Now, INT1 (FIFO overflow) triggers correctly, but INT2 remains high and doesn't trigger.
      CONFIG_RTT_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=n

    Additionally, I was wondering what might be changing here. I am confident that the IMU's code is correct, as it works in my original code (the one with the timing delay and RTT connected). However, things go wrong when I change the logging configuration in the overlay file. When I observe the signals on the logic analyzer, it seems like the IMU initializes but then stops functioning.

    Thank you,

  • 0 in reply to SaeedZadeh

    It seems I may have accidentally closed the ticket. I want to make sure my issue is still being considered.

    Thank you

  • 0 in reply to SaeedZadeh

    Hi Saeed,

    Advin is out-of-office, and I will be with you for now.

    I see that there has been a lot of communication and also the nature of question has been changed.

    Could you summarize the current situation and the code and the setup (connections and measurements), and how can I reproduce it?

    You have mentioned that "things go wrong when I change the logging configuration in the overlay file". Can you show both overlays and describe behaviors? Showing any output / logs would also be helpful.

    Regards,
    Naeem

Related