Attached is the first few samples that show the clipping effect. I found that Wire Format is set to 'automatic.'
Thanks. On Wed, Mar 28, 2018 at 7:25 PM, Ahmed Hamza <ahamza1...@gmail.com> wrote: > 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
