Hi Marcus, Thanks for your reply. I am sure that I am using the correct format and that the maximum is +/- 2048 because I am able to decode the signal. Also, the capture plot I have given before was after 20 seconds of receiver operation but if I do not wait and capture from the first sample, I see the first part of the signal is clipped when values exceeds +/- 2048.
Best Regards, Ahmed On Wed, Mar 28, 2018 at 6:47 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 03/28/2018 05:59 PM, Ahmed Hamza wrote: > > Thanks Marcus and Julian for your responses. > The signal is not narrowband. It is 6 MHz bandwidth, please see the > attached snapshot from the GNU radio spectrum analyzer. > Also, the signal is continuous without gaps. The unique thing about the > signal is that it include contents on and surrounding the DC subcarrier. > This is why I disabled the BB DC offset tracking. Is there any relation > between DC offset tracking and AGC? > Another note, is that when AGC is disabled, although the transmitted > signal has almost constant amplitude, the received signal amplitude changes > in a consistent pattern as shown in the attached images. > > I would like to use HW AGC because I think to track channel variations > (due to Doppler and other factors), I need fast AGC, and I think the one on > the Ad9364 is suitable for this task, please correct me if I am wrong. > > Thanks again, > > Best Regards, > Ahmed > > So, looking at your plots, I realize that, unless you're using SC12 wire > format, you're several bits below ADC saturation, since the DSP framework > scales > the ADC results into the SC16 default wire format. > > > > > On Wed, Mar 28, 2018 at 4:33 PM, Julian Arnold <jul...@elitecoding.org> > wrote: > >> 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/mailma >> n/listinfo/usrp-users_lists.ettus.com> mailman/listinfo/usrp-users_li >> sts.ettus.com >> >>> >> >> >> > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
