dual coherent channel rtl_sdr

[Juha Vierinen-2]

I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). 

You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. 

juha

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

I did a similar experiment with R820T based dongles using an external high quality reference and a common signal source.

The results were poor with a lot of mutual phase noise between two dongles.

What sample rates did you try and was this E4000 or R820T tuners?

--
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org


On Sep 23, 2013, at 7:59 AM, Juha Vierinen <[hidden email]> wrote:

> I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures).
>
> You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16.
>
> juha
> <rtl1.jpg>
> <rtl0.jpg>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

On 09/23/2013 10:59 AM, Juha Vierinen wrote:

I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). 

You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. 

juha

So, what were your test conditions?

I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles.

Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator.

The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display.

In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the
  two channels.





_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Ian Buckley-2]

On Sep 24, 2013, at 11:41 AM, Marcus D. Leech <[hidden email]> wrote:

> On 09/23/2013 10:59 AM, Juha Vierinen wrote:
>>
>> I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures).
>>
>> You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16.
>>
>> juha
>>
>>
> So, what were your test conditions?
>
> I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles.
>
> Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator.
>
> The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display.
>
> In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the
>   two channels.
>
> --
> Marcus Leech

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)

The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error!
Might also want to consider series termination for each cable to the boards to minimize SI issues also.
Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.

-Ian


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Ian Buckley-2]

On Sep 24, 2013, at 1:54 PM, Ian Buckley <[hidden email]> wrote:

On Sep 24, 2013, at 11:41 AM, Marcus D. Leech <[hidden email]> wrote:

On 09/23/2013 10:59 AM, Juha Vierinen wrote:

I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures).

You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16.

juha

So, what were your test conditions?

I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles.

Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator.

The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display.

In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the
 two channels.

--
Marcus Leech

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)

The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error!
Might also want to consider series termination for each cable to the boards to minimize SI issues also.
Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.

-Ian

Couple of random application notes on the topic:

http://www.maximintegrated.com/app-notes/index.mvp/id/3582

<a href="http://www.micrel.com/_PDF/App-Notes/clk/PAN0704111 - Replacing Crystals and Oscillators.pdf">http://www.micrel.com/_PDF/App-Notes/clk/PAN0704111%20-%20Replacing%20Crystals%20and%20Oscillators.pdf

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

On 09/24/2013 04:57 PM, Ian Buckley wrote:

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)

The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error!
Might also want to consider series termination for each cable to the boards to minimize SI issues also.
Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.

-Ian

Couple of random application notes on the topic:

http://www.maximintegrated.com/app-notes/index.mvp/id/3582

http://www.micrel.com/_PDF/App-Notes/clk/PAN0704111%20-%20Replacing%20Crystals%20and%20Oscillators.pdf

Just tried a series termination on each dongle, consisting of a 1000pF cap in series with a 200Ohm resistor on each arm.  It still is "sane" with a
  +3.3dBm sinusoidal input, but there's no difference in the relative phase-noise between both channels.




_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

On 09/25/2013 12:04 AM, Jared Clements wrote:

>
> Hi Marcus,
>
> Interesting discussion. I was wondering how well synchronized clocking
> might work.  Was hoping it would work better than it sounds.  Could
> you quantify the level of phase noise you're seeing, like with a power
> spectral density  plot?  Just for curiosity's sake?
>
> I know of a recently updated OOT module that should have the blocks
> you need ;-)
>
> I was hoping to build a correlating interferometer by modifying
> several of these dongles to run off the same clock.  I may need to
> rethink the plan.
>
> Jared
>

I'll get to that tomorrow night.

I just ran a simulation of what I was observing (just because the lab is
downstairs, and I'm upstairs).

Looks like the best it does is about -40dB/c  75kHz from the carrier.  
That's bluddy awful.



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Juha Vierinen-2]

Hi guys,

Based on my very limited understanding on electronics, osclilators and other such things, I would expect oscillator effects to cancel out when looking at the relative phase of two channels. I would expect the phase jitter on the relative phase to be dominated by what happens in the ADC and the digital down conversion. That is why I am running the two dongles off the same clock.  

