Hi @SubseaLED -
The update fixed the issue from me, so I’m interested in understanding how our situations may differ. Are you powering the vehicle from a battery? Are you using a bar 100 or bar100XT? Does the depth sensor error occur when sitting idle or only under load?
Please share a vehicle .BIN log with the error occuring. Thanks!
Dear Tony,
the entire system is powered by a 24V power supply then Ubec down to 5V.
There are no motors currently connected to the unit.
the depth sensor is the BAR100XT. Cables are straight to the navigator and without passing through the endcap for now as we’re under test.
I’ve tried to apply ferrite choke on the i2c wires but definetely it is not a noise issue. I confirm the same setup using the BAR30 works without issue and the offset is stable without oscillating.
Thanks @SubseaLED -
You were able to flash the firmware file from Eliot without issue? What version of ArduSub is reported as running? A log file would be helpful as mentioned!
Hi Tony,
Please see a video here of what happening.keep an eye on the offset that change without any reason.
I will provide log asap
Hi @SubseaLED -
I see no issues with the output there! Some noise is expected, after all the sensor can detect quite a large range! The fix to the ArduSub driver should eliminate "depth sensor error " coming through in Cockpit or QGround Control…
I’m also a bit confused to see the firmware file list itself as 4.8 - is this expected @EliotBR ?
Tony,
the offset should not change unless you calibrate it on surface.
In my case, the offset change randomly and decreasing…
Hi @SubseaLED -
I see the Status for the second listed sensor (the Keller) going from 987.79 to 984.74 hPa. This represents the current reading, and that difference of 987.79-984.74 = 3.05 hPa. This difference is equivalent to 0.04 psi or ~0.1 ft of depth.
The “Calibrated at” pressure changes as well, but only once, likely related to you clicking the “Calibrate” button. It represents the value the pressure sensor was giving previously, and changes from 985 to 844 hPa, a difference of 141 hPa. This is equivalent to 1.4m - did you calibrate at depth, or are you concerned of the magnitude of this difference? It is within the ± 150 mbar (±1.54 m in freshwater) accuracy specification of the sensor.
Hi Tony,
Thanks for the explanation.
Please note the offset changes 2 times… i just zeroeed the depth 1 time.
The video is no long enough but it keeps change without calibrating.
In the video i shared you can spot the below:
Calibrated at depth: 707 hPa
Then i push calibrate sensor
Calibrated at depth: 985 hPa
After few secs..
Calibrated at depth: 844 hPa
also, considering the sensor is still in air with floating readings staying around 980hPa, isn’t strange for you that the calibrated at depth had values far below the “mean reading” 707, 844 and so on..?
Yep - 4.7 is in its beta releases, and has been branched out, so new developments (in/over the master branch) register as 4.8. We are still actively back-porting changes to the 4.7 branch though, once they’ve been merged in and determined as relevant/important for version 4.7.
That’s not fully correct - ArduSub automatically re-calibrates its barometer offset whenever it is lower pressure than the previous calibration, under the assumption that it is out of the water / at the surface.
If the sensor is somehow outputting continually decreasing pressure values then the calibration offset will drift lower over time - the real question then is where are those values coming from?
This is a point I am wondering about as well, since it seems to imply there are measurement spikes that get more severe over time. A DataFlash (.bin) log from the autopilot would allow us to see the sensor values at a higher frequency, which would help to get a better sense of the nature and extent of the values. Ideally that would be from an extended duration of testing, so we can also see whether there’s any ongoing drift in the values, and whether the noise level is consistent.
I would note that the sensor is designed for use in water, so operating it in air may have unexpected / poorly defined behaviour. Could you try repeating your test with the sensor head in water (even if it’s just sitting in a cup), and seeing whether the reading still fluctuates in a similar way?
Hi Elliot,
please see attached the log and a screenshot. You can spot the reading slowly comes down while the sensor is still on surface.
00000056 (1).BIN (2.8 MB)
There are also substantial spikes in the depth reading, and as expected it is right after one of those spikes is large enough to be higher than the current zero altitude point that ArduSub recalibrates by the amount that it was over.
It’s possible you have a faulty sensor, but given the reading is stable aside from those spikes I’d lean towards there being a noise issue.
Returning to some of your earlier points:
Have you tried powering off a battery? It’s possible there are spikes in the power supply that are getting through and causing the sensor measurement faults.
Different devices are sensitive to different conditions. If you happen to have access to an oscilloscope, I’d be curious if there are any visible spikes on the power or signal lines.
Aside from resolving the underlying issue, you should also be able to treat the symptom using the BARO_FLTR_RNG parameter. Depth readings are not expected to change suddenly in normal operation, so you could potentially set a low value (e.g. 1-10) and still get reasonable results, although given that filter is percentage-based (which makes more sense in air than water) it’s possible things would get noisy again at more substantial depths.
Hi Elliot,
What i notice is that seems the deep down spikes are only present when the sensor is in air.
Sensor seems to works well when submerged and even with thrusters pushing down to the bottom of our pool.
Not sure if this behavior is correct for the sensor but will definetely get us crazy to perform a correct start calibration before to deploy the rov in water as it continue to lower down the offset until The vehicle is in water.
Interesting. I wonder if the sensor membrane is just too free to move when it’s not being compressed by water or something…
That’s definitely a good sign, given the sensor is designed to be used while submerged 
Did you try setting that noise filtering parameter I mentioned? I suspect it will help.
Hi Elliot, i’ve tried To set the filter up to 100% but seems that not help.
100% means “only filter out spikes that are >100% away from the current pressure”.
Try 1% to see if it works. If I’m calculating correctly that will be ok as long as you’re not intending to move the pressure sensor faster than ~1m/s vertically (while near the surface), including fast pitching movements of the vehicle, otherwise you might need to bump it up to 2-5.
Hi Elliot,
Just to keep you posted about it.
We ended up to add an EMA filter in the Keller cpp and recompile the firmware. not too much aggressive as was creating overshoot in auto depth mode but enough to reduce the spikes that was affecting the final depth value as it become inconsistent again also when submerged.
Regarding the offset “calibrated at depth”, after the filter we added is not going down anymore too much (we got also negative hPa some time) but it still reaching around 970hPa - real barometric pressure is 995hPa) . We still need to manually calibrate everytime the vehicle is in water.
