# Speed from Depth/Pressure sensors

I have a pressure based Depth sensor. For reference, MS5837-02BA. All depth measurements I've been able to read are very accurate (±1cm)

I tried experimenting to find out the speed of the body by differentiating the measured depth value. The measurements are taken at a 40ms time period. This is the time the sensor takes for each measurement. I've used this as the rate of measurement and calculated the speed but the values are not as correct i feel.

Here are the plots for both measured and calculated variables.  All the measurements are in meters. Would like to hear what exactly I'm doing wrong, whether its the rate of measurement or something else.

Edit: accuracy ±0.1cm to ±1cm. I verified the depth measurements using a measuring tape and it was accurate down to the cm. I couldn't measure whilst the body was moving so that may a factor

Edit 2: Response to Hilmar's comment: I've gone through what you've stated and my original depth data. So i only took my raw Depth measurements this time and discarded the speed calculations my microcontroller has done. I've calculated the derivative by finding the difference between the current and previous measurement and dividing it by the sample period. $$(x[i]−x[i−1])/dt$$

Here are the plots again but with the sample number changed to time  As you can see the plots are similar as earlier. And about your comment on the rise at t = 2000, the rise is not instantaneous but its actually gradual over the period of 1.32s . Have a look at this pic, note that the period in question is between t=2025 and t=2058, which means its a total period of 33*0.04=1.32s . And the change in depth is noticeable but not at a very high rate. Note that the measurement is actually in the order of 0.1m or 1 decimeter. Hence the body had moved 0.4719m in a period of 1.32s which is just 0.35 m/s which my object is capable of. Other than this i'm uncertain where exactly i've made a blunder here. Others suggest that the high frequency noise may be a cause of this but would a simple LPF solve this problem?

• you claim your depth sensor is very accurate within $\pm 0.1$ cm, then the depth plot you provide indicates a lot of (noise like) jiggling motion? is that true? is the object jiggling (shaking up and down) inside the water ? Dec 3, 2020 at 15:30
• Also what's the specific algorithm that you have used to compute velocity from depth measurement ? Dec 3, 2020 at 15:30
• Welcome to SE.SP! It looks like you're differentiating the noisy depth signal. That's why your velocity plot is very noisy. You're probably going to have to denoise the depth plot before trying to find velocity, or use a model-based technique to avoid the noise. Can you say something about how the depth will change?
– Peter K.
Dec 3, 2020 at 15:31
• @Ruthless. Sorry, your data is bad. There are a lot of identical values for extended periods of time, but than it jumps and stays constant again. You also have some serious outliers. And whatever you are doing in the second column, it's NOT the derivative of the first column. Dec 3, 2020 at 21:05
• @Hilmar Thats true, the device was stationary for periods in between the recording session which lasted for around 5 minutes. But have a look at the recent edit i made in the original post, maybe that will give the final idea about what mistake I've been making. Dec 3, 2020 at 21:25

All depth measurements I've been able to read are very accurate (±0.1cm)

That's highly unlikely. It seems that something is quantizing your data at pretty rough interval: maybe 2cm or so plus some extra noise. There are is also a spike at t = 2000 units ?) where the depth jumps from 0.1m to about 0.5m in one sample. Your sample interval is 40 milliseconds. 0.5m in 40ms corresponds to a speed of 12.5 m/s. Can your object really move that fast ?

Overall your data looks quite bad (noisy, quantized & spikey) and not like a real physical object tends to behave.

find out the speed of the body by differentiating the measured depth value

The second curve doesn't look the derivative of the first curve at all. I would expect a massive velocity peak of 12.5 m/s at t = 2000, but your velocity curve just shows a minor blip. Another big peak should be at t= 4000. I have no idea what you did there, but it doesn't appear to be differentiation.

This is a simple calculation of the "velocity" from the depth measurements using Excel. It seems more reasonable than the plot in the question.

Note that the data used was from Web Page Digitizer, so it won't be quite the same as the original. In the future please label the X and Y axis of your graph with proper units. I have no idea what the unit of your velocity are supposed to be but it's unlikely to be in m/s.

• Would like to clarify that I verified the depth measurements using measuring tape when underwater. However I couldn't measure during movement so that may have led to some noise. And also the body is moving vertically from thrust forces given by 2 props so that may have also Introduced some disturbance. The measurements have been taken at a sample rate of 40ms so the timestamps in the x axis are not in seconds but rather each measurement at multiples of 40ms. Dec 3, 2020 at 16:13
• For differentiation I took the previous measurement and current measurement and divided it by the interval of time it took for the microcontroller to get the signal from the sensor. Dec 3, 2020 at 16:14
• Thanks for the clarification but my comments remain: your data is bad and your differentiation looks wrong. The second graph is NOT the derivative of the first graph. Dec 3, 2020 at 16:34
• @Hilmar Apologies for the edit. I just played a bit with the data and it largely agrees with what you're saying so I thought I'd just put it on your answer rather than add a non-answer of my own. Feel free to revert.
– Peter K.
Dec 3, 2020 at 19:14
• @PeterK. It's cool, thanks! I did not know about the the Web Page Digitizer, so I learned something new ! Dec 3, 2020 at 20:53

Per your update, it does look like high frequency noise to me. A ‘simple’ low-pass filter would go a long way to cleaning it up. It’s true that that much noise is a bad thing, and you’d probably want to do what you can to clean it up, but there’s probably going to be noise no matter what, so a LPF would be well advised anyway.

Note that it doesn’t matter when you apply the LPF. You could apply it to the depth data prior to differentiation, or after and get the same result. If it were me, I’d LPF the depth data first.

Also note that a LPF will cause group delay. If you are post processing the data, rather than doing a real time analysis, you could use something like Python’s filtfilt() to get zero delay. In real time, you are limited by causality, so there will always be some delay. Matter of fact, there will be some additional delay introduced by the first order differentiator, but it’s pretty small. Mostly, just keep in mind that applying a LPF may cause your velocity data to lag the depth data, and that’s expected, and that there may be some ways around it depending on your application.

Lastly, a differentiator is a kind of high-pass filter, so high frequency noise will be accentuated by such a velocity calculation.

• I'm afraid the LPF will always need to be in real time and cause some lag but thats fine by me. I have a question as what in general would be the cutoff frequency for such an LPF in this system. Dec 4, 2020 at 4:43