LSM9DS1 vs. MPU-9250 vs. BMX055

[maziarzamani]

Hi.

I was wondering if you had made any comparison on these 3 chips, especially in terms of the magnetometer, which has been a big problem for me on the Invensense in terms of error.

[kriswiner]

There are two kinds of "deGaussing" Follow the Arduino sketch for configuration settings and it should work well.

On Tue, Nov 16, 2021 at 6:18 AM oziqus @.***> wrote:

Thank you. Kris I still have a question how to calculate degausing offsets? Do I have to set / reset every time? Gsy, I will do it, I have to do power off and power on, because when it ends on "reset" I have the north turned 180 degrees.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-970318532, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVSXFM6I252DTAFQKDUMJR3XANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[kriswiner]

What I meant is that you only need to do the one kind, and if you do the other the results won't be good.

On Tue, Nov 16, 2021 at 8:34 AM Tlera Corporation @.***> wrote:

There are two kinds of "deGaussing" Follow the Arduino sketch for configuration settings and it should work well.

On Tue, Nov 16, 2021 at 6:18 AM oziqus @.***> wrote:

Thank you. Kris I still have a question how to calculate degausing offsets? Do I have to set / reset every time? Gsy, I will do it, I have to do power off and power on, because when it ends on "reset" I have the north turned 180 degrees.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-970318532, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVSXFM6I252DTAFQKDUMJR3XANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[oziqus]

Can do it automatically on start? do I have to subtract the offset from the raw out results?

What I meant is that you only need to do the one kind, and if you do the other the results won't be good. On Tue, Nov 16, 2021 at 8:34 AM Tlera Corporation @.***> wrote: …

[kriswiner]

Not sure what you are talking about now.

The MMC5983A has to be configured properly. So in this case, just copy the configuration settings in the Arduino sketch. Then the "deGaussing" will be handled automatically.

As for the magnetic offset biases, etc and the calibration in general, the sketch calculates these and then subtracts them from the scaled data. Again, look at the Arduino sketch to see how this is done.

On Tue, Nov 16, 2021 at 8:37 AM oziqus @.***> wrote:

Can do it automatically on start? do I have to subtract the offset from the raw out results?

What I meant is that you only need to do the one kind, and if you do the other the results won't be good. On Tue, Nov 16, 2021 at 8:34 AM Tlera Corporation @.***> wrote: … <#m-5169463688807018802>

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-970452484, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQX6T64DZ4566ZYVT3UMKCFPANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[oziqus]

Where can I find this configuration?

[kriswiner]

Here: https://github.com/kriswiner/MMC5983MA

and, of course, the MMC5983MA datasheet.

On Tue, Nov 16, 2021 at 9:03 AM oziqus @.***> wrote:

Where can I find this configuration?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-970475702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSDLD6ZEJ6UMHV7JD3UMKFF3ANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[hpmax]

@kriswiner I'm not using your code but I am running into a problem with my LS6DSM. Or rather two problems:

I am sending the following commands (in this order) to initialize it: {0x08,0x09}, // FIFO_CTRL3 set to no decimation (accel+gyro) {0x0a,0x26}, // FIFO_CTRL5 set to continuous mode, 104 Hz (accel+gyro) {0x10,0x40}, // CTRL1_XL set to 104Hz, +/- 2g, ODR/2 {0x11,0x42}, // CTRL2_G set to 104Hz, +/- 125 dps {0x12,0x44}, // CTRL3_C set to BDU + IF_INC {0x14,0x60}}; // CTRL5_C set to rounding for accel+gyro

Approximately once per 1.5 seconds, I read the FIFO using the following code write(i2c_fd,&fs1,1); // Read FIFO_STATUS1 read(i2c_fd,data,2); numsamples=((data[1]&7)<<8)+data[0]; if ((data[1]&64)==64) numsamples=1023; // I don't really understand this, but the FIFO shows 0 bytes to be read until the first read write(i2c_fd,&fs3,1); // Read FIFO_STATUS3 read(i2c_fd,,&fp,1); // Get FIFO Pattern (ignoring the top 8-bits because it should never exceed 5 switch (fp) { // Ignore incomplete data based on FIFO_Pattern case 1 : start=2; fp=3; break; case 2 : start=1; fp=3; break; case 4 : start=2; fp=0; break; case 5 : start=1; fp=0; break; default : start=0; } numsamples-=(numsamples-start)%3; // Adjust numsamples to bring in an integer number of 3-axis samples plus whatever is at the front of the buffer. That means after the first read, it should always be aligned with either fp=0 or fp=3. write(i2c_fd,&fsl,1); // Read FIFO_DATAOUT_LOW read(i2c_fd,data,numsamples<<1); // Collect the data

I am attempting to grab all data on a single read. I think this is legal, as IF_INC is set, so the first byte should be FIFO_DATA_LOW, and the second FIFO_DATA_HIGH, and then because of rounding it should keep reading DATA_LOW and DATA_HIGH over again. That said, I can't tell that multiple reads yield different results. The board itself is not moving and sitting nearly flat on the bench, so Az should be 16384, and all the other readings should be 0.

1) According to Example 1 (pg 98) in the App Note: https://www.st.com/resource/en/application_note/an4987-lsm6dsm-alwayson-3d-accelerometer-and-3d-gyroscope-stmicroelectronics.pdf

FIFO_STATUS3 should describe what is in data[0]/data[1], my switch statement tells me to ignore between the first 0 and 2 words, just in case I start in the middle , since I need to align the FIFO with my read and I am only interested in 3-axis measurements. For testing purposes, I'm printing out the first and last 6 words read. Based on this, I believe all reads are correct in the sense that the first and last 6 words are consistent if FIFO_Pointer is 0 or 3 (which is expected behavior). However, as best I can tell, FIFO_Pattern seems to periodically "drift", that is it almost always keeps track of the reads but occasionally misses one (or gets an extra 1).

2) The other weird thing I've seen is that Az and (I think) Gx seem to suffer from an odd behavior. I don't think the other axes are demonstrating this problem (but it's hard to tell with the axes shifting on me as per issue 1). It appears that occasionally (not periodic at all, more like random noise) it appears that the output drops by about 250 for 1 sample. I was thinking this was just a drop of 1 LSB in the high byte, but it actually seems to be closer to 240-250 than 256. Over 5000 samples, I saw it about 20 times on the gyro. It seems like it might be more common on the accelerometer , and the drop was more like 280-290.

[kriswiner]

On 2) I wonder if you are properly converting the bytes to INT16_t since this sounds like a two's complement error.

On Sun, Feb 20, 2022 at 6:52 PM hpmax @.***> wrote:

@kriswiner https://github.com/kriswiner I'm not using your code but I am running into a problem with my LS6DSM. Or rather two problems:

I am sending the following commands (in this order) to initialize it: {0x08,0x09}, // FIFO_CTRL3 set to no decimation (accel+gyro) {0x0a,0x26}, // FIFO_CTRL5 set to continuous mode, 104 Hz (accel+gyro) {0x10,0x40}, // CTRL1_XL set to 104Hz, +/- 2g, ODR/2 {0x11,0x42}, // CTRL2_G set to 104Hz, +/- 125 dps {0x12,0x44}, // CTRL3_C set to BDU + IF_INC {0x14,0x60}}; // CTRL5_C set to rounding for accel+gyro

Approximately once per 1.5 seconds, I read the FIFO using the following code write(i2c_fd,&fs1,1); // Read FIFO_STATUS1 read(i2c_fd,data,2); numsamples=((data[1]&7)<<8)+data[0]; if ((data[1]&64)==64) numsamples=1023; // I don't really understand this, but the FIFO shows 0 bytes to be read until the first read write(i2c_fd,&fs3,1); // Read FIFO_STATUS3 read(i2c_fd,,&fp,1); // Get FIFO Pattern (ignoring the top 8-bits because it should never exceed 5 switch (fp) { // Ignore incomplete data based on FIFO_Pattern case 1 : start=2; fp=3; break; case 2 : start=1; fp=3; break; case 4 : start=2; fp=0; break; case 5 : start=1; fp=0; break; default : start=0; } numsamples-=(numsamples-start)%3; // Adjust numsamples to bring in an integer number of 3-axis samples plus whatever is at the front of the buffer. That means after the first read, it should always be aligned with either fp=0 or fp=3. write(i2c_fd,&fsl,1); // Read FIFO_DATAOUT_LOW read(i2c_fd,data,numsamples<<1); // Collect the data

I am attempting to grab all data on a single read. I think this is legal, as IF_INC is set, so the first byte should be FIFO_DATA_LOW, and the second FIFO_DATA_HIGH, and then because of rounding it should keep reading DATA_LOW and DATA_HIGH over again. That said, I can't tell that multiple reads yield different results. The board itself is not moving and sitting nearly flat on the bench, so Az should be 16384, and all the other readings should be 0.

1. According to Example 1 (pg 98) in the App Note:

   https://www.st.com/resource/en/application_note/an4987-lsm6dsm-alwayson-3d-accelerometer-and-3d-gyroscope-stmicroelectronics.pdf

FIFO_STATUS3 should describe what is in data[0]/data[1], my switch statement tells me to ignore between the first 0 and 2 words, just in case I start in the middle , since I need to align the FIFO with my read and I am only interested in 3-axis measurements. For testing purposes, I'm printing out the first and last 6 words read. Based on this, I believe all reads are correct in the sense that the first and last 6 words are consistent if FIFO_Pointer is 0 or 3 (which is expected behavior). However, as best I can tell, FIFO_Pattern seems to periodically "drift", that is it almost always keeps track of the reads but occasionally misses one (or gets an extra 1).

1. The other weird thing I've seen is that Az and (I think) Gx seem to suffer from an odd behavior. I don't think the other axes are demonstrating this problem (but it's hard to tell with the axes shifting on me as per issue 1). It appears that occasionally (not periodic at all, more like random noise) it appears that the output drops by about 250 for 1 sample. I was thinking this was just a drop of 1 LSB in the high byte, but it actually seems to be closer to 240-250 than 256. Over 5000 samples, I saw it about 20 times on the gyro. It seems like it might be more common on the accelerometer , and the drop was more like 280-290.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1046420307, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQ63QN4JNZMRX6TAMLU4GSIDANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

Interesting... I'll try to look into that. Perhaps it's happening on those two axes because they just happen to be near a numeric boundary. I believe the code is as follows:

signed char data[4096]; int numbers[2048]; Int numsamples;

read(i2c_fd,data,numsamples<<1); for (i=0;i<numsamples;++i) numbers[i]=(data[(i<<1)+1]<<8)+data[i<<1];

I did have to do a lot of weird playing around to get it to give results that seem to be correct. My total acceleration at rest seems to be about 1.025G's and rotation is on the order if .3 to 1.2 degrees per second. I don't think the high pass filters were turned on though and obviously noise (not counting the described problems) was much better (.02 degrees per second RMS and .5 to 1 milliG RMS).

[kriswiner]

numbers[i]=(data[(i<<1)+1]<<8)+data[i<<1];

Should probably cast data as int16_t

anyway, I am not able to debug your code, but this is easy to check.

On Mon, Feb 21, 2022 at 11:58 AM hpmax @.***> wrote:

Interesting... I'll try to look into that. Perhaps it's happening on those two axes because they just happen to be near a numeric boundary. I believe the code is as follows:

signed char data[4096]; int numbers[2048]; Int numsamples;

read(i2c_fd,data,numsamples<<1); for (i=0;i<numsamples;++i) numbers[i]=(data[(i<<1)+1]<<8)+data[i<<1];

I did have to do a lot of weird playing around to get it to give results that seem to be correct. My total acceleration at rest seems to be about 1.025G's and rotation is on the order if .3 to 1.2 degrees per second. I don't think the high pass filters were turned on though and obviously noise (not counting the described problems) was much better (.02 degrees per second RMS and .5 to 1 milliG RMS).

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1047188383, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTYSY5WSFPKJ23NT43U4KKQFANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

@kriswiner I think that was a good call on issue 2. I'll have to go back and make sure I am not making that mistake elsewhere.

Looking at the the raw data it appears that the problem occurred when the low byte crossed 0x7f or 0x80. So in one case I saw the high byte at 64, an the low byte at 99, and the next sample it was at 64/137 and this resulted in a jump of over 200 in the output. I presume that's because the effective jump would be from +99 to -119 or a total of -218 when the LSB increased by 38.

I changed the code to: numbers[i]=(data[(i<<1)+1]<<8)+(unsigned char)(data[i<<1]) and the problem seemed to disappear.

No progress on issue 1 though.

[kriswiner]

This doesn't look right to me. If it works, well, then OK but better is something like this:

int16_t data = ((int16_t) rawData1 << 8) | rawData0; where rawData1 is the high byte and rawData0 is the low byte.

On Mon, Feb 21, 2022 at 6:22 PM hpmax @.***> wrote:

@kriswiner https://github.com/kriswiner I think that was a good call on issue 2. I'll have to go back and make sure I am not making that mistake elsewhere.

Looking at the the raw data it appears that the problem occurred when the low byte crossed 0x7f or 0x80. So in one case I saw the high byte at 64, an the low byte at 99, and the next sample it was at 64/137 and this resulted in a jump of over 200 in the output. I presume that's because the effective jump would be from +99 to -119 or a total of -218 when the LSB increased by 38.

I changed the code to: numbers[i]=(data[(i<<1)+1]<<8)+(unsigned char)(data[i<<1]) and the problem seemed to disappear.

No progress on issue 1 though.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1047363756, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWH5V4YDJQ7BG3NGQTU4LXNNANCNFSM4BDN6GYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

As best I can tell, the key thing is to cast the high byte as signed and the low byte as unsigned. If you do that (which may well be what you're doing if rawData0 and rawData1 are unsigned chars), it works. if you don't, you start having problems. I think as long as you cast the high byte as signed if you shift it left into a larger variable it will prepend 1's on the front if the number is negative and prepend 0's if the number is positive. My problem was that my low byte was cast as signed and when you add that, it can actually add or subtract depending on the value.

if it is negative it will prepend 1's on the front of it if the high byte is negative. In my case, I actually want a 32-bit integer because I'm further adjusting the number by the resolution (i.e. 16G's multiplies by 8.

[hpmax]

@kriswiner I've spent hours upon hours debugging this and gotten no where, I was hoping you might have some insight since you recommended the part (LSM6DSM). FWIW, ST has recommended the LSM6DSO or LSM6DSR instead (these seem, at least on paper to be newer and superior to the LSM6DSM). But my issue is as follows:

I've configured it for accel/gyro data only, at 104Hz on the FIFO (see my post above for the exact configuration). Every ~150ms I am reading data out of the FIFO (about 90 16-bit words). I have Block Data Update turned on, decimation off and turned on FIFO rounding. When I go to read the data out, I alternate between reading FIFO_PATTERN (0x3C) and FIFO_DATA (0x3E -- 2 bytes). The FIFO_PATTERN should be a repeating pattern of 0-5, followed by 0-5, followed by 0-5, etc. Every once in a while, after some number (30k, 80k, 170k, etc) of reads it'll jump ahead (could be by 1, could be by more -- or it could be to some random number that's not in the 0-5 range). Sometimes it's just the pattern that jumps, other times the pattern doesn't jump but the data does (i.e. it skips ahead in the FIFO without updating the FIFO_PATTERN) leading to a discrepancy between the FIFO_PATTERN and data.

It seems 100% repeatable although it does happen randomly. 3 of the 3 boards that I made and tested exhibit this. So I bought a LSM6DSL eval board and that board experiences the problem too.

Here's what I know...

1) I've compared the data I'm getting in my software to an i2c decode feature on my scope -- they match... So as far as I can tell, I'm doing what I think I'm doing, and the part is actually putting out the data, it's not something screwy in my software.

2) The data coming out seems to be roughly correct values. I don't suspect an analog problem.

3) Resetting the part (by sending a reset command) fixes the problem until it recurs later.

4) The problem appears to be associated with reading the FIFO (or FIFO_PATTERN). That is, if I reset the part, and wait an hour then start reading, everything will be fine after the first few reads... However, if I reset the part and start reading, it will have failed within a couple minutes

[kriswiner]

I doubt there is anything wrong with the LSM6DSM FIFO. I would rather suspect the MCU and/or I2C API you are using. You have already shown that using the same MCU and I2C API and a different sensor (LSM6DSR has a different register map and ASIC than the LSM6DSM).gives the same odd behavior. Complete the comparison test by using a Teensy or ESP32 or STM32L4 and its respective I2C API to run the "same" software. My expectation is that on at least one of these, the FIFO will work as expected.

On Sat, Apr 23, 2022 at 11:04 PM hpmax @.***> wrote:

@kriswiner https://github.com/kriswiner I've spent hours upon hours debugging this and gotten no where, I was hoping you might have some insight since you recommended the part (LSM6DSM). FWIW, ST has recommended the LSM6DSO or LSM6DSR instead (these seem, at least on paper to be newer and superior to the LSM6DSM). But my issue is as follows:

I've configured it for accel/gyro data only, at 104Hz on the FIFO (see my post above for the exact configuration). Every ~150ms I am reading data out of the FIFO (about 90 16-bit words). I have Block Data Update turned on, decimation off and turned on FIFO rounding. When I go to read the data out, I alternate between reading FIFO_PATTERN (0x3C) and FIFO_DATA (0x3E -- 2 bytes). The FIFO_PATTERN should be a repeating pattern of 0-5, followed by 0-5, followed by 0-5, etc. Every once in a while, after some number (30k, 80k, 170k, etc) of reads it'll jump ahead (could be by 1, could be by more -- or it could be to some random number that's not in the 0-5 range). Sometimes it's just the pattern that jumps, other times the pattern doesn't jump but the data does (i.e. it skips ahead in the FIFO without updating the FIFO_PATTERN) leading to a discrepancy between the FIFO_PATTERN and data.

It seems 100% repeatable although it does happen randomly. 3 of the 3 boards that I made and tested exhibit this. So I bought a LSM6DSL eval board and that board experiences the problem too.

Here's what I know...

1.

I've compared the data I'm getting in my software to an i2c decode feature on my scope -- they match... So as far as I can tell, I'm doing what I think I'm doing, and the part is actually putting out the data, it's not something screwy in my software. 2.

The data coming out seems to be roughly correct values. I don't suspect an analog problem. 3.

Resetting the part (by sending a reset command) fixes the problem until it recurs later. 4.

The problem appears to be associated with reading the FIFO (or FIFO_PATTERN). That is, if I reset the part, and wait an hour then start reading, everything will be fine after the first few reads... However, if I reset the part and start reading, it will have failed within a couple minutes

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1107732777, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSRCJX6CCVBEEGTDITVGTQANANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

@kriswiner I'm not sure what the difference between the LSM6DSL and LSM6DSM are. The ST AE said they were very similar, and indeed seem to have the same register map. I suspect it is the same register map, just as I suspect the LSM6DSO and LSM6DSR are the same).

I'm not going to claim that it is impossible that the MCU is the issue. It's an embedded Linux box and I'm certain has a complex i2c API (albeit it's fairly simple on my end):

fd = open("/dev/i2c-1", O_RDWR); ioctl(fd, I2C_SLAVE, i2c_address) ; write(fd,buffer,numberofbytes); read(fd,buffer,numberofbytes);

I will point out that I have been reading data out of numerous devices including an LPS22HH, MS5611, MMC5983MA, AMS5915, a bunch of temp sensors, DS2482, and an A/D converter through the same I2C interface. It is of course possible that there is some peculiar thing that the MCU is doing that is messing with the the FIFO, but obviously it's extremely intermittent.

I actually have an ESP32-S2 on the sensor board and the intention was for the ESP32-S2 to talk to the sensors and the MCU to talk to the ESP32-S2 through two separate I2C busses, however, for now, since I don't know much about ESP32s, I am allowing the ESP32-S2 to idle and I'm bridging the busses so the MCU can talk directly to the sensors. Perhaps the ESP32 is doing something odd, but I don't see much that looks odd on the scope trace and that should ultimately be what the device sees Also, when I used the LSM6DSL dev board the ESP32 (and the sensor board itself) was not present -- so it seems unlikely that's the culprit.

Perhaps we could compare scope traces from a known good trace vs mine. My only hope is that I'm consistently doing something wrong but it's not consistently impacting it.

I was hoping that the LSM6DSR having a completely different ASIC and register map may not have the same problem. I had made a post on EEVBlog and someone there claimed that the LSM6 chips did a lot of weird erratic things and that he had just given up on them after months of trying to track down the problems unsuccessfully. But he didn't thoroughly explain so it's hard for me to take him too seriouly.

[kriswiner]

You are right, LSM6DSM and LSM6DSL are essentially the same. LSM6DSR/O are different from LSM6DSM/L

I am suggesting that you simply get a Teensy or ESP32 or some other dev board and try to read from the FIFO as you are doing now to rule out something weird going on with your Linux box I2C API.

In my experience, the I2C API fubar possibility is much more likely than ST screwing up their FIFO. Also in my experience, the LSM6DSM is among the best IMUs available. ICM42688 looks like it could be even better.

On Sun, Apr 24, 2022 at 10:10 AM hpmax @.***> wrote:

@kriswiner https://github.com/kriswiner I'm not sure what the difference between the LSM6DSL and LSM6DSM are. The ST AE said they were very similar, and indeed seem to have the same register map. I suspect it is the same register map, just as I suspect the LSM6DSO and LSM6DSR are the same).

I'm not going to claim that it is impossible that the MCU is the issue. It's an embedded Linux box and I'm certain has a complex i2c API (albeit it's fairly simple on my end):

fd = open("/dev/i2c-1", O_RDWR); ioctl(fd, I2C_SLAVE, i2c_address) ; write(fd,buffer,numberofbytes); read(fd,buffer,numberofbytes);

I will point out that I have been reading data out of numerous devices including an LPS22HH, MS5611, MMC5983MA, AMS5915, a bunch of temp sensors, DS2482, and an A/D converter through the same I2C interface. It is of course possible that there is some peculiar thing that the MCU is doing that is messing with the the FIFO, but obviously it's extremely intermittent.

I actually have an ESP32-S2 on the sensor board and the intention was for the ESP32-S2 to talk to the sensors and the MCU to talk to the ESP32-S2 through two separate I2C busses, however, for now, since I don't know much about ESP32s, I am allowing the ESP32-S2 to idle and I'm bridging the busses so the MCU can talk directly to the sensors. Perhaps the ESP32 is doing something odd, but I don't see much that looks odd on the scope trace and that should ultimately be what the device sees Also, when I used the LSM6DSL dev board the ESP32 (and the sensor board itself) was not present -- so it seems unlikely that's the culprit.

