GPS timestamped reception of GB3MBA using RTL-SDR

Using a low cost RTL-SDR TV receiver dongle with vlfrx-tools to monitor meteor pings from the 50.4 MHz beacon GB3MBA, with GPS precision timing using RF timing pulse injection.

Location

Receiver is located near Todmorden UK, 53.703N,2.072W, which is 86km north-west of the GB3MBA beacon.

Antenna

The antenna is a zenith pointing turnstile antenna with a BF245 preamplifier. Located at the top of the woods about 100m from the house and connected via 100m of 75 ohm satellite TV coax. Power to the preamp is supplied at 13V through the coax using a bias T.

The turnstile antenna in axial mode is phased for left-hand circular polarisation for maximum response to meteor head reflection of the right-hand polarised beacon signal, and the circular polarisation gives an omni-directional response to the linearly polarised meteor trail reflections.

This is a temporary location during testing. The sloping ground significantly distorts the otherwise omni-directional pattern of the axial mode turnstile antenna.

Receiver

The particular RTL-SDR in use has a R820T tuner and a RTL2832U receiver/decoder. The dongle is tuned to 50.4 MHz so that GB3MBA is at +8 kHz in its I/Q output. The SDR is driven using the vtrtlsdr program,

   vtrtlsdr -g 49.6 -vqr 226000 -F 50.400e6 @raw

which puts a nominal 226k I/Q frames per second into the buffer @raw. With this specimen of RTL-SDR the actual local oscillator frequency is near 50.4107 MHz and the actual sample rate is measured to be close to 226012 I/Q frames per second. These offsets are typical of the very low cost versions of RTL-SDR. The timing system described below takes care of these defects.

Timing system

Timing is done by injecting GPS-deriving RF timing pings into the receiver antenna port. The timing ping is tracked and measured to determine the timing of each sample from the SDR. This method eliminates the variable (approximately 115 mS) propagation delay through the SDR and the USB system of the PC, and at the same time, continuously corrects for sample rate error and SDR local oscillator error.

Both timing outputs of a u-blox M8T GPS module are combined to produce the RF timing pulse.

The u-blox M8T is initialised with the following vtubx command,

   vtubx -P 1,-0.5e-3 -F 2,7213420 /dev/ttyACM0

This sets timing output 1 to a negative-going 500uS wide pulse-per-second, and timing output 2 to a constant 7.21342 MHz square wave. The two timing signals with amplitude about 3V are combined in the passive modulator circuit below.

Capacitor C1 slows down the attack and decay of the modulating signal to produce a good envelope for centroid measurement while also limiting the bandwidth of the RF timing ping. The output of the modulator is coupled to the receiver input via a 470 ohm resistor in the bias-T. The average carrier amplitude is at 26dB below full scale in a 1Hz bandwidth which is more than enough for reliable measurement of the timing ping.

The 7th harmonic of the T2 signal is at 50.49394 MHz and should be at +93940 Hz in the I/Q spectrum. Due to the local oscillator offset, it is actually near +91240 Hz.

The vttime is using its 'iqping' timing method. This method uses the timing ping to:-

Determine the location in the raw I/Q stream of the GPS second marks, to within a few microseconds (raw intervals) and better than 1uS after exponential smoothing with 30 second time constant;
Resample the raw I/Q stream to a UT synchronous 226000 frames/second;
Shift the center frequency of the resampled I/Q stream so that the carrier of the timing ping is at its correct frequency, +/- about 0.1 Hz;

vttime measures the centroid of the timing ping envelope. After subtracting a calibration factor (the centroid offset) and applying some smoothing, this determines the location of the GPS second marks. The smoothed intervals between consecutive timing pings gives a very accurate measurement of the sample rate. This information then controls a high precision variable-rate resampler to put 226k I/Q frames/second into the buffer @timed.

Even when the T1 timing signal is high, the passive modulator still allows some of the 7.21342 MHz T2 signal to leak through. vttime makes full use of this to make accurate measurement of the carrier frequency. In fact, vttime skips the timing pulse itself when measuring the carrier frequency as there is some phase shift produced by the passive modulator during the pulse.

The vttime command is

   vttime -vv -h 20 -m iqping,f=91240,bw=20e3,w=auto,noppm,ts=30,rs=30,c=0.25e-3,ft=93940.0 @raw @timed

The iqping method options are:

f=91240 specifies the approximate frequency where vttime can expect to find the timing ping. This only needs to be within a few kHz, vttime will find it and lock on, and then track the drifting SDR local oscillator;
bw=20e3 specifies the bandwidth to use for measurement of the timing ping;
ft=93940 specifies the actual frequency of the timing ping - where it should be if the SDR local oscillator was running at exactly 50.4 MHz;
c=0.25e-3 calibrates the time delay between the second mark and the centroid of the timing ping envelope. This is just for the moment a nominal value to get within a few uS. It can be calibrated using another GPS placed near the antenna.
w=auto tells vttime to automatically choose the duration of the timing ping analysis window;
noppm turns off the default behaviour of vttime when the peak-to-mean ratio of the timing pulse is low;
ts=30,rs=30 set the moving exponential averaging time constants for timebase and sample rate measurements, respectively; The raw centroid measurements have a mean absolute jitter of about 4uS and the time constants reduce this by a factor of about 20 while still being short enough to respond to SDR clock drift;

A snapshot of the vttime log file is given below, 11 seconds worth, one log record per timing pulse.

   st2 PPSpmr 11.2 PPSmad 4.010uS in 127.236296mS out  -0.001uS rate_err -0.001 inrate 226012.4066 int 226012.7635 tc 0.000
   st2 PPSpmr 10.9 PPSmad 3.946uS in 127.230966mS out  -0.001uS rate_err -0.000 inrate 226012.4066 int 226013.0799 tc 0.000
   st2 PPSpmr 11.1 PPSmad 3.964uS in 127.225631mS out  -0.003uS rate_err -0.000 inrate 226012.4061 int 226012.0221 tc 0.001
   st2 PPSpmr 11.2 PPSmad 3.918uS in 127.219187mS out  -0.004uS rate_err -0.000 inrate 226012.4058 int 226012.4969 tc 0.001
   st2 PPSpmr 11.0 PPSmad 3.908uS in 127.213856mS out  -0.001uS rate_err  0.001 inrate 226012.4065 int 226013.2902 tc 0.000
   st2 PPSpmr 10.8 PPSmad 3.946uS in 127.208527mS out   0.000uS rate_err  0.000 inrate 226012.4068 int 226012.0626 tc -0.000
   st2 PPSpmr 10.9 PPSmad 3.919uS in 127.203204mS out   0.003uS rate_err  0.001 inrate 226012.4073 int 226012.7135 tc -0.001
   st2 PPSpmr 10.8 PPSmad 3.827uS in 127.197888mS out   0.007uS rate_err  0.001 inrate 226012.4083 int 226012.7564 tc -0.001
   st2 PPSpmr 10.9 PPSmad 3.810uS in 127.159697mS out   0.009uS rate_err  0.000 inrate 226012.4087 int 226012.0516 tc -0.002
   st2 PPSpmr 10.8 PPSmad 3.736uS in 127.120178mS out   0.008uS rate_err -0.000 inrate 226012.4086 int 226011.8630 tc -0.002
   st2 PPSpmr 11.1 PPSmad 3.686uS in 127.080654mS out   0.007uS rate_err -0.000 inrate 226012.4083 int 226012.2435 tc -0.001

st2: state 2, normal running state;
PPSpmr: the peak/mean amplitude ratio of the timing pulse. This is low due to the useful inter-pulse carrier leakage through the modulator (hence the noppm option);
PPSmad: the mean absolute difference between consecutive timing pulse intervals, a measure of the quality of the centroid timing;
in: the timing offset of the input stream timestamp assigned by vtrtlsdr from the system clock. The system clock is maintained by ntpd within about 3mS, most of the 127mS error here is from the latency of the SDR and/or USB system;
out: The output stream timing error. During stable running this hunts +/- a few nS as seen here;
int: The raw intervals between consecutive timing pulse centroids, in units of I/Q sample periods;
inrate: The smoothed intervals, as used for sample rate correction. Stable here to better than 0.01 frames/sec.;
tc: The timebase correction applied this second, units of uS;

Computing

The I/Q output from vttime is further shifted in frequency by the vtmult program so that zero frequency is at 50.4076 MHz which places the 50.408 MHz beacon signal at +400Hz. The upper sideband is then extracted by vtmix and resampled from from 226k frames/sec to 1800 samples/sec.

The above runs on a Minix PC which has a quad core Intel Atom processor. The receiver consumes about 1.5 cores of its capacity and negligible RAM and disk space.

The 1800 samples/sec output stream is sent in uncompressed float32 'vt' format over the LAN to a workstation which records the signal (vtwrite) and scans the signal for meteor pings (vtping).

The command line for this mixing, resampling, and sending over the LAN, is

   vtmult -f 7600 @timed | vtmix -c1,0,-j,0 | vtresample -r 1800 -- - ++pn,41768,f4

where 'pn' is the hostname of my workstation and 41768 is some arbitrary TCP port number.

The screen shot below shows the top of the Minix process table.

The workstation listens on port 41768 and puts the stream into a buffer @p18

   vtcat ++41768 @p18,f4

Then various processes take data from @p18,

   vtping -v -F detect,350,450 -F reject,100,250 -F reject,550,700 -D 0.20 -R 0.25 -d /t/pings @p18
   vtwrite -G3600 @p18 /t/p18
   vtspec @p18
   vtresample -r32000 @p18 | vtraw -g4 -ow | aplay -

vtping is analysing the signal for pings (more details below) and storing the results under /t/pings. vtwrite is recording the stream continuously to disk under /t/p18. Not essential, but it is useful to keep a month or so of data available to examine interesting events more closely. vtspec is displaying the I/Q signal on my screen, and the final command is used when I want to listen to the signal.

Signals

In the 15 minute spectrogram below, the beacon frequency has been shifted to 70 Hz for this plot.

There are plenty of reflections from aircraft as a result of being only a few km from the Pole Hill VOR/DME navigation beacon. Meteor pings are visible as the vertical spikes in the spectrogram. The aircraft reflections are not a problem - they are easily and completely ignored by the ping detection algorithm, and they provide a useful quick check that the receiver is working!

Ping statistics

The number of pings per hour counted by vtping is summarised for a ~910 hour observing run which recorded 22971 pings.

Ping rates are peaking in the early hours rather than at dawn, indicating that the geometry is more favourable to meteors with low elevation angle. Ping rate often exhibits a sharp peak around this time.

Ping analysis

An example spectrogram is shown below (6 seconds duration, 900 Hz bandwidth), the image generated by vtping. The white pixels are those that the detection algorithm in vtping decided are part of a meteor ping. The red pixels are background.

It is difficult to take measurements from the typical spectrogram representation of a ping. A better view is obtained in the time domain by examination of the analytic signal (obtained by combining the band-limited recorded signal with its Hilbert transform).

Below is the plot of the magnitude and instantaneous frequency of the analytic signal plotted as an offset from the 400Hz beacon frequency.

The initial Doppler here peaks at about +60Hz and decays roughly linearly over about 60mS. Most pings do not present an initial Doppler shift and only offer a small constant offset due to the low velocity drift of the ionised trail.

Notes

It is not necessary to use the u-blox M8T although it is convenient because of its two independent timing outputs. Nor is it necessary to use the special 'timing mode' of the M8T. A cheaper and more readily available option would be to use a pair of u-blox M6 or M7 modules, perhaps sharing the same GPS antenna. These only have a single timing output. One module to provide the PPS, the other to provide the frequency reference.
The Minix PC and RTL-SDR are installed outside in my radio equipment cabinent, which is subject to draughts through the vent holes on windy days. I had to wrap the Minix and dongle in insulation to prevent rapid clock drifts caused by suddent temperature changes. If the RTL-SDR clock (LO frequency or sample rate) drifts too quickly then vtrtlsdr or vttime will declare a timing break, reset, and re-settle. The thermal insulation eliminates this and allows longer averaging time constants and therefore greater short term timing accuracy.
Will this work on a Raspberry PI? Probably not. The RPi is notoriously bad at isochronous capture via USB, its chipset is designed for media playing applications such as smart TVs and the like. Capture barely works with audio interface devices at 48k stereo frames/sec, suffering frequent dropped USB packets resulting in timing breaks, so will surely struggle at 226k/sec. But maybe I will try it with a Pi 4...
It is not necessary to send the received data via the network to a workstation PC. The Minix or any similar 4-core PC has plenty of capacity for the signal analysis end of things.
The vtping program has been completely re-written with a new detection algorithm, available from version 0.9n of vlfrx-tools.
Using the venerable BF245 here for both the preamp and the ping modulator. This is just because they are a good general purpose RF FET and I happen to have a bag of them.