<div dir="ltr">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.<div><br></div><div>Thanks,</div><div>Dario</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 3, 2017 at 11:05 AM, Dario Fertonani <span dir="ltr"><<a href="mailto:dario.fertonani@gmail.com" target="_blank">dario.fertonani@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'd like to assume that <b><u>OctoClock-G</u></b>'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.<div>If this is a bad assumption, please correct me.</div><div>if this is a good assumption, then I'll use the OctoClock-G <a href="https://www.ettus.com/content/files/Octoclock_Spec_Sheet.pdf" target="_blank">specs</a> 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:</div><div>* 1.4 Vpp,</div><div>* square wave,</div><div>* 50 ohm impedance.</div><div>I'll assume a good 10 MHz source has to match those specs. Comments?</div><div><br></div><div>Thanks,</div><div>Dario</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 3, 2017 at 10:49 AM, Vladimir Rytikov <span dir="ltr"><<a href="mailto:kk6ygb@gmail.com" target="_blank">kk6ygb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Dario,</div><div><br></div>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.<div><br></div><div>there is some mentions of the spec for 10 MHz input: <a href="https://kb.ettus.com/B200/B210/B200mini/B205mini" target="_blank">https://kb.ettus.com/B2<wbr>00/B210/B200mini/B205mini</a></div><div><br></div><div>based on AD4001 spec - it says it is CMOS square wave: <a href="http://www.analog.com/media/en/technical-documentation/data-sheets/ADF4001.pdf" target="_blank">http://www.analog.com/me<wbr>dia/en/technical-documentation<wbr>/data-sheets/ADF4001.pdf</a>.  and reference signals goes almost directly to AD4001.</div><div>Power supply in B200 seems 3.3V. 2.9 V for min of logic 1.<br></div><div>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.</div><div><br></div><div><br></div><div>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.<br></div><div> </div><div>Here is the video which tells you why devices have 10 MHz reference input - that is probably should clear some of your questions: </div><div><a href="https://www.youtube.com/watch?v=I55uLRRvLCU" target="_blank">https://www.youtube.com/watch?<wbr>v=I55uLRRvLCU</a><br></div><div><br></div><div><br></div><div>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. </div><div><br></div><div><br></div><div>Thanks,</div><div>Vladimir</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-176896080714067013h5">On Tue, Oct 3, 2017 at 8:44 AM, Dario Fertonani via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-176896080714067013h5"><div dir="ltr"><div>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.</div><div><font face="monospace, monospace"><br></font></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">rfBoardPtr->set_clock_source( "external" );</font></div><div><font face="monospace, monospace">sleep( 2 );//give board time to lock</font></div><div><font face="monospace, monospace">if ( rfBoardPtr->get_mboard_sensor( "ref_locked" ).to_bool( ) == false )</font></div><div><font face="monospace, monospace">{</font></div><div><font face="monospace, monospace">    throw std::runtime_error( "Unable to find a valid 10 MHz reference signal. Please check that the signal source is properly plugged in." );</font></div><div><font face="monospace, monospace">}</font></div><div><span style="font-family:monospace,monospace">rfBoardPtr->set_time_unknown_p<wbr>ps( 0.0 );</span></div></blockquote><br><div>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, ...)?</div><div><br></div><div>Thanks,</div><div>Dario</div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman<wbr>/listinfo/usrp-users_lists.ett<wbr>us.com</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>