Güralp Systems always recommend using GNSS (GPS, GLONASS, Beidou…) for data time-stamping wherever possible. In some situations, however, it is necessary to use NTP. Note that, even in idea situations, NTP is several orders of magnitude less accurate than GNSS. This can cause significant problems for seismic observatories but may be adequate for structural monitoring or earthquake early-warning applications.
The following Güralp systems are capable of using NTP for synchronisation of the ADC clocks:
- 3TDE seismometers
- 3ESPCDE seismometers
- 5TDE accelerometers
- DM24SxEAM data acquisition units in metal cylindrical cases (but not in plastic Peli™-cases)
- NAMs (with the correct accessory kit)
✶ This document does not apply to these systems, which use a different operating system.
Platinum will not generate NMEA/PPP for the digitiser if the reported NTP error is greater than the configured threshold value of the "Maximum NTP error" parameter. This feature exists so that a system with intermittent internet access can fall back to the digitiser's internal clock if the estimated NTP error becomes too large. The initial setting is very conservative and normally needs to be increased.
To troubleshoot a system configured to synchronise to NTP:- Double-check that your system is capable of operating in this mode, using the list above. Configure the Platinum part of your system (EAM or NAM) to run in NTP mode (In the web interface: Support→Configuration→Data handling→Timing) and add the desired peers (NTP servers) to the table; select Port C (on EAMs) or Port A (on NAMs) as the "NMEA Out" port set the Baud rate of of the "NMEA Out" port to 4800 set the "Maximum NTP error (µs)" on the "NMEA Out" port to 1000000 submit the page by clicking the "Set timing to NTP mode" button Wait ten minutes for NTP to stabilise Open a command-line session to the Platinum part of your system (EAM or NAM) using ssh or the console connection and check the NTP operation with the command ntpq -p one of the configured peers (NTP servers) should be marked with an asterisk ('*') the reach value for the starred peer should be 377 note the offset value Visit the Summary→"System status" page of the web interface and tick the "Show hidden values" check-box Select the tab for the digitiser and check that you see offset and drift values being reported in the status stream. I haven't described what to do if any of these checks fail because this would turn into a long essay if I tried. I might create a web page for it at some stage, tho'. The value of 1 million for the maximum error means that the system will operate even if the NTP time is estimated to be one second out. Run like this for a few days and regularly check the actual offset value as reported by ntpq (the value is given in units of milliseconds). Once you have a feel for the typical offset and variance, you can choose an appropriate value for the "Maximum NTP error (µs)". Note that the digitiser's internal clock is much more accurate than NTP so it can be counter-productive to set the max error too high. If the NTP error swings around a lot, you may be better allowing the digitiser to free-run while the NTP error is higher than its average value. (Note that the NTP offset is reported in ms but the max error is specified in µs.) If you encountered any problems during the trouble-shooting steps, please let me know. It would be helpful to include three things: A configuration summary: From the web interface, visit Configuration→Save/Restore, save a configuration, download it to your PC and then attach it to your reply; A status summary: From the web interface, visit the main status page and, at the bottom, click the “Download snapshot as XML” button and then attach the downloaded file to your reply; and A copy of the file /var/log/messages ( https://www.guralp.com/howtos/how-to-retrieve-a-copy-of-varlogmessages-from-a-platinum-system.shtml ).