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!
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:
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
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:
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.
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.
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.
Reconnect the fan connecting plug.
Replace the bottom cover of the transceiver.
Replace the carrying handle if previously removed.