Re: [time-nuts] getting accurate timing on RTL-SDR output
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
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
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
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
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
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 quantization of the ADC, and probably not be the >>> sa
Re: [time-nuts] getting accurate timing on RTL-SDR output
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
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
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 an automated algorithm
Re: [time-nuts] getting accurate timing on RTL-SDR output
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.