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

Fri Apr 13 17:48:55 EDT 2018

Hi Jim,

Good for you!  I love to hear about backyard radio astronomy projects.

With your sample rate your GPS PPS spikes should be in the neighborhood
of 1 uS duration.  It's hard to say just how accurately you can glean the
timing
from that, but then I suspect that you're mainly interested in effectively
comparing
the outputs of the two receivers, not so much in absolute timing.  Try your
best
to keep the two receivers identical.

Dana

On Fri, Apr 13, 2018 at 2:15 PM, jimlux <jimlux at earthlink.net> wrote:

> On 4/13/18 10:33 AM, Dana Whitlow wrote:
>
>> Jim,
>>
>> I'm curious:    In what RF bandwidth will you be recording?
>>
>
> 1 MHz for now.. the RTL-SDR isn't a super flexible device - there are
> apparently good and bad rates - it does a DDC with 28.8 MHz I/Q NCO (with
> who knows what kind of performance), and then filter and decimate. There's
> a set of taps published for a FIR filter in the thing.
>
> Ultimately, it comes out as 8 bit I and 8 bit Q, so I figure if I do some
> more decimation on the 1MHz stream, I can get a few more effective bits.
>
> It will run at 2 MHz sample rate without dropping samples.. I could
> probably modify the rtl utility to run at a higher rate and do a first
> software filter/downsample to get the data rate down..
>
> I'm really only interested in fairly narrow detection bandwidth.
>
> For telescope use, Jupiter is pretty bright.
> For "phase array to listen to HF signals" 20kHz is probably plenty (it's
> not like I'm going to be developing a 3D CWSkimmer, yet)
>
> Mostly it's because I'm managing a project at JPL where we're flying an
> interferometer to look at CMEs from the Sun
> http://adsabs.harvard.edu/abs/2017EGUGA..19.5580L
> and I'm intrigued by whether I can do it in the backyard..
>
>
>
>
>
>> 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?)
>>
>
> That's a clever idea..
>
> Each node has its own GPS receiver, but they should all (within the
> tolerance of the receiver) be "ticking" at the same time.
>
>
>
>
>
>> 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.
>>>
>>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>