You are here

System Configuration and Timing

Background

In order to create a set of valid depth measurements, results from a number of subsystems need to be brought together. These can include:

Bathyswath sonar

Attitude system, providing roll, pitch & heave, possibly also heading

Compass, providing heading

GPS system, providing position

Real-time speed of sound

Echosounder

Some of these subsystems can be integrated into one unit; for example, the CodaOcotpus F180 and Applanix POS/MV provide position, attitude and heading.

In order to bring this data together correctly, the relative timing of all the data streams must be known. The most time-critical measurement is roll. For extremes of motion on a small vessel, a timing accuracy of better than 5ms may be needed. On a small vessel in a moderate sea, a timing error of 20ms in the attitude data is just detectable on the depth displays and data output.

Pitch, heading and position are required with a timing accuracy of better than 0.5 seconds (500ms).

Some survey protocols require that all data is logged with time information that can be traced back to a common time source, usually UTC time derived from GPS signals. This can be achieved using Bathyswath, but may not be supported by some auxiliary sensor systems used with it.

PC clock

The clocks in most PC computers are not particularly accurate. PC clocks are reputed to be accurate to 30 to 100ppm (parts per million; e.g. 100ppm is 0.36s in an hour). However, the Windows operating system adds its own timing errors and uncertainties. Tip: the Windows Time Service can cause the PC time data to vary at rates of up to half a second per minute [8000ppm!]. Therefore, it can help to disable it, using ‘Settings > Control Panel > Administrative Tools > Services > Windows Time’. Therefore, a method of synchronising the PC time to GPS time should be considered. Some integrated attitude and position systems provide this as part of the supplied package. Alternatively, an NTP (Network Time Protocol) time server can be integrated into the system.

If a distributed computing system is being used, and one of the PCs is acquiring UTC-GPS time, e.g. via PPS (pulse per second) , then an NTP time server can be set up on that PC, and NTP clients set up on the other PCs in the system. These NTP servers and clients are software applications, which can be obtained as shareware products for a few tens of dollars on the Internet. Bathyswath surveys have been successfully carried out using such configurations.

Serial port delays

Bathyswath records the time of a data string when the first character is received, so that the time it takes for the string to arrive is not a problem. However, there can be a large and indeterminate delay in that first character arriving. Older PCs have the serial port built in to the PC card, and the timing is reliable. Newer PCs do not consider the serial port to be important, and so implement it on some kind of sub-bus, if at all: RS232 is regarded as a ‘legacy port’. This is particularly true for laptops, which rarely have serial ports fitted, and so have to use external port adaptors, using USB, PCMCIA or Ethernet. For a good USB implementation, the time delay could be as low as 10ms, but it can well be much more. Therefore, we do not recommend the use of USB-serial adaptors. Bathyswath has been tested with Ethernet USB adaptors, and shown good attitude stability.

Possible mitigations include:

Get a serial port system that has a delay that is either very small or deterministic and known (the Bathyswath software includes a capability to correct for sensor time offsets).

Use sensor systems that are synchronised with GPS time and add this time to the data string that they send out, and configure the Bathyswath software to use this time stamp.

Use Ethernet outputs from the attitude sensors. Although there is a non-deterministic delay in the Ethernet transmission, it is small enough not to cause problems to Bathyswath processing (typically 50 microseconds or less).

Sonar data timing

Sonar data time can either be provided by the TEM’s own clock, or using the PC clock time at the time of acquiring the data. The TEM’s internal clock is accurate to about 50ppm, but it can be accurately synchronised with a time reference using a 1PPS input (see below). Each TEM records the time since its clock was reset, in seconds and milliseconds. The software records the PC time at which each TEM reset occurs, and generates a time stamp for each sonar ‘ping’ by adding this reset time to the TEM time clock.

In PPS mode, the PC reset time is rounded down to the nearest second, and the true GPS time in seconds is added. Thus, an accurate sonar time is available to the nearest millisecond, even though the PC time is up to half a second in error. For PC time errors of greater than half a second in either direction, an error in sonar time of a whole number of seconds will be seen.

PPS, Pulse per Second

Accurate clock systems often provide timing signals as electrical pulses sent out every second, on the second. These signals are called pulse-per-second, shortened to "PPS" or "1PPS". GNSS systems such as GPS provide very accurate clock signals (a GNSS system is essentially a set of atomic clocks on satellites), so the most common source of PPS in a sonar "spread" is the GNSS system.

PPS Input to TEMs

The TEMs can receive a PPS (pulse per second) signal from an external timing system. This is often derived from a GPS input, either from a GPS positioning system, or from a dedicated timing system that uses a GPS receiver.

When the TEM firmware detects a PPS pulse on its data input, it synchronises the TEM clock.

Connecting the PPS signal

PPS is generally supplied as a BNC coax connection from the GPS system. A BNC connector is supplied on the connector face of the TIU for this purpose.

The TIU PPS input is designed for high-impedance outputs. However, some systems provide PPS on a 50W output. In this case, it may be necessary to use a 50W BNC terminator and T-piece at the TIU PPS input.

Monitoring the PPS input

The Swath software provides the ability to control the PPS input, and to monitor its status.

The Sonar control dialog in the Swath program includes two controls:

1PPS Enable, and

Rising/Falling edge

The first of these tells the TEMs to use the PPS signal to synchronise their clocks (or not). The second control determines whether the rising or the falling edge of the PPS square wave signal should be used for timing. Note: the CodaOctopus F180 and Applanix POS/MV systems provide a falling-edge 1PPS signal.

A status indicator at the bottom of the Swath program main dialog box (usually on the left of the screen) provides two status indicators:

Ack, which acknowleges that the PPS signal is being received

Error, which checks that the period of the PPS signal is close to 1 second, as compared with the TEM’s internal clock. The most common cause of an error of this type is if there is ‘noise’ on the 1PPS line, causing the TEM to trigger at times other than the correct signal edges. This might occur if the 1PPS impedence and termination are incorrect.

The main dialog box also contains a ‘traffic light’ status indicator, which summarises the state of the two status indications at a glance.

The Status window gives information about PPS status. Note that a PPS error state may briefly be detected when connecting or re-connecting the PPS signal, or changing the PPS state in software, as the TEM units synchronise to the regular PPS input.

System Configurations

Alternatives

Bathyswath is designed to operate with a range of different equipment and system configurations. However, there are broadly two options for system timing:

Sensor clock timing: all sensor information is recorded using the sensor’s own clock time. This configuration provides data related to UTC-GPS time, with an accuracy of 10ms or so, but is more difficult to set up, and is only possible if the auxiliary sensor systems provide such timing information in their data interfaces.

PC clock timing: all sensor information is logged using the time at which it appears at the PC for logging. This option provides a slightly less accurate solution, is prone to communications delays, and its relation to UTC-GPS time is only as good as the PC’s clock synchronisation; which could be a second or more even with Windows time synchronisation tools. However, it is significantly more robust, easier to set up, and can be used with all attitude sensors.

Sensor Clock Timing Configuration

Description

In this mode, the sonar, and each sensor in the system, provides its data time-stamped with its own clock, and each of the clocks is tied to UTC-GPS time, using an external reference or time server.

Motivation

This configuration gives several advantages:

Errors due to unknown or variable data communication times are eliminated

Attitude correction is better, as errors due to time offsets are eliminated

Post-processed attitude and position data can be used, as these files are also related to the sensor clocks

All data is traceable back to a global time source

Data can more easily be related to data from other systems being used at the same time

Some survey protocols specify such time referencing

Potential problems

It is harder to set up, requiring careful configuration of the overall system and each component

Time offsets between the various clocks can cause significant errors in data processing. The most common of these is ‘roll bleed’, where vessel roll is not properly applied to the sonar data, and the vessel’s roll appears as a sequence of ‘waves’ in the seabed data.

It is only possible if each sensor sub-system:

Maintains its own clock

Can be tied back to a central reference source

Provides data in a format that includes time information. Most serial data interfaces from attitude sensors do not provide such timing data: formats missing this information include the ‘EM3000’ and ‘TSS1’ formats.

However, when the time data is recorded in Sensor Clock format, both the Sensor time and the PC time are recorded with each data item. Therefore, it is possible to revert to PC Clock timing in post-processing, if a Senor timing error is discovered after the survey is complete.

System diagram

<sensor clock diagram.svg>

Sensor Clock Timing Configuration

Configuration settings

Connections:

Use Ethernet output from the attitude and position sensor, using its ‘native’ sensor format, e.g. CodaOctopus MCOM or POS/MV ‘102’ format

Connect PPS from the attitude and position sensor to the TEMs

Use NTP or PPS to synchronise the PC clock. However:

Good sonar-attitude time synchronisation is possible provided that the PC clock is accurate to the nearest half-second in either direction

The Swath software can be configured to synchronise the PC clock to the time coming from the position system; while this is only accurate to several tens of milliseconds, it is good enough for sonar-attitude synchronisation.

If a separate NTP server is used, make sure that it keeps well synchronised with the attitude system clock

Swath settings:

In the initiation file, ‘swathprocconfig.txt’, set:

sonar timeUpdateInterval 0 This suppresses regular TEM clock resets. In 1PPS mode, the TEM time should be more accurate than PC time, so it is preferable to use the TEM clock without synchronising to the PC clock in the middle of survey lines.

F180socket enabled 1 … and other settings for the F180 or POS/MV, see §5.6.3 for details. (Note that the ‘F180socket’ group applies to all Ethernet-enabled motion sensors, not just the F180). This sets the default start-up state of the software; it can be enabled using the Socket Properties dialog independantly of the setting in the initiation file.

F180socket timesyncEnable 0 … if the PC time is synchronised using NTP or similar, otherwise F180socket timesyncEnable 1 … this causes Swath to update the PC time from the attitude sensor’s data streams at the start and end of survey lines (when changing the sonar from inacive to active and vice-versa). This is good enough to maintain sonar-attitude synchronisation within the necessary half-second accuracy. Note: this time-setting feature may not work under Windows Vista, due to security settings. Try disabling User Access Control.

Whilst setting up the system and performing initial tests, try selecting reportingtimingDebugInfo 1 This continuously prints the ping-attitude time difference to the Status window, allowing a trace of possible synchronisation errors.

In the Swath program:

Configure the attitude and position Ethernet interfaces

Select ‘Sensor Clock’ in the Attitude and Position set-up dialogs

Select ‘Sonar Clock’ in the Sonar dialog

Enable 1PPS in the Sonar dialog

PC Clock Timing Configuration

Description

In this mode, all data is time-stamped with the PC clock time at the moment of acquisition in the Swath software.

Motivation

The advantages of this configuration are:

Errors due to differences in system clocks are eliminated

Errors due to drift between clocks are eliminated

Errors due to Windows time sensing are eliminated

It is quicker to set up

It is the only possible configuration when using serial data interfaces from attitude sensors that do not include time data. These include the industry-standard TSS1 and EM3000 formats.

Potential problems

Times cannot be related back to universal UTC-GPS time to better than a second or so, and only then if the PC clock is synchronised in some way.

Time synchronisation between sonar and attitude data is subject to communications delays from both systems, and therefore roll correction will not be quite as good in high roll rates.

System diagram

<pc clock diagram.svg>

PC Clock Timing Configuration

Configuration settings

Connections:

Use serial output from the attitude and position sensor, using a suitable data format. Ethernet data interfaces still work in this mode, but if they are available, consider using Sensor Clock timing. On a laptop computer, it may be necessary to use an Ethernet-Serial data converter. USB data converters are not recommended, as they can insert delays of several tens of milliseconds.

PPS to the TEMs is not necessary in this mode, as the TEM clock data is ignored.

Use NTP or PPS to synchronise the PC clock if possible. However, this is not necessary to get good Bathyswath survey results.

Swath settings:

In the initiation file, ‘swathprocconfig.txt’, set:

sonar timeUpdateInterval 0 This suppresses regular TEM clock resets. These are not necessary, as the TEM clock is ignored.

F180socket enabled 0 … assuming that a serial interface is being used.

In the Swath program:

Configure the attitude and position serial interfaces as explained in the Online Help.

Select ‘PC Clock’ in the Attitude and Position set-up dialogs

Select ‘PC Clock’ in the Sonar dialog.

Disable 1PPS in the Sonar dialog. (Although there is no harm for the 1PPS to be running: it is ignored in this mode).

Set a small delay to the attitude samples to account for serial data acquisition times: ‘Configuration > Sensor Parameters > Attitude Sensor Corrections > Time Offset’. An offset of –0.015 works well for an F180 sensor operating over a serial link.

Monitoring System Timing

Motivation

Especially if using Sensor clock timing, it is important that the relative timing of the components of the system is carefully monitored during the course of surveys. To do this, open a Text window, and select ‘Show Timing Data’. This monitors the current PC time, and the time of the latest sonar, attitude and position data samples, together with the differences between these. It also shows running averages for the ping-attitude and ping-position data samples.

Text View

Note that there is no reason why any of these differences should be exactly zero, as the data is acquired asynchronously, at different rates, for each data set. (An exception is the attitude and position data if these are coming from the same sensor; in that case a zero attitude-position time can be expected). As attitude data is acquired at a faster rate than sonar data, particularly when running at longer ranges, the latest attitude sample will almost always be later than the latest ping sample, and so the ping-attitude difference will be negative, and about half the ping period. It is not appropriate to attempt to compensate for this difference, for example using the Attitude Sensor corrections settings in Swath.

Sonar Views

Strong roll errors will show up as movement in the cross-profile displays. Note that the ‘noise’ data should roll with the vessel, but the seabed should stay level (apart from real changes in the seabed as the boat moves across it, of course).

Watch the colour-depth waterfall views for signs of roll errors; on a seabed with slight slopes on it, some quite small timing errors can be seen.

Correcting for Timing Errors

If the roll error is large, check that the transducers are connected the right way round and that the attitude sensor is correctly orientated and configured.

In Sensor Clock timing mode, watch the various timing offsets. Observe the ‘now-att’ time to look for differences in the PC clock and attitude clock (this only works in real time, not from recorded data). If there is a large error (more than 1 second), check how the PC clock is being synchronised, and correct it.

If there is a small residual roll error, try small time offsets in the Attitude Sensor corrections settings in Swath.

If all else fails, using PC Clock timing is generally a safer and more robust option.