[time-nuts] getting accurate timing on RTL-SDR output

[Dana Whitlow]

Jim,

I'm curious:    In what RF bandwidth will you be recording?

My first thought would be to search for a cross-correlation peak
between the two antenna outputs, but quickly realized that this
does not tell you anything about the timing differences between
the two receivers.   I think you need to determine that independently
(else why bother with the interferometry in the first place?)

The receive bandwidth in conjunction with your S/N on the PPS
spikes will conspire to limit your timing accuracy, although you
can improve on that by averaging over a few minutes as you
plan.

Dana




On Fri, Apr 13, 2018 at 11:52 AM, Jim Lux <jimlux at earthlink.net> wrote:

> I'm building a phased array receiver (actually, an interferometer) using
> RTL-SDR pods, where the elements are isolated from each other - there's a
> common WiFi network connection, and each node has a BeagleBone Green, a
> uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it has an
> internal bypass around the RF front end).
>
> In general, I have the RTL-SDR set up to capture at 1 Megasample/second. I
> fire off a capture, record it to a file in the BeagleBone's flash, then
> retrieve it from my host computer using scp over the network.
>
> What I'm trying to do is capture data from all the nodes at
> (approximately) the same time, then be able to line it all up in post
> processing. The GPS (or NTP) is good enough to get them all to start
> recording within a few tenths of a second.
>
> So now the challenge is to "line em up".  An obvious approach is to
> transmit an inband pilot tone with some sync pattern, received by all, and
> I'm working on that too.
>
> But right now, I have the idea of capacitively coupling the 1pps pulse
> from the GPS to the antenna input - the fast rising and falling edge are
> broad band and show up in the sampled data.
>
> The attached pulses1.png shows the integrated power in 1 ms chunks (i.e. I
> sum the power from 1000 samples for each chunk) and it's easy to see the
> GPS edges.  And it's easy to create a estimate of the coarse timing (to 1
> millisecond) - shown as the red trace.
>
> But then, I want to get better.  So for the 20 edges in my 10 second
> example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The pulse
> isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range), but is
> visible. Bottom trace is the first, and they're stacked up
> 0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.
>
> And you can see, no surprise, that the sample clock in the RTL isn't dead
> on - over the 10 seconds, it looks like it drifts about 30- 50 microseconds
> - that is, the RTL clock is slow by 3-5 ppm.
>
> SO here's the question for the time-nuts hive-mind...
> What's a good (or not so good) way to develop an estimator of the
> timing/frequency error. Post processing minutes of data is just fine..
>
> I'm not sure what the actual "waveform" that is being sampled is (and it
> will be perturbed by the quantization of the ADC, and probably not be the
> same depending on where the RTL is tuned).  That is there's some sort of
> LPF in the front of the RTL, the edge is AC coupled, and then it goes into
> some sort of digital down converter in the RTL running at 28.8 MHz sample
> rate.
>
> But it seems that there might be some way to "stack" a series of samples
> and optimize some parameters to estimate the instantaneous time error-
> given that the frequency vs time varies fairly slowly (over a minute or
> so).  It's fairly obvious from the plot that if one looked at the "single"
> sample when the edge comes in, not only does the time shift with each
> pulse, but the phase rotates as well (totally expected)
>
> this is one of those things where you could probably lay a ruler on it and
> estimate it by eye pretty well, but I'd like an automated algorithm.
>
> It would be nice to be able to estimate the timing to, say, a few
> nanoseconds over a minute or so ( - that would allow a phase estimation of
> 1/10th of a wavelength of a 20 MHz signal (e.g. Jupiter's RF noise, or
> WWVH's transmissions)
>
>
> Ideas???
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>