USB GPS with PPS and pretty cheap too

Server operators
1

Hi all,

I have been looking for a PPS GPS for quite some time.
Most of them are expensive and on AliExpress none of them have PPS.

However, after a long search I found one that is really cheap, about 50~60 Euro/USD depending on shipping.
But beware, when they ship to Europe you will probably charged extra import taxes, for me in Belgium that was 41 euro extra.
Anyway, it’s still very cheap.

You can find the device here:

https://www.etsy.com/nl/transaction/1790998820

You only need to tell GPSD that the box registers as /dev/ttyUSBx (USB0 in my case).

I use Chrony and configured it like this:

refclock SHM 0 refid NMEA poll 4 precision 1e-3 offset 0.1256 delay 0.2
refclock SHM 1 refid PPS poll 4 precision 1e-9 lock NMEA prefer

When you run it, you can expect this:

MS Name/IP address Stratum Poll Reach LastRx Last sample
#- NMEA 0 4 377 24 +1000us[+1024us] +/- 101ms
#* PPS 0 4 377 22 +264us[ +287us] +/- 22us

Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
NMEA 6 3 80 +16.270 108.450 +2372us 752us
PPS 64 56 1008 +0.006 0.263 +55ns 193us

chronyc tracking
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Thu Feb 13 14:33:01 2020
System time : 0.000005683 seconds fast of NTP time
Last offset : -0.000005592 seconds
RMS offset : 0.000012070 seconds
Frequency : 28.518 ppm fast
Residual freq : +0.001 ppm
Skew : 0.323 ppm
Root delay : 0.000000 seconds
Root dispersion : 0.000054 seconds
Update interval : 16.0 seconds
Leap status : Normal

The USB bus is a bit slower then RS232, but hey, it works and works well.

I have been searching for more then a year to find something on USB that is not that expensive.
I believe this is the one.

Also, Steve bought one too, he can give far better details with his programs and charts.

2

Your link points to a transaction page behind a login, not to a product page.

3

Sorry, my bad, try this one:

4

According to the datasheet the PPS signal is only wired to an external PS/2 connector. The USB doesn’t have a PPS functionality. I guess the PPS signal is software emulated over USB? That would cause the large standard deviation chronyc shows for the PPS signal.

5

Hi Lammert,

The USB chip is actual a prolific RS232<->USB converter and seen as a “real” RS-232 port.
As such it provides the Carrier-Detect signal.

root@server:~# ppscheck /dev/ttyUSB0
Seconds nanoSecs Signals
1581890648 000235020
1581890648 100208790 TIOCM_CD
1581890649 000190026
1581890649 100181260 TIOCM_CD
1581890650 000163117
1581890650 100188096 TIOCM_CD

The deviation is less then 1ms, however Chrony is able to work out the actual precision:

NMEA 14 7 208 -0.960 22.678 +9303us 1172us
PPS 64 56 1006 -0.000 0.290 -2ns 196us

The offset is -2ns, that is a real PPS-signal.

https://www.ntppool.org/scores/77.109.90.72

root@server:~# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 040: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

I’m happy with it and Chrony seems to be spot on time.
I have never been this stable or more precise.

Also Steven has bought one too, he’s testing and found the same values.

Bas.

6

Didn’t you see the rather large jitter? A real GPS PPS time source should have both offset and jitter in < 10 microsecond level. People at GPSD had some words about the quality of PPS signals: 1PPS quality issues
In conclusion: GPS PPS through USB exists and works, but you can achieve better result if you have other method of connection, like real serial port or GPIO.

1 Like
7

PPS/serial or GPIO will be superior, agreed. However, the PPS/USB may be better than relying on remote NTP servers.

My Rpi4 has both a Navisys/USB and a Uputronics Raspberry Pi+ GPS Expansion Board (PPS/GPIO). I can compare the two. Running under chrony the Navisys has an average offset of ~670 usec with jitter of maybe 150 usec. [The USB PPS has a jitter of 1 msec, as expected for USB1 devices.]. Chrony can compensate for the 670 usec offset in the configuration file.

Testing is still in progress.

8

oh guys. ANY USB device use “packet data exchange” over usb bus may give an unpredictable delay and not so accurate as “analog/diginal” interface.

