Problems reading two barometers from version 0.3.3 onwards.

[HWal]

Thank you for this library, it is of good use to me. I am using it in a DIY airspeed indicator based on two GY63 ms5611 breakouts. The pressures from the pitot tube are read in succession and their values are compared, compensated for the offset between them.

Using version 0.3.2 this all worked fine. But with versions 0.3.3 to 0.3.5 I get corrupted values from the first baro that is read; that is the one with address 0x76.

[RobTillaart]

You're welcome, thank you for reporting this issue.

As I only have one sensor I am not able to recreate your setup, so I need your help to analyse.

0.3.2 works and 0.3.3 does not. OK-> compare

There is an optimization done in the timing

reset() => delay(3) replaced by delayMicroseconds(2800)

and convert()

These timings are from the datasheet so considered correct,

---

hypothese 1 timing is just critical for one of the sensors.

TEST 1: swap the sensors addresses to see if problem happens with the 0x76 address or with the same physical sensor?

---

hypothese 2 the internal timing in the sensor and of the processor are slightly different and the code in the lib is just at the edge.

TEST2: increase the delays e.g.

in convert to 3000 microseconds?

in convert, add a few 100 us per entry.

---

hypothese 3 RTOS blocking problem? (much less likely)

What board are you using? In version 0.3.6 - currently in develop branch - I replaced the delayMicroseconds with a loop around yield() to allow task switching in RTOS

[RobTillaart]

If hypothese 2 solves the problem I can include it in the 0.3.6 release. I'll check the datasheet for accuracy of the intern clock of the 5611 (might be indicative)

[RobTillaart]

Found this in the datasheet

The times in the array are TYPICAL times while they should have been MAX times.
So that will be adapted in the 0.3.6 version a.s.a.p. (first I need another coffee)

[RobTillaart]

Updated timing added to develop branch - https://github.com/RobTillaart/MS5611/tree/develop

[RobTillaart]

Adding a simple example for two sensors to the example folder to have a minimal test.

[HWal]

Thank you for the reply and your work on this. I will do the testing. I am not sure if I can get this done during the evening (Norway time), I'll return with result tomorrow at the latest.

[HWal]

For testing I use a NodeMCU v1.0 (ESP8266). This is easy because of the USB connection. For permanent installation in my model airplane I will use an Arduino Pro Mini.

[RobTillaart]

Thank you for the reply and your work on this. I will do the testing. I am not sure if I can get this done during the evening (Norway time), I'll return with result tomorrow at the latest.

I'm in the same time zone (Netherlands, near EIndhoven) Take the time you need, good testing takes time.

Good to hear you are testing the library with processors I did not test with. Helps to get it robust!

Do you have a picture of the model plane?)

[HWal]

[HWal]

My experimental plane (among other ordinary planes). Two ms5611 connected to create differential pressure.

[RobTillaart]

My experimental plane (among other ordinary planes). Two ms5611 connected to create differential pressure.

The latest version adds support for an offset for pressure and temperature. That allows you to calibrate them to the same reading before start ==> better differential?

[HWal]

I managed to do a couple of tests just a few minutes ago. For info, in my sensor sketch i read both baros, then add 200ms delay, then read both baros again, and so on...

Swapping adresses did no difference, other than to move the error to the other baro instance in my sketch.

However, i tried in the convert function to change some values: uint16_t del[5] = {500, 1100, 2100, 4100, 8220}; changed to uint16_t del[5] = {1000, 2000, 3000, 5000, 10000};

I have not gone deep into the library, but the changed values seem to correspond with the values used in the delay() statement in 0.3.2.

Now both baros worked fine.

[RobTillaart]

I have not gone deep into the library, but the changed values seem to correspond with the values used in the delay() statement in 0.3.2.

exact, so hypothesis 2 was the right one.

Can you verify if these values work for you?

  // values from page 3 datasheet - MAX column (rounded up)
  uint16_t del[5] = {600, 1200, 2300, 4600, 9100};

these are the rounded up MAX values from the datasheet. Would still allow to gain 10-40% waiting time compared to 0.3.2

Thanks for testing!

[HWal]

I just tried with the above values. Both barometers run fine now.

[RobTillaart]

OK, I will merge 0.3.6 then. That should work for you too.

[HWal]

Thank you very much for your help and support !

[RobTillaart]

You're welcome, please let me know how your experiments go.

[HWal]

I will, testing during flight is next when the flying season starts.

[RobTillaart]

@HWal

I created an issue - https://github.com/RobTillaart/MS5611/issues/26

The idea is that if you know the sensor ID you can store an calibration offset for temperature and pressure in code or in EEPROM and provide every sensor with the right offsets without calibrating every time.

The ROM constants are read in the ms5611.cpp file in the reset() function. Can you print your ROM constants per sensor and post them here so I can compare if they are different enough? just add a line Serial.println(readProm(reg)); will do the job.

As you have more than one sensor please provide a list per sensor.

Thanks in advance, Rob

[HWal]

Hi Rob,

I am sorry, I have been out all day, so could not provide the constants so far. I will try to do this tomorrow.

Regards, Helge.

lør. 22. jan. 2022 kl. 10:00 skrev Rob Tillaart @.***>:

@HWal https://github.com/HWal

I created an issue - #26 https://github.com/RobTillaart/MS5611/issues/26

The idea is that if you know the sensor ID you can store an calibration offset for temperature and pressure in code or in EEPROM and provide every sensor with the right offsets without calibrating every time.

The ROM constants are read in the ms5611.cpp file in the reset() function. Can you print your ROM constants per sensor and post them here so I can compare if they are different enough? just add a line Serial.println(readProm(reg)); will do the job.

As you have more than one sensor please provide a list per sensor.

Thanks in advance, Rob

— Reply to this email directly, view it on GitHub https://github.com/RobTillaart/MS5611/issues/23#issuecomment-1019114768, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZHGF2BB3YBAYCSZ2XOHDUXJW27ANCNFSM5MBAWCVQ . 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: @.***>

[RobTillaart]

No problem, already had other source . But still interested in your deviceID to see it works. Thanks

[HWal]

Hi again,

For the baro with address 0x76 i get: 12 52157 46715 31062 25551 33042 27419

For the baro with address Ox77 i get: 16 53012 52757 31868 29782 32409 27506

Does this make sense? Helge.

lør. 22. jan. 2022 kl. 19:16 skrev Rob Tillaart @.***>:

No problem, already had other source . But still interesred in your deviceid to see it works. Thanks

— Reply to this email directly, view it on GitHub https://github.com/RobTillaart/MS5611/issues/23#issuecomment-1019327358, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZHGDGYIZKXCENJS53JKLUXLYBVANCNFSM5MBAWCVQ . 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: @.***>

[RobTillaart]

It's perfect that they are different. That makes them a good source to generate an "unique" device ID.

got now 5 results, all different!

0        192      2120     12      16
42813    55102    58061    52157   53012
44132    52075    55931    46715   52757
26874    34758    36591    31062   31868
24506    31777    31881    25551   29782
32060    32430    32845    33042   32409
28365    28042    28228    27419   27506

[HWal]

Ok,

I'll move the baros back into the plane then.

Helge.

lør. 22. jan. 2022 kl. 21:46 skrev Rob Tillaart @.***>:

It's perfect that they are different. That makes them a good source to generate an "unique" device ID.

— Reply to this email directly, view it on GitHub https://github.com/RobTillaart/MS5611/issues/23#issuecomment-1019355194, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZHGBAJER2WBHR3NDHIGLUXMJR5ANCNFSM5MBAWCVQ . 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: @.***>

[RobTillaart]

Thank you for testing, hope the plane flies soon!

now I'm pretty sure I can create a uint32_t getDeviceID() function, to uniquely (enough) identify sensors from calibration data.

[RobTillaart]

@HWal just came across this issue, and was wondering if the plane did fly..

[HWal]

Thanks Rob.

Yes the plane flies! And flies well too!

I am using two 5611's to calculate airspeed and one of them to calculate height and climb rate. The data is sent to a FrSky Taranis radio Tx with the help of a library for telemetry.

For information I attach the (simple) Arduino code.

Helge.

tir. 25. okt. 2022 kl. 21:01 skrev Rob Tillaart @.***>:

@HWal https://github.com/HWal just came across this issue, and was wondering if the plane did fly..

— Reply to this email directly, view it on GitHub https://github.com/RobTillaart/MS5611/issues/23#issuecomment-1291009443, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZHGG5LLCYFX55SNDHGYLWFAU63ANCNFSM5MBAWCVQ . You are receiving this because you were mentioned.Message ID: @.***>