The GPS is already running and providing a stratum-zero clock to your system (and indeed your LAN) via ntp. It is also outputing a rectangular timing pulse with the leading edge within 20nS or so of the universal time second marks. The default pulse width from the u-blox GPS is 100mS and we need to reduce that to 10uS for use with vttime.
From a Windows PC, the u-blox GPS is easy to configure using the u-center program from u-blox, but that's no good to us working on a Pi. Fortunately vlfrx-tools contains a simple utility 'vtubx' to adjust the important settings of the timing pulse. See its options with the command
vtubx -?
Before we can use it to set up the GPS module, we must turn off gpsd to free up the GPS so that vtubx can talk to it:
systemctl stop gpsd.service
Wait for it to stop, it may take a while, then check that vtubx can talk to the GPS, with
vtubx -rv /dev/ttyACM0
which should report back the hardware and software versions of the u-blox module. The following command will set the timing pulse to 10uS width, disable SBAS (for better timing accuracy) and save the new configuration to non-volatile memory on the module.
vtubx -b- -P 10e-6 -S /dev/ttyACM0
It also tells the GPS not to output a timing pulse if the GPS fix is not good enough. It's default behaviour is to hold-over missing fixes but it is better to let vttime handle missing pulses. Now the GPS is set, you can restart the gpsd
systemctl start gpsd
The program vttime uses the GPS pulse to timestamp and resample the raw signal from the soundcard. It looks at the phase slope of a short (eg 10uS) PPS pulse, or at the leading edge of a long (> 1mS) pulse, to determine the location of the second in the sample stream to sub-sample precision, down to less than 1/100th of a sample period.
The GPS pulse input to the soundcard must be free of noise and mains hum. Sometimes it is necessary to use an opto-isolator between the GPS and the sound card, in order to separate the GPS ground from the sound card ground and to block the digital noise coming from the GPS power rail. It is most likely that you'll get good enough results just by connecting the GPS timing pulse output directly to the sound card input.
Now you can run the timing program vttime. Use one of these commands
vttime -m pulse+ -c2 -v @raw @timed # Stereo card vttime -m pulse+ -c6 -v @raw:1,2,3,4,5,6 @timed # Octo card
The -c option tells vttime which input channel the PPS is on. With the Octo card, channels 7 and 8 are empty and we don't want to waste CPU to resample these, so we explicitly select only the first six input channels.
The output goes to a new buffer called @timed. The log messages from vttime will look like
It spends a couple of seconds in state 'st0' during which is it latching on to the PPS, then switches to 'st2' which is its running state. The important fields are 'PPSmad' which indicates the timing jitter of the pulse. Here it is about 150nS. A value of around 250nS is typical for the stereo Audioinjector, and about 500nS for the Octo card. The field 'inrate' shows the average sample rate of the incoming stream.
Open another shell and look at the buffer @timed with vtstat,
vtstat @timed
You'll see that the sample rate is exactly 96000 now (correction 1.00000000) and notice also that there is about a 10 second latency. The latency is built into vttime in the form of a circular buffer. It allows the input sample rate and timing to be measured and smoothed ahead of the resampling so that it can react sooner to variations of capture sample rate.
Once you are happy with the GPS pulse, you can add the vttime command to the start-up script /root/radio. It should look something like
#!/bin/bash killall -q vtcard killall -q vttime if [ "$1" = start -o "$1" = restart ] then sleep 2 # Delay needed when using Octo, the driver is slow to initialise vtcard -B -d hw:0,0 -r96000 -b32 -c2 -g-1 -L /run/vtcard.log -v @raw vtwait -t @raw vttime -B -m pulse+ -c2 -h 30 -L /tmp/vttime.log -v @raw @timed vtwait -t @timed fi
Note the -B option to put vttime into background, -L to write a log file (this time, to /tmp directory). The -h 30 option tells vttime to continue working for up to 30 seconds if the PPS pulse disappears or is invalid in some way, this is the holdover period. And we're using another vtwait command to wait for signal data to become available in the @timed buffer.
Stop your foreground vttime (CNTL-C) and restart all the radio software with
systemctl restart radio.service
and after a minute or two that command should complete. A quick check with vtscope should show that @timed contains signal and the PPS is in the right place.
Well, that's it, you now have a good timing system and the interesting stuff can begin. You may from time to time make changes to the hardware, the GPS. Always check the PPS timing on vtscope and check the vttime log file to see that the GPS jitter is still good.