April
2018
Pathfinder DVL Guide
Page 48
EAR-Controlled Technology Subject to Restrictions Contained on the Cover Page.
Error Velocity threshold will be rejected. When using beam coordinates this velocity screening is not done
by the Pathfinder firmware. It can however, be performed outside the Pathfinder.
To keep the Pathfinder errors as independent as possible from ping to ping, the Pathfinder does not
screen for unreasonably abrupt changes in altitude or velocity. These kinds of screens are most appropri-
ately performed at the front end of a navigation system. An isolated abrupt change in altitude is most
likely an outlier (fish or other false target) that should be rejected, whereas a step function with a persis-
tent final altitude might be real (a cliff or a transition from a ship hull to the real bottom, for example). A
robust algorithm will reject the isolated data outlier while quickly recovering from a persistent step. Simi-
lar screening can be done on velocities.
Three-Beam Solution
The default operation of DVL’s requires all four beams to be tracking and providing good data. When this
occurs, the instrument screens the velocity data by comparing the magnitude of the Error Velocity to a
commanded threshold. The Error Velocity has redundant information among the four beam velocities.
This is done for all coordinate systems other than Beam. A three-beam solution is produced if, on a partic-
ular ping, only three beams have good data, and in that case only, error velocity screening cannot be per-
formed. When three-beam solutions are enabled, the DVL still computes a four-beam solution with error
velocity screening on all pings where all four beams have good data. There are operating circumstances
where due to the bottom slope and/or pitch only three beams are able to have adequate reflection from
the bottom, while the fourth beam is not. The three-beam solution makes it possible to operate in such
severe environments.
Ping Timing
It is usually desirable to minimize the time it takes a Pathfinder to complete a ping cycle because this ena-
bles faster data update rates. It is important to note that using the Water Layer Track in addition to the
Bottom Track mode significantly lowers the update rate of the Bottom Track data because there is an extra
ping(s) between Bottom Track pings. Therefore it is recommended that the Water Layer mode be com-
manded off when the Altitude is well within the Altitude capability of the Bottom Track (Bottom Track is
providing good data).
When the maximum operating altitude is known, the
can be used to limit the maximum
ping time in Bottom Track mode, since time to receive data from the bottom is proportional to the dis-
tance to the bottom.
For example, a 600 kHz Pathfinder has a default BX altitude of 110 meters. If the user knows that the alti-
tude will never exceed 50 meters, he can set the BX command to 50 meters and then when operating at
50 meters it potentially reduces the search time required to reacquire the bottom after bottom lock has
been lost, because it bypasses the search pings that look for greater altitudes. Therefore, if BX is set to 50
meters, and if the DVL is operating at 50 meters altitude, and loses the bottom, then the search algorithm
will not look at 110 meters if it does not find the bottom at 50 meters, and will only search at altitudes up
to 50 meters, which may result in a faster reacquisition.
Table 13 shows the approximate Bottom Track ping times for a Pathfinder DVL as a function of altitude
above the bottom. The data is for the case where there are no external sensors being used:
Table 13:
Approximate Bottom Track Ping Times (in milliseconds)
Altitude in meters
Ping Time in ms
1
110
10
70
40
210
86
360