Re: [USRP-users] TwinRx frequency range

[Matis Alun via USRP-users]

thanks a lot for these explanations.

matis

Le 27/03/2018 à 11:52, Derek Kozel a écrit :
> Hi Matis,
>
> The USRPs are generally designed following the rule of thumb that the 
> passband is 80% of
> sampling rate. That allows for filters, both analog and digital, to be 
> reasonable to
> construct. The TwinRX is tuning its analog center frequency to 50 MHz. With 
> the 100 MS/s
> complex sample rate frequencies from DC to 100 MHz are visible, but the 
> filters,
> amplifiers, and other elements of the receiver will degrade the receive 
> performance
> below 10 MHz. As you've found though, the degradation is very acceptable for 
> some
> applications.
>
> Marcus actually authored an app note looking at the same question with the UBX
> daughterboard.
> https://kb.ettus.com/Experiments_with_the_UBX_Daughterboard_in_the_HF_Band
>
> Regards,
> Derek
>
> On Sat, Mar 24, 2018 at 6:15 AM, Matis Alun via USRP-users 
>  > wrote:
>
> yes, its seems that we loose several dBs but which can be widely 
> compensated by the
> extremely large TwinRx gain range.
>
>
> Le 24/03/2018 à 06:38, Marcus D. Leech via USRP-users a écrit :
> > On 03/24/2018 12:41 AM, Matis Alun via USRP-users wrote:
> >> Hi,
> >>
> >> The TwinRx frequency specifications is from 10MHz to 6GHz.
> >>
> >> However, some tests shows that I can select the center frequency 
> around 10 MHz with a
> >> sampling frequency of 25MHz
> >> which allows to make some acquisitions in the HF band (3-30 MHz) with 
> a very good
> quality.
> >>
> >> My question is: why the specs limits to 10 MHz ? Is the RF part have 
> degraded
> performances
> >> under this frequency ?
> >>
> >> Below this question is: we have to deliver a big HF (3-30 MHz) system 
> to a
> customer. The
> >> acquisition part is actually built with
> >> 2 x N210 with LFRX daughter boards. Due to the lack of chain gain of 
> this
> configuration,
> >> we add some RF pre-amplifiers
> >> in order to have good RF levels at the LFRX input.
> >> Maybe that this configuration can be replaced by 1x X300 + TwinRx (we 
> didn't make
> this
> >> choice because of the TwinRx specs) ?
> >>
> >> Regards,
> >>
> >> matis
> >>
> >>
> > My guess is that signals below 10MHz can be received, but the RF 
> amplifiers in the
> > low-band portion of the TwinRx likely fall off in gain quite a bit
> >   below 10MHz.
> >
> >
> >
> > ___
> > USRP-users mailing list
> > 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
> 
>
>

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] AGC overloading ADC Ettus B200 mini

[Ahmed Hamza via USRP-users]

 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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Marcus D. Leech via USRP-users]

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

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Ahmed Hamza via USRP-users]

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

On Wed, Mar 28, 2018 at 12:29 PM, Marcus D. Leech via USRP-users <
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
> 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

[USRP-users] N310 questions

[Rob Kossler via USRP-users]

Hi,
I recently received a new N310 and I have a few questions:
1) Is it true that it is not possible to share LO signals among channels
without supplying an external LO? (as opposed to TwinRx where one shares
the internally generated LO)
2) For an external LO signal, what power level should be used?  I couldn't
find this in the manual - probably should be added unless I missed it
somewhere.
3) For the MPM, the instructions indicate that you can either update the
entire file system (on SD card) or you can recompile MPM from source.  Is
there a 3rd option where we could just install a binary MPM? This seems
like it would be the most useful.

Thanks.
Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 questions

[Robin Coxe via USRP-users]

Hi Rob.   See interleaved responses below.

-Robin


On Wed, Mar 28, 2018 at 12:42 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I recently received a new N310 and I have a few questions:
> 1) Is it true that it is not possible to share LO signals among channels
> without supplying an external LO? (as opposed to TwinRx where one shares
> the internally generated LO)
>

Correct.   The two TX channels on each daughtercard share a common LO in
internal mode.  The two RX channels on each daughtercard also share a
common LO in internal mode.   However, the two daughtercards in the N310 do
not share TX or RX LOs unless they are provided externally.


> 2) For an external LO signal, what power level should be used?  I couldn't
> find this in the manual - probably should be added unless I missed it
> somewhere.
>

Refer to the bottom of p. 7 of AD9371 datasheet:

http://www.analog.com/media/en/technical-documentation/data-sheets/AD9371.pdf
 600 MHz-8000 MHz, 0-6 dBm (3 dBm typical).   The external LO is 2x, so max
RF frequency using the external LO is 4 GHz..   Thank you for pointing out
the omission.  We will add this information to the N300/N310 KB page.

3) For the MPM, the instructions indicate that you can either update the
> entire file system (on SD card) or you can recompile MPM from source.  Is
> there a 3rd option where we could just install a binary MPM? This seems
> like it would be the most useful.
>
> A binary MPM install is not yet supported.



> Thanks.
> Rob
>
> ___
> USRP-users mailing list
> 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

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Marcus D. Leech via USRP-users]

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

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 
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 
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

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Julian Arnold via USRP-users]

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 
>  
> 
> 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 
>> 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  
>>> 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

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Tom Bereknyei via USRP-users]

In case it helps, the changes in this commit helped me get AGC working
using RFNoC/GNURadio when I couldn't find the right hooks to do it via the
API.

https://github.com/tomberek/uhd/commit/c491f3e0f44ea457003852883ff742551a57e785#diff-dff9438dbbf09c43d9ccbf24a04e2cb6



On Wed, Mar 28, 2018 at 4:35 PM Julian Arnold via USRP-users <
usrp-users@lists.ettus.com> 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  > 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 

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Ahmed Hamza via USRP-users]

Thanks Tom so much for this hint. I am using the uhd driver that comes
prebuilt with the distribution.
I will try to make the suggested changes and rebuild the UHD and try.
I will keep you updated.

Best Regards,
Ahmed

On Wed, Mar 28, 2018 at 4:47 PM, Tom Bereknyei  wrote:

> In case it helps, the changes in this commit helped me get AGC working
> using RFNoC/GNURadio when I couldn't find the right hooks to do it via the
> API.
>
> https://github.com/tomberek/uhd/commit/c491f3e0f44ea457003852883ff742
> 551a57e785#diff-dff9438dbbf09c43d9ccbf24a04e2cb6
>
>
>
> On Wed, Mar 28, 2018 at 4:35 PM Julian Arnold via USRP-users <
> usrp-users@lists.ettus.com> 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  > 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 device

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Marcus D. Leech via USRP-users]

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 > 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

>
>
> 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
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.
   

Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Ahmed Hamza via USRP-users]

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  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 
> 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  > 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