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@lists.ettus.com <mailto:usrp-users@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 <i...@ionconcepts.com
<mailto:i...@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@lists.ettus.com
<mailto:usrp-users@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@lists.ettus.com <mailto: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 <mailto: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 <mailto: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