I have some measurements of the relative IQ signal (z_1/z_2) at 100 kHz, 10 Hz, and 1 Hz sample rates. I did a power spectrum estimate using a Hanning window to look at relative phase noise. I didn't do any incoherent averaging on any of these, so there is some statistical noise. I only see some "imperfections" in the 10 Hz and 1 Hz spectrum.  However, I see these kinds of effects in 100 times more expensive receivers too. For my purposes, the relative phase behaviour of the two channels is good enough. 

I have attached the spectra. I have also attached the 1 Hz IQ signal, which shows a small systematic wiggle, but very little phase difference between the two channels.

The samples also are aligned over two hours of sampling, which means that there cannot really be a very large amount of clock drift between the two systems.

Sure, the thing has it's faults. But with $16, you really can't beat the price. 

juha

On Wed, Sep 25, 2013 at 1:21 AM, Marcus D. Leech <[hidden email]> wrote:

On 09/25/2013 12:04 AM, Jared Clements wrote:

Hi Marcus,

Interesting discussion. I was wondering how well synchronized clocking might work.  Was hoping it would work better than it sounds.  Could you quantify the level of phase noise you're seeing, like with a power spectral density  plot?  Just for curiosity's sake?

I know of a recently updated OOT module that should have the blocks you need ;-)

I was hoping to build a correlating interferometer by modifying several of these dongles to run off the same clock.  I may need to rethink the plan.

Jared

I'll get to that tomorrow night.

I just ran a simulation of what I was observing (just because the lab is downstairs, and I'm upstairs).

Looks like the best it does is about -40dB/c  75kHz from the carrier.  That's bluddy awful.



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

Hmmm, interesting.

Was this with E4000 tuners, or R820T tuners?

 

What was your exact test setup, tuned-frequency, etc?

 

 

 

on Sep 25, 2013, Juha Vierinen <[hidden email]> wrote:

Hi guys,

 

Based on my very limited understanding on electronics, osclilators and other such things, I would expect oscillator effects to cancel out when looking at the relative phase of two channels. I would expect the phase jitter on the relative phase to be dominated by what happens in the ADC and the digital down conversion. That is why I am running the two dongles off the same clock.  

 

I have some measurements of the relative IQ signal (z_1/z_2) at 100 kHz, 10 Hz, and 1 Hz sample rates. I did a power spectrum estimate using a Hanning window to look at relative phase noise. I didn't do any incoherent averaging on any of these, so there is some statistical noise. I only see some "imperfections" in the 10 Hz and 1 Hz spectrum.  However, I see these kinds of effects in 100 times more expensive receivers too. For my purposes, the relative phase behaviour of the two channels is good enough. 

 

I have attached the spectra. I have also attached the 1 Hz IQ signal, which shows a small systematic wiggle, but very little phase difference between the two channels.

 

The samples also are aligned over two hours of sampling, which means that there cannot really be a very large amount of clock drift between the two systems.

 

Sure, the thing has it's faults. But with $16, you really can't beat the price. 

 

juha

On Wed, Sep 25, 2013 at 1:21 AM, Marcus D. Leech <[hidden email]> wrote:

On 09/25/2013 12:04 AM, Jared Clements wrote:

Hi Marcus,

Interesting discussion. I was wondering how well synchronized clocking might work.  Was hoping it would work better than it sounds.  Could you quantify the level of phase noise you're seeing, like with a power spectral density  plot?  Just for curiosity's sake?

I know of a recently updated OOT module that should have the blocks you need ;-)

I was hoping to build a correlating interferometer by modifying several of these dongles to run off the same clock.  I may need to rethink the plan.

Jared

I'll get to that tomorrow night.

