RANT: ICM-20948 IMU is a disaster - Page 1
Forum section: electronics / projects

author: Aggressive_Doughnut
author_rank: Contributor
timestamp: February 23, 2021, 02:24:17 pm
content: This is just a rant, no question really unless you work for TDK InvenSense and want to fill me in on WHY GOD WHY?!?!? A client has designed in the ICM-20948 9-axis jobber and so I think, no biggie, just an I2C IMU like any other. Then...The magnetometer isn't actually part of the main IC really. They glued in a die from a different IC (AK09916) and the main part of the IMU communicates with it as an I2C slave device through a series of pain in the ass registers, with little indication of how you would accomplish this via SPI (luckily I don't have to worry about that last part).There are a bunch of cool built in hardware-calculated data available - quaternions and the like - but there is no data in the datasheet or elsewhere in the natural universe to use the functionality (DMP they call it). The document that details them is not available unless you request it, it is not very easy to digest, and their sample drivers and example applications are a serious nightmare.The InvenSense provided drivers really are fairly insane. You know it's bad when the Arduino, Adafruit, and Sparkfun devs all have threads complaining.The datasheet is very weird, with lots of missing functionality and plenty of typos. I guess they copied it from the MPU series and forgot to change a bunch of stuff? Just a few examples: There is a register to enable FIFO watermark interrupt, but nowhere to set the watermark threshold. There is a FIFO buffer, but no indication in what order your data will be stored to it. Some registers (e.g. most of the interrupt enable ones) are listed as being several bits long, with only 0 or 1 being possible values for the entire bit field - so FIFO OVF is bits 4:0, but can only be 0b00001 or 0b00000.Can we stop it with the "spec at top of datasheet says 7MHz SPI, three pages down it says running SPI faster than 2MHz is not recommended"? Just tell us that the spec is the lowest supported value.Plenty more but I'm tired of typing. Any of these things by itself isn't a big deal, happens all the time, but taken all together they are such a drag. Worst IMU I think I've ever worked with.Okay, rant over - just had to get it out. Move along, nothing to see here.

author: IDEngineer
author_rank: Super Contributor
timestamp: February 24, 2021, 03:25:30 am
content: Quote from: Aggressive_Doughnut on February 23, 2021, 02:24:17 pmOh, I don't know. There are plenty of other candidates vying for that "honor".Your comments about I2C are definitely not unique. I think what happened is that, in the past, the accelerometer and gyro were on a single die in a single package and they brought out an I2C interface so you could "reach through" the 6DOF device and talk to an optionally connected magnetometer in a separate package to get the other 3DOF's. I believe they felt this was a "feature". Later, they combined the two dies into a single package but retained the I2C interface scheme, so the two dies communicate internally within the same physical package. I've seen this on multiple devices. Backward firmware compatibility, yadda yadda yadda, but seriously.Have you discovered that some IMU's offer advanced filtering and the like but don't have the horsepower to actually work? If you keep the enabled feature set down things work OK, but enable too many features and you get erratic results - and sometimes (in the case of a particularly nasty STMicro part) it locks up hard and can only be recovered with a power cycle. That is not a typo. We actually added power cycling capability to one of our designs to accommodate this "feature" before blacklisting the part from our BOM's.But for the Grand Prize of Terrible IMU Design, stroll over to the BMI270 from Bosch Sensortec. This "recommended upgrade" from the venerable BMI160does not contain its own firmware image. No, the host (read: your code) is required to upload an 8KB firmware image to the parton every powerup. There is no nonvolatile memory on the part. You download its firmware from github (!?!), consume 8KB of your own precious nonvolatile memory, and get the pleasure of freshly uploading its brains each and every time you reset. There were SO many other ways to handle this... I cannot think of a worse one.

author: amyk
author_rank: Super Contributor
timestamp: February 24, 2021, 04:31:13 am
content: That part was likely designed for smartphones and other systems where 8KB is a rounding error in storage space, and their firmware is buggy enough that they need to keep making fixes to it

author: IDEngineer
author_rank: Super Contributor
timestamp: February 24, 2021, 05:29:40 pm
content: Agreed on both counts, but they're recommending it as the upgrade path from parts that DON'T require such nonsense. In many embedded applications it's a real stretch to claim any sort of "compatibility". Just a very odd marketing choice.

