[USRP-users] The problem with setting the frequency of USRP B 210.

Marcus D. Leech patchvonbraun at gmail.com
Tue Mar 12 10:34:37 EDT 2019


On 03/12/2019 10:26 AM, Ivan Zahartchuk wrote:
> Sorry, but I do not fully understand how to work with frequency 
> offset. For example, I have an instantaneous bandwidth of 25 MHz. Then 
> I set the frequency offset to 13 MHz? Because my amplitude decreases, 
> but the peak still remains with a large amplitude.
Here is the API documentation for tuning:

https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

If you are using an offset, with that API, and you still have a peak at 
the notional center frequency, then it is NOT DC offset, but coming
   from somewhere else.


>
> вт, 12 мар. 2019 г. в 15:13, Marcus D. Leech via USRP-users 
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>>:
>
>     On 03/12/2019 05:13 AM, Ivan Zahartchuk via USRP-users wrote:
>>     Thanks for the information. But do not tell me why then in N 210
>>     with sbx there is no such problem? Just in the N 210 I am not
>>     satisfied with the large central frequency. As I understand this
>>     is a surge in direct current. But I can't get rid of him. And
>>     sometimes there are problems with the mirror channel. If you have
>>     any advice on this, I will be extremely grateful.
>     Because the SBX is a different piece of hardware, with different
>     architecture.  It happens to tune a lot faster.
>
>     The DC offset can be dealt with using offset tuning:
>
>     https://files.ettus.com/manual/page_general.html
>
>     If you are seeing image frequencies, then use the
>
>     uhd_cal_rx_iq_balance
>
>     Utility on your N210 to caclulate and record calibration
>     parameters that will help to reduce I/Q imbalance.  DC offset and
>     I/Q imbalance are
>       inherent in a direct-conversion receiver design.  These
>     imbalances need to be calibrated out.  In the N210/SBX, host-side
>     software does
>       "static' measurement of these (using the above mentioned
>     tooling) and records a calibrations file.  Those calibrations are
>     then applied
>       at run-time to compensate.
>
>     In the B210, the AD9361 chip does I/Q correction (and other
>     corrections) dynamically, which can cause it to be slower in
>     tuning--because it
>       does the measurements whenever you re-tune.
>
>     See:
>
>     https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms1-ebz/iq_correction
>
>     For a discussion
>
>>
>>     пн, 11 мар. 2019 г. в 17:17, Ian Buckley <ianb at ionconcepts.com
>>     <mailto:ianb at ionconcepts.com>>:
>>
>>         Ivan,
>>         When the AD9361 is retuned, recalibration of various RF
>>         circuits may (need to) reoccur. The device driver looks how
>>         far you have retuned from a previous frequency, and if it
>>         exceeds a certain distance rerun’s this calibration, which
>>         takes time.
>>         Since Analog devices envisaged that this chip might need to
>>         be used in applications where fast hopping is required, it
>>         does have the ability to store multiple calibration settings
>>         locally in the radio and switch between them quickly, but
>>         this is not functionality that is used in basic operation
>>         under UHD. We may well have put API hook’s in there so you
>>         can manually call this functionality under UHD, but I can’t
>>         recall. Take a look at ADI’s documentation for more info.
>>
>>         -Ian
>>
>>         > On Mar 11, 2019, at 7:49 AM, Ivan Zahartchuk via USRP-users
>>         <usrp-users at lists.ettus.com
>>         <mailto:usrp-users at lists.ettus.com>> wrote:
>>         >
>>         > Hello. I have a problem with the usrp b200 board. I need a
>>         fast frequency tuning for spectrum analysis. But when I
>>         increase the band over 200 MHz, that is, more than 8
>>         frequency adjustments, I have problems with time. It
>>         increases dramatically.
>>         > Here is the code section where I measure the execution time
>>         of the frequency setting function:
>>         > for i, freqq in enumerate (freq):
>>         >
>>         >             recv_samps = 0
>>         >             self.usrp.set_rx_rate (bandwich [i])
>>         >             start = time.time ()
>>         >             self.usrp.set_rx_freq (lib.types.tune_request
>>         (freqq))
>>         >
>>         >             print (time.time () - start)
>>         > And I get the following results:
>>         > 0.154153108597
>>         > 0.00300002098083
>>         > 0.0029628276825
>>         > 0.00299215316772
>>         > 0.00298380851746
>>         > 0.153974056244
>>         > 0.153841018677
>>         > 0.00304222106934
>>         > 0.00305104255676
>>         > 0.0030951499939
>>         > 0.0030038356781
>>         > 0.153944015503
>>         > 0.153861045837
>>         > 0.00292587280273
>>         > 0.00306510925293
>>         > 0.00301003456116
>>         > 0.0029399394989
>>         > With USRP N 210 there is no such problem. Tell me why this
>>         problem occurs and how can it be solved?
>>         > Thanks in advance. Ivan
>>         > _______________________________________________
>>         > USRP-users mailing list
>>         > USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>         >
>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>     _______________________________________________
>>     USRP-users mailing list
>>     USRP-users at lists.ettus.com  <mailto:USRP-users at lists.ettus.com>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto: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/20190312/a26ae4bf/attachment.html>


More information about the USRP-users mailing list