I just ran a simulation of what I was observing (just because the lab is downstairs, and I'm upstairs).

Looks like the best it does is about -40dB/c  75kHz from the carrier.  That's bluddy awful.



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

On 09/25/2013 02:01 PM, Juha Vierinen wrote:

Hi guys,

Based on my very limited understanding on electronics, osclilators and other such things, I would expect oscillator effects to cancel out when looking at the relative phase of two channels. I would expect the phase jitter on the relative phase to be dominated by what happens in the ADC and the digital down conversion. That is why I am running the two dongles off the same clock.  

I have some measurements of the relative IQ signal (z_1/z_2) at 100 kHz, 10 Hz, and 1 Hz sample rates. I did a power spectrum estimate using a Hanning window to look at relative phase noise. I didn't do any incoherent averaging on any of these, so there is some statistical noise. I only see some "imperfections" in the 10 Hz and 1 Hz spectrum.  However, I see these kinds of effects in 100 times more expensive receivers too. For my purposes, the relative phase behaviour of the two channels is good enough. 

I have attached the spectra. I have also attached the 1 Hz IQ signal, which shows a small systematic wiggle, but very little phase difference between the two channels.

The samples also are aligned over two hours of sampling, which means that there cannot really be a very large amount of clock drift between the two systems.

Sure, the thing has it's faults. But with $16, you really can't beat the price. 

juha

On Wed, Sep 25, 2013 at 1:21 AM, Marcus D. Leech <[hidden email]> wrote:

On 09/25/2013 12:04 AM, Jared Clements wrote:

Hi Marcus,

Interesting discussion. I was wondering how well synchronized clocking might work.  Was hoping it would work better than it sounds.  Could you quantify the level of phase noise you're seeing, like with a power spectral density  plot?  Just for curiosity's sake?

I know of a recently updated OOT module that should have the blocks you need ;-)

I was hoping to build a correlating interferometer by modifying several of these dongles to run off the same clock.  I may need to rethink the plan.

Jared

I'll get to that tomorrow night.

I just ran a simulation of what I was observing (just because the lab is downstairs, and I'm upstairs).

Looks like the best it does is about -40dB/c  75kHz from the carrier.  That's bluddy awful.



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Here are some plots I made.

Along with the .grc file I used to produce them.   The RTL has 30dB worse phase noise, under the test conditions, at 100kHz offset.

Not wonderful, but not entirely unusable either.








_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Juha Vierinen-2]

Hi, 

I modified my clock sharing so that I only insert a signal in the Xtal_In pin of other dongle. This way I won't have two circuits driving the same crystal, as Ian pointed out. The pin next to the edge of the dongle turned out to be the Xtal_In pin (the input of the opamp on the slave dongle). The dual coherent rtlsdr dongle still works the same. I guess I was lucky to get it working the first time.

I am working towards setting up a fanout buffer, to do this properly.  

juha

On Tue, Sep 24, 2013 at 4:54 PM, Ian Buckley <[hidden email]> wrote:

On Sep 24, 2013, at 11:41 AM, Marcus D. Leech <[hidden email]> wrote:

> On 09/23/2013 10:59 AM, Juha Vierinen wrote:
>>
>> I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures).
>>
>> You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16.
>>
>> juha
>>
>>
> So, what were your test conditions?
>
> I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles.
>
> Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator.
>
> The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display.
>
> In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the
>   two channels.
>
> --
> Marcus Leech

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)

The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error!
Might also want to consider series termination for each cable to the boards to minimize SI issues also.
Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.

-Ian

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus D. Leech]

Well, I certainly would be keen to hear your further reports on this.

One thing to consider is that if you're going to build a fan-out buffer, you might as well build a 28.8MHz source using one of the easily-available 14.4Mhz TCXOs that are "out there", and design

  a doubler--this will give you a clock source that's about 2.5PPM, instead of the 100-150PPM of the "native" crystal.

 

I've found that the dongles require about 0dBm on the Xtal_In pin to work reliably, so you need about +3dBm for two of them, etc.

 

 

on Sep 26, 2013, Juha Vierinen <[hidden email]> wrote:

Hi, 

 

I modified my clock sharing so that I only insert a signal in the Xtal_In pin of other dongle. This way I won't have two circuits driving the same crystal, as Ian pointed out. The pin next to the edge of the dongle turned out to be the Xtal_In pin (the input of the opamp on the slave dongle). The dual coherent rtlsdr dongle still works the same. I guess I was lucky to get it working the first time.

 

I am working towards setting up a fanout buffer, to do this properly.  

 

juha

On Tue, Sep 24, 2013 at 4:54 PM, Ian Buckley <[hidden email]> wrote:

On Sep 24, 2013, at 11:41 AM, Marcus D. Leech <[hidden email]> wrote:

> On 09/23/2013 10:59 AM, Juha Vierinen wrote:
>>
>> I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures).
>>
>> You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16.
>>
>> juha
>>
>>
> So, what were your test conditions?
>
> I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles.
>
> Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator.
>
> The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display.
>
> In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the
>   two channels.
>
> --
> Marcus Leech

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)

The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error!
Might also want to consider series termination for each cable to the boards to minimize SI issues also.
Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.

-Ian

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Heath Hunnicutt]

Juha,

Ordinarily, I would choose to feed a clock into xtal_in, this seems logical.  However check out the Elonics patent:

http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html

The main thing to note is that square-wave clock input should be fed to xtal_in for the elonics chip.

If you read that patent, it may give you some ideas about feeding a clock to xtal_in of other chips.  Maybe other chips will also expect a sawtooth in the linear region of voltage swing, not rail-to-rail square wave.  Note the comments in that patent on jitter at square wave, etc.,

Nobody on this thread has stated whether they are using e4000 or r820.  That would probably be helpful.

[Heath Hunnicutt]

Bah!!!  The main thing to note is that the e4000 expects a clock input on XTAL_OUT.  That's right, the patent says that out can be an in, for the e4000.  Sorry I made a post in which I made a thought mistake and typed the opposite.

[Marcus D. Leech]

On 09/26/2013 06:32 PM, Heath Hunnicutt wrote:

> Juha,
>
> Ordinarily, I would choose to feed a clock into xtal_in, this seems logical.
> However check out the Elonics patent:
>
> http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html
>
> The main thing to note is that square-wave clock input should be fed to
> xtal_in for the elonics chip.
>
> If you read that patent, it may give you some ideas about feeding a clock to
> xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
> the linear region of voltage swing, not rail-to-rail square wave.  Note the
> comments in that patent on jitter at square wave, etc.,
>
> Nobody on this thread has stated whether they are using e4000 or r820.  That
> would probably be helpful.
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Well, my tests have been with R820T, which has a clock output that goes
to the RTL2832U chip.

I've actually tried both sides of Xtal_I and Xtal_O on the R820T, and it
makes no difference.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Juha Vierinen]

I use R820T. It has nonzero IF and the noise is relatively flat.

The clock looks sawtooth-like on the scope.

Juha

On 26.9.2013, at 18.32, Heath Hunnicutt <[hidden email]> wrote:

> Juha,
>
> Ordinarily, I would choose to feed a clock into xtal_in, this seems logical.
> However check out the Elonics patent:
>
> http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html
>
> The main thing to note is that square-wave clock input should be fed to
> xtal_in for the elonics chip.
>
> If you read that patent, it may give you some ideas about feeding a clock to
> xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
> the linear region of voltage swing, not rail-to-rail square wave.  Note the
> comments in that patent on jitter at square wave, etc.,
>
> Nobody on this thread has stated whether they are using e4000 or r820.  That
> would probably be helpful.
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Heath Hunnicutt]

I wonder, since you are emulating the crystal output, if the R820T would ordinarily drive the crystal to rail-to-rail, square wave output.  It might be worthwhile using a high impedence probe to see what the signal you are replacing looks like.

I say this because the elonics patent suggests that staying in the linear region of the amplifiers in the feedback circuit (not rail to rail) reduces jitter.

On Thu, Sep 26, 2013 at 3:41 PM, Marcus D. Leech <[hidden email]> wrote:

On 09/26/2013 06:32 PM, Heath Hunnicutt wrote:

Juha,

Ordinarily, I would choose to feed a clock into xtal_in, this seems logical.
However check out the Elonics patent:

http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html

The main thing to note is that square-wave clock input should be fed to
xtal_in for the elonics chip.

If you read that patent, it may give you some ideas about feeding a clock to
xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
the linear region of voltage swing, not rail-to-rail square wave.  Note the
comments in that patent on jitter at square wave, etc.,

Nobody on this thread has stated whether they are using e4000 or r820.  That
would probably be helpful.




--
View this message in context: http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Well, my tests have been with R820T, which has a clock output that goes to the RTL2832U chip.

I've actually tried both sides of Xtal_I and Xtal_O on the R820T, and it makes no difference.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio