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

[Magnus Danielson]

Hi Jim,

> That's the sort of strategy I'm looking at.. find a set of samples where
> the transient occurs, zero pad it out (so that when I do peak picking
> later, I've effectively got interpolation), then run the correlation

You find it using cross-correlation, and once found, you have a fair
idea for the next round where it is so a shorter cross-correlation can
be used if processing is relevat.

> ifft(fft(a).*conj(fft(b))) in matlab

After that, search through for the highest amplitude, which is a linear
search.

The trick of using a reference is that the conj and fft can be done as
common processing and then only the fft, multiply and ifft needs to be
done for each other channel. This removes 1/3 of the needed FFTs.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Achim Gratz]

jimlux writes:
>> A maybe not-so obvious approach would be to use RTL-SDR that have been
>> modified for direct sampling (usually via the Q branch) and inject your
>> timing pulse there.  That would limit the disturbance of the actual
>> signal while still relatively easy to extract from the data stream.
>
> That's where it's being injected.. I'm using the RTL-SDR V.3, which
> has the RF input fed right to the Q input.

OK, some more details (I did say it was a bit non-obvious :-) on that
idea.  The R820T tuner in the RTL-SDR v3 only uses the I input of the
RTL2832U as it's a low-IF architecture, leaving the Q inputs free and
unused in the normal mode of operation, which the direct sampling
modification takes advantage of by populating the Q branch with a direct
input.  The other commonly used tuner, the Elonics E4000, uses both
inputs, because it's using a zero IF architecture.  Thus it should be
possible to switch the RTL dongle to zero IF mode, get the I/Q samples
as per normal and you get two perfectly correlated data streams from two
different inputs.  You can modify the hardware to also have a direct
input on the I branch normally used by the tuner.  Alternatively, don't
modify the hardware and use the tuner to downconvert an RF sync signal
to the I branch (you can test if that works by just using it in direct
sampling mode with the I branch selected, but I think the tuner might
get switched off by the rtlsdr library, so there'd need to be some
modifications to the software).

http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2015/09/RTL2832U.pdf
https://www.reddit.com/r/RTLSDR/comments/1uazsw/rtl2832_datasheet_deep_info/

Also, the RTL-SDR v3 does have a clock input, so you can modify the
hardware to use that and make its sampling coherent to a known clock
source.  That would allow you to align the sampling files only
sporadically and then rely on the known relation to the clock as long as
no USB frames are getting dropped.

https://www.rtl-sdr.com/rtl-sdr-blog-v-3-dongles-user-guide/

No, I haven't done anything of that yet, but what initially got me
interested is the idea of correlating DCF77 (through an upconverter)
with GPS.  Still working on the antenna setup, it might be possible to
also receive TDF, MSF and maybe even RBU.  I did get as far as buying a
GPS timing module with a frequency output that I can use for the
external clocking to eventually get coherent sampling.

>> Not all of these are created equal.  Several manufacturers claim to
>> factory calibrate their TCXO to better than 0.5ppm.  I have currently
>> two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
>> so it definitely takes some time before they stabilize even if they do
>> have a TCXO in them.
>
> Could well be.. I just turned it on, waited for the beagle to boot,
> captured the data, and moved on.

My RTL-SDR v3 is still in transit, but I expect your result to indicate
that it was still warming up based on what my other RTL based dongles
do.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Mark Sims]

Note that on a lot of GPS devices that only one edge of the 1PPS pulse is 
stable and the other edge can jitter a bit.

Also, you might want to try programming the PPS to a 50% duty cycle (but having 
an asymmetrical PPS pulse might have some advantages for post processing).

The receiver with the best 1PPS stability  that I have tested is the Furuno 
GT-8736.  Its typical span is under +/- 4ns from nominal. 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[jimlux]

On 4/13/18 1:47 PM, Magnus Danielson wrote:

Hi Jim,

On 04/13/2018 06:52 PM, Jim Lux 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???


Cross-correlate. Hug your Fourier transform as you do it.

Assume that you have a rough idea where the pulse occurs for each SDR.
FFT with a suitable window function each record.
Using one as reference, you then multiply the complex response with the
reference conjugated response.
Ether compare in the frequency domain or do inverse FFT and search the > 
time-domain for peak response.



That's the sort of strategy I'm looking at.. find a set of samples where 
the transient occurs, zero pad it out (so that when I do peak picking 
later, I've effectively got interpolation), then run the correlation


ifft(fft(a).*conj(fft(b))) in matlab





This is how modern GPS receivers to quick lockup of phase, and it works
very well. Using an FFT library i could code it in relative little C
code and setup my classic channel decoder this way.

Now, use this to compare your SDR clocks compared to the reference. As
they drift over time the windown need to shift, but you can keep track
of the number of samples shifts to keep full track of it. This should
give you enough phase and frequency information. Toss in a least square
or Kalman if you think it would help.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[jimlux]

On 4/13/18 1:39 PM, Achim Gratz wrote:

Jim Lux writes:

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.


A maybe not-so obvious approach would be to use RTL-SDR that have been
modified for direct sampling (usually via the Q branch) and inject your
timing pulse there.  That would limit the disturbance of the actual
signal while still relatively easy to extract from the data stream.


That's where it's being injected.. I'm using the RTL-SDR V.3, which has 
the RF input fed right to the Q input.






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 trouble is that you are going to impair the already low dynamic
range.  The ENOB on the I/Q ADC is around 7bit only.


Well, so far, after DDC, it's coming out about 1/5th of the dynamic 
range, and I can always adjust the size of the capacitor.







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.


Not all of these are created equal.  Several manufacturers claim to
factory calibrate their TCXO to better than 0.5ppm.  I have currently
two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
so it definitely takes some time before they stabilize even if they do
have a TCXO in them.


Could well be.. I just turned it on, waited for the beagle to boot, 
captured the data, and moved on.







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..


There is a program called rtl_test that just checks how many samples it
gets in a certain amount of time.  Let it run for a few hours on a PC
with a GPS-disciplined PC clock and it'll give you a pretty accurate
estimate of the mean sampling clock deviation.

The other method is to tune to a signal of known frequency and check
what it reads as.  There is a program floating around that uses a GSM
station for that purpose.


I'm not so concerned about the frequency measurement - that's "easy".. 
What I'm interested is figuring out the precise timing (in absolute 
terms) of the samples.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Dana Whitlow]

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  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  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 

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

[Magnus Danielson]

Hi Jim,

On 04/13/2018 06:52 PM, Jim Lux 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???

Cross-correlate. Hug your Fourier transform as you do it.

Assume that you have a rough idea where the pulse occurs for each SDR.
FFT with a suitable window function each record.
Using one as reference, you then multiply the complex response with the
reference conjugated response.
Ether compare in the frequency domain or do inverse FFT and search the
time-domain for peak response.

This is how modern GPS receivers to quick lockup of phase, and it works
very well. Using an FFT library i could code it in relative little C
code and setup my classic channel decoder this way.

Now, use this to compare your SDR clocks compared to the reference. As
they drift over time the windown need to shift, but you can keep track
of the number of samples shifts to keep full track of it. This should
give you enough phase and frequency information. Toss in a least square
or Kalman if you think it would help.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Achim Gratz]

Jim Lux writes:
> 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.

A maybe not-so obvious approach would be to use RTL-SDR that have been
modified for direct sampling (usually via the Q branch) and inject your
timing pulse there.  That would limit the disturbance of the actual
signal while still relatively easy to extract from the data stream.

> 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 trouble is that you are going to impair the already low dynamic
range.  The ENOB on the I/Q ADC is around 7bit only.

> 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.

Not all of these are created equal.  Several manufacturers claim to
factory calibrate their TCXO to better than 0.5ppm.  I have currently
two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
so it definitely takes some time before they stabilize even if they do
have a TCXO in them.

> 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..

There is a program called rtl_test that just checks how many samples it
gets in a certain amount of time.  Let it run for a few hours on a PC
with a GPS-disciplined PC clock and it'll give you a pretty accurate
estimate of the mean sampling clock deviation.

The other method is to tune to a signal of known frequency and check
what it reads as.  There is a program floating around that uses a GSM
station for that purpose.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[jimlux]

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  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 

Re: [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  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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.