Many cheap “chinese” recievers on Aliexpress/eBay builded on uBlox GNSS. uBlox chip have many interfaces - RS232,USB, GPIO and separate PPS. If you use Raspberry it is the best cheap/simle solution from Aliexpress/eBay with buildin ceramic antenna. (if you select uBlox, then look on -8 series chips. It can run GPS+GLONASS+Gallileo at the same time and it’s doubles the satellite view. uBlox 7 mode cheap but cannot use many system at the same time).

uBlox also have special -T series chips for timekeeping, (after initial survey they can run in “stacionary” mode win only one satellite in view and more accuracy). -T series in soldered on some special uBlox boards like LEA-5T, LEA-6T wint RS232 interface. You can bougth this boards + antenna on eBay and I guess this is the best solution for timekepping for this price.

9

But the Navisys isn’t an very cheap no-name Chinese USB device.

Steven measured it and came to the conclusion that NTP-clients will not notice any wobble.
Whereas they do notice with other non-PPS USB devices.

It gives very predictable time and works very well.
I do not have RS-232 in my Intel I5-4440 server at 3GHz.

As this devices uses RS-232 > USB, it works.

I was sceptical too, but turned out to be a good device and not too expensive.

More info: http://www.navisys.com.tw/products/GPS&GNSS_receivers/flyer/GR-701_flyer-150703.pdf
And here: GPSD Time Service HOWTO

All the previous figures assume you’re using PPS delivered over RS232. USB GPS receivers that deliver 1PPS are rare, but do exist. Notably, there’s the Navisys GR-601W/GR-701W/GR-801W [MACX-1]. In case these devices go out of production it’s worth noting that they are a trivial modification of the stock two-chip-on-a-miniboard commodity-GPS-receiver design of engine plus USB-to-serial adapter; the GR-[678]01W wires a u-blox 6/7/8 to a Prolific Logic PL23203. To get 1PPS out, this design just wires the 1PPS pin from the GPS engine to the Carrier Detect pin on the USB adapter. (This is known as the “Macx-1 mod”.)

If you do not want to spend too much but still want a pretty-high-precission, this device is value for money.

It’s that simple.

1 Like
10

Trouble in usb bus. It’s not analog/digital and very complex. Data pack to "packets’ and packets goes throught bus. Bus transit times are unpredictable and unwarranted. So, If any device (theoretically even mouse or keyboard or external HDD) overload bus we can get any result. But if you don’t overload bus (for example, reciever connected to separate timeserver PC), I guess all will looks very good. As an option you can use PCI-E RS232 card. In theory PCI bus can be overloaded too :slight_smile:

11

It’s connected to USB3. USB3 is a different animal then previous USB-versions.
It can trigger interrupts instead of polling.
The only thing I do not know if the trigger is also used for older devices.
For USB-ports 1.x-2.x you are right, they are unpredictable.
USB3.x changed all that.

Stuff like this is different:

•USB 2.0 uses a polling model while SuperSpeed uses asynchronous notifications.

Also:

USB 2.0 style polling has been replaced with asynchronous notifications. The SuperSpeed transaction is initiated by the host making a request followed by a response from the device. If the device can honor the request, it either accepts or sends data. If the endpoint is halted, the device shall respond with a STALL handshake. If it cannot honor the request due to lack of buffer space or data, it responds with a Not Ready (NRDY) to tell the host that it is not able to process the request at this time. When the device can honor the request, it will send an Endpoint Ready (ERDY) to the host which will then reschedule the transaction.

Does this also work for older USB devices? Maybe, I do not know, it might.

Maybe USB3.x is the end of the good-old RS232…be honest, it’s time it would be replaced.

1 Like
12

Hi Umike,

Well I’m still at about 10usec and it doesn’t vary much.
However by reading more about USB then I ever wanted to know.
It puzzled me how accurate it really is and how Chrony knows this:

root@server:~# chronyc tracking
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Thu Feb 20 15:54:19 2020
System time : 0.000008806 seconds fast of NTP time
Last offset : +0.000014283 seconds
RMS offset : 0.000015548 seconds
Frequency : 28.451 ppm fast
Residual freq : +0.007 ppm
Skew : 0.302 ppm
Root delay : 0.000000 seconds
Root dispersion : 0.000055 seconds
Update interval : 16.0 seconds
Leap status : Normal

and

root@server:~# chronyc sourcestats
210 Number of sources = 9
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
NMEA 12 10 176 +4.507 18.708 +3300us 669us
PPS 64 57 1008 +0.001 0.304 +11ns 198us

