When using the newest digital modes (such as JT65, FT8, FT4, etc…) to decode signals well into the noise floor, it is imperative to have accurate time. More accurately, it is important to have good synchronization. Many modern protocols used today rely on consistent start/stop times to establish decoding windows. Being ±1s becomes important!
I am no horologist, nor do I claim to have any depth of knowledge on the topic of time and time keeping, however, it is an interest of mine and so I will discuss some concepts in a very basic form. For the sake of brevity, I will omit concepts as : oscillator aging, derating, Allan variance, etc.
Sometimes, you will see “DT” values >1s when operators have not been careful to ensure system clock synchronization.
Interestingly, all that truly matters is the synchronization of the beginning of the minutes; your clock could be off by 1, 2, 40 minutes and so long as the change-over time between minutes is synchronized with other operators, decoding should work fine. Taken a bit further, if the protocol uses 15 second “frames” such as FT8, it is the beginning of the “frame” that needs to be synchronized.
Luckily, there is a well-established protocol that allows a network of computers to establish and maintain consistent time across machines. Most modern computers rely on NTP servers to establish and maintain their local time. A good choice would be: pool.ntp.org.
More on that in a moment.
NTP allows for mass-synchronization which for our purposes is more important than time accuracy.
If you’ve been in the computer game long enough, you may recall the days of on-board batteries failing and having to reset CMOS settings as well as time and date. Motherboards of most modern devices tend to have built-in real-time clocks (RTC) with battery back-up which “keep the beat” and maintain system time, albeit with some degree of local “drift”. This drift comes from inherent instabilities of the real-time clocks which may exhibit frequency accuracy of 10-20ppm which corresponds to an approximate drift of between 1 and 2 seconds per day.
1s / day = 1s / 86400 s/day *
= 1.15 x 10e-5 / day
= 11.5 x 10e-6 / day [ 10e-6 = PPM ]
≈ 11.5 PPM to lose 1 second per day
1s / year = 1s / 3.153 x 10e7 s/year
= 3.168 x 10e-8 / year
= 31.7 x 10e-9 / year [ 10e-9 = PPB ]
≈ 31.7 PPB to lose 1 second per year
* TAI (International atomic time) seconds are shorter than UT1 (Astronomical) seconds by 0.03 PPM which led to the creation of “leap seconds” (37 have already occurred) in the UTC system, the next of which is predicted to occur June 30 2020.
seconds per day = 60 s/min * 60 min/h * 24 h/day
= 86400
seconds per year = 60s/min * 60min/h * 24h/day * 365.25day/year
≈ 3.154 x 10e7
Clock systems such as the GPS constellation have an accuracy of between 10-8 and 10-11 PPM which means that a clock with the equivalent attributes would lose 1 second every 3 to 3000 years.
If you have some $$ to spend ($2175 for 1 unit; at the time of writing), you could have <±5 x 10-11 accuracy with a chip scale atomic clock (CSAC) which would give a (simplified) drift of ~1s in ≈633 years, not properly accounting for aging.
1 PPM = 10e-6 ; 1 PPB = 10e-9 ; 1 PPT = 10e-12 5 PPM = 5 x 10e-6 .. etc To calculate seconds lost per year using PPM: (# PPM) * (1e-6) * (3.154 x 10e7 sec/year) or more simply: # PPM * 31.54 sec/year E.g. 5 PPM = (5) * (1 x 10e-6) * (3.154 x 10e7 sec/year) = (5) x (31.54 sec/year) ≈ 158 sec/year
Excel sheet to do basic PPM / PPB calculations: PPM_calcs.xlsx
It should be noted that some devices such as the Raspberry Pi do not have a battery backed-up RTC on board and thus rely heavily on NTP to set and maintain accurate system time. If you need to use a Raspberry Pi without NTP access, it would be recommended (at a minimum) to add an RTC to your design.
The DS3231 is specified to have an accuracy of ±2ppm which means at the nominal operating frequency, it would lose (on average) 63 seconds per year.
Better yet, you can turn a Raspberry Pi into a highly effective GPS disciplined time server if you use a GPS receiver with a PPM output! This will be the subject of a future write-up as I have built my own GPS disciplined time standard which has some impressive accuracy (≈5 PPB, put another way, it would take approximately 6.3 years to lose a second).
For those using Windows as their OS of choice, you will need to make some modifications to your system to keep the most accurate time possible. This is because although Windows will use NTP to update the system clock, it is not done frequently enough! One option is to download and install software which forces the system time to update more frequently, the other option is to make some modifications to the registry file. Run the registry editor as follows:
click on start button and simply type: regedit then press enter
You are looking to navigate through the branches to the following:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W32Time\TimeProviders\NtpClient
Double click on SpecialPollInterval and then select the decimal radio button. Enter an interval (in seconds) to have the system poll the NTP server of your choice. I use 900s (15 minutes) as I am polling my local stratum-1 time server. A value of something like 7200 is enough to keep good time and not spam the time servers with too many requests. If you do set up your own local NTP server, spam it to your heart’s content!
To make configuration quick and easy, I have created a regedit merge file with the aforementioned parameters which will configure Windows to use pool.ntp.org and to update every 2h (7200 seconds = 1c20 in hexidecimal). Simply download the merge file (right-click on link and “Save link as”) and then double-click it to merge the contents. For safety, it is best to right click and select “edit” to validate the file prior to double-clicking it.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers] "1"="pool.ntp.org" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters] "NtpServer"="pool.ntp.org,0x9" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient] "SpecialPollInterval"=dword:00001c20
Your system should now be configured to connect to the pool.ntp.org NTP server pool every 2 hours to update your system time. Good stuff! You should now see DT (difference of time; offset) values approaching 0 in your favourite weak-signal mode software (provided other people have good synchronization also).
