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]

They usually charge me $1.50 each plus shipping, very reasonable. CDW is likley to be significanlty higher than this..

On Sat, Apr 14, 2018 at 4:04 PM, Stephan Edelman notifications@github.com wrote:

@kriswiner https://github.com/kriswiner - Thank you, I'll get them to provide a quote.

— 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-381366951, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quNE21XvMStNWjlUR458t1a45BnIks5tooCCgaJpZM4EbfGw .

[Benik3]

The ICM-20948 is almost the same as MPU9250 what I see. Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs 1MHz).

[kriswiner]

Big difference is the VDDIO maximum is 1.8 V, so if you want to use a 3V3 MCU like we do you will need logic level conversion etc, a PITA and not worth the trouble IMHO. I would recommend the ST sensor suite as a replacement for the MPU9250.

On Sat, Apr 14, 2018 at 4:12 PM, Benik3 notifications@github.com wrote:

The ICM-20948 is almost the same as MPU9250 what I see. Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs 1MHz).

— 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-381367247, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtyDs_KN0fe4DhD1M7SRZQsrvuXPks5tooJHgaJpZM4EbfGw .

[kriswiner]

The MPU9250 mag (AK8963C) has either 14-bit or 16-bit resolution, user selectable. As for the SPI speed, this is irrelevant for sensor fusion and for most applications as far as I can see sine the max sensor sample rate is ~8 kHz. There might be a slight advantage for power usage but overall I would stick with I2C for simple math reasons; 2 pin IO vs. 4 pin IO. GPIOs are too precious to waste on motion sensors.

On Sat, Apr 14, 2018 at 4:14 PM, Tlera Corporation tleracorp@gmail.com wrote:

Big difference is the VDDIO maximum is 1.8 V, so if you want to use a 3V3 MCU like we do you will need logic level conversion etc, a PITA and not worth the trouble IMHO. I would recommend the ST sensor suite as a replacement for the MPU9250.

On Sat, Apr 14, 2018 at 4:12 PM, Benik3 notifications@github.com wrote:

The ICM-20948 is almost the same as MPU9250 what I see. Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs 1MHz).

— 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-381367247, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtyDs_KN0fe4DhD1M7SRZQsrvuXPks5tooJHgaJpZM4EbfGw .

[Benik3]

Yes. I just wouldn't say that it's replacement of MPU9250. It's just for another section of market (IoT etc.)...

[kriswiner]

The mismatched VDDIO has kept me from mustering enough interest in this sensor to do any testing with it; it would be interesting to compare the jitter and stability against the MPU9250.

I can say the LSM6DSM is at least as good as if not better than the MPU6500 and the LIS2MDL is better in a lot of ways (interrupt, lower thermal variation, lower jitter) than the AK8963C. Also, the LPS22HB is significanltly better than the MS5637, our previous "go-to" barometer, in a lot of ways (interrupt, low jitter, FIFO, direct read of pressure/temperature).

The MPU9250 was a significant improvement over the MPU9150 and this could easily be seen in even simple tests. I wonder what an ICM20948 vs. MPU9250 matchup would show...?

On Sat, Apr 14, 2018 at 4:19 PM, Benik3 notifications@github.com wrote:

Yes. I just wouldn't say that it's replacement of MPU9250. It's just for another section of market (IoT etc.)...

— 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-381367560, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgXcbfXc5SIQRoHw9XG43s8gN4nqks5tooPugaJpZM4EbfGw .

[didasy]

@kriswiner

You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.

Do they sell board or just the chip?

[kriswiner]

Omnipro sells the IC, you can get a board from CDIWeb or here https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/.

On Tue, Apr 17, 2018 at 3:49 AM, Andida Syahendar notifications@github.com wrote:

@kriswiner https://github.com/kriswiner

You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.

Do they sell board or just the chip?

— 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-381945538, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoWhzFX3oBrfS-6Pbdm9B16R2zm7ks5tpci3gaJpZM4EbfGw .

[laufetc]

And... if the volumes are very large (100k+), you can contact EM Microlectronic directly to get extremely inexpensive pricing.

On Tue, Apr 17, 2018 at 10:02 AM, Kris Winer notifications@github.com wrote:

Omnipro sells the IC, you can get a board from CDIWeb or here <https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/

.

On Tue, Apr 17, 2018 at 3:49 AM, Andida Syahendar < notifications@github.com> wrote:

@kriswiner https://github.com/kriswiner

You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.

Do they sell board or just the chip?

— 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-381945538, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoWhzFX3oBrfS- 6Pbdm9B16R2zm7ks5tpci3gaJpZM4EbfGw .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-382047992, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJxqYS895kBTGAlZz5RrJ56AiWJtPAVks5tphIogaJpZM4EbfGw .

[burnhamd]

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180?
I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

[kriswiner]

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd notifications@github.com wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

[saedelman]

Kris,

Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:18 PM, Kris Winer notifications@github.com<mailto:notifications@github.com> wrote:

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd notifications@github.com<mailto:notifications@github.com> wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kriswiner/MPU6050/issues/6#issuecomment-387494994, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw.

[kriswiner]

They are very efficient, never thought about licensing. We are still in the middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs. our own, etc. Might be premature but if you need +/- 1 degree heading accuracy, we can discuss licensing our methods for getting there.

On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman notifications@github.com wrote:

Kris,

Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:18 PM, Kris Winer <notifications@github.com<mailto: notifications@github.com>> wrote:

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd <notifications@github.com< mailto:notifications@github.com>> wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386, or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ kriswiner/MPU6050/issues/6#issuecomment-387494994, or mute the thread< https://github.com/notifications/unsubscribe- auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.

— 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-387496047, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw .

[saedelman]

Hello Kris,

Can I contact you offline?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:24 PM, Kris Winer notifications@github.com<mailto:notifications@github.com> wrote:

They are very efficient, never thought about licensing. We are still in the middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs. our own, etc. Might be premature but if you need +/- 1 degree heading accuracy, we can discuss licensing our methods for getting there.

On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman notifications@github.com<mailto:notifications@github.com> wrote:

Kris,

Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:18 PM, Kris Winer notifications@github.com<mailto:notifications@github.com<mailto: notifications@github.commailto:notifications@github.com>> wrote:

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd notifications@github.com<mailto:notifications@github.com< mailto:notifications@github.com>> wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386, or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ kriswiner/MPU6050/issues/6#issuecomment-387494994, or mute the thread< https://github.com/notifications/unsubscribe- auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.

— 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-387496047, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kriswiner/MPU6050/issues/6#issuecomment-387496643, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFAUW558HQN6C6RyrAp6ZAC1JOu4NFDUks5tweLZgaJpZM4EbfGw.

[kriswiner]

925 8547820

On Tue, May 8, 2018 at 11:26 AM, Stephan Edelman notifications@github.com wrote:

Hello Kris,

Can I contact you offline?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:24 PM, Kris Winer <notifications@github.com<mailto: notifications@github.com>> wrote:

They are very efficient, never thought about licensing. We are still in the middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs. our own, etc. Might be premature but if you need +/- 1 degree heading accuracy, we can discuss licensing our methods for getting there.

On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman <notifications@github.com mailto:notifications@github.com> wrote:

Kris,

Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:18 PM, Kris Winer <notifications@github.com<mailto: notifications@github.com><mailto: notifications@github.commailto:notifications@github.com>> wrote:

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd <notifications@github.com< mailto:notifications@github.com>< mailto:notifications@github.com>> wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386 , or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ kriswiner/MPU6050/issues/6#issuecomment-387494994, or mute the thread< https://github.com/notifications/unsubscribe- auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.

— 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-387496047, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ kriswiner/MPU6050/issues/6#issuecomment-387496643, or mute the thread< https://github.com/notifications/unsubscribe-auth/ AFAUW558HQN6C6RyrAp6ZAC1JOu4NFDUks5tweLZgaJpZM4EbfGw>.

— 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-387497260, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnXhIw-w8uir_-URFVavz1yn68fZks5tweNTgaJpZM4EbfGw .

[kriswiner]

Here https://www.digikey.com/products/en/sensors-transducers/motion-sensors-imus-inertial-measurement-units/567?k=Thales%20Visionix%20Navchip is an example of a much more expensive 6 DoF solution; I can't quite figure out what this does that the $35 USFS (EM7180 + MPU9250) doesn't...except cost and weight a lot more and require an odd connector interface, etc. Who is the customer for this kind of product?

On Tue, May 8, 2018 at 11:24 AM, Tlera Corporation tleracorp@gmail.com wrote:

They are very efficient, never thought about licensing. We are still in the middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs. our own, etc. Might be premature but if you need +/- 1 degree heading accuracy, we can discuss licensing our methods for getting there.

On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman <notifications@github.com

wrote:

Kris,

Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?

Regards,

Stephan.

Stephan Edelman NewAce Corporation 866.779.1518 x221 416.460.9602

On May 8, 2018, at 2:18 PM, Kris Winer <notifications@github.com<mailto: notifications@github.com>> wrote:

No idea, I have never used Invensense's MPL. We typically get +/- 2 degree rms heading error with the EM7180, and can get +/- 1 degree heading error with our own propriatary fusion algorithms. This depends on excellent calibration of the sensors. +/- 4 degrees is typical of what I would expect from the MPU9250 using simple Madgwick or Mahony fusion.

On Tue, May 8, 2018 at 11:16 AM, burnhamd <notifications@github.com<mail to:notifications@github.com>> wrote:

Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180? I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.

— 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-387494386, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kris winer/MPU6050/issues/6#issuecomment-387494994, or mute the thread< https://github.com/notifications/unsubscribe-auth/ AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.

— 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-387496047, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw .

[Batilan]

Hi Kris,

Great topic and great linked articles! Any chance you will include the STM IIS2MDC magnetometer in your research? However I guess you have more than enough sensors to compare already :-). Probably you already saw this nice overview of STM magnetometers.

[kriswiner]

Well we like the LIS2MDL very much and the IIS2MDC seems to be a successor, but I will have to look into it. This https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/ is our latest breakout for the all-ST sensor suite including the LIS2MDL, and we are producing a version with the EM7180 motion co-processor right now. We will have accuracy data for this sensor suite compared to the MPU9250 on github in a few weeks. For now I can tell you it performs as well or better that the MPU9250 and with our own sensor fusion algorithms we can routinely obtain 1 degree heading accuracy. So the sensor are really quite good.

On Sat, May 19, 2018 at 3:37 AM, Batilan notifications@github.com wrote:

Hi Kris,

Great topic and great linked articles! Any change you will include the STM IIS2MDC magnetometer http://www.st.com/content/st_com/en/products/mems-and-sensors/e-compasses/iis2mdc.html in your research? However I guess you have more than enough sensors to compare already :-). Probably you already saw this nice overview of STM magnetometers. http://www.st.com/en/mems-and-sensors/e-compasses.html?querycriteria=productId=SC1449

— 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-390396197, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm72w6PTzU029CpQTdW1IBCyVZ-Lks5tz_XZgaJpZM4EbfGw .

[kriswiner]

As far as I can tell, the LIS2MDL and IIS2MDC are identical.

On Sat, May 19, 2018 at 8:29 AM, Tlera Corporation tleracorp@gmail.com wrote:

Well we like the LIS2MDL very much and the IIS2MDC seems to be a successor, but I will have to look into it. This https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/ is our latest breakout for the all-ST sensor suite including the LIS2MDL, and we are producing a version with the EM7180 motion co-processor right now. We will have accuracy data for this sensor suite compared to the MPU9250 on github in a few weeks. For now I can tell you it performs as well or better that the MPU9250 and with our own sensor fusion algorithms we can routinely obtain 1 degree heading accuracy. So the sensor are really quite good.

On Sat, May 19, 2018 at 3:37 AM, Batilan notifications@github.com wrote:

Hi Kris,

Great topic and great linked articles! Any change you will include the STM IIS2MDC magnetometer http://www.st.com/content/st_com/en/products/mems-and-sensors/e-compasses/iis2mdc.html in your research? However I guess you have more than enough sensors to compare already :-). Probably you already saw this nice overview of STM magnetometers. http://www.st.com/en/mems-and-sensors/e-compasses.html?querycriteria=productId=SC1449

— 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-390396197, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm72w6PTzU029CpQTdW1IBCyVZ-Lks5tz_XZgaJpZM4EbfGw .

[CZEMacLeod]

@kriswiner I notice earlier in this thread you were discussing the LIS3MDL and later then go with the LIS2MDL. Do you have any discussion on the differences and why you picked the 2 vs. the 3? I currently have a GPS board with the LIS3MDL and want to understand what limitations I may encounter and if I should try and change chip... Unfortunately they don't seem to be pin compatible so I can't easily switch chip and investigate myself just now.

[kriswiner]

The LIS2MDL offers some advantages but ther perfromance of the LIS3MDL should be fine. The 2MDL uses anisotropic magnetoresistance instead of Hall effect and is less susceptible to temperature variations. It als has a single wide-range sensitivity.

On Mon, Jul 30, 2018 at 4:47 AM, Cynthia MacLeod notifications@github.com wrote:

@kriswiner https://github.com/kriswiner I notice earlier in this thread you were discussing the LIS3MDL and later then go with the LIS2MDL. Do you have any discussion on the differences and why you picked the 2 vs. the 3? I currently have a GPS board with the LIS3MDL and want to understand what limitations I may encounter and if I should try and change chip... Unfortunately they don't seem to be pin compatible so I can't easily switch chip and investigate myself just now.

