we are using one of your Bar30 MS5837-30BA wired to a Raspberry pi I2C pins. The sensor is powered at 5V, is alone on the I2C bus,and its adress is correctly listed by a
i2cdetect -y 1 .
Using the example python (or Java) driver found at:
our sensor returns those values:
pressure: 60552 mbar
temperature: -83.18°C
which are obviously wrong.
The values oscilate a bit, in the range of what I would expect from a working sensor. Touching the sensor with a finger will result in a ~+2°C increase in temperature (ie: ~-79°C), which indicates a coherent reaction.
The driver implementation by ControlEverything seems to follow the datasheet quite well. The fact that the values are not random indicates (to my eyes) that the communication is working correctly. The sensor shows no sign of exterior damage.
Am I missing something, or should I consider that the sensor is faulty?
I agree that the python driver you linkedlooks ok. However, this does not mean that it does not have a bug, which might be hard to spot. I think you should verify your results with another driver before concluding that the sensor hardware is at fault for the incorrect readings. There is an Arduino driver on the Blue Robotics github page.
I took a look at the Python driver and it looks okay. The calculations all check out fine. There are a few differences that are good to note:
They are using the lowest oversampling rate (256 samples instead of 8192), so the resolution will be much lower.
They have a very long delay after requesting data (500 milliseconds). The maximum data reading time is only 20 milliseconds so this is unnecessarily long.
They are not checking the checksum (CRC) so theoretically the calibration data could be coming in incorrectly. We aren’t checking it in our Arduino library either, but if the data was wrong that could indicate a communication issue.
We’ve very few cases of these sensors reporting incorrect data (possibly no cases). We also test each one after building them and verify that the pressure reading is accurate, so this sensor definitely reported correctly with the Arduino library when it was first tested.
I would recommend checking with the Arduino library as well, just to verify. If the sensor turns out to be damaged then we’ll be happy to replace it.
we received our Arduino board, and I tested the sensor with the library you provide, all 3.3V<->5V level shifted.
At first, the sensor reported the same type of incoherent pressure. After a while (~10min), it reported a pressure of 940mbar. After some while, it slowly raised to 1100mbar. The reported temperature was 4°C above the actual room temperature.
I then pluged the sensor on the raspberry pi, with the python driver, and it reported the same value as on the arduino (1100mbar). I let the acquisition run for about two hours, and when I came back the values were wrong again. Testing on the arduino now gives wrong value again.
Okay! I don’t know what happened either but at least it’s working! We’ll get that faulty one replaced for you. Thanks for working through this so diligently.
I am seeing this problem with MS5837-02BA using my own code, Wire.h and Nano 33 BLE. Looks like ADC is faulty but RAM reads correctly (CRC check valid, calibration values OK). I’ve seen at least two faulty sensors like this so far. They may work correctly for a few days non-stop, then start drifting all around in both temperature and pressure, and after a while might work correctly again. During drifting, I sometimes see uint24 underrun and overrun of the raw output of command 0x48 which reads pressure: value goes from about 6000 (low) to about 16.7 million (high), and back and forth across the boundary (corresponding to absolute pressure values of about -160 kPa and 560 kPa, respectively).
Looks like it is a hardware problem then, and not something I’ve missed in my code. Could these China-sourced chips be cheap knockoffs or batches rejected as faulty instead of the genuine sensor?
Good to know. I don’t recall seeing that mention in the datasheet, and our sensors are in humid conditions all the time, even if not entirely submerged, as some moisture usually remains within the tubing even when the sensor is otherwise disconnected.
Looks like the design needs to be altered so that it can dry when not in use, or do you suppose that some sort of coating could be applied to the sensor itself to make it better protected against water?
Just had a look and this is actually mentioned on the third page of both the Bar30 and Bar02 datasheets, as
I brought this up last week and was told
Rusty also added that
so it is at least being looked into - just not top priority at this stage while we’re sorting out other things like the continued expansion of the newly announced wetlink family of products
