Time sync where there's no/no reliable internet.

Discussion in 'Ham Radio Discussions' started by ON6KE, Sep 11, 2019.

ad: L-HROutlet
ad: l-rl
ad: Left-2
ad: Subscribe
ad: L-MFJ
ad: Left-3
ad: abrind-2
  1. KD8TUT

    KD8TUT Ham Member QRZ Page

    I've got a Yaesu FTM-400 and can pull the NMEA code from it to sync the clock on a PC.

    It lacks a PPS output, so the sync is just so so. there's a 200 to 400ms offset between when the radio generates the NMEA message. You can fudge that offset in an ntp server config to get consistently within 100ms. Useful if the internet connection goes south for a long time. Certainly useful for FT8.

    Initially my station was going to be 100% GPS referenced for time and frequency standard. But it seemed that the equipment needed for time sync was more expensive than it was worth considering the following.

    Please note: I'm a bit of a calibration geek...

    You can achieve and maintain sub 2ms time calibration with an ntp server on a good internet connection.

    2019-09-14 04_19_44-Multiplicity 3.jpg

    On a bad internet connection you can expect maybe 200ms offset after a couple of days. When the connection goes down, ntp servers can revert to the computer's internal clock until communication is re-established- with minimal drift using the data collected about the local clock.

    Since I live in an area where power and internet go down monthly, here's how I set up a system to maintain time accuracy.

    First, I've got a utility server which handles my APRS station (2 radios- one transmits), a SQL server for logging, a local DX cluster, and a bunch of other things.

    I loaded Meinberg NTP on it, and setup the ntp server to sync to the NIST time servers. When the connection is up it does great. It drifts pretty good (2-300ms) after a few hours of outage.

    Looking for more stability I found the "peer" function which is designed for these kinds of situations.

    So I loaded two of my other machines with the ntp server (these are linux), but set them up as peers with my main server.

    The effect is wonderful. After 1 day of outage, I only drifted 20ms. In effect the 3 servers sync against each other until the main server can reach the external servers.

    The beauty of this is that you don't need a great internet connection.
  2. W0PV

    W0PV Ham Member QRZ Page

    So the objective is setting the PC clock for best FT mode decoding.

    Be aware that this does not require the ABSOLUTE time to be correct. It does not matter if your clock is an exact full minute or more off, any more than a whole time zone in error.

    Rather just the time relative to the desired signal within its FT xmsn interval (15 secs for FT8). This is reported by WSJT as the DT (differential time) value.

    With that in mind check out the small utility program named Time Fudge by W9MDB that enables manual setting of the clock in small increments.

    I use it to "fudge", bump, the PC time to match that observed in a desired stations decodes. The goal being to make DT=0. I believe this in effect maximizes error free decoding probability.

    It is incredible how far off many stations may be from "the pack", outliers often > +/- 2.5 secs, which is reported as about the highest threshold before decoding stops all together no matter how strong the signal.

    Of course if the band is quiet and you are only one calling CQ, the goal is to be as close as possible in time sync with "the herd" of possible listeners on frequency.

    Then starting as close as possible to the absolute reference is best. But as many have pointed out, that can be fairly easily observed in many ways and set manually. Callers can adjust to you ;)

    Matt, this is a great idea. I encourage you to make that utility and publish it.

    Even better would be either an added feature to that or a separate tool that would automatically perform what is described above is done manually with Time Fudge, ie, recognize and track a specific call sign DT value, then setting the local PC clock in +/- increments to make DT=0.

    73, John, WØPV
  3. ON6KE

    ON6KE Ham Member QRZ Page

    Hello Matt,
    just enquiring. Are you - given the interest shown here in this post - considering publishing an updated version of your scripts?

    73, good DX
  4. KK5JY

    KK5JY Ham Member QRZ Page

    Maybe so, we'll see how much interest there is.

    The main application is a small .Net console app, so it could run on anything. The part that does the actual "clock set" is a C-language utility that is Linux-specific. To be truly useful, I would need to make that part cross-platform. It would also need a GUI -- it wouldn't take much, but most people won't use console-mode software.

    What I may do is write up a short article about it and post it on my website. If there's enough interest in a Windows version, I may work on a Windows + GUI version. When the weather turns nice here in a few days, I'm planning to start spending more time at my countryside get-away location, and that's where it will come in handy. That will give me more opportunity to refine it and perhaps put a GUI on it.

    If you or anybody else would be interested in getting a notification when/if I put up a webpage with the software, please send me a PM.

    Part of the problem of FT8 is that one quickly runs out of stations to work. :) I have been on FT8 less than a year, and my QSO rate is falling fast. :eek: So I may not be FT8ing much longer.
  5. KK5JY

    KK5JY Ham Member QRZ Page

    I'm not sure I totally understand what you are suggesting, but adding a feature to track a specific single station (or any fixed, limited set of stations) would not be difficult. It's just another filter to apply when deciding which stations to watch. The converse would be another good idea -- a list of stations to exclude as timing sources. That would be helpful if you know certain stations were usually "field stations" or "network-disconnected" stations that themselves did not have NTP access.

    Maybe someday the FT8 messages themselves will contain a bit indicating whether the station is NTP-locked. :)

    The current algorithm filters on age of each spot, and the SNR of each spot. That is, it focuses on strong stations most recently heard. It then excludes DT values that are outside a user-defined number of standard deviations from the mean. All of these things are "knobs" that could be put into a GUI.

    Another item that I want to add is a "search" function that ticks the clock forward or backward by maybe 100ms per cycle until some number of stations are heard. This could be used as an initial "rough sync" to get to the point where WSJT-X starts producing usable DT values, so that the "fine tuning" can proceed from there. This would be really useful for PCs whose RTC is total junk, like the ones I have in some of my notebook computers and some of the lower-end RasPi RTCs.

    Fun stuff.
  6. W0PV

    W0PV Ham Member QRZ Page

    FT could to use those spare bits for something. But being NTP-locked seems more of a proactive convenience, especially for a CQn station. More essential is that any two stations attempting to communicate have their PC clocks locked together.

    Let me try to explain the concept more. Example of "DT Tracker" at work,

    Let's say that on a FT channel there are a few stations. Most are decoding with DT within a tenth or two of DT=0.0 That's just fine for making QSO's with them.

    However, one desired DX station is consistently decoding with DT = - 1.4 and say -18db or less.
    To maximize sensitivity / probability that the DX will see my reply it would be best if my PC clock was synced to his PC clock. This motivates me to advance my PC clock by +1.4, which is can be done with Time Fudge.

    After the Time Fudge clock bump, other signals will decode with DT = 1.4 +/- original error, but the DX is now DT=0. Often that makes enough difference to finally get a "red stripe".

    Fiddling with Time Fudge is kinda clunky, would be neater to just have a utility that tracked the DT error of whatever call sign was clicked on and loaded into WSJT ready to call and the tool would set the local PC clock to make DT=0 for that station and keep it there if drift occurs. :)
    Last edited: Sep 15, 2019
    KA0HCP likes this.
  7. KP4SX

    KP4SX Premium Subscriber QRZ Page

    Good idea. I was wondering how the setup might work from a 'cold' start when not copying anyone. 100ms steps seems too small. I'd think more like 500ms would be faster.
  8. KK5JY

    KK5JY Ham Member QRZ Page

    It might be. I'd have to look at the current code to see what the maximum allowed DT is for the most "picky" modes. To be honest, it would almost have to be a per-mode setting. It would also be a "knob" that a user could "turn" on a GUI version.

    Edit: right now, I "cold start" the process visually. I just step the time forward or backward by hand until the time slot lines align with lots of stations. The utility I'm using has shortcut keys for doing exactly that. It could also be done audibly for people who can stand the sound of FT8 in the speaker. :)
  9. KK5JY

    KK5JY Ham Member QRZ Page

    Okay, I follow what you are saying now.
  10. KA9JLM

    KA9JLM Ham Member QRZ Page

    I have seen NTP servers that are out of time.

    This may take a byte.

Share This Page