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 black receivers with Lemo™ connectors when used with Minimus digitisers and Fortimus digital instruments. 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

A summary of the status of the signals from the GNSS receiver is shown on the web interface of the Minimus and Fortimus. The web interface shows the PPS status and NMEA status separately:

In addition, this information is also shown on the LCD of the Fortimus, which shows a red warning when the sample clock is not locked:

Icons at the top left-hand-side of the display provide indications about the Sample clock synchronisation status and the presence (or otherwise) of NMEA:

For more detailed information, it is necessary to visit the digitiser's console. To do this, locate the entry for the Minimus or Fortimus in Discovery's main window and double-click it. This opens the Control Centre. Click the Console button to open the console window:

Discovery console window

Drag the bottom of the window downwards to increase its height, if necessary:

stretching the window's bottom

Commands are entered by typing them into the box at the bottom left-hand-side of the console window and clicking the send button. The output is displayed in the window. The console session will time out and disconnect if left inactive for too long. In this case, simply click the reconnect button to restart your session.

There are six levels of debugging information that can be displayed for both NMEA and PPS. These are selected with the integers zero through five where zero means no debugging information and five is maximally verbose. To select the debugging level for NMEA, issue the command

dbg gps.c n

replacing n with the required number. For example,

dbg gps.c 5

produces highly verbose debugging output. A debug level of one dumps raw NMEA sentences to the console, as described later. Entering

dbg gps.c 0

disables the debugging output.

In a similar fashion, the command

dbg gps_pps.c n

sets the debugging level for the PPS signal to n.

The requested debugging information appears in the console window in near real time.

Other GNSS-related commands which can be entered at the console include:

Interpreting the status information


Monitoring NMEA contents

If there is doubt about the actual contents of the NMEA data stream, it is possible to inspect the raw NMEA. The live NMEA stream received at a Minimus or Fortimus can be examined by setting the debug level for gps.c to 1, as described earlier:

Minimus sample NMEA

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:


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 or the digitiser itself, we have to consider the status of both 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 (as determined by inspecting the status page of the web interface) is, in each diagram below, indicated by the green tick () or red cross () in the centre of the laptop display.

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 digitiser works 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 digitiser

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.

Further reading