Am 09.04.2021 um 09:48 schrieb Maria Muñoz <mamuk...@gmail.com>:
Hi Julian,
Sorry for the late reply and thanks for the answer.
I have been debugging the configuration printing the entries of
"set_agc" that I have found on cpp/py files in the uhd driver and
ettus repositories, and I can confirm that the code is not getting to
the ad9361_device.cpp as I thought in the beginning.
If I go through the code from my python script to the
ad9361_device.cpp configuration file I see the following:
* The python scripts calls for ettus.rfnoc_rx_radio.set_agc method,
which is found in ettus repository (for usrp_source is on
gnuradio/uhd lib)
* The rfnoc_rx_radio class is defined in
gr-ettus/lib/rfnoc_rx_radio_impl.h, where there is also a pointer
to the radio_control class defined:
/class rfnoc_rx_radio_impl : public rfnoc_rx_radio
{
public:
rfnoc_rx_radio_impl(::uhd:://rfnoc::noc_block_base::sptr
block_ref);
~rfnoc_rx_radio_impl();
/*** API
******************************//******************************//*****/
double set_rate(const double rate);
void set_antenna(const std::string& antenna, const size_t
chan);
double set_frequency(const double frequency, const size_t
chan);
void set_tune_args(const ::uhd::device_addr_t& args, const
size_t chan);
double set_gain(const double gain, const size_t chan);
double set_gain(const double gain, const std::string&
name, const size_t chan);
void set_agc(const bool enable, const size_t chan);
void set_gain_profile(const std::string& profile, const
size_t chan);
double set_bandwidth(const double bandwidth, const size_t
chan);
void
set_lo_source(const std::string& source, const
std::string& name, const size_t chan);
void
set_lo_export_enabled(const bool enabled, const
std::string& name, const size_t chan);
double set_lo_freq(const double freq, const std::string&
name, const size_t chan);
void set_dc_offset(const bool enable, const size_t chan);
void set_dc_offset(const std::complex<double>& offset,
const size_t chan);
void set_iq_balance(const bool enable, const size_t chan);
void set_iq_balance(const std::complex<double>&
correction, const size_t chan);
private:
::uhd::rfnoc::radio_control:://sptr d_radio_ref;
};/
* In gr-ettus/lib/rfnoc_rx_radio_impl.cpp when set_agc command is
received, it returns a call to the pointer I mention before, and
therefore, to the radio_control class:
/void rfnoc_rx_radio_impl::set_agc(//const bool enable, const
size_t chan)
{
return d_radio_ref->set_rx_agc(//enable, chan);
}/
* The radio_control class is found in the UHD driver repository in
uhd/host/include/uhd/rfnoc/radio_control.hpp which is virtually
implemented as radio_control_impl class in
e3xx_radio_control_impl.cpp (host/lib/usrp/board/e3xx)
* This file calls to the ad9361_ctrl class which is implemented in
e3xx_ad9361_iface.cpp (host/lib/usrp/board/e3xx)
* At this point, there is a call for the rpc_client where I get kind
of lost about how to change the registers this way:
/void set_agc(const std::string& which, bool enable)
{
_rpcc->request_with_token<void>(this->_rpc_prefix + "set_agc",
which, enable);
}/
To be brief:
* When debugging I can't see that my code gets to the only
configuration file I found which is the ad9361_device.cpp
* The set_agc command seems to be manage through the rpc_client (I
think this is related to the module peripheral manager which is a
"layer of control that UHD uses to access, configure and control
the hardware", https://files.ettus.com/manual/page_mpm.html)
* Inside the code, in multi_usrp files there is a comment that the
specific configuration of the AGC is set in the property_tree but
I don't know how to write the configuration registers of the agc
through the property_tree.
So my questions here are:
1. How can I set the configuration registers of the AGC, through the
MPM or the property tree?
2. Are there examples on how I can set these registers through the
MPM or the property_tree?
Kind Regards,
Maria
El mié, 24 mar 2021 a las 11:20, Julian Arnold
(<jul...@elitecoding.org <mailto:jul...@elitecoding.org>>) escribió:
Maria,
that sounds about right!
However, to make absolutely sure GNU Radio picks up the modified
libuhd
you could add a print statement somewhere in your UHD code.
You could also compare your UHD install prefix to the path gr-uhd
uses for linking libuhd.
Below is the patch I used for my tests:
diff --git a/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp
b/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp
index 9e088871d..0e5bc86c5 100644
--- a/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp
+++ b/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp
@@ -1089,7 +1089,7 @@ void
ad9361_device_t::_setup_gain_control(bool agc)
_io_iface->poke8(0x0FD, 0x4C); // Max Full/LMT Gain
Table Index
_io_iface->poke8(0x0FE, 0x44); // Decr Step Size, Peak
Overload Time
_io_iface->poke8(0x100, 0x6F); // Max Digital Gain
- _io_iface->poke8(0x101, 0x0A); // Max Digital Gain
+ _io_iface->poke8(0x101, 0x02); // Max Digital Gain
_io_iface->poke8(0x103, 0x08); // Max Digital Gain
_io_iface->poke8(0x104, 0x2F); // ADC Small Overload
Threshold
_io_iface->poke8(0x105, 0x3A); // ADC Large Overload
Threshold
@@ -1098,14 +1098,14 @@ void
ad9361_device_t::_setup_gain_control(bool agc)
_io_iface->poke8(0x108, 0x31);
_io_iface->poke8(0x111, 0x0A);
_io_iface->poke8(0x11A, 0x1C);
- _io_iface->poke8(0x120, 0x0C);
+ _io_iface->poke8(0x120, 0x04);
_io_iface->poke8(0x121, 0x44);
_io_iface->poke8(0x122, 0x44);
_io_iface->poke8(0x123, 0x11);
_io_iface->poke8(0x124, 0xF5);
_io_iface->poke8(0x125, 0x3B);
_io_iface->poke8(0x128, 0x03);
- _io_iface->poke8(0x129, 0x56);
+ _io_iface->poke8(0x129, 0x11);
_io_iface->poke8(0x12A, 0x22);
} else {
_io_iface->poke8(0x0FA, 0xE0); // Gain Control Mode Select
Cheers,
Julian
On 3/24/21 9:59 AM, Maria Muñoz wrote:
> Hi Julian,
>
> I have the chance to test the AGC with a B210 and perform the
same graph
> as you send me but I am unable to see what you saw so I think I'm
> missing something.
> I also have UHD 4.0 and GNURadio 3.8 (installed by source).
>
> The steps I take are these:
>
> * First, I change the ad9361_device.cpp that is in uhd
repository in
> //uhd/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp,
> registers 0x101, 0x120, 0x129, 0x123 and 0x12A./
> * Then, I do "make" and "make install" to compile the changes in
> build-host folder.
> * After that, I generate the python script for the GRC flow
graph and
> move the "set_agc" command after the "set_rate" one.
> * Finally, I run the python.
>
> I can't see my waveform between the values I set. Is there
something
> wrong with those steps? Did you do anything else?
>
> King Regards,
>
> Maria
>
> /
> /
>
> El mar, 23 mar 2021 a las 9:23, Maria Muñoz (<mamuk...@gmail.com
<mailto:mamuk...@gmail.com>
> <mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>>>) escribió:
>
> Hi Julian,
>
> Thanks for the checking!
>
> I have also checked my graph and samp_rate is setting first,
so I'll
> try to test it with a sine waveform as you suggested and see
if that
> works. If not, maybe is an RFNoC/gr-ettus problem. I'll put
an issue
> in the gr-ettus repository in that case.
>
> Thanks again for your help.
>
> Kind Regards,
>
> Maria.
>
> El mar, 23 mar 2021 a las 0:36, Julian Arnold
> (<jul...@elitecoding.org <mailto:jul...@elitecoding.org>
<mailto:jul...@elitecoding.org <mailto:jul...@elitecoding.org>>>)
escribió:
>
> Maria,
>
> I couldn't resist trying this myself, as your
modifications seemed
> reasonable.
>
> So I did set up a simple test with a b210 connected to
my siggen
> feeding
> it with a tone of varying power at 2.4102GHz.
>
> For the default UHD AGC settings I could confirm that
the signal
> was
> kept between -10 dBFS and -12 dBFS (20 * log10(|x|) over a
> pretty wide
> input power range.
> This was using GR 3.8 and UHD 4.0.
>
> However, I had to modify the generate flow-graph
slightly, as
> the AGC
> was enables before the sample-rate was set (maybe double
check
> that, too).
>
> Afterwards, I used your settings (I did change reg 0x129
to 0x11
> (1dB
> +-), though).
> Also those settings worked as expected and the signal
was nicely
> kept
> between -2 dBFS and -4 dBFS.
>
> Attached is a picture of the flow-graph I used for testing.
> Maybe you
> could also start by testing with a sine wave to
verifying that your
> values get applied properly.
>
> Cheers,
> Julian
>
> On 3/22/21 6:21 PM, Maria Muñoz wrote:
> > Hi Julian,
> >
> > Sure.
> >
> > I am receiving a QPSK through the radio and
plotting it in a
> QT graph
> > (see grc.png)
> > If I have AGC disable, I get what is shown in
> "test_without_agc.png",
> > then if I enable it, I see what is on
"test_with_agc.png" where
> > "Quadrature" is always center more or less in 0.25 which
> might fit with
> > the values given by default (inner high threshold =
-12dBFS,
> inner low
> > threshold = -10 dBFS).
> >
> > If I change the ad9361_device.cpp (attached) from
line 1085,
> by changing
> > registers 0x101, 0x120 and 0x129 with values 0x02,
0x04 and 0x16
> > respectively to move between -2dbFS and -4 dBFS, I
see the same
> > waveform that I have in "test_with_agc.png" (I expect
it to
> be around 0.7)
> >
> > Kind regards,
> >
> > Maria
> >
> > El lun, 22 mar 2021 a las 17:45, Julian Arnold
> (<jul...@elitecoding.org <mailto:jul...@elitecoding.org>
<mailto:jul...@elitecoding.org <mailto:jul...@elitecoding.org>>
> > <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>>) escribió:
> >
> > Maria,
> >
> > would you mind sharing your patch? Otherwise,
it’s hard
> to tell what
> > exactly is going on.
> >
> > Cheers,
> > Julian
> >
> >> Am 22.03.2021 um 16:24 schrieb Maria Muñoz
> <mamuk...@gmail.com <mailto:mamuk...@gmail.com>
<mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>>
> >> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>>>>:
> >>
> >>
> >> Hi Julian,
> >>
> >> I re-open this topic to ask a question about the
> configuration of
> >> the ad9361 registers in GNUradio/RFNoC
> >>
> >> As I understand, when AGC is enabled in slow
mode, there
> are 4
> >> configurable thresholds (inner low, inner high,
> outer low, and
> >> outer high) and also 4 configurable steps to
reach the zone
> >> between the inner thresholds.
> >>
> >> I have found the configuration of these registers
> >>
in /uhd/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp
> >> and changed their values there. Then, I have
recompiled
> uhd (make
> >> & make install) but, when I re-run my graph I see no
> change in my
> >> waveform (it seem to stay in the same limits as
the default
> >> configuration).
> >>
> >> Am I missing any other step that I have to done to
> configure these
> >> parameters?
> >>
> >> Kind Regards,
> >>
> >> Maria
> >>
> >> El vie, 12 mar 2021 a las 10:04, Maria Muñoz
> (<mamuk...@gmail.com <mailto:mamuk...@gmail.com>
<mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>>
> >> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>
> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>>>>) escribió:
> >>
> >> Ok Julian, I will check the tree node and try to
> modify the
> >> properties. Thanks again for the help!
> >>
> >> Kind Regards,
> >> Maria
> >>
> >> El jue, 11 mar 2021 a las 18:26, Julian Arnold
> >> (<jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>>)
> >> escribió:
> >>
> >> Maria,
> >>
> >> >>
> /self.ettus_rfnoc_rx_radio_0.set_rx_agc(False, 0)/
> >> >>
> >> >> but I have received the following
errorThat's
> why I
> >> gave the reference ([1]) showing the correct
> syntax ;)
> >> Anyways, glad it worked out for you!
> >> You might consider filing a bug issue
against
> gr-ettus on
> >> github.
> >>
> >> >> By the way, I have read that there are
> several modes
> >> for AGC
> >> >> (fast,slow,hybrid..) I was wondering
which
> type is
> >> implemented by
> >> >> default and if it is possible to
change AGC
> mode in the
> >> flowgraph.
> >> Those modes were mainly dictated by the
AD9361.
> Default
> >> should be
> >> "slow". The "hybrid" mode is not
implemented as
> far as I know.
> >> Which mode you want ("slow" / "fast")
depends on the
> >> signal you want to
> >> receive. For burst-mode digital signals you
> might want to
> >> switch to the
> >> "fast" mode.
> >> However, I think this is only possible by
> directly writing
> >> to the corresponding property-tree node.
Again,
> I'm not
> >> sure about
> >> UHD-4.0/gr-ettus though.
> >>
> >> Cheers,
> >> Julian
> >>
> >>
> >> On 3/11/21 5:26 PM, Maria Muñoz wrote:
> >> > Hi Julian,
> >> >
> >> > I have initially changed the python
generated
> for my
> >> flowgraph with this
> >> > line:
> >> >
> >> >
/self.ettus_rfnoc_rx_radio_0.set_rx_agc(False, 0)/
> >> >
> >> > but I have received the following error:
> >> >
> >> > T/raceback (most recent call last):
> >> > File
"constellation_soft_decoder.py", line
> 301, in
> >> <module>
> >> > main()
> >> > File
"constellation_soft_decoder.py", line
> 277, in main
> >> > tb = top_block_cls()
> >> > File
"constellation_soft_decoder.py", line
> 166, in
> >> __init__
> >> >
> self.ettus_rfnoc_rx_radio_0.set_rx_agc(True, 0)
> >> > AttributeError: 'rfnoc_rx_radio_sptr'
object
> has no
> >> attribute 'set_rx_agc'/
> >> >
> >> > But rfnoc_radio_impl.cc defines it:
> >> >
> >> > /void
rfnoc_rx_radio_impl::set_agc(const bool
> enable,
> >> const size_t chan)
> >> > {
> >> > return
d_radio_ref->set_rx_agc(enable, chan);
> >> > }/
> >> >
> >> > Searching the rfnoc_rx_radio_sptr with
grep
> takes me to
> >> "swig" files. I
> >> > have looked at ettus_swig.py and seen
that the
> command
> >> name is set_agc
> >> > instead of set_rx_agc:
> >> >
> >> > /def set_agc(self, enable: "bool
const", chan:
> "size_t
> >> const") -> "void":
> >> > r"""
> >> > set_agc(rfnoc_rx_radio self, bool
> const enable,
> >> size_t const chan)
> >> > Enable/disable the AGC for
this RX
> radio (if
> >> available)
> >> > """
> >> > return
> _ettus_swig.rfnoc_rx_radio_set_agc(self,
> >> enable, chan)/
> >> > /
> >> > /
> >> > Changing this in the flowgraph.py seems to
> work!! Thanks
> >> for the help on
> >> > this! I put this information here just
in case
> someone
> >> is stuck in the
> >> > same point.
> >> >
> >> > By the way, I have read that there are
several
> modes for
> >> AGC
> >> > (fast,slow,hybrid..) I was wondering
which type is
> >> implemented by
> >> > default and if it is possible to
change AGC
> mode in the
> >> flowgraph.
> >> >
> >> > Kind Regards,
> >> >
> >> > Maria
> >> >
> >> >
> >> > El mié, 10 mar 2021 a las 12:03, Maria
Muñoz
> >> (<mamuk...@gmail.com
<mailto:mamuk...@gmail.com> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>>
> <mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>
<mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>>>
> >> > <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>
> <mailto:mamuk...@gmail.com <mailto:mamuk...@gmail.com>>
> >> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>
> <mailto:mamuk...@gmail.com
<mailto:mamuk...@gmail.com>>>>>) escribió:
> >> >
> >> > Hi Jules,
> >> >
> >> > Thank you, I will try it and let
you know
> as soon as
> >> possible.
> >> >
> >> > By the way, I have checked the python
> >> generated using the UHD USRP
> >> > SOURCE block (instead of the RFNoC
radio
> block) with
> >> AGC active and
> >> > it generates the set of AGC fine.
So, as
> you said,
> >> it is fixed in
> >> > gr-uhd but it might still be a bug in
> gr-ettus.
> >> >
> >> > Thanks again for the help!
> >> >
> >> > Kind Regards,
> >> >
> >> > Maria
> >> >
> >> > El mié, 10 mar 2021 a las 11:25,
Julian Arnold
> >> > (<jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>>>) escribió:
> >> >
> >> > Maria,
> >> >
> >> > >> So, if I understand
correctly, I
> have to put
> >> there also
> >> > something like
> >> > >>
> >>
> "self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)"
isn't it?
> >> >
> >> > Exactly! Take a look at [1]
for the
> correct syntax.
> >> >
> >> > [1]
> >> >
> >>
>
https://github.com/EttusResearch/gr-ettus/blob/1038c4ce5135a2803b53554fc4971fe3de747d9a/include/ettus/rfnoc_rx_radio.h#L97
> >> >
> >> > Let me know if that worked out
for you.
> >> >
> >> > Cheers,
> >> > Julian
> >> >
> >> >
> >> > On 3/10/21 9:59 AM, Maria
Muñoz wrote:
> >> > > Hi Julian,
> >> > >
> >> > > Thanks for the quick answer.
> >> > >
> >> > > I think you might be right
about
> the possible
> >> bug turning on
> >> > the AGC
> >> > > from GRC. I have checked
the flow graph
> >> generated and there's no
> >> > > set_rx_agc enable option (I
checked
> the c++
> >> definition block
> >> > where this
> >> > > option did appear but I
hadn't look
> at the
> >> python generated).
> >> > >
> >> > > The lines related to the
radio in my
> >> flowgraph are these:
> >> > >
> >> > > /self.ettus_rfnoc_rx_radio_0 =
> >> ettus.rfnoc_rx_radio(
> >> > > self.rfnoc_graph,
> >> > >
uhd.device_addr(''),
> >> > > -1,
> >> > > -1)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_rate(samp_rate)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_antenna('RX2', 0)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_frequency(cf, 0)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_gain(gain, 0)
> >> > >
> >>
> self.ettus_rfnoc_rx_radio_0.set_bandwidth(samp_rate, 0)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_dc_offset(True, 0)
> >> > >
> >>
self.ettus_rfnoc_rx_radio_0.set_iq_balance(True, 0)/
> >> > >
> >> > > So, if I understand
correctly, I
> have to put
> >> there also
> >> > something like
> >> > >
> >>
> "self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)"
isn't it?
> >> > >
> >> > > Kind Regards,
> >> > >
> >> > > Maria
> >> > >
> >> > > El mié, 10 mar 2021 a las 9:16,
> Julian Arnold
> >> > (<jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>>
> >> > >
<mailto:jul...@elitecoding.org <mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>
> >> > <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>
> >> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>
> <mailto:jul...@elitecoding.org
<mailto:jul...@elitecoding.org>>>>>>) escribió:
> >> > >
> >> > > Maria,
> >> > >
> >> > > I might not be the
right person
> to answer
> >> this, as my
> >> > experience with
> >> > > UHD 4.0 is relatively
limited
> at the moment.
> >> > >
> >> > > However, I cant tell
you that
> the AGC on
> >> B2x0 devices is
> >> > controlled via
> >> > > software (using
set_rx_agc()).
> There is
> >> no need to
> >> > directly modify the
> >> > > state of any pins of
the FPGA.
> >> > >
> >> > > I vaguely remember that
there
> was a bug
> >> in an earlier
> >> > version of gr-uhd
> >> > > (somewhere in 3.7) that
made it
> difficult
> >> to turn on the
> >> > AGC using GRC.
> >> > > That particular one is
fixed in
> gr-uhd.
> >> Not sure about
> >> > gr-ettus, though.
> >> > >
> >> > > Maybe try using
set_rx_agc()
> manually in
> >> you flow-graph
> >> > (*.py) and see
> >> > > if that helps.
> >> > >
> >> > > Cheers,
> >> > > Julian
> >> > >
> >> > > On 3/9/21 5:11 PM,
Maria Muñoz via
> >> USRP-users wrote:
> >> > > > Hi all,
> >> > > >
> >> > > > I was wondering if it is
> possible to
> >> enable AGC from
> >> > the RFNoC radio
> >> > > > block in GNURadio. I
use UHD 4.0
> >> version and GNURadio
> >> > 3.8 with
> >> > > gr-ettus.
> >> > > >
> >> > > > I see that the RFNoC Rx
> radio block has an
> >> > enable/disable/default
> >> > > AGC
> >> > > > option in the
GNURadio block
> which I
> >> assume calls the
> >> > UHD function
> >> > > > "set_rx_agc"
> >> > > >
> >> > >
> >> >
> >>
>
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486)
> >> > > >
> >> > > > I have also checked
on the
> FPGA side
> >> that there is a
> >> > pin from
> >> > > FPGA to
> >> > > > AD9361
called XCVR_ENA_AGC
> which is
> >> set always to 1 on
> >> > the top
> >> > > level of
> >> > > > the FPGA image (see
attached
> file
> >> "e320.v", line 872).
> >> > This pin,
> >> > > > according to
> >> > > >
> >> > >
> >> >
> >>
>
https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf
> >> > >
> >> > > > is the "Manual
Control Input for
> >> Automatic Gain
> >> > Control (AGC)".
> >> > > > Must be this pin set
to 0 to
> have AGC
> >> working?
> >> > > > If not, how can
I get AGC
> working?
> >> I've made some tests
> >> > > > enabling/disabling this
> option but I
> >> do not see any
> >> > changes
> >> > > between the
> >> > > > waveforms received.
> >> > > >
> >> > > > Any help would be
appreciated.
> >> > > >
> >> > > > Kind Regards,
> >> > > >
> >> > > > Maria
> >> > > >
> >> > > >
> >>
_______________________________________________
> >> > > > 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>>
> >> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>>
> >> >
<mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>
> >> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>>>
> >> >
<mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>
> >> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>>
> >> >
<mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
> <mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>
> >> <mailto: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/mailman/listinfo/usrp-users_lists.ettus.com
> >> > > >
> >> > >
> >> >
> >>
>
