Hey, > Is your signal very narrowband?
Also, keep in mind, that the AGC defaults to the 'slow' mode when enabled. This mode is intended for signals like FM broadcast. So if your signal is coming in bursts, the AGC won't be able to handle it properly. Cheers, Julian Marcus D. Leech via USRP-users schrieb am 28.03.2018 22:16: > On 03/28/2018 01:50 PM, Ahmed Hamza wrote: > >> >> Hi Marcus, >> >> >> Thank you for your prompt response. >> >> >> I can change the TX power, kindly find attached the received "I" channel >> in case of TX power -25 dbm and -45 dbm. Also, there is about 10 dB >> attenuation before the Ettus RX. As you can see, there are many samples that >> goes to +/- 2048 and I believe that means ADC is overloaded. It is mentioned >> in the reference manual of Ad9364: >> >> "When the ADC is overloaded, the error between its samples and the input >> signal will cause the ADC to output more samples with values of +4 or −4 as >> it struggles to track the input signal.", is there anything else I can try? >> Note: Disabling AGC and changing gains gives reasonable outputs (i.e., >> amplitude of samples change with changing the applied gain without samples >> going to +/- 2048). But I need to use AGC because I want to have "over the >> air" testing instead of cable testing. >> >> >> Also, I tried to use --args type=b200 but it did not help. Is it possible >> after loading and executing the script top_block_py (i.e., while USB port is >> used to stream I/Q) to send commands for the board to get sample rate, >> carrier freq., gains,....? >> >> >> Thanks again, >> >> >> Best Regards, >> >> Ahmed >> > You can insert calls to API elements like get_rx_gain, from with a > flow-graph. However, for flow-graphs generated by GRC, it's a bit > tricky--you'll have to > add code after GRC has generated its output. > > See the section of the Gnu Radio manual here: > > https://gnuradio.org/doc/doxygen/group__uhd__blk.html > <https://gnuradio.org/doc/doxygen/group__uhd__blk.html> > > Is your signal very narrowband? The hardware AGC will be looking at the > entire input bandwidth to the ADC, which is large. Which means that a > narrowband > signal doesn't really "drive" the AGC very hard, so it gets "pinned" at max > gain. This is why hardware AGC is generally not super-useful. > > There's nothing inherently incompatible between manual, fixed, gain, and > doing over-the-air tests. It is typically the case in the DSP world that the > DSP flow handles AGC-like functions, because the DSP flow has a MUCH better > "view" of the intended signal bandwidth than the front-end of > the hardware. > > >> On Wed, Mar 28, 2018 at 12:29 PM, Marcus D. Leech via USRP-users >> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > wrote: >>> >>> >>> On 03/28/2018 11:32 AM, Ahmed Hamza via USRP-users wrote: >>> >>>> >>>> Hi, >>>> >>>> >>>> I am using Ettus B200 mini, to receive signal at carrier frequency 725 MHz >>>> and the bandwidth is 6 MHz. The sampling rate is set to 13.28 MHz. >>>> >>>> >>>> I enabled AGC by calling set_rx_agc() from set_gain inside >>>> /usrp_source_impl.cc. >>>> >>>> The thing is that I am receiving a signal with a maximum that reach +/- >>>> 2048 frequently so I believe that the ADC is overloaded. The test is using >>>> cable so it is supposed that there is no out of band interference. >>>> >>>> >>>> My questions are: >>>> >>>> 1) Do you know what may be causing this behavior and what should I try? >>>> >>>> 2) Where can I find the default values that Ettus B200 mini used for >>>> Ad9364 registers? >>>> >>>> 3) Is there a way to read and/or write values of Ad9364 registers? >>>> >>>> 4) There are some get functions provided by Ettus, could this get >>>> functions used in run time (I mean after loading the script)? For example, >>>> if I do, uhd_usrp_probe --string >>>> /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode/value after loading the >>>> script >>>> >>>> I get: linux; GNU C++ version 5.3.1 20151219; Boost_105800; >>>> UHD_003.009.002-0-unknown >>>> >>>> Error: LookupError: KeyError: No devices found for -----> >>>> >>>> Empty Device Address >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Best Regards, >>>> >>>> Ahmed >>>> >>>> >>> Reduce the power of the device that is sending the signal--use attenuators >>> if you have to. >>> >>> uhd_usrp_probe needs a device address: use --args type=b200 >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>> http://lists.ettus.com/ >>> <http://lists.ettus.com/mailman/listinfo/usrp-users_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
