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

You'd have to look at the detailed specs of the ADF4001 PLL chip that is used to steer the VCTCXO. That chip doesn't, as far as I know, have a "reference quality metric" output, and if it does, UHD doesn't expose it. On 2017-10-03 11:44, Dario Fertonani via USRP-users 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

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@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 > >

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@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 >> >> >

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@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@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 >>> >>> >> >