Different response time of ICM20948

[Zzx-J]

Hi,

I have serveral ICM20948 and i am using them with the DMP interrupt on to get 9-axis quaternions.

I have found that the response time of the IMU are different. i.e. when doing the same movement, there would be a lag of the output for some of the IMUs. Is that normal?

I have upload the same code for each imu, the sampling frequency, ODR of the IMUs should be the same. Additionally i have tried different ODRs but still there are lags in response for some of the IMUs. I have also checked the data output frequency, again, they are same as expected.

Anybody help please?

[PaulZC]

Hi @Zzx-J ,

I can't help you with this question. But I am happy to leave it open in case someone else can.

Best wishes,
Paul

[faxik]

I'm experiencing the same. However, if I add some debug prints to the sketch, I see that the time inconsistency comes from the status sequence:

status=ICM_20948_Stat_FIFOMoreDataAvail
status=ICM_20948_Stat_FIFOIncompleteData
status=ICM_20948_Stat_FIFOIncompleteData
status=ICM_20948_Stat_FIFOIncompleteData
status=ICM_20948_Stat_FIFOIncompleteData
status=ICM_20948_Stat_FIFOIncompleteData
status=ICM_20948_Stat_FIFOIncompleteData```

This, in turn, comes from the lines (1253–2154) in ICM_20948_C.c:

```c++
    if (fifo_count < icm_20948_DMP_Quat9_Bytes)
      return ICM_20948_Stat_FIFOIncompleteData;

I believe this has something to do with the readout requests (I guess a misalignment in an earlier request or another corruption). Maybe the correct way to process is to clean the FIFO in such a case.

[QuinnBast]

I am not using interrupts but I am getting a similar problem here. It seems that I can read some data from the sensors initially, however after a few seconds, the FIFO totally dies and stops processing any data with the status enum set to ICM_20948_Stat_FIFOIncompleteData.

I'm using basically the exact same code as example 11 running on an Arduino Mega 2560 except I modified it a bit to collect data with the Sparkfun QwiicMux to cycle between all of my IMU sensors that I have.

I also customized the output to look a bit different, but running the code that processes DMP data as shown in example 11 results in some weird behavior:

{"type":"ProgramStart","data":{"status":"OK"}}
{"type":"MuxDetected","data":{"status":"OK"}}

// This repeats for all of my sensors on the mux:
{"type":"BeginDeviceSetup","data":{"status":"OK","id": 0}}
{"type":"DeviceDmpEnabled","data":{"status":"OK","id": 0}}
{"type":"DeviceUncalibrated","data":{"status":"OK","id": 0,"details":"Calibration data will be saved in 2 minutes."}}

{"type":"SetupSuccess","data":{"status":"OK"}}

// Then I start getting sensor data. YAY!
{"type":"SensorData","data":{"status":"OK","id":0,"quat":{"qw": 0.97,"qx":0.25,"qy":0.05,"qz":-0.02,"acc":1024},"telem":{"yaw":-1.05,"pitch":6.40,"roll":28.80}}}
{"type":"SensorData","data":{"status":"OK","id":3,"quat":{"qw": nan,"qx":-0.98,"qy":-1.69,"qz":-1.73,"acc":24593},"telem":{"yaw":nan,"pitch":nan,"roll":nan}}}
{"type":"SensorData","data":{"status":"OK","id":7,"quat":{"qw": 1.00,"qx":-0.00,"qy":-0.00,"qz":0.00,"acc":314},"telem":{"yaw":0.01,"pitch":-0.01,"roll":-0.03}}}
{"type":"SensorData","data":{"status":"OK","id":7,"quat":{"qw": 1.00,"qx":-0.00,"qy":-0.00,"qz":0.00,"acc":336},"telem":{"yaw":0.02,"pitch":-0.02,"roll":-0.06}}}
{"type":"SensorData","data":{"status":"OK","id":3,"quat":{"qw": nan,"qx":1.50,"qy":-1.50,"qz":0.00,"acc":6},"telem":{"yaw":nan,"pitch":nan,"roll":nan}}}
{"type":"SensorData","data":{"status":"OK","id":7,"quat":{"qw": 1.00,"qx":-0.00,"qy":-0.00,"qz":0.00,"acc":336},"telem":{"yaw":0.03,"pitch":-0.03,"roll":-0.08}}}
{"type":"SensorData","data":{"status":"OK","id":1,"quat":{"qw": 0.98,"qx":0.11,"qy":0.00,"qz":-0.18,"acc":433},"telem":{"yaw":-20.15,"pitch":2.57,"roll":12.70}}}

// Each sensor will report data until it reports a FIFO Incomplete....
// The other sensors will report data, but after a FIFO Incomplete, that sensor id never reports `SensorData` ever again.
{"type":"SensorData","data":{"status":"OK","id":0,"quat":{"qw": 0.82,"qx":0.12,"qy":0.11,"qz":-0.55,"acc":353},"telem":{"yaw":-67.00,"pitch":18.33,"roll":3.85}}}
{"type":"SensorData","data":{"status":"OK","id":1,"quat":{"qw": 0.86,"qx":0.17,"qy":-0.05,"qz":-0.49,"acc":336},"telem":{"yaw":-58.52,"pitch":4.29,"roll":19.69}}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorData","data":{"status":"OK","id":7,"quat":{"qw": 1.00,"qx":-0.03,"qy":-0.01,"qz":0.02,"acc":336},"telem":{"yaw":1.90,"pitch":-1.52,"roll":-3.96}}}
{"type":"SensorData","data":{"status":"OK","id":0,"quat":{"qw": 0.82,"qx":0.12,"qy":0.11,"qz":-0.55,"acc":353},"telem":{"yaw":-67.10,"pitch":18.34,"roll":3.86}}}
{"type":"SensorData","data":{"status":"OK","id":1,"quat":{"qw": 0.86,"qx":0.17,"qy":-0.05,"qz":-0.49,"acc":336},"telem":{"yaw":-58.59,"pitch":4.29,"roll":19.70}}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorData","data":{"status":"OK","id":7,"quat":{"qw": 1.00,"qx":-0.03,"qy":-0.01,"qz":0.02,"acc":336},"telem":{"yaw":1.91,"pitch":-1.52,"roll":-3.97}}}
{"type":"SensorData","data":{"status":"OK","id":0,"quat":{"qw": 0.82,"qx":0.12,"qy":0.11,"qz":-0.55,"acc":353},"telem":{"yaw":-67.21,"pitch":18.35,"roll":3.86}}}
{"type":"SensorData","data":{"status":"OK","id":1,"quat":{"qw": 0.86,"qx":0.17,"qy":-0.05,"qz":-0.49,"acc":336},"telem":{"yaw":-58.66,"pitch":4.30,"roll":19.72}}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorData","data":{"status":"OK","id":3,"quat":{"qw": 0.63,"qx":0.66,"qy":-0.33,"qz":-0.25,"acc":-46},"telem":{"yaw":-48.58,"pitch":-4.92,"roll":94.25}}}

// After a while, all of the sensors end up reporting FIFOIncomplete and no sensor data comes through at all when reading from the FIFO.
{"type":"SensorNotOk","data":{"status":"FAILURE","id":1,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":3,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":7,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":1,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":3,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":7,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":1,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":2,"details":"ICM_20948_Stat_FIFOIncompleteData"}}
{"type":"SensorNotOk","data":{"status":"FAILURE","id":3,"details":"ICM_20948_Stat_FIFOIncompleteData"}}

After this point, the sensor is basically dead and won't report anything further and my whole system, comes to a halt.

After some trial and error attempting to figure out what the problem was, I was able to find a work around. But it is an absolute hack and I really dislike this. I am also not sure why this is necessary...

if ((sensor->status == ICM_20948_Stat_Ok) || (sensor->status == ICM_20948_Stat_FIFOMoreDataAvail))
{
      // Process DMP here.
} else if(sensor->status != ICM_20948_Stat_Ok && sensor->status != ICM_20948_Stat_FIFONoDataAvail) {
      // This is a problem...
      Serial.print(F("{\"type\":\"SensorNotOk\",\"data\":{\"status\":\"FAILURE\",\"id\":"));
      Serial.print(x);
      Serial.print(F(",\"details\":\""));
      Serial.print(ErrorTypes[sensor->status]);
      Serial.println(F("\"}}"));

      // I guess reset the FIFO? Seems like a lame workaround to a bug...
      sensor->resetFIFO();
}

My program now 'works' I suppose, and this is the behavior now:

// Sensor failures still happen...
{"type":"SensorNotOk","data":{"status":"FAILURE","id":1,"details":"ICM_20948_Stat_FIFOIncompleteData"}}

// But, soon after... The sensor with that ID will report data again instead of being frozen forever:
{"type":"SensorData","data":{"status":"OK","id":1,"quat":{"qw": 0.90,"qx":0.29,"qy":0.15,"qz":-0.28,"acc":350},"telem":{"yaw":-27.45,"pitch":25.87,"roll":29.57}}}

[PaulZC]

Hi Quinn (@QuinnBast ),

I suspect you are overrunning the FIFOs? If you are reading data from multiple sensors("cycle between all of my IMU sensors"), be careful that you reading them frequently enough to prevent the FIFOs filling up...

For I2C, try increasing the bus clock speed to 400kHz. Does that help?

Switching to SPI may be a better solution...

I hope this helps,
Paul

[QuinnBast]

Hi @PaulZC ,

Thank you for the suggestion, you were correct. I was running the bus clock at 400kHz but it was too slow for 5 sensors. I have found that if I limit the number of sensors I am collecting from to just 3 sensors, then I am able to reliably and consistently collect data from all of the sensors, whereas collecting from 4 or 5 sensors will cause inconsistent data, nans, and transient failures in the sensors as listed above. Likely due to the FIFO writing past it's buffer (stack overflow?).

That is a bit unfortunate because the project I'm working on kind of needs to be able to read the data from all 5 sensors... I tried decreasing the ORD rate but that ended up being too slow and not reliable enough for my use. SPI might be a better solution as the bandwidth on SPI is apparently much higher than I2C (10-20x), but unfortunately I had purchased the SparkFun Qwicc connector cables for my prototype under the assumption that it would work. I'll have to see if I can purchase some additional jumper cables to hook up my prototype for SPI.

That being said, I had to also purchase the SparkFun Qwiic Mux because these sensors only allow being configured on I2C with 2 addresses. Looking at the SPI implementation in this library, does the library automatically enable/disable the chip select pin when talking to the device?

[PaulZC]

Hi @QuinnBast ,

"does the library automatically enable/disable the chip select pin": yes, it does. Code link below.

Best wishes,
Paul

SparkFun_ICM-20948_ArduinoLibrary/src/ICM_20948.cpp

Lines 2062 to 2073 in 32cf061

	_spi->beginTransaction(spisettings);
	digitalWrite(cs, LOW);
	// delayMicroseconds(5);
	_spi->transfer(((reg & 0x7F) | 0x00));
	// SPI.transfer(data, len); // Can't do this thanks to Arduino's poor implementation
	for (uint32_t indi = 0; indi < len; indi++)
	{
	_spi->transfer(*(data + indi));
	}
	// delayMicroseconds(5);
	digitalWrite(cs, HIGH);
	_spi->endTransaction();

[PaulZC]

Also, the DualSPITest example may be useful.