[USRP-users] 10 MHz reference signal on B210

Vladimir Rytikov kk6ygb at gmail.com
Tue Oct 3 13:49:51 EDT 2017


Dario,

10 MHz signal input is meat to be freq reference. If a radio could tell
that 10 MHz is not 10 MHz - there was no need to feed it externally. USRP
boards seem have +/1ppm freq stability. 1ppm means when you tell radio to
tune to 100 MHz - it might end up giving you 100 MHz + 100 Hz or might end
up at 100MHz - 100Hz or actually anywhere within that range and even jump
around depend on temperature for example. When you tell radio go to 2 GHz
it might go to 2 GHz +/- 2 kHz. it is not a big deal for some applications
while for other applications it is a problem.

there is some mentions of the spec for 10 MHz input: https://kb.ettus.com/B2
00/B210/B200mini/B205mini

based on AD4001 spec - it says it is CMOS square wave:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADF4001.pdf.
and reference signals goes almost directly to AD4001.
Power supply in B200 seems 3.3V. 2.9 V for min of logic 1.
and 0.4 V for max of logic 0. which makes me wonder what the USRP spec
means by mentioning higher voltages. In any case they seem have protective
diod which will clip the signal and probably add extra distortions to your
reference freq.


PPL on the radio will be happy to lock to whatever it gets and it will
treat it as 10 MHz. somehow could trigger however you are really far off -
like 20 MHz instead of 10 MHz. You can probably can build a counter (in
FPGA) which will run for a week off ref freq and off on board freq  and see
of you reference is doing worse than 1ppm or so.

Here is the video which tells you why devices have 10 MHz reference input -
that is probably should clear some of your questions:
https://www.youtube.com/watch?v=I55uLRRvLCU


there is another spec for clock - it's jitter. that one seems way more
important.  jitter hurts you in a way that you are not just off freq, but
your freq is constantly jumping around in some kind of random-ish pattern.
I see the USRP spec for it - however I can't really comment on that.


Thanks,
Vladimir


On Tue, Oct 3, 2017 at 8:44 AM, Dario Fertonani via USRP-users <
usrp-users at lists.ettus.com> wrote:

> I'm testing the behavior of B210-based systems, comparing the performance
> with "internal" and "external" (10 MHz) clock source. Expect for the
> following "is the 10 MHz input actually present" check running when the app
> starts, the two branches share the same code.
>
> rfBoardPtr->set_clock_source( "external" );
> sleep( 2 );//give board time to lock
> if ( rfBoardPtr->get_mboard_sensor( "ref_locked" ).to_bool( ) == false )
> {
>     throw std::runtime_error( "Unable to find a valid 10 MHz reference
> signal. Please check that the signal source is properly plugged in." );
> }
> rfBoardPtr->set_time_unknown_pps( 0.0 );
>
>
> Besides that check, is there a way of measuring the quality of the signal
> via (UHD) software API, ideally in a more granular way? The check above
> "passes" even when the input signal is poor, which I see by validating
> through external instruments the quality of the radio signal emitted by the
> board. Ideally, I'd want an API that tells me about such problems before I
> actually check the radio output. To be clear, these are relatively-minor
> radio issues, but are sufficient to reduce the DL peak rate of my LTE
> system from 150 Mbps to 50-100 Mbps with respect to a fully-functional
> board (either fed by "internal" clock source, or by a proper 10 MHz
> source). The quality of the radio output varies noticeably (at least when
> measured with advanced full-stack metrics) when I change the amplitude of
> the 10 MHz reference, which is surprising since said changes are within the
> recommended range of the 10 MHz reference. Could someone please confirm
> said specs, in terms of (peak-to-peak) amplitude and waveform (square,
> sine, ...)?
>
> Thanks,
> Dario
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171003/e080675e/attachment-0002.html>


More information about the USRP-users mailing list