Samuel: Possibly the difference between "<" and "<=" will make some difference in the hardware lineup, but it should, as you point out, be "memoryless". What version of UHD are you using? On 2017-02-22 17:22, Samuel Prager wrote: > Hi Marcus, > > Thanks for the response. Regardless of the number of times hardware is switched, we would expect that going from: > > 100 Mhz --> 1 Ghz > > would yield the same end result as going from: > > 100 Mhz --> 500 Mhz --> 1 Ghz. > > However, this is not the case. (The former results is an unusably degraded operational state). > > In practice, this means that in order to go from 100 mhz to 1 ghz, we must first tune to a freq s.t. 500 mhz <= freq < 1 ghz. Otherwise, our application will quietly suffer an unacceptable loss in performance. > > Shouldn't the hardware set be determined only by the current frequency ie. essentially memoryless? > > We have noticed that the methods _set_tx_freq(__double freq__)_ and _set_rx_freq(double freq)_ in _db_ubx.cpp_ use slightly different bounds in their respective if...else statements. i.e.: > > In _set_tx_freq(__double freq__): _ > _ _ > >>   else if ((freq > (800*fMHz)) && (freq <= (1000*fMHz))) >> >> { >> >> set_cpld_field(TXLO1_FSEL3, 0); >> >> set_cpld_field(TXLO1_FSEL2, 0); >> >> set_cpld_field(TXLO1_FSEL1, 1); >> >> set_cpld_field(TXLB_SEL, 0); >> >> set_cpld_field(TXHB_SEL, 1); >> >> freq_lo1 = _txlo1->set_frequency(freq, ref_freq, target_pfd_freq, is_int_n); >> >> _txlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); >> >> } > > In _set_rx_freq(__double freq__): _ > _ _ > >>   else if ((freq >= 800*fMHz) && (freq < 1000*fMHz)) >> >> { >> >> set_cpld_field(SEL_LNA1, 0); >> >> set_cpld_field(SEL_LNA2, 1); >> >> set_cpld_field(RXLO1_FSEL3, 0); >> >> set_cpld_field(RXLO1_FSEL2, 0); >> >> set_cpld_field(RXLO1_FSEL1, 1); >> >> set_cpld_field(RXLB_SEL, 0); >> >> set_cpld_field(RXHB_SEL, 1); >> >> freq_lo1 = _rxlo1->set_frequency(freq, ref_freq, target_pfd_freq, is_int_n); >> >> _rxlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); >> >> } > > Is it possible that this is of any consequence? > > Sam > > On Feb 22, 2017, 12:38 PM -0800, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com>, wrote: > > On 02/22/2017 03:26 PM, Samuel Prager via USRP-users wrote: > Hello, > > We are experiencing an issue with our UBX-160 when tuning to a sequence of center frequencies with _set_rx_frequency()_ and _set_tx_frequency()_ in which tuning to center frequencies in a particular order consistently results in significant degradation of the received signal. > > Sequence A: > 100 MHz (default) --> 1000 MHz --> 500 MHz > > Sequence B: > 100 MHz (default) --> 500 MHz --> 1000 MHz > > We are transmitting identical waveforms (non continuously, with prf of ~100 ms in external loopback with 30 dB attenuation) and estimate the PSD of the rx signal and apply a matched filter. > > With sequence A, the RX signal for both 1GHz and 500 MHz is ~4 dB weaker and has a noticeably attenuated/rounded spectrum in comparison to sequence B. The matched filter output is significantly degraded for sequence A. The issues seen with sequence A are repeatable and can be corrected at any time by tuning according to sequence B. > > I am guessing that this is caused by an issue in db_ubx.cpp. Is there a fix for this? We are on the rfnoc-devel branch of uhd and are up to date with commit 2cf80a6. > > Thank you, > > Sam > > The analog signal chain is slightly different above 500MHz. Internally, the UBX is a superhet implementation, and there's a switch of IF > schemes and analog bits and pieces (amplifiers, etc) at 500Mhz, from what I recall. > > In sequence (B), you're likely staying with one set of hardware until you go to 1000MHz, and with sequence (A) you're switching twice. > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=B7ggal6dWXv9lWaY_uyVSibLwQAv_0bX6_CQ-3QOWFA&s=JORokZIFg2ZqhJeGXPxFwE62pnWYYxbTyKWurzt1uXU&e= 

Output from build this morning: > Building version: 4.0.0.rfnoc-devel-235-g094c587b As of this morning we've incorporated all the latest changes from uhd rfnoc-devel branch (commit 2cf80a6) Sam On Feb 22, 2017, 2:38 PM -0800, mleech@ripnet.com, wrote: > Samuel: > Possibly the difference between "<" and "<=" will make some difference in the hardware lineup, but it should, as you point out, be "memoryless". > What version of UHD are you using? > > > > On 2017-02-22 17:22, Samuel Prager wrote: > > Hi Marcus, > > > > Thanks for the response. Regardless of the number of times hardware is switched, we would expect that going from: > > > > 100 Mhz —> 1 Ghz > > > > would yield the same end result as going from: > > > > 100 Mhz —> 500 Mhz —> 1 Ghz. > > > > However, this is not the case. (The former results is an unusably degraded operational state). > > > > In practice, this means that in order to go from 100 mhz to 1 ghz, we must first tune to a freq s.t. 500 mhz <= freq < 1 ghz. Otherwise, our application will quietly suffer an unacceptable loss in performance. > > > > Shouldn't the hardware set be determined only by the current frequency ie. essentially memoryless? > > > > We have noticed that the methods set_tx_freq(double freq) and set_rx_freq(double freq) in db_ubx.cpp use slightly different bounds in their respective if...else statements. i.e.: > > > > In set_tx_freq(double freq): > > > > >   else if ((freq > (800*fMHz)) && (freq <= (1000*fMHz))) > > >         { > > >             set_cpld_field(TXLO1_FSEL3, 0); > > >             set_cpld_field(TXLO1_FSEL2, 0); > > >             set_cpld_field(TXLO1_FSEL1, 1); > > >             set_cpld_field(TXLB_SEL, 0); > > >             set_cpld_field(TXHB_SEL, 1); > > >             freq_lo1 = _txlo1->set_frequency(freq, ref_freq, target_pfd_freq, is_int_n); > > >             _txlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); > > >         } > > > > In set_rx_freq(double freq): > > > > >   else if ((freq >= 800*fMHz) && (freq < 1000*fMHz)) > > >         { > > >             set_cpld_field(SEL_LNA1, 0); > > >             set_cpld_field(SEL_LNA2, 1); > > >             set_cpld_field(RXLO1_FSEL3, 0); > > >             set_cpld_field(RXLO1_FSEL2, 0); > > >             set_cpld_field(RXLO1_FSEL1, 1); > > >             set_cpld_field(RXLB_SEL, 0); > > >             set_cpld_field(RXHB_SEL, 1); > > >             freq_lo1 = _rxlo1->set_frequency(freq, ref_freq, target_pfd_freq, is_int_n); > > >             _rxlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); > > >         } > > > > Is it possible that this is of any consequence? > > > > Sam > > > > On Feb 22, 2017, 12:38 PM -0800, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com>, wrote: > > > On 02/22/2017 03:26 PM, Samuel Prager via USRP-users wrote: > > > > Hello, > > > > > > > > We are experiencing an issue with our UBX-160 when tuning to a sequence of center frequencies with  set_rx_frequency() and  set_tx_frequency() in which tuning to center frequencies in a particular order consistently results in significant degradation of the received signal. > > > > > > > > Sequence A: > > > > 100 MHz (default) —> 1000 MHz —> 500 MHz > > > > > > > > Sequence B: > > > > 100 MHz (default) —> 500 MHz —> 1000 MHz > > > > > > > > We are transmitting identical waveforms (non continuously, with prf of ~100 ms in external loopback with 30 dB attenuation) and estimate the PSD of the rx signal and apply a matched filter. > > > > > > > > With sequence A, the RX signal for both 1GHz and 500 MHz is ~4 dB weaker and has a noticeably attenuated/rounded spectrum in comparison to sequence B. The matched filter output is significantly degraded for sequence A. The issues seen with sequence A are repeatable and can be corrected at any time by tuning according to sequence B. > > > > > > > > I am guessing that this is caused by an issue in db_ubx.cpp. Is there a fix for this? We are on the rfnoc-devel branch of uhd and are up to date with commit 2cf80a6. > > > > > > > > Thank you, > > > > > > > > Sam > > > > > > > > > > > The analog signal chain is slightly different above 500MHz.  Internally, the UBX is a superhet implementation, and there's a switch of IF > > >   schemes and analog bits and pieces (amplifiers, etc) at 500Mhz, from what I recall. > > > > > > In sequence (B), you're likely staying with one set of hardware until you go to 1000MHz, and with sequence (A) you're switching twice. > > > > > > > > > _______________________________________________ > > > USRP-users mailing list > > > USRP-users@lists.ettus.com > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=B7ggal6dWXv9lWaY_uyVSibLwQAv_0bX6_CQ-3QOWFA&s=JORokZIFg2ZqhJeGXPxFwE62pnWYYxbTyKWurzt1uXU&e=

Hi Sam, There should not be a boundary difference between the TX side and RX side at 1 GHz. We will fix that. Regardless, you should see the same result at a given frequency no matter what the sequence is. One thought is a possible epsilon issue. The frequencies are double values. If you are doing arithmetic operations to calculate the frequencies, you could actually be calling the functions with slightly different values in each case. Regards, Michael On Wed, Feb 22, 2017 at 2:58 PM, Samuel Prager via USRP-users < usrp-users@lists.ettus.com> wrote: > Output from build this morning: > > Building version: 4.0.0.rfnoc-devel-235-g094c587b > > > As of this morning we've incorporated all the latest changes from uhd > rfnoc-devel branch (commit 2cf80a6) > > Sam > > On Feb 22, 2017, 2:38 PM -0800, mleech@ripnet.com, wrote: > > Samuel: > > Possibly the difference between "<" and "<=" will make some difference in > the hardware lineup, but it should, as you point out, be "memoryless". > > What version of UHD are you using? > > > > > > > On 2017-02-22 17:22, Samuel Prager wrote: > > Hi Marcus, > > Thanks for the response. Regardless of the number of times hardware is > switched, we would expect that going from: > > 100 Mhz —> 1 Ghz > > would yield the same end result as going from: > > 100 Mhz —> 500 Mhz —> 1 Ghz. > > However, this is not the case. (The former results is an unusably degraded > operational state). > > In practice, this means that in order to go from 100 mhz to 1 ghz, we must > first tune to a freq s.t. 500 mhz <= freq < 1 ghz. Otherwise, our > application will quietly suffer an unacceptable loss in performance. > > Shouldn't the hardware set be determined only by the current frequency ie. > essentially memoryless? > > We have noticed that the methods *set_tx_freq(**double freq**)* and *set_rx_freq(double > freq)* in *db_ubx.cpp* use slightly different bounds in their respective > if...else statements. i.e.: > > In *set_tx_freq(**double freq**): * > > > else if ((freq > (800*fMHz)) && (freq <= (1000*fMHz))) > { > set_cpld_field(TXLO1_FSEL3, 0); > set_cpld_field(TXLO1_FSEL2, 0); > set_cpld_field(TXLO1_FSEL1, 1); > set_cpld_field(TXLB_SEL, 0); > set_cpld_field(TXHB_SEL, 1); > freq_lo1 = _txlo1->set_frequency(freq, ref_freq, > target_pfd_freq, is_int_n); > _txlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); > } > > > In *set_rx_freq(**double freq**): * > > > else if ((freq >= 800*fMHz) && (freq < 1000*fMHz)) > { > set_cpld_field(SEL_LNA1, 0); > set_cpld_field(SEL_LNA2, 1); > set_cpld_field(RXLO1_FSEL3, 0); > set_cpld_field(RXLO1_FSEL2, 0); > set_cpld_field(RXLO1_FSEL1, 1); > set_cpld_field(RXLB_SEL, 0); > set_cpld_field(RXHB_SEL, 1); > freq_lo1 = _rxlo1->set_frequency(freq, ref_freq, > target_pfd_freq, is_int_n); > _rxlo1->set_output_power(max287x_iface::OUTPUT_POWER_5DBM); > } > > > Is it possible that this is of any consequence? > > Sam > > On Feb 22, 2017, 12:38 PM -0800, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com>, wrote: > > On 02/22/2017 03:26 PM, Samuel Prager via USRP-users wrote: > > Hello, > > We are experiencing an issue with our UBX-160 when tuning to a sequence of > center frequencies with *set_rx_frequency()* and *set_tx_frequency()* in > which tuning to center frequencies in a particular order consistently > results in significant degradation of the received signal. > > Sequence A: > 100 MHz (default) —> 1000 MHz —> 500 MHz > > Sequence B: > 100 MHz (default) —> 500 MHz —> 1000 MHz > > We are transmitting identical waveforms (non continuously, with prf of > ~100 ms in external loopback with 30 dB attenuation) and estimate the PSD > of the rx signal and apply a matched filter. > > With sequence A, the RX signal for both 1GHz and 500 MHz is ~4 dB weaker > and has a noticeably attenuated/rounded spectrum in comparison to sequence > B. The matched filter output is significantly degraded for sequence A. The > issues seen with sequence A are repeatable and can be corrected at any time > by tuning according to sequence B. > > I am guessing that this is caused by an issue in db_ubx.cpp. Is there a > fix for this? We are on the rfnoc-devel branch of uhd and are up to date > with commit 2cf80a6. > > Thank you, > > Sam > > > > The analog signal chain is slightly different above 500MHz. Internally, > the UBX is a superhet implementation, and there's a switch of IF > schemes and analog bits and pieces (amplifiers, etc) at 500Mhz, from > what I recall. > > In sequence (B), you're likely staying with one set of hardware until you > go to 1000MHz, and with sequence (A) you're switching twice. > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists. > ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c= > clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m= > B7ggal6dWXv9lWaY_uyVSibLwQAv_0bX6_CQ-3QOWFA&s= > JORokZIFg2ZqhJeGXPxFwE62pnWYYxbTyKWurzt1uXU&e= > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >