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 . Other pages are available for other combinations of equipment, as detailed in the following table:
Terminology
The following terms are used throughout this document:
- SoH - State of Health. This term is used to refer to information about the status of an instrument, such as its mass positions, and information about the status of a digitiser, such as whether its sample clock is locked or not.
- GNSS - Global Navigation Satellite System. This is a generic term for any of a number of systems which use constellations of satellites, each fitted with an extremely accurate atomic clock, to provide signals to earth-based receivers. This allows the receivers to use the signal propogation delays to compute position to an accuracy of a few metres and time to an accuracy of a few microseconds.
- GPS - Global Positioning System. Although this term properly refers only to the US-operatated GNSS (formerly called "NavStar"), it is often used as a synonym for GNSS. Timing systems for Güralp digitisers were initially developed for use only with the GPS system and many of the commands and messages reflect this fact. The connectors are labelled GPS even on equipment which supports multiple GNSS constellations. Within this document, if there is any doubt, the context should make it clear to which system we refer.
- Constellation - This is the formal term for the collection of active satellites that form the space-based sector of a GNSS.
- SV - This is an abbreviation for Space Vehicle, the
formal term for a satellite in a GNSS constellation. Each
satellite in a constellation has a unique identification number,
referred to as its "SV#". These are allocated
in ranges as follows:
1 — 32 Navstar/GPS 65 — 88 GLONASS 89 — 96 GLONASS
(future extensions)301 — 336 Galileo 401 — 437 BeiDou - NMEA - This initialism for the National Marine Electronics Association is used (in this context) as an abbreviation for the NMEA 0183 standard for marine communications. It is the most common standard used for transmitting time, position and other information from GNSS receivers. It consists of a series of formatted text messages called "sentences" which provide operational and status information. The NMEA from a GNSS receiver contains information such as the time, date, location, fix status (see below), number of satellites visible and accuracy of calculations.
- PPS - An abbreviation for one-Pulse-Per-Second, this term describes a pulse train sent by the GNSS receiver to the digitiser. The leading edge of each pulse accurately identifies the start of each second. Subsequent NMEA sentences make explicit the time and date of the second thus indicated.
- FIX - When a GNSS receiver has computed a position, it is described as having obtained a "fix". When satellite visibility is limited, a first approximation can be made by assuming that the receiver is near sea-level (actually: on the surface of the WGS84 reference elipsoid). This is referred to as a two-dimensional or "2D" fix. When signals from a sufficient number of satellites are being received, a full three-dimensional fix, which includes elevation is achieved. This is known as a "3D" fix.
- GNSS power-cycling - This is a Güralp-specific firmware feature intended to reduce power consumption in power-critical applications. The user can specify a time period, n of between one and twenty-four hours. The GNSS receiver is powered up at boot and every n hours thereafter. Each time it is powered up, the system resynchronises, if necessary, and then waits until the offset and drift have fallen to acceptable levels. It then powers the receiver down again before repeating the cycle.
- Status stream - For CD24 and DM24 digitisers, along with all equipment containing them, this is a textual stream which contains state-of-health information about the digitiser, including the GNSS and sample-clock. The term is also used loosely to refer to status information available from the console of the Minimus and Fortis.
Contents
Table
of
Contents
- Overview
- Contents
- Accessing the status stream
- Interpreting the status stream
- CD24s, 6TDs and 3ESPCDs with 6-pin receivers
- DM24s, 3TDs, 40TDs, 5TDs with 10-pin receivers but no EAM
- Monitoring NMEA contents
- CD24s, DM24s and all digital instruments without EAMs
- Affinitys and all digitisers and instruments with EAMs
- Minimus and Fortimus
- Configuration problems
- CD24s, 6TDs and 3ESPCDs with 6-pin receivers
- DM24s, 3TDs, 40TDs, 5TDs with 10-pin receivers but no EAM
- Affinitys, all instruments with EAMs and round digitisers with EAMs
- Diagnosis by replacement
- Diagnosis by test
- Testing a CD24/6TD/ESPCD Break-out Box
- Further reading
Accessing the status stream
The status stream from CD24 and DM24 digitisers can be inspected using Scream, and EAM's web interface or the command-line of an EAM. Status information for Minimus and Fortimus units can be accessed via its console.
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.
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.
Minimus and Fortimus
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:
- Sample clock synchronisation status:
- indicates that the sample clock has been successfully synchronised. This confirms that both NMEA and PPS are being received.
- indicates that the sample clock has not been successfully synchronised but both NMEA and PPS are being received. This suggests a problem with the location or orientation of the GNSS receiver but it may also indicate a problem with, for example, the antenna within the receiver.
- indicates that the PPS data are not being received so the sample clock can not be successfully synchronised. This could be the result of a problem with the digitiser, the cable or the receiver, so further diagnosis is required.
- Location status:
- indicates that NMEA has been received at least once since the digitiser was rebooted and that the location is not latitude zero and longitude zero. This means that NMEA has been received successfully at some point since the last reboot but not necessarily that it is currently being received. Reboot the digitiser to check the current situation.
- indicates that NMEA has not been received since the digitiser was last rebooted.
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 to open the console window:
Drag the bottom of the window downwards to increase its height, if necessary:
Commands are entered by typing them into the box at the bottom left-hand-side of the console window and clicking . 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 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:
- gps off - switches the GNSS receiver off
- gps on - switches the GNSS receiver on
- gps pos - displays the current GNSS position
- gps status - displays current GNSS status information
- gps leapsec - check the leap second state
Interpreting the status stream
CD24s, 6TDs and 3ESPCDs with 6-pin receivers
The GNSS-related messages from these systems include:
GPS Power On continuous
This indicates that the digitiser is providing power to the GNSS receiver.GPS
This indicates that NMEA and PPS are being received, which is the normal operational state. It appears at boot-up and whenever the power is restored during GNSS power-cycling.NO GPS
This indicates that no PPS signal is being received. The receiver, cable and digitiser should be tested as described below.NO GPS MESSAGE
This indicates that no NMEA sentences are being received. The receiver, cable and digitiser should be tested as described below.$PGSBB,Guralp Systems Ltd - UbloxGPS v1.0 mgs 08/09/15 (Build 1.08)*1F
This is a Güralp manufacturer-specific sentence emitted by our latest
generation of GNSS receivers.
No FIX SV#'s none
This message indicates that the GNSS receiver is not receiving satellite signals. Check the location and orientation of the receiver and ensure that it is not obscured by buildings or overgrowth.Auto 2-D SV#'s 3 6 20 ( 3 )
This message indicates that the GNSS receiver has received signals from three satellites: numbers 3, 6 and 20. The receiver has not, however, been able to compute a three-dimensional "fix" (hence 2D) so its calculated time is not yet sufficiently accurate to be used for synchronisation. If this situation persists, check the location and orientation of the receiver and ensure that it is not obscured by buildings or overgrowth. If it has a good view of the sky, the receiver may be faulty and should be replaced in order to verify the fault.Auto 3-D SV#'s 18 10 16 8 27 21 ( 6 )
- this indicates that the receiver has heard from six satellites and has computed a three-dimensional fix (latitude, longitude and height) which means that the receiver can now be used for synchronisation of the sample clock.Lat 19'54.0759N Long 019'21.1105E Height 00055M
This message is normal and healthy. It displays the location (latitude, longitude in degrees, minutes and decimal fractions of minutes and height above the WGS84 reference elipsoid in metres) as calculated by the GNSS receiver.2018 1 11 10:20:38 Clock sync'd to GPS =>> 2018 1 11 10:20:39
- this indicates that the timing subsystem in the digitiser has successfully synchronised itself to the incoming data from the GNSS receiver. The "previous" time is shown at the beginning of the message and the receiver's time - the "new" and correct time - is shown at the end.o/s= 254 drift= -15 pwm= 11731
- Messages like this are printed to the status stream every minute while the clock is synchronised and the timing subsystem is working correctly. The values printed are:- o/s - the offset between the sample clock and GNSS time, measured in units of 1/120 of a microsecond (8.33… ns). A feedback system monitors this number and adjusts the frequency of the crystal controlling the sample clock in order to minimise the offset.
- drift - the first derivative of the offset, which is also used as an input to the feedback system. It is the sum of the offsets over the preceding minute so it is expressed in units of (1/120)÷60 µs/s ≈ 1.79 ns/s.
- pwm - the output of the feedback system. This number is fed into a digital-to-analogue converter which generates a voltage which affects the oscillatory frequency of the crystal that controls the sample clock. This number is not usually of interest but, if the offset is growing steadily in magnitude and the pwm is not changing, this indicates that the crystal is out of specification and needs to be replaced. Contact for advice.
DM24s, 3TDs, 40TDs, 5TDs with 10-pin receivers but no EAM
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:
No GPS DATA
This indicates that the digitiser is not receiving the NMEA data-stream from the receiver. The receiver, cable and digitiser should be tested as described below.Missing PPS
This indicates that the digitiser has not received exactly sixty pulses on the PPS input during the previous minute. Note that this does not indicate that the digitiser is receiving no PPS. This can be a transient issue - there are valid reasons why this may occur immediately after power-up of the digitiser or GNSS receiver - so you need only take action if it occurs repeatedly in the status stream. If this is the case, the receiver, cable and digitiser should be tested as described below.0 NMEA> PGSA,A,3,05,07,13,20,28,30,02,,,,,,2.13,1.14,1.79*00
This indicates that the digitiser is receiving NMEA from the receiver but has been unable to parse it correctly. In the example given, it is clear that the sentence is mostly legible but the beginning of the sentence is missing. (All relevant NMEA sentences begin $GP.) If this is a single transient error, it can be ignored. If it occurs repeatedly, the digitiser may be overloaded: check the configuration and contact for advice.
Check Port1 Baud Rate0 NMEA> ¹°°°«¯¹±·²¯²¶ß²²³°°®ôøôºÐïòô ° ±¹²°° âáõä°° âáõCheck Port1 Baud Rate
This is the same error as that described above but it is clear from the quoted NMEA input that the data-stream is either not NMEA, not being transmitted at the correct Baud rate or is becoming corrupted. The receiver, cable and digitiser should be tested as described below.GPS Date/Time 04/04/16 09:31:44
This message is normal and healthy. It indicates that a correctly-formatted NMEA sentence has been received and parsed. The date and time according to the GNSS receiver are included in the message.Lat 19'54.0759N Long 019'21.1105E Height 50m
This message is normal and healthy. It displays the location (latitude, longitude in degrees, minutes and decimal fractions of minutes and height above the WGS84 reference elipsoid in metres) as calculated by the GNSS receiver.1.8 MicroSec Fast Freq error -2 e-9
- These messages are produced every twenty minutes when the sample clock is successfully locked to GNSS time. It displays the current offset between GNSS time and the sample clock together with the frequency error, which is the difference between the first derivatives of GNSS time and the sample clock.No FIX SV#'s none
This message indicates that the GNSS receiver is not receiving satellite signals. Check the location and orientation of the receiver and ensure that it is not obscured by buildings or overgrowth.Auto 2D SV#'s 3 6 20 ( 3 )
This message indicates that the GNSS receiver has received signals from three satellites ("SV" stands for Space Vehicle, which is the GPS term for satellite. Each satellite in a constellation has a unique identification number. These numbers are referred to as the "SV#s". In this example, we have signal from satellite numbers 3, 6 and 20.) The receiver has not, however, been able to compute a three-dimensional "fix" (hence 2D) so its calculated time is not yet sufficiently accurate to be used for synchronisation. If this situation persists, check the location and orientation of the receiver and ensure that it is not obscured by buildings or overgrowth. If it has a good view of the sky, the receiver may be faulty and should be replaced in order to verify the fault.Auto 3D SV#'s 18 10 16 8 27 21 ( 6 )
- this indicates that the receiver has heard from six satellites and has computed a three-dimensional fix (latitude, longitude and height) which means that the receiver can now be used for synchronisation of the sample clock.2018 1 11 10:20:38 Clock sync'd to Reference =>> 2018 1 11 10:20:39 ..
- this indicates that the timing subsystem in the digitiser has successfully synchronised itself to the incoming data from the GNSS receiver. The "previous" time is shown at the beginning of the message and the receiver's time - the "new" and correct time - is shown at the end. A small number of period characters ('.') are printed following the final time. These are printed every 200 ms until a PPS pulse arrives: this pulse is then used for synchronisation. There should normally be around three: seeing more than five is cause for concern.o/s= 254 drift= -15 pwm=11731 Auto 3D
- Messages like this are printed to the status stream every minute while the clock is synchronised and the timing subsystem is working correctly. The values printed are:- o/s - the offset between the sample clock and GNSS time, measured in units of 1/120 of a microsecond (8.33… ns). A feedback system monitors this number and adjusts the frequency of the crystal controlling the sample clock in order to minimise the offset.
- drift - the first derivative of the offset, which is also used as an input to the feedback system. It is the sum of the offsets over the preceding minute so it is expressed in units of (1/120)÷60 µs/s ≈ 1.79 ns/s.
- pwm - the output of the feedback system. This number is fed into a digital-to-analogue converter which generates a voltage which affects the oscillatory frequency of the crystal that controls the sample clock. This number is not usually of interest but, if the offset is growing steadily in magnitude and the pwm is not changing, this indicates that the crystal is out of specification and needs to be replaced. Contact for advice.
- fix quality - this indicates
how accurately the GNSS receiver has been able to calculate
the position and, hence, the time. The possible values
are:
- Manual 3D - The NMEA is coming from a GPS emulator, such as an integrated EAM, and it is asserting that the time that it is transmitting is accurate.
- No Fix - The GNSS receiver cannot see enough satellites to compute any position or time information. Four satellites are required for a 3D fix. Check the location and orientation of the receiver and ensure that it is not obscured by buildings or overgrowth. If this does not help, try replacing the receiver.
- Auto 2D - The GNSS receiver can see some satellites, but not enough to compute a full, three-dimensional fix. The location information will be reasonably accurate but the time information will not be suitable for synchronising the sample clock. See the notes above for "No fix" for possible remedies.
- Auto 3D - The GNSS receiver is seeing sufficient satellites to compute a full, three-dimensional fix. The digitiser's timing subsystem will start using the GNSS data to synchronise the sample clock.
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.
CD24s, DM24s and all digital instruments without EAMs
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.)
Affinitys, round digitisers and all instruments with EAMs
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.
Minimus and Fortimus
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:
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.
CD24s, 6TDs and 3ESPCDs with 6-pin receivers
Configuration for the GNSS receivers associated with this equipment is very simple. There are three configuration options which affect the timing subsystem:
GPS-TYPE
Syntax: type GPS-TYPE
The value of type should be 2 for correct operation. A value of 0 means that GNSS signals will be ignored. If in doubt, enter 2 GPS-TYPE at the command line of the digitiser to ensure that the setting is correct.HR-CYCLE
Syntax: interval HR-CYCLE
This setting controls whether the GNSS receiver is powered on continually or whether the power is turned off once synchronisation is achieved, in order to save power. If there is doubt about the correct operation of the GNSS receiver, disable GNSS power-cycling by entering the command 0 HR-CYCLE. The value of 0 selects continuous power to the receiver.XGPS
Syntax: 0 | 1 XGPS
This setting manually switches on and off the GNSS subsystem, over-riding any HR-CYCLE setting. Issuing the command 0 XGPS turns the receiver off (and you should hear the associated relay inside the digitiser click as it is operated) and issuing the command XGPS turns it on again.By using this command to disable and re-enable the GNSS power while measuring the voltage between pins A and F of the receiver connector on the break-out box, it is possible to verify operation of the relay and the provision of power to the receiver. If you cannot confirm a 5 volt DC positive output on pin A, relative to pin F, proceed to check the break-out box. If the break-out box functions correctly , the digitiser or instrument is faulty: contact for advice.
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:
GPS-TYPE
Syntax: type GPS-TYPE
In most cases, the value of type should be 2 for correct operation but see the note below. A value of 0 means that GNSS signals will be ignored. If in doubt, enter 2 GPS-TYPE at the command line of the digitiser.Note: Some GLONASS-capable GNSS receivers need the GPS-TYPE to be set to 4. This disables the automatic setting of 4800 Baud on the GPS port, allowing operation at 38,400 Baud, which is necessary in order to allow sufficient time for the extra NMEA sentences required each second. For such systems, the command 1 38400 BAUD must also be issued to configure the GPS input port correctly.HR-CYCLE
Syntax: interval HR-CYCLE
This setting controls whether the GNSS receiver is powered on continually or whether the power is turned off once synchronisation is achieved, in order to save power. If there is doubt about the correct operation of the GNSS receiver, disable GNSS power-cycling by entering the command 0 HR-CYCLE. The value of 0 selects continuous power to the receiver.MON .
Syntax: 0 | 2 MON .
This setting manually switches on and off the GNSS subsystem, over-riding and HR-CYCLE setting. Issuing the command 0 MON . turns the receiver off (and you should hear the associated relay inside the digitiser click as it is operated) and issuing the command 2 MON . turns it on again.Note: The command MON . includes a single trailing period ('.') which must not be omitted.By using this command to disable and re-enable the GNSS power while measuring the voltage between pins B and A of the receiver connector on the digitiser or instrument, it is possible to verify operation of the relay and the provision of power to the receiver. If you cannot confirm a positive DC output on pin B, relative to pin A, the digitiser or digital instrument is faulty: contact for advice.
Affinitys, all instruments with EAMs and round digitisers with EAMs
This section applies to:
- Affinity digitisers;
- Instruments with built-in EAMs: 3TDEs, 3ESPCDEs, 40TDEs and 5TDEs; and
- DM24SxEAMs in cylindrical cases.
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
Test cable for six-pin receivers
The cable illustrated below can be used with white, six-pin receivers. Because these receivers require a 5 volt DC power-supply, USB power can be used directly and there is no need for an independent power supply. The FTDI cable shown exposes a 5 volt output on the red wire.
Test cable for ten-pin receivers
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:
- 4800 Baud (but see note below)
- 8 data bits
- no parity
- 1 stop bit
- no hardware flow control (i.e. no RTS/CTS or DTR/DTS)
- no software flow control (i.e. no XON/XOFF)
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.
Testing a CD24/6TD/ESPCD Break-out Box
Systems with CD24 digitisers without an EAM use a break-out box to separate the data, GPS and power lines from the 19-way connector on the instrument or digitiser. The break-out box is, potentially, an additional point of failure.
The break-out box can be tested with a continuity meter. One with an audible indication is recommended. This makes it easy to check for short-circuits between pins: the probe can be moved around between all pins while you listen for any beeps. If the probes of your meter are too fat to make good contact with the sockets, a bent paper-clip can be inserted into the socket and used as a contact for the probe.
The pin-outs are given below: it is important to check for continuity on each of the relevant connections and also to ensure that there are no short-circuits from any pin to any other. (The complete pin-outs for every connector on the break-out box are given in the 6TD manual.)
Function | Pin on 19-way connector |
Pin on 6-way GPS connector |
---|---|---|
Isolated ground | M | A |
Power supply to receiver (+5 V DC) | G | F |
NMEA data-stream from receiver | J | B |
RS232 to receiver | H | C |
One pulse per second (PPS) from receiver | K | D |
Further reading
- Global Navigation Satellite Systems (GNSS) overview
- A simple explanation of how GNSS works
- GPS (formerly Navstar) - the US' GNSS constellation
- The GPS home page
- GLONASS - the Russian GNSS constellation
- - the GLONASS home page (archived)
- BeiDou - the Chinese GNSS constellation
- - the BeiDou home page
- Galileo - the upcoming EU constellation
- - the Galileo home page
- NMEA overview
- A rich description of GNSS-related NMEA sentences
- The GPS week-number roll-over problem and how it affects Güralp products
- The GPS leap-second problem and how it affects Güralp products