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. 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.