A high level of jitter indicates either rapidly changing velocities or navigational noise. Rapidly changing velocities can be real (such as over shallow or steeply sloping topography), can be induced by a calibration error (such as a residual phase adjustment), or can be a good indicator of geninely bad data (such as in ice). Noise in the navigation can indicate a bad position (for whatever reason), or can indicate noisy positions in general (selective availability and p-code GPS have very different inherent jitter levels).
Guidelines: This parameter is really meant as a way to identify potentially bad profiles.
Defaults:
The current default is 5 (reasonable for p-code GPS positions).
Cruises with dithered GPS (such as the demo) may require over 30.
Approach: Set the jitter threshold at a level where it is only flagging the outliers and then look to see whether you can actually see a visible difference between the flagged profiles and their neighbors. If all the flagged profiles are anomalous in some way, then the jitter criterion did its job and you should 'list to disk' with that threshold. If you do not want to delete the profiles flagged, the best approach is to raise the threshold (so the profiles are not flagged) and then use "delete bad times" to manually delete the profiles.
Other adjustments: see neighbors
From the original demo, you can see the number of flagged profiles
decrease as the jitter criterion is raised. The original demo did not
have p-code GPS positions. There are no particular spikes in jitter
associated with the on-station/underway transition or with the time on
station (as opposed to underway). The stripes in velocity are due to
an amplitude
calibration error not yet fixed at this stage in processing.
(thumbnails are linked to larger versions)
jitter threshold is 5 | jitter threshold is 20 | jitter threshold is 35 |
jitter threshold is 5![]() |
jitter threshold is 10![]() |
explanation![]() |