Pressure values exactly half of expected value?

[sathibault]

Temperature is correct. Pressure values are around 505 which is half what it should be. Any ideas how this could happen?

[RobTillaart]

Thanks for this issue, I'll try to pick this up tomorrow. I do not recall seeing this before, also in other issues this is never mentioned.

Do you use 3V3 or 5V device? Can you tell more about your setup? code?

[sathibault]

It is connected to a Feather M4 Express with 3V3 power. I'm calling the library in the default configuration with no arguments: MS5611.begin() in setup and MS5611.read() and MS5611.getPressure() in loop.

[RobTillaart]

Had a quick look,

It might be in line 133 in ms5611.cpp

C[3] = 3.90625E-3; // TCS = C[3] / 2^6

==>

C[3] = 0.015625 // TCS = C[3] / 2^6

3.90625E-3 = 1/(2^8)

Can you give it a try?

(need to check if I still have a test sensor somewhere)

[RobTillaart]

mmm the above should give an error factor 4. tomorrow I will dive into the datasheets

[sathibault]

Just in case it helps, these are the PROM values:

MS5611_LIB_VERSION: 0.3.8
140
38252
37147
24739
23894
32339
28498

[RobTillaart]

Thanks, those are device specific calibrations. Cant draw conclusions from them.

Q: do you have a link where you bought the device? Just to check if the type is exactly the same.

A factor 2 can also be caused if a bit is missing in communication. Q: Do you have appropriate pull ups on data and clock line? .just to check.

[RobTillaart]

Good morning,

Analysis

I have looked this morning into two documents, a datasheet and an application note. (AN520_004 www.meas-spec.com Aug. 09, 2011) and I noticed the following:

1. that the comment in my code 2^6 should be 2^8 according to the datasheet.
2. that the constants used in the algorithm to calculate the pressure differ between the two documents.

Conclusions (so far)

Point 1 is easy to fix, and as the constants in thecode are in line with the datasheet, and there was no factor 2 problem before I consider them correct.

Point 2 is remarkable and indicates that there might be (at least) two different series of the sensor.

Actions

1. I will make a test33 branch with the "other constants" and if you can test this with your sensor that would be great.
2. The constant 0 in EEPROM is the manufacturer code and is not used in the library. I will make a function to access it so it is possible to see if there are differences between these numbers.

To be continued.

[RobTillaart]

differences in the constants.

                                          datasheet     |    appNote
  C[0] = 1;
  C[1] = 32768L;          //  SENSt1   = C[1] * 2^15    |    * 2^16
  C[2] = 65536L;          //  OFFt1    = C[2] * 2^16    |    * 2^17
  C[3] = 3.90625E-3;      //  TCS      = C[3] / 2^8     |    / 2^7
  C[4] = 7.8125E-3;       //  TCO      = C[4] / 2^7     |    / 2^6
  C[5] = 256;             //  Tref     = C[5] * 2^8     |    * 2^8
  C[6] = 1.1920928955E-7; //  TEMPSENS = C[6] / 2^23    |    / 2^23

C5 and C6 are for Temperature and they are the same. The others are for pressure and they all differ a factor 2. So it might explain your issue!

[RobTillaart]

Please download and try - https://github.com/RobTillaart/MS5611/tree/test33

[RobTillaart]

The test33 branch also contains updates for the coming 0.3.9 release.

• rp2040 in build
• changelog.md
• experimental functions uint16_t getManufacturer() and uint16_t getSerialCode()

These should not interfere with the changed constants.

[RobTillaart]

Added setMathMode(mode) to the branch to switch between the default mode and the mode with the constants used in the application notes. Although the latter are not tested yet I expect these to solve the issue.

[sathibault]

You did it, nice work!

[RobTillaart]

I'm not 100% happy yet with the API so there might be minor changes. I'm thinking of putting the call to reset() within the setMsthMode() call + some param checking.

[RobTillaart]

Can you post the info of the type of device you have? The n I can give it as example in the readme.md when to use the mathMode.

[RobTillaart]

@sathibault Refactored the library, now the mathMode is a parameter of reset(mathMode = 0). Default the datasheet mode for backwards compatibility, option mathMode =1 for the factor 2 pressure correction. The separate functions to set the mode are gone (no need to call reset() after setting the mode anymore. The interface of the lib is almost identical so most people won't notice. And for those who need the factor2 correction, they only need to add one call in the setup() of their code.

I will merge later today

[sathibault]

Can you post the info of the type of device you have? The n I can give it as example in the readme.md when to use the mathMode.

I don't really have any detail on it. It came from a drone development kit and seems to be a custom board. There's nothing readable on the chip. The PROM reg 0 is 140. Not sure if that is an indicator or not.

[RobTillaart]

I don't really have any detail on it.

Thanks for checking, most important is that the sensor now works as intended and that I have docs that describe the math. if you are interested - https://www.amsys-sensor.eu/sheets/amsys.fr.an520_e.pdf

The PROM reg 0 is 140. Not sure if that is an indicator or not.

I have 5 or 6 dumps and they are all different. I do not have any clue what reg 0 means. The other regs are at least in the same orde of magnitude so they are calibration data.