[USRP-users] 10 MHz reference signal on B210

Dario Fertonani dario.fertonani at gmail.com
Tue Oct 10 11:11:30 EDT 2017


The key issues was "square wave". Once that waveform is used, as opposed to
a sine wave, everything works as expected in a wider range of Vpp values.

Thanks,
Dario

On Tue, Oct 3, 2017 at 11:05 AM, Dario Fertonani <dario.fertonani at gmail.com>
wrote:

> I'd like to assume that *OctoClock-G*'s 10 MHz output is good to use as
> 10 MHz input on B210 (and other) USRP boards, given who the vendor of
> OctoClock-G is.
> If this is a bad assumption, please correct me.
> if this is a good assumption, then I'll use the OctoClock-G specs
> <https://www.ettus.com/content/files/Octoclock_Spec_Sheet.pdf> to infer
> what a good 10 MHz input for USRP board looks like. Here's what said specs
> say about the 10 MHz signal produced:
> * 1.4 Vpp,
> * square wave,
> * 50 ohm impedance.
> I'll assume a good 10 MHz source has to match those specs. Comments?
>
> Thanks,
> Dario
>
>
>
> On Tue, Oct 3, 2017 at 10:49 AM, Vladimir Rytikov <kk6ygb at gmail.com>
> wrote:
>
>> 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/B200/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/20171010/73f50205/attachment-0002.html>


More information about the USRP-users mailing list