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 (<[email protected]
<mailto:[email protected]>>) 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
(<[email protected] <mailto:[email protected]>>) 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
(<[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>) 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
<[email protected] <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>>:
>>
>>
>> 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
(<[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>) 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
>> (<[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>)
>> 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
>> (<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>>) 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
>> > (<[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>>) 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
>> > (<[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>
>> > > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>>>) 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
>> > > > [email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>>
>> > > >
>> >
>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> > > >
>> > >
>> >
>>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
