Time keeps on tickin’….

After four and a half years of running my little wordpress via Fastly’s spectacular CDN, we are using the NEW HOTNESS! As some may have heard, I recently took a position as a Solutions Engineer at Section.io and figured the best thing to to get familiar with the platform and start playing is to switch over. So, we are now running some basic caching and manipulation via Varnish and OpenResty in the pipeline.

This site will probably break. A Lot. I’m still learning and figuring things out – but it’s a LOT easier than I expected. I look forward to doing some really neat things with the new stack!

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
START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"

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

GPSD_SOCKET="/var/run/gpsd.sock"

# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"

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 2.debian.pool.ntp.org iburst
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
pool 4.pool.ntp.org iburst
...
# Uncomment the following line to turn logging on.
log tracking measurements statistics
...
allow 10.0.3.1/24

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.

DMR hotspot FIXED!

This MMDVM was driving me nuts. I was getting consistent stutters and dropouts and it was really frustrating. I recently got onto D-Star and was impressed with how easy that was to set up and use, so figured I’d power through until I cracked the DMR nut.

The MD380 was solid; worked fine on local RF machines. The MMDVM was showing no BER or dropped packets. So it had to be somewhere in the RF link between the two.

I played with RF power, calibration, all of that. Tried four different MMDVM firmware images and three on the 380. Then I found it.

I had to bump the DMR TX audio (deviation) just a little bit. Soon as I brought it up a few from 50, it started working.

I’m so happy! Now I’m online with two digital modes. Next step is to run an Ethernet cable to my 9700 and set it up as my D-star ‘hotspot’ to use with my new shiny ID-51A plus2.

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