ICM-20948 read realtime data error

Hi, I have the Asset Tracker eval with the Sara R5 AWS and the ICM-20948 IMU.
I bought the STM32 MicroMod, and I am trying to make the IMU work.

And when I plot the data received:


(AccelX, AccelY, AccelZ, GyroX, GyroY, GyroZ, Temp)

When I moved it three times:

Note that it used the full scale of the gyro, and the moves were relatively soft, I do not know why it used the full scale.

If I move the board, no motion is shown in the plotter, or it is plotted with some seconds of delay, like if the data is in a FIFO and I have to read all the samples to get the movement samples. But I disabled the FIFOs, and I am reading directly the sensor output registers, not the FIFO, so I do not know why this happens.

I was thinking on having the sensor configured to sample at 100Hz, and then apply the 11 Hz LPF and read it from the STM at 10Hz.

What can be the problem?

Thank you,
Best regards


It looks pretty good to me? I made a rough guesstimate of when it was moved x3…especially if it hasn’t been calibrated yet

This post ICM-20948 acceleration outputs - #2 by jremington has a link to a calibration guide; if you’d like to change the scale being plotted/used just alter a few lines in your code

Hi! Thank you for the reply.
The problem is that I move the sensor and after some seconds, the data is displayed.

The data is read->sent->displayed and the time of that is almost 0, so it is not a problem in the communication and plotting, the problem is that the data rode from the sensor is old data, I cannot read the live data.

You just need to change the serial plotter’s settings to graph a shorter timeframe/window if you mean the graphic window

As for whether the code settings are the issue…to troubleshoot this further, you can try the following:

  1. Adjust the Sensor Sampling Rate and LPF: Instead of configuring the sensor to sample at 100Hz and applying an 11Hz LPF, try a higher sampling rate (e.g., 200Hz) and a higher LPF cutoff frequency (e.g., 20Hz). This may help reduce the delay in the motion detection and plotting.
  2. Disable the LPF: Try reading the sensor data directly without applying the LPF and see if the motion is plotted correctly. This can help isolate the issue to the LPF or the sensor sampling rate.
  3. Measure the Sensor Latency: Use an oscilloscope or a logic analyzer to measure the latency between the actual motion and the data appearing in the sensor output registers. This can help you understand the sensor’s internal processing time.
  4. Implement a Time Synchronization: If the sensor has a timestamp or a clock signal, you can use it to synchronize the sensor data with the motion. This can help compensate for any internal processing delays in the sensor.
  5. Optimize the Data Handling: Ensure that the data is being processed and plotted efficiently, without any bottlenecks in your code or the hardware interface. Profiling your system may reveal any performance issues that could be causing the delay.

You could just try a max Hz/output rate to test initially and work backward