If there’s no valid velocity detected by the sensor then ArduSub isn’t receiving values, so it can’t track or maintain velocity or position (just like when no sensor is connected). If the sensor is getting valid measurements intermittently then that would explain why you’re getting notes about aiding and odometry fusion repeatedly starting and stopping.
No need to apologise 
The Water Linked DVL page includes a useful high level description of how a DVL works. A “good bottom lock” occurs when
- the sensor is receiving reflections, and
- the reflections it’s measuring “make sense”.
As obvious failure cases, if the water is very deep then the transmitted pulses the DVL sends out will never get back (so requirement 1 is missing), and if there’s an external source of sound waves then the sonar measurements the DVL makes may be completely inconsistent with the inertial movement being detected by its IMU (so requirement 2 is missing). Of course if one or more of the sensors (sonar receivers, accelerometers, gyroscopes, etc) are damaged that can affect either of those requirements.
Less obvious failures can occur if
- the materials being reflected off don’t have a consistent surface
- e.g. moving vegetation
- the surface is reflecting sound away from the sensors
- e.g. steep slopes
- there are multiple echoes occurring from each transmission
- e.g. from the walls or water surface within a small tank
I expect your issue here is with that last one, whereby multiple echoes occur spread out over time, and potentially with different frequency shifts, which could be confusing the sensor. It may be possible for a DVL to try to compensate for being in a small water volume by reducing the transmission and/or receiver gain (to reduce the strength of subsequent reflections), but not everything can be compensated for.
Do you have similar issues if you’re testing in a swimming pool or larger body of water?