Hi Julian,
I have debugged the code running the "usrp-filter-explorer.cpp" which
also change some of the ad9361 configurations and I have the opportunity
to check it both in USRP E320 and USRP B210 (same as the one you have).
I have been able to see that the path through the source code using the
B210 is as expected (as you said, it goes through the ad9361_device.cpp
file) but that's not happening with the USRP E320.
The b210 log output (with added comments) is this:
/[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
UHD_4.0.0.HEAD-0-g90ce6062
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Initialize CODEC control...
*[INFO] [AD9361_DEVICE] initialize*
*[INFO] [AD9361_DEVICE] setup_gain_control_agc
[INFO] [AD9361_device] setup_adc*
[INFO] [B200] Initialize Radio control...
*[INFO] [AD9361_CTRL] set_agc
[INFO] [AD9361_DEVICE] set_agc
[INFO] [AD9361_DEVICE] setup_gain_control_agc
[INFO] [AD9361_CTRL] set_agc
[INFO] [AD9361_DEVICE] set_agc
[INFO] [AD9361_DEVICE] setup_gain_control_agc
[INFO] [AD9361_DEVICE] setup_gain_control_agc*
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
*[INFO] [MANAGER] agc
[INFO] [AD9361_DEVICE] filter
[INFO] [AD9361_DEVICE] filter*
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
*[INFO] [MANAGER] agc
[INFO] [AD9361_DEVICE] filter
[INFO] [AD9361_DEVICE] filter*
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [AD9361_DEVICE] setup_gain_control_agc
*[INFO] [AD9361_device] setup_adc*
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [MULTI_USRP] Setting master clock rate selection to 'manual'.
[INFO] [B200] Asking for clock rate 32.000000 MHz...
*[INFO] [AD9361_DEVICE] setup_gain_control_agc
[INFO] [AD9361_device] setup_adc*
[INFO] [B200] Actually got clock rate 32.000000 MHz.
Using master clock rate: 3.2e+07
Using search mask: rx_frontends/A/
Found the following filters matching "rx_frontends/A/":
/mboards/0/dboards/A/rx_frontends/A/filters/DEC_3
/mboards/0/dboards/A/rx_frontends/A/filters/FIR_1
/mboards/0/dboards/A/rx_frontends/A/filters/HB_1
/mboards/0/dboards/A/rx_frontends/A/filters/HB_2
/mboards/0/dboards/A/rx_frontends/A/filters/HB_3
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_BB
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_TIA
Active filters:
[INFO] [AD9361_DEVICE] filter
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/FIR_1
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_1
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_2
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_3
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_BB
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_TIA
Available Info on Active Filters:
[INFO] [AD9361_DEVICE] filter
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/FIR_1
[filter_info_base]
type: Digital FIR (i16)
bypass enable: 0
position index: 5
[digital_filter_base]
input rate: 6.4e+07
interpolation: 1
decimation: 2
full-scale: 32767
max num taps: 128
taps:
(tap 0: 0)(tap 1: 0)(tap 2: 1)(tap 3: 0)(tap 4: -2)(tap
5: 0)(tap 6: 3)(tap 7: 0)(tap 8: -5)(tap 9: 0)(tap 10: 8)
(tap 11: 0)(tap 12: -11)(tap 13: 0)(tap 14: 17)(tap 15:
0)(tap 16: -24)(tap 17: 0)(tap 18: 33)(tap 19: 0)(tap 20: -45)
(tap 21: 0)(tap 22: 61)(tap 23: 0)(tap 24: -80)(tap 25:
0)(tap 26: 104)(tap 27: 0)(tap 28: -134)(tap 29: 0)(tap 30: 169)
(tap 31: 0)(tap 32: -213)(tap 33: 0)(tap 34: 264)(tap
35: 0)(tap 36: -327)(tap 37: 0)(tap 38: 401)(tap 39: 0)(tap 40: -489)
(tap 41: 0)(tap 42: 595)(tap 43: 0)(tap 44: -724)(tap
45: 0)(tap 46: 880)(tap 47: 0)(tap 48: -1075)(tap 49: 0)(tap 50: 1323)
(tap 51: 0)(tap 52: -1652)(tap 53: 0)(tap 54: 2114)(tap
55: 0)(tap 56: -2819)(tap 57: 0)(tap 58: 4056)(tap 59: 0)(tap 60: -6883)
(tap 61: 0)(tap 62: 20837)(tap 63: 32767)(tap 64:
20837)(tap 65: 0)(tap 66: -6883)(tap 67: 0)(tap 68: 4056)(tap 69: 0)(tap
70: -2819)
(tap 71: 0)(tap 72: 2114)(tap 73: 0)(tap 74: -1652)(tap
75: 0)(tap 76: 1323)(tap 77: 0)(tap 78: -1075)(tap 79: 0)(tap 80: 880)
(tap 81: 0)(tap 82: -724)(tap 83: 0)(tap 84: 595)(tap
85: 0)(tap 86: -489)(tap 87: 0)(tap 88: 401)(tap 89: 0)(tap 90: -327)
(tap 91: 0)(tap 92: 264)(tap 93: 0)(tap 94: -213)(tap
95: 0)(tap 96: 169)(tap 97: 0)(tap 98: -134)(tap 99: 0)(tap 100: 104)
(tap 101: 0)(tap 102: -80)(tap 103: 0)(tap 104: 61)(tap
105: 0)(tap 106: -45)(tap 107: 0)(tap 108: 33)(tap 109: 0)(tap 110: -24)
(tap 111: 0)(tap 112: 17)(tap 113: 0)(tap 114: -11)(tap
115: 0)(tap 116: 8)(tap 117: 0)(tap 118: -5)(tap 119: 0)(tap 120: 3)
(tap 121: 0)(tap 122: -2)(tap 123: 0)(tap 124: 1)(tap
125: 0)(tap 126: 0)(tap 127: 0)
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_1
[filter_info_base]
type: Digital (i16)
bypass enable: 0
position index: 4
[digital_filter_base]
input rate: 1.28e+08
interpolation: 1
decimation: 2
full-scale: 2048
max num taps: 15
taps:
(tap 0: -8)(tap 1: 0)(tap 2: 42)(tap 3: 0)(tap 4:
-147)(tap 5: 0)(tap 6: 619)(tap 7: 1013)(tap 8: 619)(tap 9: 0)(tap 10: -147)
(tap 11: 0)(tap 12: 42)(tap 13: 0)(tap 14: -8)
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_2
[filter_info_base]
type: Digital (i16)
bypass enable: 0
position index: 3
[digital_filter_base]
input rate: 2.56e+08
interpolation: 1
decimation: 2
full-scale: 256
max num taps: 7
taps:
(tap 0: -9)(tap 1: 0)(tap 2: 73)(tap 3: 128)(tap 4:
73)(tap 5: 0)(tap 6: -9)
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/HB_3
[filter_info_base]
type: Digital (i16)
bypass enable: 0
position index: 2
[digital_filter_base]
input rate: 5.12e+08
interpolation: 1
decimation: 2
full-scale: 16
max num taps: 5
taps:
(tap 0: 1)(tap 1: 4)(tap 2: 6)(tap 3: 4)(tap 4: 1)
[INFO] [AD9361_DEVICE] filter
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_BB
[filter_info_base]
type: Analog Low-pass
bypass enable: 0
position index: 1
[analog_filter_base]
desc: third-order Butterworth
[analog_filter_lp]
cutoff: 2.24e+07
rolloff: 60
/mboards/0/dboards/A/rx_frontends/A/filters/LPF_TIA
[INFO] [AD9361_DEVICE] filter
[filter_info_base]
type: Analog Low-pass
bypass enable: 0
position index: 0
[analog_filter_base]
desc: single-pole
[analog_filter_lp]
cutoff: 4e+07
rolloff: 20/
/
/
On the other hand, the USRP E320 returns this:/
/
/[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
UHD_4.0.0.HEAD-0-g90ce6062
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=31DFBB7,claimed=False,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g90ce6062
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 31DFBB7
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args
`mgmt_addr=192.168.10.2,product=e320'.
*[INFO] [AD9361_IFACE] agc
[INFO] [AD9361_IFACE] agc*
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
Using master clock rate: 3.2e+07
Using search mask: rx_frontends/A/
Found the following filters matching "rx_frontends/A/":
*[INFO] [E3xx_radio_ctrl] filter*
Active filters:
Available Info on Active Filters:
/
/
/
The E320 goes to the ad9361_iface file (I have not called the set_agc
command so perhaps is called for the initial configuration?) and the
E3xx_radio_ctrl for the filter command (that's strange because I would
expected that it had passed through the iface too). There's also no
single filter name printed, maybe the correct tree path in the E320 is
not "rx_frontends/A/.
The call in ad9361_iface file is this one (which calls the rpc_client,
that's why I thought on the previous email that the configuration goes
that way):
/void set_agc(const std::string& which, bool enable)
{
UHD_LOG_INFO("AD9361_IFACE", "agc");
_rpcc->request_with_token<void>(this->_rpc_prefix + "set_agc", which,
enable);/
I am running the same source code for both USRP's, in the same
environment, just changing the connection from one USRP to another in my
PC, so I'm afraid this is an specific E320 problem.
Kind Regards,
Maria
//
El lun, 12 abr 2021 a las 9:55, Maria Muñoz (<mamuk...@gmail.com
<mailto:mamuk...@gmail.com>>) escribió:
Hi Julian,
Thanks for the answer.
Yes, I'm working with the E320. I'll try to force the "_setup_agc"
code as you said and debug again to see if hopefully, I get the AGC
configured.
If someone has configured the E320 before I will also appreciate any
help on this.
Thanks again for the help
Kind Regards,
Maria
El lun, 12 abr 2021 a las 9:43, Julian Arnold
(<jul...@elitecoding.org <mailto:jul...@elitecoding.org>>) escribió:
Maria,
it just dawned on me, that you are working with an e320 not an e310.
Although most of what I said should still apply (especially
erverything
related to the (AD936x)) things might be a little bit different.
I'm
epecially unsure about the RPC part, here.
Maybe someone else can chime in regarding this aspect.
However, I think that `_setup_gain_control(false)` should run
regardless
during device init. So you should see some logging output there.
If _setup_agc() is not beeing called you could try to force the
AGC on,
just for verification purposes, by changing
`_setup_gain_control(false)`
to `_setup_gain_control(true)` in `initialize()` and
`set_clock_rate()`.
Cheers,
Julian
On 4/9/21 3:34 PM, Julian Arnold wrote:
> Maria,
>
> the properties you want to change (min/max thresholds) are
not exposed
> via the property tree. Only the mode is (slow or fast).
> However, the same code that configures the AGC that worked
for me on the
> B210 should run on the E310. The RPC client should not be
involved in
> that case (although I’m not sure about that).
>
> Have you tried applying my patch directly (I had slightly
modified
> register values).
>
> Also, could you try running your code directly on the E310
(bypassing
> networked-mode) to see if that makes a difference?
>
> Cheers,
> Julian
>
>
> Julian Arnold, M.Sc
>
>> Am 09.04.2021 um 09:48 schrieb Maria Muñoz
<mamuk...@gmail.com <mailto: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>
<mailto: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>>
>> > <mailto: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>>
>> <mailto: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>>>
>> > > <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,
>> > >
>> > > 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>>>
>> > >> <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>>>>>:
>> > >>
>> > >>
>> > >> 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>>>
>> > >> <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ó:
>> > >>
>> > >> 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>>> <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,
>> > >>
>> > >> >>
>> > /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>>>>
>> > >> > <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
<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>>>>
>> > >> <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,
>> > >> >
>> > >> > >> 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>>>>>
>> > >> > >
>> <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
<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>>>>>
>> > >> >
>> <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
<mailto: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
<mailto:usrp-users@lists.ettus.com>
> To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
>
