Open main menu

Trouble-shooting GNSS/GPS problems


Güralp digitisers use Global Navigation Satellite Systems (GNSS) to synchronise their sample clocks. This is the most accurate time-source available other than atomic clocks which are expensive and impractical in most circumstances. Güralp GNSS receivers are available for use with the US GPS (formerly Navstar) constellation, the Russian GLONASS constellation, the Chinese BeiDou constellation and, when it becomes available in 2020, the European Galileo constellation.

For best results, Güralp GNSS receivers need to have a clear view of the sky, unobstructed by buildings and foliage. Because they are fully exposed to the elements, the receiver and associated cable are, potentially, the most vulnerable part of an installation. Damage due to animals, vandalism and electric storms have all been reported. If you have problems with GNSS synchronisation, this guide is intended to help you trouble-shoot.

The guide has been split into several pages to cover different combinations of equipment. This page covers white receivers with 10-pin connectors used with EAMs, DM24SxEAMs and all *TDE instruments (3TDEs, ESPCDEs, 40TDEs and 5TDEs). Other pages are available for other combinations of equipment, as detailed in the following list:


The following terms are used throughout this document:


Return to

Accessing the status stream

The status stream from the digitiser can be inspected directly using Scream. The status information is also copied both to the web interface and to an internal log-file from where it can be inspected using the Platinum command-line.

Using Scream

Scream displays all streams in the right-hand pane of its main window. If you select a digitiser from the list in the left hand pane - the source tree - the right-hand side of the display will show only streams from the selected digitiser. Once you have selected the digitiser of interest, the status stream can be identified by its name, which will end with two zeros: 00. Note also that the sample rate will be shown as zero (because this is a textual stream) and the RIC will be shown as N/A for the same reason.

If there is a yes in the column headed Rec., the status stream is being recorded by Scream (typically to the local PC, although this is configurable) and you can view previous entries from the configured recording destination: please see the Scream manual for more information. To enable recording, right-click on the stream name and select Start Recording from the context menu.

Note: Data recording in Scream is independent from any recording being performed by the digitiser itself. The recording indication in Scream's main window only applies to Scream's own, local recording functionality.

To view live status stream entries, double-click on the stream name in Scream's main window or select View from the context menu. A new window will open showing the most recent entries:

The screen will be updated in real time: as packets arrive via the status stream, they will be displayed in this window. Note that, although some significant events will trigger the immediate output of a status packet, individual messages in the status stream are normally collected in the digitiser until 1 kB are available before they are packed and transmitted so, depending on how busy or otherwise the traffic on the stream is, it may take several minutes to receive an update.

To avoid this delay when diagnosing problems, open a terminal window by right-clicking on the digitiser's icon () in the source tree and selecting Terminal... from the context menu:

When the terminal window opens, enter the commands OK-1 and flush-status:

Then enter the command go to close the terminal window. Any outstanding status messages will be sent within a second or two and they will appear in the status stream window, if it is still open.

Using the web interface

The status stream from the embedded digitiser is recorded by the EAM and included in its own status-recording mechanisms.

You can view the status stream from the embedded digitiser using the "System status" screen of the web interface. Start by ticking the "Show hidden values" check-box at the bottom of the screen. Once the display has refreshed, click the tab for the digitiser in question: this will be labelled with the System ID and Serial number of the digitiser.

The status stream is recorded in the "Log entry" sections labelled SOH log where "SOH" stands for "State Of Health", the traditional name for status information.

Using the EAM's command line

The status stream from the embedded digitiser is recorded by the EAM and included in its own status-recording mechanisms.

The most recent status information from both EAM and digitiser is stored in the file /var/log/messages. When this file is full, it is renamed /var/log/messages.0 and a new /var/log/messages is started. In a similar fashion, any existing /var/log/messages.0 is renamed /var/log/messages.1 and so on until there are twenty files, numbered zero to nineteen, in addition to the current, live messages file.

Regardless of the actual type of digitiser used, the digitiser status stream entries in the messages file are prefixed with the EAM's time and date and the word DM24 followed by a colon (':). This allows the use of the grep command to extract just the digitiser status from the messages files. For example, the command

grep DM24: /var/log/messages

will extract the digitiser status entries from the latest messages file. If you want the status entries from all messages files, the following command ensures that they appear in the correct order (oldest first):

grep DM24: `ls -rv /var/log/messages*`

Because this produces a lot of output, it is wise to pipe the output through a pagination program such as less. For example:

grep DM24: `ls -rv /var/log/messages*` | less

You can now view the output a page at a time by keying the spacebar. It is also possible to move backwards through the entries or to search for specific text: see the less manual page for more information.

Interpreting the status stream

Instruments with embedded CD24 digitisers

The GNSS-related messages from these systems include:

DM24SxEAMs and instruments with embedded DM24 digitisers

Note: Some of these messages are very similar to those in the previous section but there are some minor differences in spelling, spacing, capitalisation and punctuation throughout.

While booting - or after a GNSS power-cycle - the DM24 prints the message

GPS Power On continuous

to the status stream. If you do not see this message during boot-up, check the digitiser configuration as described below.

Once the GNSS receiver is powered up, the following messages may appear:

Monitoring NMEA contents

If there is doubt about the actual contents of the NMEA data stream, it is possible to inject the raw NMEA into the status stream so that it can be inspected. This feature is normally enabled for a few tens of seconds at most: the injection is then disabled and the status stream retrieved and inspected as outlined previously.

Note: DM24SxEAMs in black plastic cases do not have the EAM's Port C connected to the NMEA input. These units should be treated as stand-alone DM24 digitisers.

In these systems, the NMEA signal from the GNSS receiver is routed through the EAM's Port C before processing by the digitiser. The stream can be viewed as a real-time data-stream from the command-line of the EAM. To do this, issue the command:

minicom PortC

An emulator window will open showing the live NMEA sentences scrolling in real-time. To exit the display, key ctrl + A then Q.

For more information, please see the minicom manual page.

Configuration problems

It is possible to disable synchronisation by changing configuration settings. If you suspect that this might have happened, please check the following settings, depending on your hardware type.

Instruments with embedded CD24 digitisers

Configuration for the GNSS receivers associated with this equipment is very simple. There are three configuration options which affect the timing subsystem:

Note: The command .FIX is a quick and convenient way to check whether any changes made to the GNSS subsystem have made a difference. It reports the current date and time, the status of the GNSS receiver's fix and the number of satellites currently in view. For successful operation, the fix status must be 3D.

DM24s, 3TDs, 40TDs, 5TDs with 10-pin receivers but no EAM

Configuration for the GNSS receivers associated with this equipment is very simple. There are three configuration options which affect the timing subsystem:

Affinitys, all instruments with EAMs and round digitisers with EAMs


This section applies to:

It does not apply to DM24SxEAMs in black, plastic Peli™-cases, which have different internal wiring.

Other than the Affinity, these units contain embedded CD24 or DM24 digitisers and should first be investigated according to the relevant section above. Access to the command-line of the embedded digitiser is obtained either via the "Forth terminal access" item in the web interface menu or via use of the data- terminal command from the Platinum command-line.

There is an additional level of control and monitoring for the GNSS receivers for all of these systems. The power to the receiver can be turned on and off and the voltage supplied to and current drawn by the receiver can be monitored.

To view this via the web interface, visit the "Digital I/O" page from the "Control" menu and scroll down to the entry labelled "Port C" or, on the Affinity, "GPS Port".

Note that the "Output" state is "high(on)". This means that the system is supplying power to the GNSS receiver. On systems with an integrated DM24, this power control is in series with the DM24's own power control, so both should be checked. If the "Output" state is "low(off)", click the associated button to turn on the power.

Note that the "Current" and "Voltage" figures are reasonable. (On an Affinity, there is also a "5V Current" figure: this can be ignored.) The voltage should be between 10 and 30 volts and the current should be a few tens of milliamperes. If the current is zero, check the cable and receiver as outlined elsewhere in this document. If the voltage is very low or zero even when the "Output" state is "high(on)", try disconnecting the receiver: if the voltage rises to near the supply voltage, check the cable and receiver; if the voltage stays low, there is a problem with the instrument or digitiser: contact for advice.

Diagnosis by replacement

This technique is suitable if you have no test equipment but you do have another installation nearby which is working correctly or equivalent equipment which you know works correctly. In the discussion below, we shall call the installation under test A and the working system B.

Note that, because the problem could be in either the receiver, the receiver cable or the digitiser itself, we have to consider the status of all three of these components to be unknown, as indicated by the amber question-marks (?) in the diagrams below. The components of the working system, however, are all known to be good, as indicated by the green ticks () in the diagrams.

The status of the complete system are, in each case, indicated by the Scream digitiser icons, where the colour of the top half of the icon indicates the synchronisation status: green () for synchronised and red () for unsynchronised. These icons are used to indicate test results in the diagrams below.

Checking the receivers

The first step is to interchange the GNSS receivers:

There are two possible outcomes: system A will start working and system B will stop working or there will be no change in symptoms.

If system A starts working

Because the only change we have made to system A is to add the known-good receiver from system B, it is clear that the receiver originally attached to system A must be faulty. We have also verified that system A's cable and digitiser work correctly, so the status of all components is now known:

The faulty GNNS receiver (now attached to system B) should be replaced.

If there is no change

Because system B is still working, we now know that the receiver originally attached to A was not the cause of the problem. We can mark both receivers as good and restrict our investigation to system A's cable and digitiser, the statii of which are still unknown:

Continue by checking the cables, as described in the next section.

Checking the cables

The next step is to interchange the receiver cables:

Again, there are two possible outcomes: system A will start working and system B will stop working or there will be no change in symptoms.

If system A starts working

Because the only change we have made to system A is to add the known-good cable from system B, we can see that the cable originally attached to system A must be faulty. We have also verified that system A's digitiser works correctly, so the status of all components is now known:

The faulty receiver cable (now attached to system B) should be replaced.

If there is no change

Because B is still working, we know that the cable originally attached to A was not the cause of the problem. We can mark both cables as good so the only remaining possibility is that system A's digitiser is the cause of the problem:

The configuration of the digitiser should be checked but, if no misconfigurations are found, the digitiser will probably need returning for repair. Please contact for advice.

Diagnosis by test

If you have a large fleet of installations, it may be worth a small investment in test equipment. An adapter cable can provide power to the GNSS receiver while routing the NMEA to a PC for display and simultaneously indicating the PPS using an LED. This allows a receiver to be tested without the use of a digitiser.

The cables shown below use socket(s) to connect to the receiver(s) via the existing receiver cables. It is just as easy to use plugs, so that they can be connected directly to the receiver or, if you wish, both plugs and sockets wired in parallel so that receivers can be tested either with or without their associated cables.

All bayonet connectors are compatible with MIL-DTL-26482. Suitable connectors include the ITT/Cannon KPT series, the Amphenol PT series and the Souriau UTS series.

All of the cables use FTDI serial⬄RS232 conversion cables in order to allow direct connection to the USB port of a PC or laptop. Both of the types mentioned below are described in the FTDI USB to RS232 Serial Converter Range data-sheet.

Test cables

Special test cable for ten-pin receivers only

The cable illustrated below can be used with white, ten-pin receivers and also, when accompanied by the relevant GSL-supplied adapter cable, with the black receivers used with Minimus and Affinity digitisers and Fortimus instruments. The power supply can be any unit which is compatible with the digitiser: typically between 10 and 30 volts DC. The FTDI cable used in this example does not have a 5 volt output.

Universal test cable

If you have a mixture of receiver types, the following cable can be used to test them all. It incorporates the same FTDI cable as used in the 6-pin version to provide the 5 volt DC supply required for six-pin receivers while an external power supply of between 10 and 30 volts DC must be used with ten-pin receivers.

Using a test cable

Set the power supply to an appropriate voltage for the receiver under test. This is 5 V DC for 6-pin receivers and 12 V DC for ten-pin receivers (and receivers with Lemo™ connectors) unless you have built a voltage regulator into the cable, in which case you can use 12 V DC exclusively.

Connect the GPS receiver to the test cable and plug the USB connector into your PC or laptop.

On the PC or laptop, open a terminal emulator. Minicom is recommended for Linux PCs and PuTTY is recommended for Windows PCs but most emulators will work satisfactorily.

Configure the emulator for:

Note: Some GLONASS-capable GNSS receivers require a 38,400 Baud connection in order to transmit all of the necessary NMEA sentences before the next PPS pulse arrives.

The test configuration should look like this:

You should see NMEA data on screen. NMEA is an ASCII format so all characters should be legible and form one-line "sentences", each beginning with a dollar sign ($) followed by two further characters and ending with an asterisk (*) followed by two further characters.

The two characters following the initial $ are the "talker ID". This will be GP for GPS/NAVSTAR messages, BD for BeiDou messages, GP for GLONASS messages, GN for mixed GPS/NAVSTAR and GLONASS messages and, once it becomes available, GA for Galileo messages.

The final two characters, following the asterisk, are the check-sum for the sentence. Sentences should arrive in groups of around five or six and one group should appear regularly, once per second. If you do not see this and you are happy that the Baud rate is correct, the receiver is not producing NMEA and should be reprogrammed or replaced. Please consult for advice.

You should also see the indicator LED flashing once every second. This shows the incoming PPS pulse, which is used for the fine-grained synchronisation. If you do not see this, the receiver is not producing PPS and should be replaced.

Further reading