It knows the offset is 11nsecs, how can it know it’s 11ns?
If the jitter was the problem it could not know but it does.

Then I noticed something in the USB specs and that is USB-packages are time-stamped!
So even when there is jitter it knows the exact jitter and work out the exact time.

RS232 is not time-stamped, it request an IRQ and expects to be processed.

I could be wrong, but in my opinion they only thing that can make it off is if the system-clock is off and thus the timestamp is off.
How else would Chrony know my PPS is about +/-50nsecs offset?

As time is a stable path in the future, there is no need for it to be real-time in the present, because you can calculate with past data what the current exact time should be.

I mean, it is known where time is heading as has been a stable factor for centuries :slight_smile:

1 Like
13

NTP time is the software time loop inside the chronyd daemon based on the external clocks (PPS, NTP packets etc). System time is the time of the operating system. This measure mainly tells that the operating system clock has synchronized with the software clock in the chronyd daemon, not that chrony absolutely matches the time of the upstream time source.

For comparison, this is result on one of my Stratum 2 servers. There is no way this server runs at 30 microseconds accuracy compared to absolute time. The best upstream server is at 10 millisecond distance with a jitter of 500 microseconds.

System time : 0.000030078 seconds fast of NTP time

14

Yes it can be very accurate, just read the protocol:

NTP provides the protocol mechanisms to synchronize time in principle
to precisions in the order of nanoseconds while preserving a
non-ambiguous date, at least for this century. The protocol includes
provisions to specify the precision and estimated error of the local
clock and the characteristics of the reference clock to which it may
be synchronized. However, the protocol itself specifies only the
data representation and message formats and does not specify the
synchronizing algorithms or filtering mechanisms.

Other mechanisms have been specified in the Internet protocol suite
to record and transmit the time at which an event takes place,
including the Daytime protocol [8] and IP Timestamp option [9]. The
NTP is not meant to displace either of these mechanisms. Additional
information on network time synchronization can be found in the
References at the end of this document. An earlier synchronization
protocol is discussed in [3] and synchronization algorithms in [2],
[5], [10] and [12]. Experimental results on measured roundtrip delays
and clock offsets in the Internet are discussed in [4] and [11]. A
comprehensive mathematical treatment of clock synchronization can be
found in [1].

Here is the entire document on the protocol:

It means that NTP has the ability to know when the time was send in the past and it knows when it arrived.
As such it should be able to calculate a very high precision.

And a nice schematic of the structure:

From these four timestamps the system can calculate two values:

  • The “Delay” , the time that was needed to transfer the packet in the network, and
  • the “Offset” , the time difference of the two computer clocks.

From these documents I make that NTP is pretty precise at giving the exact time.
Of course the further away from stratum0 the more error-time.

Or I’m completely wrong, has happened before :slight_smile:

15

Yes, the protocol allows this high precision, it is designed that way. When you have in practice only millisecond accuracy and not microsecond, the imprecision is due to the underlying infrastructure, not the NTP protocol itself.

1 Like
16

So how come Chrony is able to present these?

.-- Source mode ‘^’ = server, ‘=’ = peer, ‘#’ = local clock.
/ .- Source state '’ = current synced, ‘+’ = combined , ‘-’ = not combined,
| / ‘?’ = unreachable, ‘x’ = time may be in error, ‘~’ = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | |
MS Name/IP address Stratum Poll Reach LastRx Last sample
#- GPS1 0 4 377 21 +5760us[+5758us] +/- 101ms
# PPS 0 4 377 22 -219us[ -221us] +/- 62us
#- GPS2 0 4 377 21 -68ms[ -68ms] +/- 101ms
^- ntp-main-2.oma.be 1 9 377 508 +2149us[+2140us] +/- 8973us
^- ntp2.rrze.uni-erlangen.de 1 8 377 313 -5677us[-5697us] +/- 19ms
^- d9649312.static.ziggozak> 1 8 357 52 +2402us[+2402us] +/- 17ms
^- 194.80.204.184 1 9 357 52 -504us[ -504us] +/- 15ms
^- ntp4.bit.nl 1 8 377 256 -2783us[-2809us] +/- 12ms
^- ntp0.nl.uu.net 1 8 377 121 -118us[ -115us] +/- 9167us
^- ntp1.nl.uu.net 1 9 367 185 -219us[ -264us] +/- 8544us