— 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-408836442, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qldF5Ua1FIjeDZF89gwzbLMNEp27ks5uLvJvgaJpZM4EbfGw .

[dtornqvist]

I have designed my own breakout board for the ICM-20948. If you are interested, check it out! I would love to get some comments as this is one of my first designs. https://github.com/dtornqvist/icm-20948-breakout

[kriswiner]

Hi David,

The design looks very well done. I didn't check the schematic and will assume this is correct. I have some comments on the layout:

First, this kind of design is much more easily done with a four-layer pcb and the design performance would be better as well. Then you could have a 1.8 V layer and a GND layer and avoid having the long traces for these that are in your current design.

Are you using the grossly oversized Sparkfun passive footprints? I would cut these down by half in width and length.

Best to avoid vias anywhere near the ICM package to minimize pcb stresses.

I would use the extra PTH for ICMaddress pin so you can have more than one on a given I2C bus. This is standard practice.

I notice there is no copper ground pour on either layer; maybe no room with all of those traces. But the bottom at least needs one. Both sides really, then you can eliminate several vias, which is a good thing.

All power traces should be minimum 0.25 mm wide.

There should be no copper underneath the ICM package, and the ICM pad should not be connected to the pcb. At least the latter was true for the MPU9250 and I would be surprised if the advice is to solder the central pad for the new design.

Don't you need pullups on the I2C bus?

I would use 13-mil (0.325 mm) vias since this is the smallest allowed with two layers. Another benefit to a four layer design is the via size minimum drops to 10 mil.

Yes, there are a lot of clearance issues even with the looser OSHPark design rules (which I recommend you use.

My minimum recommendations:

Use ground copper pours on top and bottom and eliminate as many GND vias as possible.

Cut the size of the passive footprints.

remove metal from underneath the ICM package.

You need at least 15 mils center-to-center (0.375 mm) separation between each trace.

When you have the ground pours in and the design revised let me have another look.

Kris

On Fri, Jan 18, 2019 at 5:10 AM David notifications@github.com wrote:

I have designed my own breakout board for the ICM-20948. If you are interested, check it out! I would love to get some comments as this is one of my first designs. https://github.com/dtornqvist/icm-20948-breakout

— 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-455540747, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpIHPgcFVoXxElNtZNkB2obQ_Varks5vEce9gaJpZM4EbfGw .

[dtornqvist]

Thanks a lot for all constructive comments! :-)

Currently, I try to live with EAGLE free and is therefore limited to two layers. But I guess I will have to upgrade for more complicated designs.

Thanks for the remark about the capacitor footprints, I changed those.

I have removed everything underneath the ICM-package and moved away the vias. Please check if you think they are far away enough.

I added a solder jumper to set the ICM-address.

I read up on how to make ground planes and added on both sides.

The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I missed making them 0.25. Since those are only reference for the signal levels, do you think it is necessary?

Pull-ups on the i2c bus should not be needed as the level translator contains internal pull-ups.

I downloaded the design rules from OSH Park, which were more strict than the original settings i had. The remaining issues now all relate to the footprint of the ICM. My current footprint is from the Sparkfun MPU-9250. Do you know any better footprints or do I have to update manually? Is it possible to get a footprint for this module that fulfill the OSH Park specifications?

[kriswiner]

I have a footprint that I use. The only caveat is I would make the lead pad lengths a bit shorter if I were doing it again. Maybe I already did on this design:

https://oshpark.com/shared_projects/zlx9tPml

note this is before I minimized the passive footprints, although these are smaller than the Sparkfun version.

On Sun, Jan 20, 2019 at 2:01 AM David notifications@github.com wrote:

Thanks a lot for all constructive comments! :-)

Currently, I try to live with EAGLE free and is therefore limited to two layers. But I guess I will have to upgrade for more complicated designs.

Thanks for the remark about the capacitor footprints, I changed those.

I have removed everything underneath the ICM-package and moved away the vias. Please check if you think they are far away enough.

I added a solder jumper to set the ICM-address.

I read up on how to make ground planes and added on both sides.

The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I missed making them 0.25. Since those are only reference for the signal levels, do you think it is necessary?

Pull-ups on the i2c bus should not be needed as the level translator contains internal pull-ups.

I downloaded the design rules from OSH Park, which were more strict than the original settings i had. The remaining issues now all relate to the footprint of the ICM. My current footprint is from the Sparkfun MPU-9250. Do you know any better footprints or do I have to update manually? Is it possible to get a footprint for this module that fulfill the OSH Park specifications?

