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
<mailto: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>
<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>
<mailto: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>
<mailto: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
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>>
mailman/listinfo/usrp-users_lists.ettus.com
<http://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
