# Depth Hold Mode change of behaviour after Bar30 replacement

**URL:** <https://discuss.bluerobotics.com/t/depth-hold-mode-change-of-behaviour-after-bar30-replacement/17211>\
**Category:** Blue Robotics Products\
**Tags:** ardusub\
**Created:** [June 20, 2024, 7:06am UTC](https://discuss.bluerobotics.com/t/depth-hold-mode-change-of-behaviour-after-bar30-replacement/17211 "2024-06-20T07:06:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sample](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@sample](https://discuss.bluerobotics.com/u/sample)\
**Post date:** [June 20, 2024, 7:06am UTC](https://discuss.bluerobotics.com/t/depth-hold-mode-change-of-behaviour-after-bar30-replacement/17211/1 "2024-06-20T07:06:14Z")

</div>

Hi Blue Robotics,

We have a BlueROV2 Heavy R3 with an RPi 3B and Pixhawk, running ArduSub 4.1.0. Recently, we replaced the Bar30 (R1) sensor with a new Bar30. Since we didn’t have an adapter available, we cut off the JST GH connector and soldered on the DF13 connector. The depth readings appear to be accurate.

However, after replacing the sensor, the behavior of the Depth Hold Mode has changed. We can no longer adjust the depth by pressing the throttle stick. Instead, the ROV maintains the depth at which the Depth Hold Mode was activated. To change the depth, we have to switch to a different mode, go to the required depth, and then engage the Depth Hold again. We did not modify any ArduSub parameters or firmware after replacing the sensor.

Do you have any idea what might be causing this issue?

Thank you.

---

<div class="post-metadata">

**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\
**Post date:** [July 1, 2024, 5:19am UTC](https://discuss.bluerobotics.com/t/depth-hold-mode-change-of-behaviour-after-bar30-replacement/17211/2 "2024-07-01T05:19:18Z")

</div>

Hi @sample,

The depth sensor is only used for feedback about the current depth - it has no other influence on the autopilot’s behaviour or what kinds of control inputs the autopilot accepts.

I expect there’s some kind of issue with your ArduSub version, or (unlikely) the software you’re using to send control commands to ArduSub. I’m not aware of any parameters that disallow vertical adjustment commands while in depth mode.

Assuming you’re using [BlueOS](https://blueos.cloud), I’d recommend saving/downloading your current parameters from the Autopilot Parameters page (just in case you want to revert to them), then loading the default parameters from the Configure section of the Vehicle Setup page, and if that doesn’t help then try flashing on the latest stable (`4.1.2`) or beta (`4.5.0`) firmware.

Note that there have been some stability updates to the firmware flashing process in recent BlueOS 1.3 beta images, so you might want to install the latest BlueOS beta version before flashing on a new Pixhawk firmware (you’ll need to [turn on Pirate Mode](https://blueos.cloud/docs/blueos/1.2/advanced-usage/#pirate-mode) to be able to see the beta versions in the BlueOS Version page).

---

<div class="post-metadata">

**Author:** ![sample](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@sample](https://discuss.bluerobotics.com/u/sample)\
**Post date:** [July 1, 2024, 8:17pm UTC](https://discuss.bluerobotics.com/t/depth-hold-mode-change-of-behaviour-after-bar30-replacement/17211/3 "2024-07-01T20:17:09Z")

</div>

Hi Eliot,

Thank you for your response. We initially tried upgrading the firmware, but that did not resolve the issue. Fortunately, loading the default parameters worked. It seems the problem was related to the parameters after all. We now consider this issue resolved!