Reference Clock power level for Ettus N210

Hi,

I’m using a USRP N210 and I need a 10 MHz reference clock. From
ettus.com I got:

"
Ref Clock - 10 MHz

Using an external 10 MHz reference clock, a square wave will offer the
best phase noise performance, but a sinusoid is acceptable. The
reference clock requires the following power level:

USRP2 5 to 15 dBm
N2XX 0 to 15 dBm
"

So in my case (N210) I should have a minimum 0 dBm signal.
Can someone confirm this information (N2XX 0 to 15 dBm) for N210? The
bad news for me is I have a -15dBm 10 MHz available…

Thank you,
Antonio

Hi,
looking at the N200 schematics from files.ettus.com, I’d say:
stick to the 0dBm, your clock signal has to pass a transformer and some
safety/matching circuitry and still ought to be more accurate than the
on-board VCTCXO; the clock multiplexer
(http://www.micrel.com/index.php/en/products/clock-timing/clock-data-distribution/multiplexers/article/29-sy89545l.html)
datasheet says it needs at least a voltage swing of 0.1V after that.
I’m not very much of a circuits person, but I think you won’t
deteriorate much of your clock accuracy by using a clock buffer, which
are quite inexpensive (if you need but one and are not afraid to
solder… TI gives away samples for free).
Then again, you’re trying to achieve a better clock performance than the
on-board 10MHz ref clock, so I guess you shouldn’t start introducing
cheap hardware in the clock signal path…

Greetings,
Marcus

PS: maybe the [email protected] mailing list is better suited
for this… I’ve added that to CC:

Thank you Marcus,
I will wait for some answers from [email protected] before
proceeding.

Best regards,
Antonio

We posted those numbers because they are the numbers we know will work
reliably. -15dBm is unlikely to work well, but you won’t damage
anything
by trying.

Matt

On Wed, Apr 23, 2014 at 3:43 PM, Antonio P.

On 04/23/2014 09:07 AM, Antonio P. wrote:

reference clock requires the following power level:
Antonio


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

Yup, the minimum is 0dBm.


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

On Wed, 23 Apr 2014 15:07:52 +0200
Antonio P. [email protected] wrote:

Using an external 10 MHz reference clock, a square wave will offer the
best phase noise performance, but a sinusoid is acceptable.

The difference between the phase noise of a square wave and a sinus
input is negligible in a radio application. Your system will be
dominated
by the noise of your input. Unless you are doing detection with very
long integration time (in the order of seconds and longer). And even
there i’m not sure whether it’s not still the input noise that’s
dominating
the performance instead of your reference clock noise. And in that case
you care more about close in phase noise which is dominated by
non-linear
mixing of low frequency noise sources into your signal, than what we
commonly refere to as jitter.

To get that down you want to:

  1. use sinusoidal input and not square wave
    Square wave has high frequency components, depending on the squaring
    buffer you will have considerable spectral components between 100MHz
    and 1GHz… or even more. Cables have worse and worse characteristics
    the higher you go. Also small impedance mismatches will lead to
    more severe reflections the higer the frequency is. Also as the
    temperature changes, you will have changing phase shifts for
    different
    frequency components (cables are non-linear in that regard).

  2. Change the clock multiplexer (SY89545) from a LVDS->LVDS type to a
    pure analog part. Or rather, remove it completely and go directly
    onto the AD9510

But that’s only the case if and only if you care about long integration
times and the 10th decimal point of performance.

For all else. Using a good quartz oscillator is more than good enough
and you dont need to care about anything but having approximately the
right signal levels.


The trouble with you, Shev, is you don’t say anything until you’ve saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the
heap
– Tirin, The Dispossessed, U. Le Guin

On Wed, 23 Apr 2014 17:37:44 +0200
Attila K. [email protected] wrote:

For all else. Using a good quartz oscillator is more than good enough
and you dont need to care about anything but having approximately the
right signal levels.

Let me give you a bit more information here.
According to the N210 schematics, the clock’s PLL has a BW of 3kHz.
This means that noise beyond 3kHz is dominated by the VCXO on board.
Noise blow 3kHz is dominated by the reference clock. This means, that
if you can keep the noise of the reference clock low at frequencies
lower
than 3kHz, then you will have good performance.

Depending on what you use as refernce clock, you have to identify the
noise sources and their properties and then work on those that have
most impact on your performance.

  Attila K.


The trouble with you, Shev, is you don’t say anything until you’ve saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the
heap
– Tirin, The Dispossessed, U. Le Guin

On 04/23/2014 09:31 AM, Marcus M. wrote:

solder… TI gives away samples for free).
Then again, you’re trying to achieve a better clock performance than
the on-board 10MHz ref clock, so I guess you shouldn’t start
introducing cheap hardware in the clock signal path…

Greetings,
Marcus

PS: maybe the [email protected] mailing list is better suited
for this… I’ve added that to CC:

I think the main thing to watch out for with clock buffers is their
linearity, since low-level non-linearity effects can increase
phase-noise.
Perhaps not a lot, but a little.

I’d use a clock buffer, and see.


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

Thank you all for the precious suggestions.

Antonio

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs