October 13, 2011 at 14:01Very accurate time server stratum 1 on Garmin GPS
GPS receivers can be used not only to determine the location, but also to receive accurate time signals. In the article I will show how to configure the exact time server that uses GPS as a source and works with an accuracy of several microseconds. As an example, I use the Garmin receiver and the FreeBSD OS, but the article will also be useful to owners of Linux and Windows.
UPD: the server is available at stratum1.net Web face: www.stratum1.net .
A similar topic on the hub already ran , but I believe that the topic should be disclosed in much more detail: the author omitted many important details.
To determine your own three-dimensional coordinates, the GPS receiver calculates the distance to 4 satellites. This distance is calculated by measuring the travel time of the radio signal from the satellite. Because the speed of light is 3 × 10 8 m / s, the signal transit time is very short, and very accurate synchronization of the clock on the satellite and receiver is required for the calculation. Therefore, each GPS satellite is equipped with an atomic clock with an accuracy of 1 ns / day, and the receiver provides a time accuracy of about 50 ns [17]. To determine the time, it is enough for the receiver to receive a signal from one satellite ( tanenn ).
Thus, you can get the exact time from the GPS receiver. After all, a computer’s clock is not particularly accurate, not to mention switches, IP cameras, etc. But why do you need GPS if you can synchronize using the NTP protocol, for example, with pool.ntp.org?
You can use almost any GPS receiver - the main thing is that it supports the standard NMEA 0183 protocol. The NMEA protocol is used to transmit GPS information in simple ASCII strings over a serial interface such as RS-232. Along with the geographical coordinates, the NMEA also transmits the exact time, usually once per second.
The accuracy of the time received from a conventional GPS receiver can be up to several milliseconds (ms), however, it depends heavily on the model of the receiver: usually transmitting NMEA messages is not a priority for the receiver, so accuracy may not be very good.
If you want to provide even greater accuracy - up to several microseconds, you need to use a GPS receiver that can deliver a PPS signal (Pulse per second ). The PPS pulse is repeated once per second with very high accuracy and can be read ntpd.
Below I will consider both options: first, regular NMEA and in more detail PPS.
Windows administrators can install the ntpd port for Windows and follow the instructions in this article .
For Linux and FreeBSD, the instructions are the same:
The problem is that the receiver can send time data late. Also, do not forget about the delay in transmitting NMEA messages. In order to correct this delay, add a reliable NTP server stratum-1 with the prefer parameter to ntp.conf and restart ntpd.
For verification, we need to use the ntpq -p command. Output format:
Each line contains information about the time source, whether it is an NTP server or a local time source.
The first character in the line is the selection status: * - the selected source, + - as I understand it, the candidate for selection - the system will switch to it in case of failure of the main source, o - PPS-source, space - not working source, - xand others - “rejected” (unreliable) sources.
Next are:
remote - the host name or IP address;
refid - source ID (driver name or server address with which the source is synchronized);
stratum: 0 for the primary time source (GPS), 1 for the server connected to it, 2 for the server that synchronizes with stratum 1, etc .;
t - type: l - local clock, u - network node, etc .;
when - time from the last transmission;
poll - polling interval log 2 seconds, i.e. if poll = 4, the server polls the source every 2 4 = 16 seconds;
reach is an octal number indicating the success of the last 8 transmission attempts. For example, 0 - not a single successful attempt, 377 8= 11111111 2 - all attempts are successful. After starting ntpd, if everything is in order, the source passes the values reach 0, 1, 3, 7, 17, 37, 77, 177, 377;
delay - packet transit time;
offset - the difference between the time of the source and local;
jitter - jitter or, in other words, variance (dispersion) of the packet transit time.
Most of all, we will be interested in the symbol of the status of the choice, reach, offset and jitter. Reach should be equal to 377, and offset and jitter should be as small as possible.
Run the ntpq -p command. Wait until the offset of the NTP server is low enough.
The selected ntpd server is marked * , while our GPS receiver is marked as bad (x). Offset GPS receiver is about -956 ms. Apparently, information is transmitted about the previous second. To correct this lag, it is necessary under the line server 127.127.20.0 ... add the line:
Now you can again make GPS your preferred server. After restarting the server, * should appear before GPS_NMEA (0) .
For myself, I chose a Garmin 18x LVC receiver with a PPS pulse accuracy of ± 1 μs. This is an OEM receiver, it does not have a beautiful screen, but it is convenient to use in your own applications.
This receiver transmits data to the COM port and requires 5V, 90 mA power, so it will be convenient to power it from USB. We need a DB9 female connector or a COM cable cut in half, as well as a cut USB cable for power. The native receiver connector also needs to be cut off - this will not affect the warranty. Connection diagram:
yellow wire - with pin 1 (PPS)
white wire - with pin 2 (transmission)
green wire - with pin 3 (reception)
both black wires - with black USB cable and pin 5 (ground)
red wire - with red wire USB (+ 5V).
Desirablesolder the contacts. A simple twist may not work (however, I did not check).
Inspired by articles [2] and [3], I went even further and added a fuse, a “power” LED, a “PPS” LED and resistors for LEDs to the wiring diagram. Craftsmen-electronics engineers may well fit everything in the plug of a COM-cable, but I got a whole box.
I bought a ready-made breadboard, DB-9 and USB Type B sockets, screw terminal blocks (I did not find a native BM06B-SRSS-TBT or SM06B-SRSS-TB connector), a 1A fuse and holder. How could I soldered all this, and Epoxy stuck the connectors :)
In principle, it is not necessary to bother like that. You can simply connect the wires from GPS, COM and USB, as done here .
To improve performance and reliability, it is advisable to configure the receiver. This can be done by sending commands through the terminal (see the manual ) or using the Windows utility SNSRCFG . I chose the second way.
Connect to the receiver:
Comm → Setup: set the COM port, Baud rate: manual, 4800.
Comm → Connect
The program should load the current configuration.
Configure:
Config → Sensor Configuration
Make sure that the PPS is turned on and increase the pulse length to 200 ms.
You can also try disabling DGPS - we will not use it, and set Fix Mode = 2D - in theory, this will allow the receiver to work with three visible satellites instead of four. However, I can not guarantee that these two options affect something.
Select NMEA messages:
Config → NMEA Sentence Selection
NTPd understands GPRMC and GPGGA messages. To reduce data transfer time, I left only GPGGA.
FreeBSD has had PPS support for quite some time, so PPS is easier to configure and more accurate. Linux users can refer to the article Using a Garmin GPS 18 LVC as NTP stratum-0 on Linux 2.6 . The settings written below apply to FreeBSD.
To enable PPS support, you must rebuild the system core with the option:
The NTP server is already present in the system, but it will not be superfluous to update. For FreeBSD, we do this from the ports:
Now you need to add the lines to rc.conf:
ntpd_program points to the ntpd installation path from the ports.
Create a symbolic link to / dev / gpsX and to the / dev / ppsX device (for example, I have / dev / cuau0 -> / dev / gps0). You can use the ln command or add the appropriate lines to /etc/devfs.conf:
In the NTP documentation, it is recommended that you receive only PPS pulses from GPS for the exact clock progress, and the time itself from another stratum 1 server. To do this, add (4-5) stratum 1 servers and our PPS to /etc/ntp.conf , eg:
Driver 22 is responsible for the PPS. flag3 turns on kernel discipline . The ntpd documentation says that it is not necessary to include kernel discipline: ntpd will work more precisely if you just set minpoll 4. However, it works just the opposite: with flag3 the clock runs more precisely - so I suggest you experiment with this parameter yourself.
You can go the other way: receive both time with GPS and PPS signals:
flag1 includes PPS, flag3 - kernel discipline.
This will allow you to get time without using the Internet, but in this case, most likely you will need a correction (similar to paragraph 3.2).
After making the changes, restart ntpd:
Run the ntpq -p command (for more details, see section 3.2). If you get only a PPS signal, then the output should be something like this:
Before PPS (0) should be “o”, reach within a couple of minutes to reach 377. The remaining servers are used to obtain time.
If you also receive NMEA information from GPS, then
GPS_NMEA (0) must be preceded by * .
It will not be superfluous to check the status of PPS. This can be done using the ntpdc -c kerninfo or ntptime commands. ntptime gives a little more detailed information:
What you need to look at:
ntp_gettime () and ntp_adjtime () should return “OK”.
in status there should be flags PPSFREQ, PPSTIME, PPSSIGNAL, and there should not be PPSWANDER, PPSJITTER, PPSERROR.
jitter exceeded shows the number of pulses that arrived not quite on time. It is worth worrying if the jitter exceeded value becomes too large and the PPSJITTER flag appears in the status.
intervals - the number of calibration intervals, should increase by one time per interval seconds (in the example 256 s)
stability exceeded - the number of time corrections too large, 0 - everything is in order.
errors - the number of PPS pulses that did not arrive at all or did not arrive at the right time should not increase during operation.
stability - the less, the more stable the PPS source and server clock work. Must be less than 0.1.
jitter - jitter of PPS pulses. There should be a few microseconds (us), no more.
Always keep in mind that the GPS receiver needs some time to establish its location after turning it on: up to half an hour for older models, 45 seconds for the Garmin 18x. This time depends on how long the receiver has been turned off ( tanenn ). ntpd also takes some time to correct the clock. According to my observations: 10-20 seconds to "see" the receiver, 20-30 minutes to offset decreased to the optimum value. If your reach, after several minutes of operation, is set to 377, and offset is reduced (modulo), then everything is in order.
If ntpd does not see the receiver: reach in ntpq -p is frozen at zero, you need to carefully check the connection of the receiver to the server. Stop ntpd and open the COM port in the terminal. In FreeBSD:
where / dev / gps0 is the device file, 4800 is the data transfer rate.
If the receiver is connected correctly, NMEA messages should “sprinkle”. Make sure the receiver "sees" the satellites. In a GPGGA message, the number of satellites must be 4 or more, and one must be in front of that number. If you have GPRMC messages enabled, then after the time, the “A” symbol should go.
To exit cu, press “Enter”, then “~”, then “.”.
If NMEA messages indicate that the receiver does not see satellites, you must move it to the coverage area. It is best that the receiver can view the whole sky. My Garmin can be installed on the roof, but through experiments I stuck it in a place on the window where he sees satellites around the clock.
Examine ntpd logs. Maybe you should install the latest version of the server.
If NMEA messages do not arrive at all, make sure that the data rate from the receiver matches the expected ntpd. Verify that the COM port and receiver are connected to it.
Make sure that the total cable length from the port to the receiver does not exceed 5 m. Otherwise, you will have to bother and make a differential line to transmit the signal to protect against interference. It is recommended that the GPS cable shielding be connected to the USB cable shielding.
Again, check the connection, for example using a voltmeter or an oscilloscope. I use the DSO Nano Pocket Pocket Oscilloscope. This is how the PPS signal looks:
It is also convenient to use RealTerm : it displays both NMEA messages and the PPS signal once per second on the DCD line.
Do not use USB-COM adapters: PPS signal through them may not go or go with a delay. As a rule, the COM port is always present on the motherboard, it just may not be displayed on the wall of the case.
Make sure that you adjust the received time as described in 3.2. If the receiver settings allow you to disable all NMEA messages, except for one of: $ GPRMC, $ GPGLL, $ GPGGA, $ GPZDA or $ GPZDG. If you use only PPS, you can disable all messages.
Try disabling COM port buffering. Install in /boot/device.hints:
See if there are new firmware versions for your GPS receiver. ( Garmin 18x LVC Firmware download ) The
obvious idea is to increase the data transfer speed. But according to the ntpd documentation, this will not help us. The speed is better to leave 4800.
It may be worth trying to change the OS system timer. On FreeBSD, you can write in /etc/sysctl.conf:
My offset began to “jump” when the air conditioning in the server room began to turn on and off.
The graph of the offset PPS and temperature when the temperature is stable:
When the air conditioner is messy:
From the graph it is clear that the offset depends on the room temperature. This is apparently due to the imperfection of the timer on the server. Methods for resolving this issue are described here and here .
The "hard" way is to replace the generator on the motherboard with a temperature compensated (TXCO). But this is an option for the gurus of microelectronics and a soldering iron.
Before publishing the server on the network, read the documentation sections regarding setting permissions and limiting the number of requests .
If you want to create an NTP server for the local network, you can add the server address to the DHCP settings. However, I have a suspicion that this option does not work on Windows clients, but on * nix dchpclient you need to configure it on each machine.
Often they simply replace the time.windows.com DNS with a local NTP server :) Now, all Windows computers will be slaughtered on our server.
The list of clients can be viewed with the ntpdc -c monlist command.
Also wrote a small script for Zabbixtracking parameters reach / offset / jitter PPS and selected time server. Running the script needs to be added to zabbix_agentd.conf:
Restart the agent. On the server, respectively, you need to add these items for the NTP server. Now you can configure triggers and graphs.
In addition to NMEA, ntpd supports a host of more exotic devices (see the full list ).
It is worth noting, first of all, the ability to synchronize the clock by radio signal. For example, the RWM service operates in Russia, and the DCF77 station broadcasts from Frankfurt in Germany. DCF77 is well caught in the European part of Russia (I have a confident reception in Moscow). To make friends DCF77 and ntpd is easy, see the article . The accuracy of such a solution will be lower, however it is several times cheaper than the GPS option: you just need to buy an antenna, no radio engineering knowledge is required here.
Craftsmen can adjust the synchronization by the pulses of the Mayak radio at the end of each hour. The length of the last sixth pulse depends on the current hour. But this method will be clearly worse in accuracy than conventional time synchronization on the Internet.
The exact time can be obtained from the mobile operator ( hellt ). This "feature" is called NITZ. However, not all operators and not all GSM devices support it. I checked my GSM modems Siemens MC55 and Arduino GPRS-shield on a SIM900 chip - there are no such AT commands in these devices.
There are also ready-made NTP servers with GPS or GLONASS sensors, but they, of course, are much more expensive.
ntp1.vniiftri.ru
ntp2.vniiftri.ru
ntp4.vniiftri.ru
ntp.mobatime.ru
ntp0.ntp-servers.net
ntp1.ntp-servers.net
ntp2.ntp-servers.net
ntp0.zenon.net
gps-time. prao.psn.ru
ntp.ix.ru
I will try to make my server open as soon as I figure out the permissions. stratum1.net .
Sorted by "utility":
UPD: the server is available at stratum1.net Web face: www.stratum1.net .
A similar topic on the hub already ran , but I believe that the topic should be disclosed in much more detail: the author omitted many important details.
1. A bit of theory
According to GPS World magazine, more than a billion GPS receivers are currently in use in the world, and more than 90% of them are used only to receive accurate time signals. [19]
To determine your own three-dimensional coordinates, the GPS receiver calculates the distance to 4 satellites. This distance is calculated by measuring the travel time of the radio signal from the satellite. Because the speed of light is 3 × 10 8 m / s, the signal transit time is very short, and very accurate synchronization of the clock on the satellite and receiver is required for the calculation. Therefore, each GPS satellite is equipped with an atomic clock with an accuracy of 1 ns / day, and the receiver provides a time accuracy of about 50 ns [17]. To determine the time, it is enough for the receiver to receive a signal from one satellite ( tanenn ).
Thus, you can get the exact time from the GPS receiver. After all, a computer’s clock is not particularly accurate, not to mention switches, IP cameras, etc. But why do you need GPS if you can synchronize using the NTP protocol, for example, with pool.ntp.org?
- if the system does not have Internet access;
- if you need high accuracy of time - units of microseconds (microseconds);
- if you need to synchronize a distributed system from a reliable source of time;
- just for fun :)
2. GPS receiver
You can use almost any GPS receiver - the main thing is that it supports the standard NMEA 0183 protocol. The NMEA protocol is used to transmit GPS information in simple ASCII strings over a serial interface such as RS-232. Along with the geographical coordinates, the NMEA also transmits the exact time, usually once per second.
The accuracy of the time received from a conventional GPS receiver can be up to several milliseconds (ms), however, it depends heavily on the model of the receiver: usually transmitting NMEA messages is not a priority for the receiver, so accuracy may not be very good.
If you want to provide even greater accuracy - up to several microseconds, you need to use a GPS receiver that can deliver a PPS signal (Pulse per second ). The PPS pulse is repeated once per second with very high accuracy and can be read ntpd.
Below I will consider both options: first, regular NMEA and in more detail PPS.
3. Getting time from GPS (without PPS)
3.1 Configuring GPS and ntpd
Windows administrators can install the ntpd port for Windows and follow the instructions in this article .
For Linux and FreeBSD, the instructions are the same:
- Connect the GPS receiver to the server's COM port (the USB adapter should also work).
- Create a symbolic link / dev / gpsX to the device (for example, I have / dev / cuau0 -> / dev / gps0).
- In ntp.conf add the line
server 127.127.20.0 mode 0 prefer iburst minpoll 4 maxpoll 6
Line 127.127.20. 0 means we are using a local time source, driver 20 (NMEA Generic), device / dev / gps 0 .
If your device operates at a speed other than 4800 bps, you need to set the speed using the mode command: 0 - 4800 bps (by default, you can not specify), 16 - 9600, 32 - 19200, etc.
iburst - speeds up initialization;
minpoll n - minimum polling interval of 2 n seconds, minimum 4, i.e. 16 s;
maxpoll n - maximum polling interval of 2 n seconds, maximum 17, about a day and a half;
prefer - the preferred server.
More details can be found in the excellent ntpd documentation.. - Restart the server. Run ntpq -p. The list should contain the GPS_NMEA (0) line ... If this did not happen, refer to item 5 “Possible problems”.
3.2 Verification and correction
The problem is that the receiver can send time data late. Also, do not forget about the delay in transmitting NMEA messages. In order to correct this delay, add a reliable NTP server stratum-1 with the prefer parameter to ntp.conf and restart ntpd.
For verification, we need to use the ntpq -p command. Output format:
Each line contains information about the time source, whether it is an NTP server or a local time source.
The first character in the line is the selection status: * - the selected source, + - as I understand it, the candidate for selection - the system will switch to it in case of failure of the main source, o - PPS-source, space - not working source, - xand others - “rejected” (unreliable) sources.
Next are:
remote - the host name or IP address;
refid - source ID (driver name or server address with which the source is synchronized);
stratum: 0 for the primary time source (GPS), 1 for the server connected to it, 2 for the server that synchronizes with stratum 1, etc .;
t - type: l - local clock, u - network node, etc .;
when - time from the last transmission;
poll - polling interval log 2 seconds, i.e. if poll = 4, the server polls the source every 2 4 = 16 seconds;
reach is an octal number indicating the success of the last 8 transmission attempts. For example, 0 - not a single successful attempt, 377 8= 11111111 2 - all attempts are successful. After starting ntpd, if everything is in order, the source passes the values reach 0, 1, 3, 7, 17, 37, 77, 177, 377;
delay - packet transit time;
offset - the difference between the time of the source and local;
jitter - jitter or, in other words, variance (dispersion) of the packet transit time.
Most of all, we will be interested in the symbol of the status of the choice, reach, offset and jitter. Reach should be equal to 377, and offset and jitter should be as small as possible.
Run the ntpq -p command. Wait until the offset of the NTP server is low enough.
remote refid st t when poll reach delay offset jitter =================================================== ============================== * mail.mobatime.r .DTS. 1 u 5 377 1 14.894 -3.198 0.490 xGPS_NMEA (0) .GPS. 0 l 2 377 7 0.000 -955.90 31.554
The selected ntpd server is marked * , while our GPS receiver is marked as bad (x). Offset GPS receiver is about -956 ms. Apparently, information is transmitted about the previous second. To correct this lag, it is necessary under the line server 127.127.20.0 ... add the line:
fudge 127.127.20.0 time2 0.956
Now you can again make GPS your preferred server. After restarting the server, * should appear before GPS_NMEA (0) .
4. Getting time from GPS with PPS signals
4.1 Connecting your Garmin 18x LVC receiver
For myself, I chose a Garmin 18x LVC receiver with a PPS pulse accuracy of ± 1 μs. This is an OEM receiver, it does not have a beautiful screen, but it is convenient to use in your own applications.
This receiver transmits data to the COM port and requires 5V, 90 mA power, so it will be convenient to power it from USB. We need a DB9 female connector or a COM cable cut in half, as well as a cut USB cable for power. The native receiver connector also needs to be cut off - this will not affect the warranty. Connection diagram:
yellow wire - with pin 1 (PPS)
white wire - with pin 2 (transmission)
green wire - with pin 3 (reception)
both black wires - with black USB cable and pin 5 (ground)
red wire - with red wire USB (+ 5V).
Desirablesolder the contacts. A simple twist may not work (however, I did not check).
Inspired by articles [2] and [3], I went even further and added a fuse, a “power” LED, a “PPS” LED and resistors for LEDs to the wiring diagram. Craftsmen-electronics engineers may well fit everything in the plug of a COM-cable, but I got a whole box.
I bought a ready-made breadboard, DB-9 and USB Type B sockets, screw terminal blocks (I did not find a native BM06B-SRSS-TBT or SM06B-SRSS-TB connector), a 1A fuse and holder. How could I soldered all this, and Epoxy stuck the connectors :)
In principle, it is not necessary to bother like that. You can simply connect the wires from GPS, COM and USB, as done here .
4.2 Configuring Garmin 18x LVC
To improve performance and reliability, it is advisable to configure the receiver. This can be done by sending commands through the terminal (see the manual ) or using the Windows utility SNSRCFG . I chose the second way.
Connect to the receiver:
Comm → Setup: set the COM port, Baud rate: manual, 4800.
Comm → Connect
The program should load the current configuration.
Configure:
Config → Sensor Configuration
Make sure that the PPS is turned on and increase the pulse length to 200 ms.
You can also try disabling DGPS - we will not use it, and set Fix Mode = 2D - in theory, this will allow the receiver to work with three visible satellites instead of four. However, I can not guarantee that these two options affect something.
Select NMEA messages:
Config → NMEA Sentence Selection
NTPd understands GPRMC and GPGGA messages. To reduce data transfer time, I left only GPGGA.
4.3 Configuring FreeBSD and ntpd
FreeBSD has had PPS support for quite some time, so PPS is easier to configure and more accurate. Linux users can refer to the article Using a Garmin GPS 18 LVC as NTP stratum-0 on Linux 2.6 . The settings written below apply to FreeBSD.
To enable PPS support, you must rebuild the system core with the option:
options PPS_SYNC
The NTP server is already present in the system, but it will not be superfluous to update. For FreeBSD, we do this from the ports:
cd / usr / ports / net / ntp make install clean
Now you need to add the lines to rc.conf:
ntpd_enable = "YES" ntpd_program = "/ usr / local / bin / ntpd"
ntpd_program points to the ntpd installation path from the ports.
Create a symbolic link to / dev / gpsX and to the / dev / ppsX device (for example, I have / dev / cuau0 -> / dev / gps0). You can use the ln command or add the appropriate lines to /etc/devfs.conf:
link cuau0 gps0 link cuau0 pps0
In the NTP documentation, it is recommended that you receive only PPS pulses from GPS for the exact clock progress, and the time itself from another stratum 1 server. To do this, add (4-5) stratum 1 servers and our PPS to /etc/ntp.conf , eg:
server ntp.mobatime.ru prefer iburst maxpoll 9 server ntp1.vniiftri.ru iburst maxpoll 9 server ntp2.vniiftri.ru iburst maxpoll 9 server 127.127.22.0 minpoll 4 fudge 127.127.22.0 flag3 1
Driver 22 is responsible for the PPS. flag3 turns on kernel discipline . The ntpd documentation says that it is not necessary to include kernel discipline: ntpd will work more precisely if you just set minpoll 4. However, it works just the opposite: with flag3 the clock runs more precisely - so I suggest you experiment with this parameter yourself.
You can go the other way: receive both time with GPS and PPS signals:
server 127.127.20.0 prefer minpoll 4 fudge 127.127.20.0 flag1 1 flag3 1
flag1 includes PPS, flag3 - kernel discipline.
This will allow you to get time without using the Internet, but in this case, most likely you will need a correction (similar to paragraph 3.2).
After making the changes, restart ntpd:
/etc/rc.d/ntpd restart
Run the ntpq -p command (for more details, see section 3.2). If you get only a PPS signal, then the output should be something like this:
remote refid st t when poll reach delay offset jitter =================================================== ============================== xnut.rsuitb.ru 5.89.176.137 3 u 21 64 377 2.074 41.522 5.869 + mx.kr-pro.ru 62.117.76.138 2 u 34 64 377 4.167 0.336 0.423 + wooster.rojer.p 195.54.192.55 3 u 25 64 377 70.609 9.523 0.262 x193.124.4.177 7.123.225.33 3 u 21 64 377 2.133 56.525 9.041 ntp1.vniiftri.r .INIT. 16 u - 512 0 0.000 0.000 0.000 xntp2.vniiftri.r .PPS. 1 u 39 64 377 73.585 -14.117 0.189 * mail.mobatime.r .DTS. 1 u 17 64 377 15.223 0.147 0.843 oPPS (0) .PPS. 0 l 5 16 377 0.000 -0.001 0.002
Before PPS (0) should be “o”, reach within a couple of minutes to reach 377. The remaining servers are used to obtain time.
If you also receive NMEA information from GPS, then
remote refid st t when poll reach delay offset jitter =================================================== ============================== * GPS_NMEA (0) .GPS. 0 l 11 16 17 0.000 -9.795 14.537
GPS_NMEA (0) must be preceded by * .
It will not be superfluous to check the status of PPS. This can be done using the ntpdc -c kerninfo or ntptime commands. ntptime gives a little more detailed information:
ntptime ntp_gettime () returns code 0 (OK) time d24065e8.9067dfac Wed, Oct 12 2011 23: 15: 52.564, (.564085545), maximum error 4739 us, estimated error 1 us, TAI offset 0 ntp_adjtime () returns code 0 (OK) modes 0x0 (), offset 2.004 us, frequency -28.979 ppm, interval 256 s, maximum error 4739 us, estimated error 1 us, status 0x2107 (PLL, PPSFREQ, PPSTIME, PPSSIGNAL, NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, pps frequency -28.979 ppm, stability 0.019 ppm, jitter 1.434 us, intervals 313, jitter exceeded 195, stability exceeded 0, errors 1.
What you need to look at:
ntp_gettime () and ntp_adjtime () should return “OK”.
in status there should be flags PPSFREQ, PPSTIME, PPSSIGNAL, and there should not be PPSWANDER, PPSJITTER, PPSERROR.
jitter exceeded shows the number of pulses that arrived not quite on time. It is worth worrying if the jitter exceeded value becomes too large and the PPSJITTER flag appears in the status.
intervals - the number of calibration intervals, should increase by one time per interval seconds (in the example 256 s)
stability exceeded - the number of time corrections too large, 0 - everything is in order.
errors - the number of PPS pulses that did not arrive at all or did not arrive at the right time should not increase during operation.
stability - the less, the more stable the PPS source and server clock work. Must be less than 0.1.
jitter - jitter of PPS pulses. There should be a few microseconds (us), no more.
5. Possible problems and debugging
5.1 Don't panic!
Always keep in mind that the GPS receiver needs some time to establish its location after turning it on: up to half an hour for older models, 45 seconds for the Garmin 18x. This time depends on how long the receiver has been turned off ( tanenn ). ntpd also takes some time to correct the clock. According to my observations: 10-20 seconds to "see" the receiver, 20-30 minutes to offset decreased to the optimum value. If your reach, after several minutes of operation, is set to 377, and offset is reduced (modulo), then everything is in order.
5.2 ntpd does not see the receiver
If ntpd does not see the receiver: reach in ntpq -p is frozen at zero, you need to carefully check the connection of the receiver to the server. Stop ntpd and open the COM port in the terminal. In FreeBSD:
cu -l / dev / gps0 -s 4800
Connected
$ GPGGA, 160042.5545.7890, N, 03722.6113, E, 1,08,0.9,188.3, M, 13.3, M ,, * 47
$ GPGGA, 160043.5545.7890, N, 03722.6114, E, 1.08.0.9.188.3, M, 13.3, M ,, * 41
| hhmmss | --- latitude-- | --longitude --- | ^^
| number of satellites
...
where / dev / gps0 is the device file, 4800 is the data transfer rate.
If the receiver is connected correctly, NMEA messages should “sprinkle”. Make sure the receiver "sees" the satellites. In a GPGGA message, the number of satellites must be 4 or more, and one must be in front of that number. If you have GPRMC messages enabled, then after the time, the “A” symbol should go.
To exit cu, press “Enter”, then “~”, then “.”.
If NMEA messages indicate that the receiver does not see satellites, you must move it to the coverage area. It is best that the receiver can view the whole sky. My Garmin can be installed on the roof, but through experiments I stuck it in a place on the window where he sees satellites around the clock.
Examine ntpd logs. Maybe you should install the latest version of the server.
If NMEA messages do not arrive at all, make sure that the data rate from the receiver matches the expected ntpd. Verify that the COM port and receiver are connected to it.
Make sure that the total cable length from the port to the receiver does not exceed 5 m. Otherwise, you will have to bother and make a differential line to transmit the signal to protect against interference. It is recommended that the GPS cable shielding be connected to the USB cable shielding.
5.3 ntpd does not see the PPS signal
Again, check the connection, for example using a voltmeter or an oscilloscope. I use the DSO Nano Pocket Pocket Oscilloscope. This is how the PPS signal looks:
It is also convenient to use RealTerm : it displays both NMEA messages and the PPS signal once per second on the DCD line.
Do not use USB-COM adapters: PPS signal through them may not go or go with a delay. As a rule, the COM port is always present on the motherboard, it just may not be displayed on the wall of the case.
5.4 Large offset / jitter
Make sure that you adjust the received time as described in 3.2. If the receiver settings allow you to disable all NMEA messages, except for one of: $ GPRMC, $ GPGLL, $ GPGGA, $ GPZDA or $ GPZDG. If you use only PPS, you can disable all messages.
Try disabling COM port buffering. Install in /boot/device.hints:
hint.sio.0.flags = "0x2"
See if there are new firmware versions for your GPS receiver. ( Garmin 18x LVC Firmware download ) The
obvious idea is to increase the data transfer speed. But according to the ntpd documentation, this will not help us. The speed is better to leave 4800.
It may be worth trying to change the OS system timer. On FreeBSD, you can write in /etc/sysctl.conf:
kern.timecounter.hardware = i8254
My offset began to “jump” when the air conditioning in the server room began to turn on and off.
The graph of the offset PPS and temperature when the temperature is stable:
When the air conditioner is messy:
From the graph it is clear that the offset depends on the room temperature. This is apparently due to the imperfection of the timer on the server. Methods for resolving this issue are described here and here .
The "hard" way is to replace the generator on the motherboard with a temperature compensated (TXCO). But this is an option for the gurus of microelectronics and a soldering iron.
6. Preparing the NTP server for use
Before publishing the server on the network, read the documentation sections regarding setting permissions and limiting the number of requests .
If you want to create an NTP server for the local network, you can add the server address to the DHCP settings. However, I have a suspicion that this option does not work on Windows clients, but on * nix dchpclient you need to configure it on each machine.
Often they simply replace the time.windows.com DNS with a local NTP server :) Now, all Windows computers will be slaughtered on our server.
The list of clients can be viewed with the ntpdc -c monlist command.
Also wrote a small script for Zabbixtracking parameters reach / offset / jitter PPS and selected time server. Running the script needs to be added to zabbix_agentd.conf:
UserParameter = ntp.pps_jitter, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php pps jitter UserParameter = ntp.pps_offset, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php pps offset UserParameter = ntp.pps_reach, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php pps reach UserParameter = ntp.source_jitter, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php source jitter UserParameter = ntp.source_offset, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php source offset UserParameter = ntp.source_reach, / usr / local / bin / php /usr/local/share/zabbix/ntp_zabbix.php source reach
Restart the agent. On the server, respectively, you need to add these items for the NTP server. Now you can configure triggers and graphs.
7. Other methods of time synchronization
In addition to NMEA, ntpd supports a host of more exotic devices (see the full list ).
It is worth noting, first of all, the ability to synchronize the clock by radio signal. For example, the RWM service operates in Russia, and the DCF77 station broadcasts from Frankfurt in Germany. DCF77 is well caught in the European part of Russia (I have a confident reception in Moscow). To make friends DCF77 and ntpd is easy, see the article . The accuracy of such a solution will be lower, however it is several times cheaper than the GPS option: you just need to buy an antenna, no radio engineering knowledge is required here.
Craftsmen can adjust the synchronization by the pulses of the Mayak radio at the end of each hour. The length of the last sixth pulse depends on the current hour. But this method will be clearly worse in accuracy than conventional time synchronization on the Internet.
The exact time can be obtained from the mobile operator ( hellt ). This "feature" is called NITZ. However, not all operators and not all GSM devices support it. I checked my GSM modems Siemens MC55 and Arduino GPRS-shield on a SIM900 chip - there are no such AT commands in these devices.
There are also ready-made NTP servers with GPS or GLONASS sensors, but they, of course, are much more expensive.
List of working Russian public servers statum 1
ntp1.vniiftri.ru
ntp2.vniiftri.ru
ntp4.vniiftri.ru
ntp.mobatime.ru
ntp0.ntp-servers.net
ntp1.ntp-servers.net
ntp2.ntp-servers.net
ntp0.zenon.net
gps-time. prao.psn.ru
ntp.ix.ru
Literature
Sorted by "utility":
- Ntpd documentation
- Adding a FreeBSD NTP server based on an GPS 18 LVC device
- Using a Garmin GPS 18 LVC as NTP stratum-0 on Linux 2.6
- NTP Reference Clocks Using FreeBSD 7.0
- Stratum 1 NTP, Garmin GPS 18 LVC on FreeBSD 8.0 ( mirror )
- Time synchronization with a Garmin GPS
- PPS Synchronization (NTP FAQ)
- Stratum one time servers
- Prof. David R. Andersen: NTP Temperature Compensation
- NTP temperature compensation
- Network Time Protocol server using PC gnu / linux and freebsd
- LinuxPPS NTPD support
- The kernel discipline
- Why does the clock on my computer keep incorrect time? (FreeBSD FAQ)
- NTP Precision Time System
- The Network Time Protocol (NTP) at the end provides links to RFCs and mailing lists.
- Five ideas behind GPS
- DFC77 receiver
- What is the danger of cheap GPS jammers