Sorry, I missed how chrony is getting the 1PPS data? Is that wired up using your front panel 1PPS signal to, e.g., some GPIO input, or are you using the DCD signal on the serial port? Note that you'll likely see a bunch of jitter on the 1PPS signal due to how USB transfers work, wasting some of the precision available to you with the 1PPS signal from most GPS receivers. On the other hand, if you're only worried about sub-millisecond accuracy, maybe don't bother? You can make yourself crazy chasing the microseconds here.. In that regime, you need a GPS receiver fancy enough to specify the cable length delay to the antenna to account for those extra nanoseconds. Thanks for the making the video about your project! I certainly appreciate the alarm feature that you added; it demonstrates a little bit of the unhealthy fascination that some of us have about precision timekeeping. Next thing you know, you''ll be hanging about at midnight UTC when a leap second is inserted to see what happens with your GPS receiver and NTP code..
I made the video rather quickly when I wasn't completely well, so missed some details in retrospect. Yes, you are quite correct about USB not being a good choice due to jitter. I chose the DCD handshaking line of a real RS232 socket on my Dell desktop computer (but USB adaptor to laptop for configuration). The uBlox software seems to have a cable delay option you can use to compensate for cable length. I guess that's a second order obsession I might get into later, worrying about velocity factors, the jitter of the linux kernel responding to hardware handshake transitions... but I had better finish some other projects first :-)
Great stuff! I've wanted to make my own GPS disciplined clock for a while now and your video will be a great reference. Subbed!
For me the hardest thing was to get the RS232 cable/polarity correct. Every time I get something wrong first time!
Sorry, I missed how chrony is getting the 1PPS data? Is that wired up using your front panel 1PPS signal to, e.g., some GPIO input, or are you using the DCD signal on the serial port? Note that you'll likely see a bunch of jitter on the 1PPS signal due to how USB transfers work, wasting some of the precision available to you with the 1PPS signal from most GPS receivers.
On the other hand, if you're only worried about sub-millisecond accuracy, maybe don't bother? You can make yourself crazy chasing the microseconds here.. In that regime, you need a GPS receiver fancy enough to specify the cable length delay to the antenna to account for those extra nanoseconds.
Thanks for the making the video about your project! I certainly appreciate the alarm feature that you added; it demonstrates a little bit of the unhealthy fascination that some of us have about precision timekeeping. Next thing you know, you''ll be hanging about at midnight UTC when a leap second is inserted to see what happens with your GPS receiver and NTP code..
I made the video rather quickly when I wasn't completely well, so missed some details in retrospect. Yes, you are quite correct about USB not being a good choice due to jitter. I chose the DCD handshaking line of a real RS232 socket on my Dell desktop computer (but USB adaptor to laptop for configuration). The uBlox software seems to have a cable delay option you can use to compensate for cable length. I guess that's a second order obsession I might get into later, worrying about velocity factors, the jitter of the linux kernel responding to hardware handshake transitions... but I had better finish some other projects first :-)