Perhaps we could compare scope traces from a known good trace vs mine. My only hope is that I'm consistently doing something wrong but it's not consistently impacting it.

I was hoping that the LSM6DSR having a completely different ASIC and register map may not have the same problem. I had made a post on EEVBlog and someone there claimed that the LSM6 chips did a lot of weird erratic things and that he had just given up on them after months of trying to track down the problems unsuccessfully. But he didn't thoroughly explain so it's hard for me to take him too seriouly.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1107880751, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQRZVJSEW3NWL4UJ4LVGV56NANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

I guess this begs the question... Is the LSM6DSR superior to the LSM6DSM in terms of actual performance? The FIFO certainly seems easier to use and less apt to getting screwed up, but maybe not. I presume the ICM42688 (which on paper does appear to have lower noise on the gyro) is unobtanium at this point?

I'm including some scope traces... Sequence looks like this... I read out address 0x3c (FIFO_PATTERN3) get 0x02 (indicating Gyro Z). I then read two bytes from 0x3e (FIFO_LOW followed by FIFO_HIGH) and get 0x32 followed by 0x00 (which is actually 0x0032, which is about 0.2 degrees per second I then read 0x3c again. I should get 0x03, but I get 0x01. I then write out 0x30 and stop. The 0x30 was intended to act as a trigger on the scope to let the scope know it should capture the data around the 0x30 write.

If you see anything wrong, please let me know.

[kriswiner]

ICM42688 is in stock here https://www.cdiweb.com/products/detail/icm42688p-tdk-invensense/637291/. The cool thing about this sensor is the ability to input a 32 kHz clock signal which significantly improves gyro drift https://github.com/kriswiner/ICM42688.

Did you get a chance to verify that using a different MCU/API you see the same FIFO behavior?

I can't wade through scope traces...

On Thu, Apr 28, 2022 at 1:02 AM hpmax @.***> wrote:

I guess this begs the question... Is the LSM6DSR superior to the LSM6DSM in terms of actual performance? The FIFO certainly seems easier to use and less apt to getting screwed up, but maybe not. I presume the ICM42688 (which on paper does appear to have lower noise on the gyro) is unobtanium at this point?

I'm including some scope traces... Sequence looks like this... I read out address 0x3c (FIFO_PATTERN3) get 0x02 (indicating Gyro Z). I then read two bytes from 0x3e (FIFO_LOW followed by FIFO_HIGH) and get 0x32 followed by 0x00 (which is actually 0x0032, which is about 0.2 degrees per second I then read 0x3c again. I should get 0x03, but I get 0x01. I then write out 0x30 and stop. The 0x30 was intended to act as a trigger on the scope to let the scope know it should capture the data around the 0x30 write.

If you see anything wrong, please let me know.

[image: NewFile1] https://user-images.githubusercontent.com/3003859/165705565-75659c39-42b0-456b-a917-10210159ca15.png [image: NewFile2] https://user-images.githubusercontent.com/3003859/165705568-f5f50a87-2bad-4e01-a809-446381e1beba.png [image: NewFile3] https://user-images.githubusercontent.com/3003859/165705569-3ae44517-bd88-4630-9a73-293258de86d9.png [image: NewFile4] https://user-images.githubusercontent.com/3003859/165705571-058b14e2-7ea2-402f-810d-75a3464a2350.png [image: NewFile5] https://user-images.githubusercontent.com/3003859/165705572-702cb585-3397-4a1d-99fb-f0a06ea8770d.png [image: NewFile6] https://user-images.githubusercontent.com/3003859/165705574-1d529f45-0fa1-4b03-b142-0d8492b61d06.png [image: NewFile7] https://user-images.githubusercontent.com/3003859/165705575-6ff4d2f5-15de-48b9-909f-d32975600e09.png [image: NewFile8] https://user-images.githubusercontent.com/3003859/165705576-4c4fd658-03d3-4e5e-aeb2-08d457fd29fd.png [image: NewFile9] https://user-images.githubusercontent.com/3003859/165705579-0d751d8a-863e-4201-8a21-6488b8fc6cac.png

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1111872903, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSEGDNSCIXXADLDUS3VHJA2XANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

I tried using ioctl(fd,I2C_RDWR,...) instead of ioctl(fd,I2C_SLAVE) and it seems to be working now. I've read 3.5 million data points out of the FIFO without any apparent corruption, prior to that I was lucky to get 150k -- oddly, I didn't notice any difference in the scope traces

The ICM42688 does indeed look pretty cool in terms of gyro performance. Accelerometer performance looks pretty similar.

At what point are you going to declare the ICM42688 the 6DOF to use vs the LSM6DSM? How does the LSM6DSR compare to the LSM6DSM?

Thanks for all the help!

Images are from the modified code. Second image is a zoom in on the end of the first.

[kriswiner]

Working on a breakout https://oshpark.com/shared_projects/zIig3KIDyou could test. These should be for sale on Tindie in a few weeks.

On Fri, Apr 29, 2022 at 11:53 PM hpmax @.***> wrote:

I tried using ioctl(fd,I2C_RDWR,...) instead of ioctl(fd,I2C_SLAVE) and it seems to be working now. I've read 3.5 million data points out of the FIFO without any apparent corruption, prior to that I was lucky to get 150k -- oddly, I didn't notice any difference in the scope traces

The ICM42688 does indeed look pretty cool in terms of gyro performance. Accelerometer performance looks pretty similar.

At what point are you going to declare the ICM42688 the 6DOF to use vs the LSM6DSM? How does the LSM6DSR compare to the LSM6DSM?

Thanks for all the help!

Images are from the modified code. Second image is a zoom in on the end of the first.

[image: NewFile1] https://user-images.githubusercontent.com/3003859/166095299-961d197a-b1f4-4d4e-8bd9-51235dfc4c84.png [image: NewFile2] https://user-images.githubusercontent.com/3003859/166095306-593ccd59-0ac0-4ce7-866e-f6921cb11882.png

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1113934706, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKW6NI7YKSKCWSYO63LVHTKGLANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

I just had a couple thoughts while I'm working on my project here.

First, you (or TDK) is claiming the ICM42688 has much better gyro performance because it can be used with an external high accuracy oscillator.

This implies that the gyro output itself has some dependency on clock rate. Clock rate error can presumably be characterized as gaussian, with a mean error, and standard deviation. Presumably both change with time (perhaps as a result of temperature) I'm working on the assumption that the LSM6 has an internal (not super accurate) oscillator, that both measurements and ODR are derived from. This makes me wonder if the mean error could be characterized on an ongoing basis:

Find when it transitions from 0 to 1 sample in the FIFO. Record time. Operate normally, count samples, after, say 10,000 samples, wait until the FIFO goes from 0 to 1. Record time. Then simply subtract previous time from current time and divide by the number of samples read (/6 or whatever). Repeat indefinitely.

Ever tried this? Any thoughts?

Another question I had is that looking at the Madgwick algorithm it seems to be based on getting updates on all available , but the LSM6 and MMC5983MA have different ODRs, so there is no way to fully synchronize them. Any thought on how to deal with that?

[kriswiner]

One could in principle correct the internal oscillator for temperature (this tends to go as T^2) but unless you compare ODR with a time standard (oscilloscope, for example) correcting the mean time drift would be hard to do in firmware.

The ICM42688 claims its best clock accuracy via PLL is 50,000 ppm error. ALmost any 32 kHz crystal will do way better than this,say, 20 ppm. TCXOs can routinely do 3 ppm. The results from my testing to date indeed show the yaw drift for 6 DoF Madgwick orientation estimation is reduced by 4.5 times with a 32 kHz source. Note there is no provision for doing this with the LSM6DSX.

The accel and mag are simply correctors on the main gyro orientation estimation. There is little error introduced by differing ODRs. Or said another way, we have no trouble achieving < 1 degree rms heading accuracy using the sensors this way.

On Sat, May 7, 2022 at 11:57 AM hpmax @.***> wrote:

I just had a couple thoughts while I'm working on my project here.

First, you (or TDK) is claiming the ICM42688 has much better gyro performance because it can be used with an external high accuracy oscillator.

This implies that the gyro output itself has some dependency on clock rate. Clock rate error can presumably be characterized as gaussian, with a mean error, and standard deviation. Presumably both change with time (perhaps as a result of temperature) I'm working on the assumption that the LSM6 has an internal (not super accurate) oscillator, that both measurements and ODR are derived from. This makes me wonder if the mean error could be characterized on an ongoing basis:

Find when it transitions from 0 to 1 sample in the FIFO. Record time. Operate normally, count samples, after, say 10,000 samples, wait until the FIFO goes from 0 to 1. Record time. Then simply subtract previous time from current time and divide by the number of samples read (/6 or whatever). Repeat indefinitely.

Ever tried this? Any thoughts?

Another question I had is that looking at the Madgwick algorithm it seems to be based on getting updates on all available , but the LSM6 and MMC5983MA have different ODRs, so there is no way to fully synchronize them.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1120264600, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVUIKCQZO4PX5QHY4DVI24JFANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

My thought was if your microcontroller has an accurate clock then if you look over a "long" time period (perhaps 10k samples, you should be able to measure an exact number of samples per measurable time period. It'd be hard to get 3ppm or 20ppm, but I bet you could do < 200 ppm, which is a LOT better than 50,000 ppm. I'm not advocating this as a substitute for an external TCXO, I'm suggesting this as a way to improve gyro measurements on the LSM6DSX.

While I've got you here... I might as well ask... If I change the full scale value on the gyro or accelerometer on the LSM6DSX does it affect samples currently in the FIFO? Does it affect the next sample after the change? What if it's in the middle of the conversion? Is there a good way to change without getting a discontinuity?

[kriswiner]

As always with these kinds of what if questions, just try it and show the drift improvement, if any.

If you change scale dynamically during data collection I have no idea what might happen, but likely nothing good...

On Sat, May 7, 2022 at 2:32 PM hpmax @.***> wrote:

My thought was if your microcontroller has an accurate clock then if you look over a "long" time period (perhaps 10k samples, you should be able to measure an exact number of samples per measurable time period. It'd be hard to get 3ppm or 20ppm, but I bet you could do < 200 ppm, which is a LOT better than 50,000 ppm. I'm not advocating this as a substitute for an external TCXO, I'm suggesting this as a way to improve gyro measurements on the LSM6DSX.

While I've got you here... I might as well ask... If I change the full scale value on the gyro or accelerometer on the LSM6DSX does it affect samples currently in the FIFO? Does it affect the next sample after the change? What if it's in the middle of the conversion? Is there a good way to change without getting a discontinuity?

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1120294510, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQKBJ4LPTT3C2DG3FLVI3ONFANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

Noticed a couple things:

1) Over the course of about a half hour, the measured ODR when set to 104Hz seemed to vary between 103.098 and 103.112 Hz. I didn't do a linear regression, but it seemed to be mostly bouncing around. Also worth noting that I'd expect at best 30 ppm accuracy and at worst 100 ppm in the measurement. So it could have been measurement noise, not actual noise in the ODR. Obviously, this doesn't address short term jitter.

2) I shut off accelerometer and gyro when making full-scale adjustments, and the turned it back on. In the case of the accelerometer, the Z-axis took a few measurements before it stabilized (2-4 maybe). Prior to that it read slightly low. (400 counts out of 16700). X and Y axes seemed unaffected. Gyro took more measurements to stabilize (maybe 8) and they were more all over the place.

[kriswiner]

The jitter in the measured ODR is ~50 ppm. Not sure what, if anything, this means. Unless you are using an oscilloscope to measure this it is a conflation of IMU and MCU accuracy.

The internal IMU PLL accuracy is much lower apparently. The real consequence of clock accuracy is gyro drift which translates into yaw or heading drift. So if you want to try to correct for clock error the thing to test for efficacy would be yaw drift.

On Sun, May 8, 2022 at 6:52 AM hpmax @.***> wrote:

Noticed a couple things:

1.

Over the course of about a half hour, the measured ODR when set to 104Hz seemed to vary between 103.098 and 103.112 Hz. I didn't do a linear regression, but it seemed to be mostly bouncing around. Also worth noting that I'd expect at best 30 ppm accuracy and at worst 100 ppm in the measurement. So it could have been measurement noise, not actual noise in the ODR. Obviously, this doesn't address short term jitter. 2.

I shut off accelerometer and gyro when making full-scale adjustments, and the turned it back on. In the case of the accelerometer, the Z-axis took a few measurements before it stabilized (2-4 maybe). Prior to that it read slightly low. (400 counts out of 16700). X and Y axes seemed unaffected. Gyro took more measurements to stabilize (maybe 8) and they were more all over the place.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1120422964, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTXGO6KL4HAPCPMIUTVI7BJJANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

What I was hoping to see was drift over time. Based on my measurements (at least for the half hour or so I measured) I saw no noticeable drift (in clock frequency). I agree, that the vast majority of the variation that I was seeing was probably in the MCU not the IMU. But the whole point was, could I detect drift and adjust the gyro readings to compensate. If I'm not seeing drift in the clock, then I'm not sure how to compensate. I'll try a longer term test, like... Maybe a day or two worth of data and see if anything changes...

I'm actually a bit disappointed, absolute accuracy is surprisingly bad... I'm seeing as much as 1.02G's in the Z-axis and about .024G's on the X and Y axis. .4 degrees per second while not moving seems common on the gyro.

[kriswiner]

Ii is the drift in the gyro that matters, and the way to observe and if possible correct this is through calculation of the gyro-dependent heading from the gyro and or accel-corrected gyro data. You won't see anything in the data itself. Although I suppose if you simply examine the gyro data you might see drift over time there...

On Sun, May 8, 2022 at 11:34 AM hpmax @.***> wrote:

What I was hoping to see was drift over time. Based on my measurements (at least for the half hour or so I measured) I saw no noticeable drift. I agree, that the vast majority of the variation that I was seeing was probably in the MCU not the IMU. But the whole point was, could I detect drift and adjust the gyro readings to compensate. If I'm not seeing drift in the clock, then I'm not sure how to compensate. I'll try a longer term test, like... Maybe a day or two worth of data and see if anything changes...

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1120466730, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKV2CPGX3HH4W3W6V73VJACKLANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

What I was hoping to see was drift in the gyro that was correlated with drift in mean ODR. Like I said, I'll try a longer time frame and see if I see drift in either.

As a side note/question... I tried asking MEMSIC directly, but they were... difficult. I'm trying to understand the Auto_SR_en/Prd_set/En_Prd_set. Frankly, I think their digital interface is awful. Why not have a FIFO and tag whether something is Set or Reset? I'm not sure how you'd know when a Set actually occurs to calculate the offset? (Or for that matter, auto-calculate the offset and apply it)... Or do they?

I wrote a sophisticated algorithm that does a set, runs 6 readings, does a reset, runs 6 readings, and then does a least squares fit to figure out the values at the same "time" and then calculate the offset if the gyro doesn't show a significant reading during that time -- and this would be triggered if the temp changes by more than 3C.... But is that better than the automatic algorithm?

[hpmax]

@kriswiner I'm curious, you mentioned using an STM32L4 to generate the 32kHz clock on the ICM42688... The built in oscillator on the STM32L4 is actually pretty poor (2000 ppm best case?)... So I presume you are using an external oscillator. Can you say what oscillator you're using? And have you tried different oscillators with different levels of stability to see how the results are affected. I think better than 1ppm is achievable without getting too expensive. It starts getting expensive when you do better than 0.28ppm though. Question is, is it worth it to get 0.28, or 0.5, or 1 vs 10 or is there a different limiting factor.

[kriswiner]

The STM32L4 (like this https://www.tindie.com/products/tleracorp/ladybug-stm32l432-development-board/ one) uses a 20 ppm 32.768 kHz LSE crystal and, with an internal PLL and proper calibration can achieve 1 ppm accuracy RTC. The output square wave is probably not 1 ppm accurate but it doesn't need to be since the internal PLL of the ICM42688 is 50,000 ppm, so even a 20 ppm crystal is a significant improvement and is likely good enough. That said, I am currently using the SiT1556 3 ppm TCXO instead of the STM32L4 and this works pretty well and is relatively cheap. I have a breakout board on OSHPark that you could try with this here https://oshpark.com/shared_projects/zIig3KID that works well. This one https://oshpark.com/shared_projects/UHYxnRye I haven't assembled yet...

On Sat, Jun 18, 2022 at 10:00 AM hpmax @.***> wrote:

@kriswiner https://github.com/kriswiner I'm curious, you mentioned using an STM32L4 to generate the 32kHz clock on the ICM42688... The built in oscillator on the STM32L4 is actually pretty poor (2000 ppm best case?)... So I presume you are using an external oscillator. Can you say what oscillator you're using? And have you tried different oscillators with different levels of stability to see how the results are affected. I think better than 1ppm is achievable without getting too expensive. It starts getting expensive when you do better than 0.28ppm though. Question is, is it worth it to get 0.28, or 0.5, or 1 vs 10 or is there a different limiting factor.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1159515526, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKU7FRS5CK5DHD2NGNLVPX6DPANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[hpmax]

I really am curious though how gyro drift corresponds to frequency accuracy. Is there a way to try the same experiment you did before and run it with different accuracies. Perhaps deliberately induce error in the STM32 clock output. Might tell us what's worth pursuing and what isn't.

Thanks for publishing the board. I'm a bit scared of hand assembling that though. I tried building up a board with 2 LPS22, LSM6DSM, and the MMC5983MA and found it had... issues. I was using a stencil, and a reflow oven (admittedly I might not have used the best paste or best practices with the stencil) -- but it was a painful experience.

[kriswiner]

I doubt you will get enough fidelity to see any difference between, say 1 ppm , 5 ppm, and 10 ppm, accuracy sources, for example. Think of it more like an either or choice between barely adequate (50,000 ppm) and pretty good (anything << 1000 ppm).

On Sat, Jun 18, 2022 at 1:19 PM hpmax @.***> wrote:

I really am curious though how gyro drift corresponds to frequency accuracy. Is there a way to try the same experiment you did before and run it with different accuracies. Perhaps deliberately induce error in the STM32 clock output. Might tell us what's worth pursuing and what isn't.

Thanks for publishing the board. I'm a bit scared of hand assembling that though. I tried building up a board with 2 LPS22, LSM6DSM, and the MMC5983MA and found it had... issues. I was using a stencil, and a reflow oven (admittedly I might not have used the best paste or best practices with the stencil) -- but it was a painful experience.

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1159554549, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUYP45AF6YZOTCZXJ3VPYVNTANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[DaveyDave123]

Hi Kris. Many thanks for this conversation and posts on your blog - they are really insightful. Having read these and trawling through some datasheets, I'm coming to the conclusion that the only 9-Dof package that actually fuses all sensor outputs (inc. magno) to produce an absolute attitude is the BNO08X series. Whilst the MPU-9250 and ICM20948 seem to feature fusion for gyro & accel there is not apparent function to bring all 3 together within the chip itself. Is this consistent with your view or have a missed something?

[kriswiner]

There is the ICM20948 which I believe does true 9 DoF fusion using one of its many embedded DMPs but I have never used it so I am not sure. The problem with the BNO055, for example, is that the sensors suck. So for accurate heading estimation, the key ingredients in order of importance are:

1) sensor quality 2) proper sensor calibration

...

99) sensor fusion algorithms 100) everything else...

That said, we have tested the ICM20948 (not me) and it compares favorably to something like this https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-lsm6dsm-lis2md/. So not a bad solution if you can stand a split-power-rail (3V3 analog, 1V8 digital) design and ~2 degree rms heading accuracy is sufficient for your application. However, it is nowhere close to as good as this https://www.tindie.com/products/onehorse/usfsmax-module-and-carrier/. Of course, nothing is at this price point.

Kris

On Wed, Mar 15, 2023 at 10:26 AM DaveyDave123 @.***> wrote:

Hi Kris. Many thanks for this conversation and posts on your blog - they are really insightful. Having read these and trawling through some datasheets, I'm coming to the conclusion that the only 9-Dof package that actually fuses all sensor outputs (inc. magno) to produce an absolute attitude is the BNO08X series. Whilst the MPU-9250 and ICM20948 seem to feature fusion for gyro & accel there is not apparent function to bring all 3 together within the chip itself. Is this consistent with your view or have a missed something?

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1470452934, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTCGHFCEFM5USANB2LW4H3STANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>

[DaveyDave123]

Thanks Kriss. W. r. t. the ICM20948, I do not believe it provides a fused output (as far as I can tell) - I have an open support enquiry, so it'll be interesting to see what they say. Comparing the packages from the datasheets seems challenging as often comparable parameters (sometimes even accuracy figures) are not present for that purpose. The BNX055 seemed to be OK in your 'Bake Off' article and I value some of the AR/VR-orientated features including forward prediction, etc...., but the datasheet does not quote accuracy figures.... The USFSMAX module looks really interesting - certainly an opportunity for improved heading accuracy. Is that down to the magnetoresistance nature of the magnetometer or something else?

Dave

[kriswiner]

Yes, the MC5983A is a superb magnetometer with higher resolution and lower jitter than anything else out there. Albeit a little more power hungry than I would like. But the real trick is the calibration procedure; this is what allows us to go from the pedestrian ~2 degree rms heading accuracy to 0.25 degrees with the USFS module..

On Thu, Mar 16, 2023 at 4:47 AM DaveyDave123 @.***> wrote:

Thanks Kriss. W. r. t. the ICM20948, I do not believe it provides a fused output (as far as I can tell) - I have an open support enquiry, so it'll be interesting to see what they say. Comparing the packages from the datasheets seems challenging as often comparable parameters (sometimes even accuracy figures) are not present for that purpose. The BNX055 seemed to be OK in your 'Bake Off' article and I value some of the AR/VR-orientated features including forward prediction, etc...., but the datasheet does not quote accuracy figures.... The USFSMAX module looks really interesting - certainly an opportunity for improved heading accuracy. Is that down to the magnetoresistance nature of the magnetometer or something else?

Dave

— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-1471806727, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSHEUPBDQB7LCWDSLTW4L4T5ANCNFSM4BDN6GYA . You are receiving this because you were mentioned.Message ID: @.***>