I’m having a strange problem with the pressure sensor and I’m wondering if anyone has seen anything similar. Basically, whenever I sample the MS5837 at a “high” rate (10Hz), the readings start going haywire.
After it starts returning bogus data, I can reset, power down, change sampling rate, or whatever, and it is still bogus. However, if I only sample slowly, I can watch as the values for both temperature and pressure slowly drift back to normal values. I’ve got a logic analyzer hooked up to the I2C bus and have confirmed its not a firmware glitch in the calibration code.
Anyone else see this behavior? I’m also curious to see if other folks are successfully using this at sampling rates > 10Hz.
Attached graph shows what I mean. Just left the sensor alone and it starts drifting towards bogus values. Eventually, I think a bug in my code caused a reduced sampling rate, and the values then trend back towards the expected 1000 mbar / 22C range.
This is almost certainly a software issue, or an issue with the connections. ArduSub samples much higher than 10Hz. Can you please post your code? Make sure that you have very good connections, how do you have the sensor wired?
Thanks for the feedback on the sampling rate, I’m tempted to just get another sensor to test with.
The sensor is wired with a clean 3.3V source and uses 3.3V logic on the SDA and SCL lines.
I’m using the BlueRobotics_MS5837 arduino library with some slight modifications. I’ve changed the OSR from 8192 to 2048 for both temperature and pressure, and reduced the delay between the conversion requests from 20ms to 5ms. I’ve also fixed the 0x00FF0 bug in the crc4 function.
To rule out bad math on the uC side, I’ve logged the raw D1 and D2 values and performed some hand calculations. I’ve also confirmed that the uC is reading in the correct values by hooking up a logic analyzer and watching the ADC read responses. Here’s some raw values while the sensor is trending back towards expected pressure/temperature (for reference, a ‘good’ reading should be about D1: 4162862 D2: 6824718, which is more in line with the example values from the spec sheet)…
Take note of page 11 in the datasheet. It is a little bit vague, but it does state:
<div data-canvas-width=“787.7350000000002”>‘If the ADC read command is sent during conversion the result will be 0, the conversion will not stop and the final result will be wrong. Conversion sequence sent during the already started conversion process will yield incorrect result as well’</div>
<div data-canvas-width=“787.7350000000002”></div>
<div data-canvas-width=“787.7350000000002”>What rate are you sending the ADC read command at? Although sending the conversion command at 5ms seems to be within spec of the max conversion time (4.54 ms) with OSR at 2048, you are not leaving much overhead, less than 500 microseconds. With OSR 8192 and conversion command rate of 20ms, there is more that 2ms delay above the specified conversion time. It is quite possible that your delay() is rounding to the nearest millisecond and you actually end up waiting closer to 4ms. Try increasing your delay() command to 6 or 7 ms, or use delayMicroseconds(5000) for finer resolution timing.</div>
<div data-canvas-width=“787.7350000000002”></div>
<div data-canvas-width=“787.7350000000002”>-Jacob</div>
Excellent point about the delay, and I think you are correct that the delay() implementation can allow for closer to 4ms of delay. I’ll have to experiment with that and will also try reducing OSR to 256.
And I did catch that in the spec- I interpreted that as returning a zero byte when doing the ADC read, which is not what I’m seeing. I’ll run some experiments to see if I can clear up how that behaves w.r.t. returning zeroes or just incorrect data.
The BlueRobotics library is set up like:
Start D1 Conversion
Wait 20ms (or in my case 5ms)
Read ADC
Start D2 Conversion
Wait 20ms (5ms for me)
Read ADC
Run through the calculation code w/ the calibration coefficients read in at startup
I took a peak at the ArduSub code and got some ideas for edits from it. I’ve altered my code to only read the temperature once every 5 reads of the pressure.
I think I’ll also grab a couple of raw sensors from digikey and see if they behave any differently than this one I’ve got, since I seem to be unique in having this issue.