Open main menu
SUPPORT DOCUMENTATION

Trouble-shooting GNSS/GPS problems

Overview

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 DM24 digitisers, 3TD and 40TD instruments as well as 3ESPCD instruments with 10-pin GPS connectors. Other pages are available for other combinations of equipment, as detailed in the following list:

Terminology

The following terms are used throughout this document:

Contents

Return to
Table
of
Contents

Accessing the status stream

The status stream from a DM24 digitiser can be inspected using Scream. If it is connected via an EAM, you can also access the status stream using the EAM's web interface or 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 an EAM's web interface

If the output of your digitiser is routed through an EAM or if you are using a digitiser or instrument with an integrated EAM, the status stream from the digitiser is recorded by the EAM and included in its own status-recording mechanisms.

You can view the status stream from a connected 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 an EAM's command line

If the output of your digitiser is routed through an EAM or if you are using a digitiser or instrument with an integrated EAM, the status stream from the 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

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.

When connected via an EAM

To enable injection of the raw NMEA into the status stream of a CD24 digitiser, issue the following commands:

OK-1
2 MON !
GO

To disable injection, issue the commands:

OK-1
1 MON !
GO

(Issuing OK-1
0 MON ! will disable all NMEA reporting. The setting of 1 enables error notifications only.)

When connected via an EAM

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. There are three configuration options which affect the timing subsystem:

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.

Universal test cable

If you have a mixture of receiver types, the following cable can be used to test them all. It incorporates an FTDI cable with a 5 volt DC output which provides the supply required for six-pin receivers; An external power supply of between 10 and 30 volts DC must still be used with ten-pin receivers.

Using a test cable

Set the power supply output voltage to around 12 V DC.

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