— 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-455852717, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw .

[kriswiner]

If the 1.8 V traces are not power traces but only signal traces then 8 mil is sufficient. I would not use 6 mil traces anywhere on a 2 layer design.

On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation tleracorp@gmail.com wrote:

I have a footprint that I use. The only caveat is I would make the lead pad lengths a bit shorter if I were doing it again. Maybe I already did on this design:

https://oshpark.com/shared_projects/zlx9tPml

note this is before I minimized the passive footprints, although these are smaller than the Sparkfun version.

On Sun, Jan 20, 2019 at 2:01 AM David notifications@github.com wrote:

Thanks a lot for all constructive comments! :-)

Currently, I try to live with EAGLE free and is therefore limited to two layers. But I guess I will have to upgrade for more complicated designs.

Thanks for the remark about the capacitor footprints, I changed those.

I have removed everything underneath the ICM-package and moved away the vias. Please check if you think they are far away enough.

I added a solder jumper to set the ICM-address.

I read up on how to make ground planes and added on both sides.

The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I missed making them 0.25. Since those are only reference for the signal levels, do you think it is necessary?

Pull-ups on the i2c bus should not be needed as the level translator contains internal pull-ups.

I downloaded the design rules from OSH Park, which were more strict than the original settings i had. The remaining issues now all relate to the footprint of the ICM. My current footprint is from the Sparkfun MPU-9250. Do you know any better footprints or do I have to update manually? Is it possible to get a footprint for this module that fulfill the OSH Park specifications?

— 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-455852717, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw .

[kriswiner]

On the ADO, you can use a solder jumper, but I prefer exposing this choice to an edge pin for a lot of reasons but mostly because I don't like NC outputs. Bad design practice. But your design, your choice.

I didn't receive any files for the new design. When ready, I am happy to take another look if you want me to.

On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation tleracorp@gmail.com wrote:

If the 1.8 V traces are not power traces but only signal traces then 8 mil is sufficient. I would not use 6 mil traces anywhere on a 2 layer design.

On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation tleracorp@gmail.com wrote:

I have a footprint that I use. The only caveat is I would make the lead pad lengths a bit shorter if I were doing it again. Maybe I already did on this design:

https://oshpark.com/shared_projects/zlx9tPml

note this is before I minimized the passive footprints, although these are smaller than the Sparkfun version.

On Sun, Jan 20, 2019 at 2:01 AM David notifications@github.com wrote:

Thanks a lot for all constructive comments! :-)

Currently, I try to live with EAGLE free and is therefore limited to two layers. But I guess I will have to upgrade for more complicated designs.

Thanks for the remark about the capacitor footprints, I changed those.

I have removed everything underneath the ICM-package and moved away the vias. Please check if you think they are far away enough.

I added a solder jumper to set the ICM-address.

I read up on how to make ground planes and added on both sides.

The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I missed making them 0.25. Since those are only reference for the signal levels, do you think it is necessary?

Pull-ups on the i2c bus should not be needed as the level translator contains internal pull-ups.

I downloaded the design rules from OSH Park, which were more strict than the original settings i had. The remaining issues now all relate to the footprint of the ICM. My current footprint is from the Sparkfun MPU-9250. Do you know any better footprints or do I have to update manually? Is it possible to get a footprint for this module that fulfill the OSH Park specifications?

— 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-455852717, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw .

[dtornqvist]

Hi again Kris,

I have updated the ICS footprint and made sure all traces are at least 8 mil. I have not connected AD0 to an edge pin yet, mostly because I would have to route it to the level converter on the left side of the board and then back to the pin on the right side again...

Please have a look, the git repo should be updated: https://github.com/dtornqvist/icm-20948-breakout

Thanks!

[kriswiner]

Much better!

I have some further recommandations.

First required.

Place a ground plane cutout on the bottom side underneath the ICM package; no copper beneath the package is the goal.

Increase the width of the ground planes to 10 mil and de-select thermals, not required here.

Add silkscreen labels to denote PTH function.

I would also move the cap pair closer to the ICM.

Desired (these are my aesthetic preferences, no required for proper function).

You have the separation between PTH headers at 0.6 inches, but many dev boards (like the Teensy, for example) use a 0.7 inch separation. So your chouce precludes direct mounting on these boards.

There is a lot of pcb between the headers and the pcb edge. I would minimize this such that the header silkscreen edge matched the copper edge. of course, I would drop the header silkscreen altogether since it add nothing to the design but unnecessarily takes up a lot of space.

I would rotate the solder jumper by 90 degrees and scoot the caps and LDO over to the left a bit to accomodate it. Then I would try to minimize the board height.

The other problem is that optimally the ICM would be in the center of the board. This is not possible in this design (unless you put the translator on the back of the board).

Select 20 mils as the mask width so the vias are covered with solder mask so as not to expose metal.

Close the gap in the ground plan above the ICM. The ground plane should be continuous around the circuit if possible.

Might be more but take another stab at considering these recommendations.

Kris

On Mon, Jan 21, 2019 at 1:10 AM David notifications@github.com wrote:

Hi again Kris,

I have updated the ICS footprint and made sure all traces are at least 8 mil. I have not connected AD0 to an edge pin yet, mostly because I would have to route it to the level converter on the left side of the board and then back to the pin on the right side again...

Please have a look, the git repo should be updated: https://github.com/dtornqvist/icm-20948-breakout

Thanks!

— 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-455998910, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlabNhP3cRf6lQbwC1-4b3HosAMwks5vFYPogaJpZM4EbfGw .

[MBurtsev]

Has anyone tried BNO080/085 ?

[kriswiner]

Doesn't matter how fancy the fusion algorithm is if the underlying sensors are crappy. And they are on the BNO055/80/85. No chance of accurate absolute orientation estimation with this bunch...

On Mon, Jan 21, 2019 at 3:06 PM Maksim Burtsev notifications@github.com wrote:

Has anyone tried BNO080/085 ?

— 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-456220927, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqEQmZ63tQbocU05H_dtbCp-7lXLks5vFkfvgaJpZM4EbfGw .

[MBurtsev]

Is it real? It costs more than its competitors. I thought it was high quality.

[kriswiner]

Same sensors as can be found on the BMX055, not very good...

On Mon, Jan 21, 2019 at 10:05 PM Maksim Burtsev notifications@github.com wrote:

Is it real? It costs more than its competitors. I thought it was high quality.

— 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-456281656, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpydySqzMFHzrfCSdropaxp3F0Jpks5vFqo0gaJpZM4EbfGw .

[dtornqvist]

Hi again Kris,

I have updated the board with many of your points to get better placement of the components and utilize space better, also changed to 0.7 inch width (although I realized that my teensy is in fact 0.6 wide)

After you pointed out to not route under the icm package, I read up on the Invensense guidelines. They say on p1 (Trace Routing) that "Note: For best performance, design a ground plane under the sensor to reduce PCB signal noise from the board on which the sensor is mounted." So I guess that should be there, but they also clearly point out to not have any vias or signals underneath as I had from the beginning.

I am also wondering about the thermals. I might try the soldering oven in our makerspace. If not, I will use the heatgun for the icm and hand solder the rest. Wouldn't the thermals help so I don't have to heat the whole board then?

Thanks! David

[kriswiner]

Hi David,

I am sorry but you are correct about the Teensy width. The PTHs are indeed 0.6 inches separation; it is the total pcb width that is 0.7 inches so my apologies if you changed this on my recommendation.

I would pay no attention to the Invensense gidelines and keep copper outside of the pckage area, both sides.

The thermals is a detail, choose whichever one you like but I usually go with the choice that maximized the ground pour.

On Tue, Jan 22, 2019 at 2:08 PM David notifications@github.com wrote:

Hi again Kris,

I have updated the board with many of your points to get better placement of the components and utilize space better, also changed to 0.7 inch width (although I realized that my teensy is in fact 0.6 wide)

After you pointed out to not route under the icm package, I read up on the Invensense guidelines https://www.invensense.com/wp-content/uploads/2015/02/InvenSense-MEMS-Handling.pdf. They say on p1 (Trace Routing) that "Note: For best performance, design a ground plane under the sensor to reduce PCB signal noise from the board on which the sensor is mounted." So I guess that should be there, but they also clearly point out to not have any vias or signals underneath as I had from the beginning.

I am also wondering about the thermals. I might try the soldering oven in our makerspace. If not, I will use the heatgun for the icm and hand solder the rest. Wouldn't the thermals help so I don't have to heat the whole board then?

Thanks! David

— 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-456582127, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlZzMzO0dcgU_B6bEydnrlKzYIGxks5vF4vRgaJpZM4EbfGw .

[kriswiner]

One thing you could do on the new design is to use a 10 K pullup to 1.8 V for ADO and route the ADO to the unused pin. This way the default would be ADO==HIGH and if someone wanted to change the address, they would ground the ADO pin. This avoids mixing the power rails (as long as hte user does not apply 3V3 to the ADO pin and eliminates the need for the solder jumper, meaning you can go back to the 0.6 inch header separation.

[MBurtsev]

It would be cool if someone had tested these sensors and made a video.

[MBurtsev]

Need some objectivity in the estimates.

[kriswiner]

Why don't you test them then?

On Wed, Jan 23, 2019 at 3:09 AM Maksim Burtsev notifications@github.com wrote:

Need some objectivity in the estimates.

— 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-456762438, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm-ZqXa0eGeGVVuk1kf088CmL_VZks5vGELQgaJpZM4EbfGw .

[dtornqvist]

Thanks Kris,

I went back to 0.6 inch width and removed the solder jumper. I went through the level translator with the signal so I don't need the pull-up. I also removed the ground plane under the ICM.

A question for putting it directly on a Teensy. I have a Teensy 3.6, so I was thinking I could put it so that the left pins align with pins 2-4. The right pins then align with pins 21-23 which are analog outputs. Can the board get ground and 3.3v from them? I see in the data sheet for the icm that the largest draw is 3.11mA, but I don't find if that could be supported from the Teensy analog outputs.

[kriswiner]

Yes, all analog pins double as digital pins and you can use digitalWrite(HIGH/LOW) as power pins up to the current limit of the NXP chip, which is usually 20 mA per pin and total current <= 25 mA. You can check the NXP data sheet to be sure. So the ICM should work just fine mounted this way.. Not everyone will do this, most would use it on a breadboard. If you are planning to sell it, that is...

On the ADO, you might want a 10K pull up/down anyway since you want the address to default reliably to one or the other, and if you leave it floating you force the user to supply a signal there. Not a good idea to leave it floating since the address could end up being either, which is annoying.

On Wed, Jan 23, 2019 at 10:52 AM David notifications@github.com wrote:

Thanks Kris,

I went back to 0.6 inch width and removed the solder jumper. I went through the level translator with the signal so I don't need the pull-up. I also removed the ground plane under the ICM.

A question for putting it directly on a Teensy. I have a Teensy 3.6, so I was thinking I could put it so that the left pins align with pins 2-4. The right pins then align with pins 21-23 which are analog outputs. Can the board get ground and 3.3v from them? I see in the data sheet for the icm that the largest draw is 3.11mA, but I don't find if that could be supported from the Teensy analog outputs.

— 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-456922338, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quHpJoyMMTOOzSaU8wTTK2oWBdScks5vGK-AgaJpZM4EbfGw .

[dtornqvist]

That's great!

The data sheet for the level translator NTS0104, p17 says: "Each A port I/O has an internal 10 k pull-up resistor to VCC(A), and each B port I/O has an internal 10 k pull-up resistor to VCC(B)". Do you still think I need an extra pull-up?

I am just doing this board to learn and it has been really great with all the advice you have given! If you or someone else want to modify/sell its just to go ahead. I will make a couple myself to test using a soldering oven and to test the IMU.

Thanks!

[kriswiner]

Probably don't need the pullup then.

I would use an NCV8170 DFN-4 LDO and probably a smaller logic level translator for any board I would design.

I am interested to see if you can get it to work. If so, let me know.

Does the interrupt need to be on 1.8 V also? I suppose you need the translator for this too. So four signals for translation. One reason I don't like this chip at all...;>

On Wed, Jan 23, 2019 at 12:24 PM David notifications@github.com wrote:

That's great!

The data sheet for the level translator NTS0104, p17 https://www.nxp.com/docs/en/data-sheet/NTS0104.pdf says: "Each A port I/O has an internal 10 k pull-up resistor to VCC(A), and each B port I/O has an internal 10 k pull-up resistor to VCC(B)". Do you still think I need an extra pull-up?

I am just doing this board to learn and it has been really great with all the advice you have given! If you or someone else want to modify/sell its just to go ahead. I will make a couple myself to test using a soldering oven and to test the IMU.

Thanks!

— 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-456952717, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgKGLzpX7XDFOAJRMMU0EnQlQBZrks5vGMT6gaJpZM4EbfGw .

[dtornqvist]

I wanted to make it as simple as possible to solder as this is the smallest thing I have ever done. I will let you know how it goes, but it might take a while before i get the cards, components and get down to the lab.

The interrupt levels seem tied to VDDIO as well, so yes very annoying chip...

[dtornqvist]

I can happily say that the board seems to work just fine! I also made an initial version of an Android library for it, see: https://github.com/dtornqvist/icm-20948-arduino-library Thanks for all help!

[kriswiner]

Glad it works for you!

Maybe you can sell them now at Tindie...

On Sat, Feb 16, 2019 at 11:31 AM David notifications@github.com wrote:

I can happily say that the board seems to work just fine! I also made an initial version of an Android library for it, see: https://github.com/dtornqvist/icm-20948-arduino-library Thanks for all help!

— 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-464375793, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qrsuLFWGBn6Huz0sCw90sPg0Aa1lks5vOFyLgaJpZM4EbfGw .

[davhak]

Dear Kris,

Could you please share your recommendation which of the modern ST 6dof acc+gyr sensor is best to combine with ST magnetometer like LIS2MDL? Initially i was thinking to use the LSM6DSOX+LIS2MDL pair but then came across your post (https://community.st.com/s/question/0D50X0000B6Re9V/i-am-seeing-odd-current-behavior-with-the-lsm6dsox-but-not-in-lsm6dsm-due-to-int2-connection-to-slave-interrupt). ST has plenty of dev. boards with various acc+gyr and magnetometers but it is not clear which of the sensors LSM6DSM / LSM6DSOX / ISM330DHCX / LSM6DSRX / etc. serves best for new design and works best with magnetometer like LIS2MDL in the Mode 2 (i.e. when mag. is connected to acc+gyr as external sensor). Of course if the sensor has machine learning core or FSM it can be a big plus but after seeing your post at ST forum opens new questions so any suggestion from your side would be of great help.

Thanks a lot for any feedback.

[kriswiner]

If you want absolute orientation estimation then LSM6DSM + LIS2MDL can work https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf very well. This is what we use. I like and have have used the LSM6DSO for the embedded finite state machine and lower overall power usage.

I think the problem I am seeing with the LSM6DSO is due to the connection between the LSM6DSO INT2 and the LIS2MDL INT. I redesigned this board to disconnect the mag interrupt from the LSM6DSO (not really needed) and pulled up LSM6DSO INT2 by a 10 or 100 K resistor (can't remember) thinking this would eliminate the spurious current I was seeing. I haven't gone back to test whether this is the case.

In general, I would recommend a weak pullup in LSM6DSX INT2 and notc connecting it to the mag. Still OK to connect it to the MCU though and this can be useful for the LSM6DSO since you can program INT1 to trigger from the finite state machine and INT2 to trigger from embedded functions, etc.

Not sure if this answers your question. If not, please ask again.

On Sun, Mar 29, 2020 at 3:43 AM davhak notifications@github.com wrote:

Dear Kris,

Could you please share your recommendation which of the modern ST 6dof acc+gyr sensor is best to combine with ST magnetometer like LIS2MDL? Initially i was thinking to use the LSM6DSOX+LIS2MDL pair but then came across your post ( https://community.st.com/s/question/0D50X0000B6Re9V/i-am-seeing-odd-current-behavior-with-the-lsm6dsox-but-not-in-lsm6dsm-due-to-int2-connection-to-slave-interrupt). ST has plenty of dev. boards with various acc+gyr and magnetometers but it is not clear which of the sensors LSM6DSM / LSM6DSOX / ISM330DHCX / LSM6DSRX / etc. serves best for new design and works best with magnetometer like LIS2MDL in the Mode 2 (i.e. when mag. is connected to acc+gyr as external sensor). Of course if the sensor has machine learning core or FSM it can be a big plus but after seeing your post at ST forum opens new questions so any suggestion from your side would be of great help.

Thanks a lot for any feedback.

— 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-605616828, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVSXWTRN5EQ4CXAQADRJ4Q6TANCNFSM4BDN6GYA .

[davhak]

Dear Kris,

Thanks a lot for your time, the paper and information.

Indeed, the main goal is to get the absolute orientation. Since the device is going to be powered from batter the low power usage is also of a concern. So having your recommendations in mind one could then stick with LSM6DSOX+LIS2MDL option.

Thanks again for your help!

[kriswiner]

LSM6DSM is a very low power sensor, using 0.45 mA in normal mode, while the LSM6DSO I believe uses 0.35 or 0.4 mA. Not too much difference.

On Sun, Mar 29, 2020 at 12:09 PM davhak notifications@github.com wrote:

Dear Kris,

Thanks a lot for your time, the paper and information.

Indeed, the main goal is to get the absolute orientation. Since the device is going to be powered from batter the low power usage is also of a concern. So having your recommendations in mind one could then stick with LSM6DSOX+LIS2MDL option.

Thanks again for your help!

— 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-605684490, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA .