Adventures in GPS NTP

For some reason I decided that I needed a Really. Accurate. Clock. here in the ham shack, so, here we go.

Step 1: Get a GPS receiver. I picked one of the VK-162 USB devices on Amazon for about $15. This is a good way to get started but not the ultimate goal, which I’ll explain later.

Step 2: Install all the necessary stuff to talk to the GPS.

apt-get install ntpd gpsd-clients gpsd gpsd-clients

The VK-162’s simply pop a /dev/ttyACM0 serial device in, so it’s pretty straightforward. A little bit of configuration:

# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time

# Use USB hotplugging to add new USB devices automatically to the daemon

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.


# Other options you want to pass to gpsd

Note the -n option. This tells gpsd to not wait for a client to connect before polling the GPS. Helps get the fix a bit faster, I believe.

Now we fire up the service and ensure we’re getting a GPS fix:

Looks good. 8 satellites and 1.02 HDOP (which indicates a pretty accurate fix)

Step 3: Get chronyd installed and configured.

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
refclock SHM 0 offset 0.0700 delay 0.01 refid NTP0 noselect
#refclock SHM 0 offset 0.5 delay 0.01 refid NTP0 prefer 
#pool iburst
pool iburst
pool iburst
pool iburst
pool iburst
pool iburst
# Uncomment the following line to turn logging on.
log tracking measurements statistics

gpsd and chronyd speak using a shared memory segment for speed. I kept that commented-out definition in there, because I want to give a short lecture about COPYING OTHERS’ CONFIG LINES AND NOT UNDERSTANDING THEM.

When I first set this up, I could NOT get chronyd to use the GPS as the ‘master’ if I had ANY other NTP servers configured. It always seemed to be right around 430 mS fast.

After peering at the config, I went OH MY GOD, threw something in a harmless direction, and removed the “offset 0.5” that somebody else’s config needed.

Why this makes sense: It takes about 68-70 mS on average for the GPS puck to send the string through the 9600 bps serial line it establishes.

So, now, after figuring that out, I’ve ballparked the offset I need. I’m now logging and collecting average data – comparing the GPS puck to a WHOLE BUNCH of NTP servers – and will dial it in. You’ll see the ‘noselect’ on the GPS device, which means that i don’t want to actually set the time using this today – just logging its delay. I expect to get mS accuracy out of the current setup.

And lo and behold, my other machines love and prefer it:

* means it’s the active server, + means these are being combined/averaged in.

The next step is to set up a real source with a serial-only GPS board – one that has “pulse per second” (PPS) output. Linux can use this to hit an interrupt to advance the clock, and combined with the NMEA serial strings and internet NTP servers to know which second it is, I expect to have microsecond accuracy. Tightest FT8 signal on the block, friends.

ISS voice chat clip!

I had the rig on 145.800 and heard squelch break – I was really listening for SSTV, but an astronaut got on voice! Here’s a couple minutes of his side of the conversation.

ISS voice chat

IC-9700 fan mod


The frequency stability of the Icom IC-9700 as originally delivered by Icom, has been found to be rather disappointing. Although the radio has a 10MHz frequency reference input, it (as of firmware V1.06) does not discipline the internal reference oscillator to the external 10MHz frequency, and the frequency of the unit varies significantly during both extended transmit and receive periods (With my unit I am seeing variations of the order of 60-70Hz at 432MHz, and up to 200Hz at 1296MHz).

The fan in the unit does not run while the unit is in receive mode, and this appears to be a cause of significant temperature variations within the transceiver.

A minor modification that allows the fan to run at approximately half speed allows the temperature within the transceiver to remain much more constant and (for my unit) has reduced the frequency variations to typically no more than 4-5Hz during testing.

The modification consists of adding a 6.8V Zener diode across the transistor that is used to power the fan.


  • 6.8V 5W Zener diode.


  • Remove the carrying handle if fitted.
  • Remove the 12 small screws securing the bottom cover to the transceiver N.B. Use a JIS screwdriver to avoid damage to the screw heads).
  • Remove the bottom cover.
  • Locate the fan connector (labelled “J2881 FAN”) towards the rear of the transceiver.

Picture: Before.jpg

  • Remove the fan plug to facilitate access.
  • Trim and bend the leads of the Zener diode to fit neatly between the tab connection of the transistor, and the pin of the fan socket that the red wire of the fan is connected to.
  • Tin the end of the cut leads of the Zener diode.
  • Carefully solder the Zener diode into place.

Picture: After.jpg

  • Reconnect the fan connecting plug.
  • Replace the bottom cover of the transceiver.
  • Replace the carrying handle if previously removed.

Gaming on the ham bands!

I was randomly tuning around tonight, testing a new antenna, when I happened upon a lil’ role playing game going down on a local 2 meter repeater. Adults, teens, even kids were playing! So blessed. This is the kind of fun stuff I’d like to see more of on the bands.

MP3 of what I caught below.

Audio of the RPG net on the 146.700 machine