author: Aggressive_Doughnut
author_rank: Contributor
timestamp: February 25, 2021, 06:07:58 pm
content: Funny, I have worked with the BMI160 but never the 270. Just had a quick Google and yes, looks a proper nightmare. This IMU has the same thing BTW. The "DMP" functions that enable game vector rotations and other quaternion stuff need to be loaded into what must be a very small onboard FPGA on every startup. So yea, you need to have the firmware, matrices, etc on the micro or in a flash rom or something then load them when you start it up to have access to those functions. As a fun extra bonus there are a bunch of warnings on half of the memory about accessing via i2c, they recommend SPI, the other half of the memory has warnings about SPI, recommend using i2c :-P Fun times.

author: IDEngineer
author_rank: Super Contributor
timestamp: February 25, 2021, 07:16:42 pm
content: Makes you wonder why MEMS devices seem so uniquely cursed, doesn't it? I've encountered chips in all disciplines with problems but MEMS seem to have their own concentrated agony of bugs, problems, and horrible design decisions. It's not just one vendor or one family of MEMS devices, either.

author: Aggressive_Doughnut
author_rank: Contributor
timestamp: February 25, 2021, 07:25:33 pm
content: Amen. It's intensely frustrating given how great they can be when you get everything working. The first company that gets it right will have my unending fidelity. I will say that I've had good luck with the IMUs from ST, but they are fairly simple devices - none of this built in programmable logic stuff.

author: IDEngineer
author_rank: Super Contributor
timestamp: February 25, 2021, 07:36:40 pm
content: Quote from: Aggressive_Doughnut on February 25, 2021, 07:25:33 pmThat echoes my experience too. Our early devices used ST components and they worked great. But earlier in this thread I mentioned a later ST device that has a horrible lockup fault that can only be fixed with a power cycle. The amazing thing is the spec sheet openly acknowledged a different problem that locked up, and frankly stated that their recommendation was to cycle power! I applaud the honestly but how about they just design the parts properly?That problem had to do with bootup. If the part was unresponsive they suggested cycling power until it worked right. The problem WE found was more insidious - it would occur minutes, hours, sometimes days later after the part had been working fine. Totally unpredictable and unreproducable with any kind of pattern. That was the first time I used a function generator, in pulse mode, to enable/disable an HPAK power supply so we could automate cycling power on a breadboard for extended periods.Hmm... maybe they hired some folks from the Windows team at Microsoft. They don't seem too bothered by "just reboot".

author: Aggressive_Doughnut
author_rank: Contributor
timestamp: February 25, 2021, 07:43:01 pm
content: Interesting... I have another client that I am talking to that wants to use the LSM6DSOX in their device - I hope that isn't the one that's giving you problems!

author: IDEngineer
author_rank: Super Contributor
timestamp: February 25, 2021, 08:34:59 pm
content: Pretty close... LSM6DS3. I don't know if the suffixes differentiate them enough to make it better for your client.I'm reviewing my notes from that device right now. Some (not all!) of the symptoms we found:* INT1 output can stop working after a random amount of time.*WHO_AM_I value can go wrong after random amount of time.* Chip appears to need "burn-in". Errors will occur for some amount of time, then settle out and a given chip will become more reliable. Timeframe is unpredictable but typically 24-48 hours continuous testing.* SPI interface becomes inoperative. Obviously this condition cannot be recovered with a "soft reset" since you cannot issue the soft reset via the failed SPI interface.* Gyro is extremely sensitive to mechanical stress. This is common for all MEMS gyros but significantly worse with this part. Small amounts of stress generate many LSB's of bias, far more than other parts.My notes go on for a long time. We wasted a LOT of time on this part and still have the PFET-based power control circuit on the PCB that allowed us to cycle power on it under firmware control.Buyer beware!

author: Aggressive_Doughnut
author_rank: Contributor
timestamp: February 26, 2021, 02:14:59 am
content: Yikes! The LSM6DSOX is considerably newer, so I will keep my fingers crossed that they worked out some of the kinks, but I will be vigilant with the testing.

author: IDEngineer
author_rank: Super Contributor
timestamp: February 26, 2021, 02:41:07 am
content: "Considerably newer": That's another problem. I've never seen parts cycle in and out of production as fast as MEMS accs/gyros. Most sensors are in production for years, but I've had a part retired after 24 months in production. Zilch, just simply gone from the distribution chain and you're in a scramble to redesign the PCB and revise the firmware and validate the entire product again. I presume such rapid retirement is being driven by the cellphone market, which consumes a lot of these parts and also sees ridiculously short market lives. I'd seek out non-cellphone MEMS but they all want that market's volumes so they tailor themselves for it.While we're ranting... I wish they'd stop trying to put too much local processing on the MEMS chips. As I mentioned earlier, it is entirely possible (and with no warning in the spec sheets) to enable more "features" than the chip can process. You might - MIGHT - get away with one level of filtering but once you enable much more the chip runs out of horsepower. Sometimes obviously (goes unresponsive, which suggests the SPI interface is implemented in firmware?!?), sometimes silently (your data just becomes invalid with no indication, which means YOU have to do sanity checks all the time). My default now is to disable EVERYTHING and just take the raw data and do my own processing. That has proven reasonably reliable (except for the LSM6DS3, as mentioned) and if you don't have reliability, you don't have a product.BTW, the BMI160 - otherwise a very good part - also suffers from insufficient horsepower to use its own features. No warnings in the spec sheet, but cross the line and the chip goes weird. I turn off everything possible in that part too and just take the raw data. Generally speaking the "features" they offer are kind of marginal anyway, you want and can achieve more control in your own firmware.

author: Berni
author_rank: Super Contributor
timestamp: February 26, 2021, 06:45:53 am
content: I worked with quite a few MEMS motion sensing devices and i agree, interfacing to most of them is a complete shit show.That MPU9256 was a particularly dumb example too with also its "glued in" compass die.I don't really see a reason to use much of the internal data processing capabilities of these MEMS sensors. You can do it in your own firmware where you can actually see what the processing does, debug it, tweak it..etc rather than using there poorly documented buggy black box. The only place where such internal processing makes sense is to detect wakeup gestures. So your whole device can power down and wait for an interrupt signal from a accelerometer to detect motion and wake up the rest of the system.Also the chip packages these things come in are annoying. They often use a thin PCB as the package bottom with just pads on the bottom, not running up the sides like a normal QFN has, so very difficult to see if they are actually soldered properly. But then they also go make the pad pattern under there something weird, like use two different pin pitches along two different sides. The technical drawings in the datasheet are are also drawn in the worst way possible for when you are trying to create a footprint in a CAD tool.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 26, 2021, 05:26:24 pm
content: Sensor fusion– what the DMP does in those parts, combining the data from different sensors to a fused sets of readings – is hard, because there are several different mathematical models on how one can do it. The three approaches I know somewhat for nine degrees of freedom (accelerometer, gyroscope, and magnetic sensor fusion) areKalman filter, Mahony, andMadgwick(derivative of Mahony).In 2014, Freescale published a Kalman filter for attitude-heading-reference-system (AHRS). Paul Stoffregen (Teensy and Teensyduino developer) has ported it to the Arduino environment asNXPMotionSense, and the Madgwick/Mahony asMahonyAHRS, as well as a Windows/macOS/Linux MotionCal program (sources and binaries) to calibrate the sensor set by simply orienting it in all possible orientations (by "waving it around"). Details and links are on the PJRCprop shieldproduct page. While he is the Teensy developer, these are widely used in the Arduino environment with other microcontrollers. The Kalman filter basically requires a 32-bit MCU with floating point support (in the Arduino environment, compiled using GCC) to work well; the Mahony/Madgwick one needs much less computing power and can be used even on 8-bit MCUs.It is not a surprise, then, that the multi-sensor packages that do implement sensor fusion are .. not optimal. To do Kalman filteringright, you need an ALU with 24 to 32 bit fixed point or floating-point support,anda method to calibrate the final device and provide the coefficients back to the sensor. If you skimp on the arithmetic, you lose some precision/stability by using the Mahony/Madgwick algorithm. If you don't, you may price yourself out of the competitive market; these sensor packages are ubiquitous, at least one in every phone and tablet and laptop there are, not to mention all kinds of toys and gadgets. And then you have the hardware manufacturing details and problems on top.

author: Mecanix
author_rank: Frequent Contributor
timestamp: February 26, 2021, 07:58:15 pm
content: ...if the 'Great Marketing' don't have an eval board with a proven reference design yada yadaI got swamp'ed-in pretty deep and for much longer hours than anticipated at several occasions. Lack of experience and knowledge to blame in my case, but was caught up similar scenarios as yours more than enough to avoid the fancy marketing lacking eval & ref design options. Wireless Comm ICs comes to mind suddenly (still have nightmares today lol) :/