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.ferton...@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 <kk6...@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@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@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