These are microsecond-corrected-offset-timevalues.

Or even worse:

210 Number of sources = 10
.- Number of sample points in measurement set.
/ .- Number of residual runs with same sign.
| / .- Length of measurement set (time).
| | / .- Est. clock freq error (ppm).
| | | / .- Est. error in freq.
| | | | / .- Est. offset.
| | | | | | On the -.
| | | | | | samples.
| | | | | | |
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
GPS1 36 19 559 -2.329 4.213 +3497us 1035us
PPS 64 56 1009 +0.007 0.303 +68ns 200us
GPS2 13 7 191 +4.206 15.216 -68ms 705us
ntp-main-2.oma.be 27 12 58m +0.368 0.754 +826us 818us
ntp2.rrze.uni-erlangen.de 23 13 61m -0.065 0.277 -5695us 329us
d9649312.static.ziggozak> 15 8 61m -0.308 0.690 +1221us 572us
194.80.204.184 22 12 56m -0.374 1.138 -1013us 1407us
ntp4.bit.nl 23 19 58m +0.026 0.207 -2664us 203us
ntp0.nl.uu.net 22 13 47m -0.009 0.343 -199us 380us
ntp1.nl.uu.net 25 14 54m -0.045 0.220 -88us 238us
root@server:~#

How does it know the estimated offset if it isn’t supposed to know the correct time?
If you know the (almost) exact difference, it’s not hard to predict the exact time in the future.
The one thing that is stable in NTP is the timeline, it’s stable for hundreds of years, and we already know where it’s going to be over 1 million years or more.
The only problem, in my opinion, is that the greater the offset (and delay) is, the less accurate the prediction will be.
However, the samples do not have to be realtime, as long as they are realtime-stamped, they can arrive after 1 minute and still let you calculate the exact time.
Sure there is a bit of slack here and there, but it can’t be as bad as milliseconds, else it wouldn’t know my PPS offset of 68ns. Or the other servers being off for -88us.

Timekeeping for the future can be calculated in the past, with past samples.
RS232 is not timestamped, so must be done realtime, USB and TCP/IP is timestamped.

When I check sourcestats, they always take a lot of samples before you get numbers, they do not show or change on 1 sample alone.

Sorry, I do not buy the millisecond accuracy as Chrony shows different all over the place.

17

Sure, stratum one is more accurate than higher stratums. No NTP traffic involved. I see regularly higher stratum server ~3 msec offset just because of asymmetric IP routes.

1 Like
18

Sorry that is not true. A higher stratum is just further down the hierarchy.
It does not mean it has less accurate time.
It only means the conditions to keep time are less strict the higher the number and NTP/Chrony have less faith in it over a lower stratum.
Ergo, it has to “work” harder to earn trust to deliver the correct time.
That is all there is too it.

If NTP has 3 servers, it will trust Stratum1 over Stratum2 over Stratum3.
But as soon as Stratum2 or 3 tick better then Stratum1 it will push Stratum1 aside and move.

However, your server moves up a stratum when that happens.

But it still gives the correct time.

19

This GPS is spot on time.

I never would needed to buy it as a normal GPS is pretty good at keeping time.

It turned out several Intel CPU’s are causing all the problems.
They simply can’t tick right, complaints are all over the place.

A stupid RaspberryPi of 50 bucks tick perfect, all day long and UDP packets are lost 1 out of 500 or less.

If your blue-line looks like a Jojo and you have an Intel, the Intel is probably the problem.

Update: Wrong assumption as RPi4 and Sparc show it also

20

@Bas, you are making a lot of sense and showing data to back it up. keep it up. it’s easy to point out GPIO or RS-232 is better, which it is, but so far your USB3 solution looks pretty solid.

I’m interested in the easy, low cost solution that does not involve Raspberry Pi. I have 3 RPI’s in use now but don’t want to use those. I’m interested in making my Stratum 3 time server (on a PC) provide better accuracy without soldering or getting an RS232 board to get GPS data into the PC.

What you’ve described seems to work pretty well with Chrony and USB3.

Now, where’s the low cost USB-3 GPS unit with PPS?

The etsy link above is dated and nothing available. It’s a difficult search for ublox-7, PPS, and USB-3

These two devices have pps pins but do not have USB3: