[USRP-users] DDC in USRP N200 Motherboard

2018-08-31 Thread Flo A. via USRP-users 
Hei!

I have a very general question regarding the function of the digital mixer
as part of the USRP motherboard-DDC:

Since the RF signal is already mixed to baseband by the synthesizer
component of e.g. the LFRX daugtherboard, I do not understand why we need
another mixer after the ADC as part of the DDC.

Probably this is more a question related to DDCs in general but it would be
great if you could provide me with an explanation for that.

Thanks in advance cheers!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DDC in USRP N200 Motherboard

2018-08-31 Thread Marcus D. Leech via USRP-users 

On 08/31/2018 09:26 AM, Flo A. via USRP-users wrote:

Hei!

I have a very general question regarding the function of the digital 
mixer as part of the USRP motherboard-DDC:


Since the RF signal is already mixed to baseband by the synthesizer 
component of e.g. the LFRX daugtherboard, I do not understand why we 
need another mixer after the ADC as part of the DDC.


Probably this is more a question related to DDCs in general but it 
would be great if you could provide me with an explanation for that.


Thanks in advance cheers!

Neither the LFRX, nor the BASIC_RX have on-board synthesizers and 
mixers, so in that *particular* case, the DDC is crucial to bringing the

  RF signal down to baseband.

For synthesized boards, the DDC is also used to "fine tune" the baseband 
conversion, since real-world synthesizers have a finite frequency

  step-size.

The other part of the DDC is doing rate conversion (filtering and 
decimation), since the ADC operates at a fixed sample rate of 100Msps

  on the N2xx.



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

[USRP-users] N310 Questions

2018-08-31 Thread Tillson, Bob (US) via USRP-users 
Running on Windows with 3.13.0.0, porting some apps from X310 3.9.7.


1)  lo_locked never seems to go true

Have some basic apps that poll/sleep until lo is locked after a tx tune, never 
proceed past this point.

Used tx_waveforms to also verify, assertion fails on lo_locked check.

Is this something you are aware of?


2)  Is there a way in 3.13 to programmatically disable dc offset correction?

When function is called message comes out saying not possible on this device.

would a way to disable it be through mpm.conf?  This is a bit more permanent 
than I would like, is there a different API to control this?

Thanks,

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

Re: [USRP-users] N310 timeout before streaming complete

2018-08-31 Thread Rob Kossler via USRP-users 
In this post and one other post, I mentioned two issues I am having related
to N310 streaming:

   1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout prior
   to receiving the requested number of samples (this is the issue identified
   in this post). This may be simply dependent upon the number of samples
   requested.
   2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated
   captures such that after several successful captures, I eventually get a
   streaming timeout and all subsequent captures fail.

So, turns out that this issue is bigger for me than I realized.  I had a
bunch of trouble yesterday while doing some research experimentation. I had
selected to go with X310 devices rather than N310 devices because of their
relative maturity.  Today, I confirmed that my issues yesterday with the
X310 are the same as I previously mentioned for the N310 (#2 above).  So,
perhaps it is an issue with UHD-3.13 (I did not check any other branch).

I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for
loop of 50 iterations" and changed the streaming mode to be continuous.
The modified source is included as an attachment (a 'diff' of my code to
the original with show the minor changes I made).  I attached a console log
of the output messages when run with my X310 which shows both the command
line parameters I used as well as the resulting errors.  Note that
everything is going as expected through Iteration 5, but starting at
Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a
timeout occurs prior to receiving any samples.

Please let me know if you have any questions.  This is a pretty big issue
for me and will prevent me from using 3.13 until addressed.

Rob


On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler  wrote:

> Hi,
> This post is perhaps a continuation of a previous post "Problems with MPM
> 3.13 on N310", but I wanted to change the subject to reflect this current
> issue.
>
> The issue is an Rx streaming timeout.  It can be easily duplicated with a
> stock Ettus example.  Below you will find the console log which includes
> the command line parameters.  Note the following:
>
>- I requested 31250 samples
>- There is a error "Timeout while streaming" indicated at the end
>- The final file size of 119340 indicates that 29835 samples were
>received
>- I do not have any reason to believe that the specific command line
>arguments below are needed to duplicate the issue.  I just didn't bother to
>try other ones.
>
> In the other thread, I mentioned that my Rx timeout issue had gone away
> after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE.  However,
> the issue below occurs when using that mode so it will be a problem for me.
>
> Let me know if you have any questions.
>
> Rob
>
>
> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$
> txrx_loopback_to_file --tx-args="addr=192.168.61.2"
> --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6
> --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6
> --rx-freq=2500e6
>
> Creating the transmit usrp device with: addr=192.168.61.2...
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.2-0-g0ddc19e5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=315A34B,claimed=False,addr=192.168.61.2
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=192.168.61.2,product=n310'.
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D004)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1331 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1349 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
>
> Creating the receive usrp device with: addr=192.168.61.2...
> Using TX Device: Single USRP:
>   Device: N300-Series Device
>   Mboard 0: ni-n3xx-315A34B
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: Magnesium
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: Magnesium
>   RX Channel: 2
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Magnesium
>   RX Channel: 3
> RX DSP: 1
> RX Dboard: B
> RX Subdev: Magnesium
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: Magnesium
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: Magnesium
>   TX Channel: 2
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Ma

Re: [USRP-users] N310 Questions

2018-08-31 Thread Ali Dormiani via USRP-users 
I am not qualified to answer your specific questions but our N310 had some
bugs when using 3.13.0.0. There are a few N310 specific bug-fixes in
3.13.0.2.

## 003.013.000.002
* N3xx: Fix issue where changing the clock/time source could result in
clocks becoming unlocked
* N3xx: Improve error messages for invalid clock/time settings
* N3xx: Add support for Rev G mboard
* MPM: Add function parameter to support holding AD9371 in reset
* Docs: Add section on building fs/SD images for N3xx
* Docs: Fix Doxygen warnings
## 003.013.000.001
* N3xx: Fix UIO usage in Aurora BIST
* N3xx: Fix EEPROM parsing (for upcoming hardware)
* UHD: Fix install path for Python API

On Fri, Aug 31, 2018 at 8:59 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Running on Windows with 3.13.0.0, porting some apps from X310 3.9.7.
>
>
>
> 1)  lo_locked never seems to go true
>
>
>
> Have some basic apps that poll/sleep until lo is locked after a tx tune,
> never proceed past this point.
>
>
>
> Used tx_waveforms to also verify, assertion fails on lo_locked check.
>
>
>
> Is this something you are aware of?
>
>
>
> 2)  Is there a way in 3.13 to programmatically disable dc offset
> correction?
>
>
>
> When function is called message comes out saying not possible on this
> device.
>
>
>
> would a way to disable it be through mpm.conf?  This is a bit more
> permanent than I would like, is there a different API to control this?
>
>
>
> Thanks,
>
>
>
> ___
> 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] Use same RFNoC block twice

2018-08-31 Thread Leandro Echevarría via USRP-users 
Hey everybody,

I've got a question. I have a RFNoC block that has a unique NoC ID as a
parameter, but is instantiated twice in my design (same situation as the
Radio Cores or DDC/DUC blocks, that share the same NoC ID but are connected
to different Crossbar ports when included more than once in the design).

In my software tests I take control of both radio cores separately by doing
this:

uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio", radio_id0); // RX0 (DB-A)
uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", radio_id1); // RX1 (DB-B)
uhd::rfnoc::radio_ctrl::sptr radio_ctrl0 = usrp->get_block_ctrl<
uhd::rfnoc::radio_ctrl >(radio_ctrl_id0);
uhd::rfnoc::radio_ctrl::sptr radio_ctrl1 = usrp->get_block_ctrl<
uhd::rfnoc::radio_ctrl >(radio_ctrl_id1);

And I'm taking control of custom, generic blocks like this:

uhd::rfnoc::block_ctrl_base::sptr myblock_ctrl;
if (usrp->has_block(cubepacketizer_blockid)) {
myblock_ctrl = usrp->get_block_ctrl(myblock_id);
blocks.push_back(myblock_ctrl->get_block_id());
}

What should I do now if, in this example, myblock_id is instantiated twice
in my core, and I need to get a controller for one of each blocks?
(For instance, to process two different signal paths, coming from both
Radio Cores).

Thanks a lot,

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

Re: [USRP-users] Use same RFNoC block twice

2018-08-31 Thread Brian Padalino via USRP-users 
On Fri, Aug 31, 2018 at 2:54 PM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey everybody,
>
> I've got a question. I have a RFNoC block that has a unique NoC ID as a
> parameter, but is instantiated twice in my design (same situation as the
> Radio Cores or DDC/DUC blocks, that share the same NoC ID but are connected
> to different Crossbar ports when included more than once in the design).
>
> In my software tests I take control of both radio cores separately by
> doing this:
>
> uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio", radio_id0); // RX0
> (DB-A)
> uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", radio_id1); // RX1
> (DB-B)
> uhd::rfnoc::radio_ctrl::sptr radio_ctrl0 = usrp->get_block_ctrl<
> uhd::rfnoc::radio_ctrl >(radio_ctrl_id0);
> uhd::rfnoc::radio_ctrl::sptr radio_ctrl1 = usrp->get_block_ctrl<
> uhd::rfnoc::radio_ctrl >(radio_ctrl_id1);
>
> And I'm taking control of custom, generic blocks like this:
>
> uhd::rfnoc::block_ctrl_base::sptr myblock_ctrl;
> if (usrp->has_block(cubepacketizer_blockid)) {
> myblock_ctrl = usrp->get_block_ctrl(myblock_id);
> blocks.push_back(myblock_ctrl->get_block_id());
> }
>
> What should I do now if, in this example, myblock_id is instantiated twice
> in my core, and I need to get a controller for one of each blocks?
> (For instance, to process two different signal paths, coming from both
> Radio Cores).
>

Your block ID will be (0, "CustomBlock", 0) for the first instance, and (0,
"CustomBlock", 1) for the other instance.

  auto custom_ctrl0 =
usrp->get_block_ctrl(customblock_id0)

To get the custom control block.  Just like the radio example.

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

Re: [USRP-users] Use same RFNoC block twice

2018-08-31 Thread Leandro Echevarría via USRP-users 
Great Brian, thanks a lot for your help!

On Fri, Aug 31, 2018 at 4:19 PM Brian Padalino  wrote:

> On Fri, Aug 31, 2018 at 2:54 PM Leandro Echevarría via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey everybody,
>>
>> I've got a question. I have a RFNoC block that has a unique NoC ID as a
>> parameter, but is instantiated twice in my design (same situation as the
>> Radio Cores or DDC/DUC blocks, that share the same NoC ID but are connected
>> to different Crossbar ports when included more than once in the design).
>>
>> In my software tests I take control of both radio cores separately by
>> doing this:
>>
>> uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio", radio_id0); // RX0
>> (DB-A)
>> uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", radio_id1); // RX1
>> (DB-B)
>> uhd::rfnoc::radio_ctrl::sptr radio_ctrl0 = usrp->get_block_ctrl<
>> uhd::rfnoc::radio_ctrl >(radio_ctrl_id0);
>> uhd::rfnoc::radio_ctrl::sptr radio_ctrl1 = usrp->get_block_ctrl<
>> uhd::rfnoc::radio_ctrl >(radio_ctrl_id1);
>>
>> And I'm taking control of custom, generic blocks like this:
>>
>> uhd::rfnoc::block_ctrl_base::sptr myblock_ctrl;
>> if (usrp->has_block(cubepacketizer_blockid)) {
>> myblock_ctrl = usrp->get_block_ctrl(myblock_id);
>> blocks.push_back(myblock_ctrl->get_block_id());
>> }
>>
>> What should I do now if, in this example, myblock_id is instantiated
>> twice in my core, and I need to get a controller for one of each blocks?
>> (For instance, to process two different signal paths, coming from both
>> Radio Cores).
>>
>
> Your block ID will be (0, "CustomBlock", 0) for the first instance, and
> (0, "CustomBlock", 1) for the other instance.
>
>   auto custom_ctrl0 =
> usrp->get_block_ctrl(customblock_id0)
>
> To get the custom control block.  Just like the radio example.
>
> Brian
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD not compatible with FPGA master noc_shell

2018-08-31 Thread Brent Stapleton via USRP-users 
The underlying reason for the mismatches is that, because the uhd/fpga-src
submodule points to a commit on fpga, we need THAT commit to be on the fpga
master branch. So, by necessity, we'll always have some amount of time in
which the two repositories are out of sync (that is, fpga is ahead of uhd).
This window was longer than usual, and we apologize for that. In the
future, if hiccups like this are an absolute deal-breaker for you, please
consider using the submodule pointer, or one of the UHD release branches.

Regarding PyBOMBS, as far as I can tell, there isn't a silver bullet in
this situation. I like the idea of the uhd-fpga recipe tracking
uhd/fpga-src, but I don't think git can clone submodules. The best thing
that comes to mind is to have the uhd-fpga recipe populate the uhd/fpga-src
submodule, which just saves the effort of manually updating the submodule.
If you have a better suggestion, we'd love to hear it.

Best Regards,
Brent

On Thu, Aug 30, 2018 at 5:28 PM Juan Francisco 
wrote:

> It seems that this issue has tripped up several people.  It might be
> prudent to not push the FPGA changes to master until you have the
> corresponding UHD updates ready to go.
>
> On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton <
> brent.staple...@ettus.com> wrote:
>
>> Hi Juan,
>>
>> In general, FPGA images built from the submodule in the uhd repository
>> will be compatible with UHD built from that commit. The HEADs of the two
>> master branches (uhd and fpga) do not have that guarantee. For example, the
>> HEAD of uhd master branch (as I write this email) is the git
>> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
>> Those both use NoC shell compat number 4.
>>
>> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
>> away that image.
>>
>> Regards,
>> Brent
>>
>> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> There appears to be a compatibility mismatch for the latest FPGA master
>>> and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
>>> from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:
>>>
>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>> 0xF1F0D000)
>>> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
>>> Expecting 4, got 5.
>>> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
>>> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
>>> the FPGA image.
>>>
>>> Thanks,
>>> Juan
>>> ___
>>> 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] [Discuss-gnuradio] re-initialize multi usrp object

2018-08-31 Thread Marcus Müller via USRP-users 
Hi Sanjoy,

> ubuntu 14.04

That is ancient, and Ubuntu's LTS isn't worth the "S" they have in its
name. Don't do this to yourself. Update to the recent LTS release,
18.04.

This is really more of a general UHD question than specific to GNU
Radio – you'll probably be better off discussing this on usrp-users (in
CC:, you need to sign up for that).

> If I use reset command, it gives error on the runtime. 
> 

Without you telling us what that error exactly is, it's going to be
hard to help you. Can you point me towards where you've found the
"reset command"?

Anyway, the multi_usrp class doesn't have a 'reset' method, but the
shared pointer does. Not quite sure what you want to achieve, so I'm
afraid that you'll have to tell us

* what exactly your code is supposed to do
* what it exactly does (and the error)
* how those differ, and optimally 
* a minimal full example that someone could compile and investigate.

The last step seems to be optional, but honestly, it's usually the most
helpful one, for yourself, because it requires you to think about what
exactly you need to do to trigger the unexpected behaviour and thus
gives you the ability to investigate yourself.

Best regards,

Marcus

On Fri, 2018-08-31 at 23:23 +0200, Sanjoy Basak wrote:
> 
> Hi All,
> I need to re-initialize multi usrp object in my (c++) application on
> the runtime. How should I reset the multi usrp object? 
> If I use reset command, it gives error on the runtime. 
> Could anyone tell me what is the correct way to re-initialize the
> multi usrp object?
> 
> uhd::usrp::multi_usrp::sptr usrp;
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp = uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
> 
> //receive and operate
> ...
> 
> //reinitialize usrp
> usrp.reset();
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp=uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
> 
> I am using usrp x310, ubuntu 14.04 and uhd 3.9 lts.
> 
> Best regards
> Sanjoy
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [USRP-users] UHD not compatible with FPGA master noc_shell

2018-08-31 Thread Andrew Danowitz via USRP-users 
Hi Brent,

Sounds good. I think the gnuradio pybombs recipe pulls in volk as a
submodule. I think they manage it with the line "gitargs: --recursive" in
their recipe.

On Fri, Aug 31, 2018 at 2:15 PM, Brent Stapleton via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The underlying reason for the mismatches is that, because the uhd/fpga-src
> submodule points to a commit on fpga, we need THAT commit to be on the fpga
> master branch. So, by necessity, we'll always have some amount of time in
> which the two repositories are out of sync (that is, fpga is ahead of uhd).
> This window was longer than usual, and we apologize for that. In the
> future, if hiccups like this are an absolute deal-breaker for you, please
> consider using the submodule pointer, or one of the UHD release branches.
>
> Regarding PyBOMBS, as far as I can tell, there isn't a silver bullet in
> this situation. I like the idea of the uhd-fpga recipe tracking
> uhd/fpga-src, but I don't think git can clone submodules. The best thing
> that comes to mind is to have the uhd-fpga recipe populate the uhd/fpga-src
> submodule, which just saves the effort of manually updating the submodule.
> If you have a better suggestion, we'd love to hear it.
>
> Best Regards,
> Brent
>
> On Thu, Aug 30, 2018 at 5:28 PM Juan Francisco 
> wrote:
>
>> It seems that this issue has tripped up several people.  It might be
>> prudent to not push the FPGA changes to master until you have the
>> corresponding UHD updates ready to go.
>>
>> On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton <
>> brent.staple...@ettus.com> wrote:
>>
>>> Hi Juan,
>>>
>>> In general, FPGA images built from the submodule in the uhd repository
>>> will be compatible with UHD built from that commit. The HEADs of the two
>>> master branches (uhd and fpga) do not have that guarantee. For example, the
>>> HEAD of uhd master branch (as I write this email) is the git
>>> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
>>> Those both use NoC shell compat number 4.
>>>
>>> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
>>> away that image.
>>>
>>> Regards,
>>> Brent
>>>
>>> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 There appears to be a compatibility mismatch for the latest FPGA master
 and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
 from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:

 [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
 0xF1F0D000)
 [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
 Expecting 4, got 5.
 Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
 supports revision 4. Please either upgrade UHD  (recommended) or downgrade
 the FPGA image.

 Thanks,
 Juan
 ___
 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
>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] axi_round_and_clip busted?

2018-08-31 Thread Andrew Danowitz via USRP-users 
When I try to use axi_round_and_clip in my design, simulation won't run and
has weird internal simulation issues. If I build it into an rfnoc image,
the flow graph doesn't return any data. Has anyone else run into this?

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] axi_round_and_clip busted?

2018-08-31 Thread Nick Foster via USRP-users 
I've successfully used axi_round_and_clip in a number of designs and it
seems to simulate fine for me. Xsim or vsim? How is it being instantiated?
What weird internal simulation issues are you seeing?

Nick

On Fri, Aug 31, 2018 at 2:58 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When I try to use axi_round_and_clip in my design, simulation won't run
> and has weird internal simulation issues. If I build it into an rfnoc
> image, the flow graph doesn't return any data. Has anyone else run into
> this?
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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] Problems of using usrp N210 + RFX900 daughterboard

2018-08-31 Thread Qiuyue Xue via USRP-users 
Hi all,

I have been using the usrp N210 and RFX900 daughterboard, and it was
working well two days ago, but after I updated my macports(and all the
ports including uhd and gnuradio), the device can't work anymore.

For now I can detect the usrp (when run uhd_detect_devices command), but
when I run uhd_usrp_probe or some other commands(like gqrx or
gnuradio application), I get this kind of error/warning message:

At first it gave error:

[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2); Boost_106600;
UHD_3.13.0.1-MacPorts-Release

[INFO] [USRP2] Opening a USRP2/N-Series device...

[INFO] [USRP2] Current recv frame size: 1472 bytes

[INFO] [USRP2] Current send frame size: 1472 bytes

[INFO] [USRP2] Detecting internal GPSDO

[INFO] [GPS] No GPSDO found

[ERROR] [DBMGR] The daughterboard manager encountered a recoverable error
in init.

Loading the "unknown" daughterboard implementations to continue.

The daughterboard cannot operate until this error is resolved.

LookupError: KeyError: key "0" not found in dict(i,
N14adf4360_regs_t17prescaler_value_tE)

  _

 /

|   Device: USRP2 / N-Series Device

| _

|/

|   |   Mboard: N210r4

|   |   hardware: 2577

|   |   mac-addr: 00:80:2f:19:89:31

|   |   ip-addr: 192.168.10.2

|   |   subnet: 255.255.255.255

|   |   gateway: 255.255.255.255

|   |   gpsdo: none

|   |   serial: 30757BE

|   |   FW Version: 12.4

|   |   FPGA Version: 11.1

|   |

|   |   Time sources:  none, external, _external_, mimo

|   |   Clock sources: internal, external, mimo

|   |   Sensors: mimo_locked, ref_locked

|   | _

|   |/

|   |   |   RX DSP: 0

|   |   |

|   |   |   Freq range: -50.000 to 50.000 MHz

|   | _

|   |/

|   |   |   RX DSP: 1

|   |   |

|   |   |   Freq range: -50.000 to 50.000 MHz

|   | _

|   |/

|   |   |   RX Dboard: A

|   |   |   ID: RFX900 (0x0025)

|   |   |   Serial: E1R14UBR9

|   |   | _

|   |   |/

|   |   |   |   RX Frontend: 0

|   |   |   |   Name: Unknown (0x) - 0

|   |   |   |   Antennas:

|   |   |   |   Sensors:

|   |   |   |   Freq range: 0.000 to 0.000 MHz

|   |   |   |   Gain Elements: None

|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   RX Codec: A

|   |   |   |   Name: ads62p44

|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB

|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB

|   | _

|   |/

|   |   |   TX DSP: 0

|   |   |

|   |   |   Freq range: -200.000 to 200.000 MHz

|   | _

|   |/

|   |   |   TX Dboard: A

|   |   |   ID: RFX900 (0x0029)

|   |   |   Serial: E1R14UBR9

|   |   | _

|   |   |/

|   |   |   |   TX Frontend: 0

|   |   |   |   Name: Unknown (0x) - 0

|   |   |   |   Antennas:

|   |   |   |   Sensors:

|   |   |   |   Freq range: 0.000 to 0.000 MHz

|   |   |   |   Gain Elements: None

|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   TX Codec: A

|   |   |   |   Name: ad9777

|   |   |   |   Gain Elements: None

After I tried to reseat the daughterboard and add 8 screws to the
daughterboard, the error becomes warning:

[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2); Boost_106600;
UHD_3.13.0.1-MacPorts-Release

[INFO] [USRP2] Opening a USRP2/N-Series device...

[INFO] [USRP2] Current recv frame size: 1472 bytes

[INFO] [USRP2] Current send frame size: 1472 bytes

[WARNING] [DBMGR] Unknown transceiver board ID combination.

Is your daughter-board mounted properly?

RX dboard ID: RFX900 (0x0025)

TX dboard ID: RFX900 (0x0025)


  _

 /

|   Device: USRP2 / N-Series Device

| _

|/

|   |   Mboard: N210r4

|   |   hardware: 2577

|   |   mac-addr: 00:80:2f:19:89:31

|   |   ip-addr: 192.168.10.2

|   |   subnet: 255.255.255.255

|   |   gateway: 255.255.255.255

|   |   gpsdo: none

|   |   serial: 30757BE

|   |   FW Version: 12.4

|   |   FPGA Version: 11.1

|   |

|   |   Time sources:  none, external, _external_, mimo

|   |   Clock sources: internal, external, mimo

|   |   Sensors: mimo_locked, ref_locked

|   |

Re: [USRP-users] Problems of using usrp N210 + RFX900 daughterboard

2018-08-31 Thread Marcus D. Leech via USRP-users 

On 08/31/2018 09:40 PM, Qiuyue Xue via USRP-users wrote:

Hi all,

I have been using the usrp N210 and RFX900 daughterboard, and it was 
working well two days ago, but after I updated my macports(and all the 
ports including uhd and gnuradio), the device can't work anymore.


For now I can detect the usrp (when run uhd_detect_devices command), 
but when I run uhd_usrp_probe or some other commands(like gqrx or 
gnuradio application), I get this kind of error/warning message:


At first it gave error:

[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2); 
Boost_106600; UHD_3.13.0.1-MacPorts-Release


[INFO] [USRP2] Opening a USRP2/N-Series device...

[INFO] [USRP2] Current recv frame size: 1472 bytes

[INFO] [USRP2] Current send frame size: 1472 bytes

[INFO] [USRP2] Detecting internal GPSDO

[INFO] [GPS] No GPSDO found

[ERROR] [DBMGR] The daughterboard manager encountered a recoverable 
error in init.


Loading the "unknown" daughterboard implementations to continue.

The daughterboard cannot operate until this error is resolved.

LookupError: KeyError: key "0" not found in dict(i, 
N14adf4360_regs_t17prescaler_value_tE)


_

/

| Device: USRP2 / N-Series Device

| _

|/

| | Mboard: N210r4

| | hardware: 2577

| | mac-addr: 00:80:2f:19:89:31

| | ip-addr: 192.168.10.2

| | subnet: 255.255.255.255

| | gateway: 255.255.255.255

| | gpsdo: none

| | serial: 30757BE

| | FW Version: 12.4

| | FPGA Version: 11.1

| |

| | Time sources:none, external, _external_, mimo

| | Clock sources: internal, external, mimo

| | Sensors: mimo_locked, ref_locked

| | _

| |/

| | | RX DSP: 0

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX DSP: 1

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX Dboard: A

| | | ID: RFX900 (0x0025)

| | | Serial: E1R14UBR9

| | | _

| | |/

| | | | RX Frontend: 0

| | | | Name: Unknown (0x) - 0

| | | | Antennas:

| | | | Sensors:

| | | | Freq range: 0.000 to 0.000 MHz

| | | | Gain Elements: None

| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz

| | | | Connection Type: IQ

| | | | Uses LO offset: No

| | | _

| | |/

| | | | RX Codec: A

| | | | Name: ads62p44

| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB

| | | | Gain range fine: 0.0 to 0.5 step 0.1 dB

| | _

| |/

| | | TX DSP: 0

| | |

| | | Freq range: -200.000 to 200.000 MHz

| | _

| |/

| | | TX Dboard: A

| | | ID: RFX900 (0x0029)

| | | Serial: E1R14UBR9

| | | _

| | |/

| | | | TX Frontend: 0

| | | | Name: Unknown (0x) - 0

| | | | Antennas:

| | | | Sensors:

| | | | Freq range: 0.000 to 0.000 MHz

| | | | Gain Elements: None

| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz

| | | | Connection Type: IQ

| | | | Uses LO offset: No

| | | _

| | |/

| | | | TX Codec: A

| | | | Name: ad9777

| | | | Gain Elements: None


After I tried to reseat the daughterboard and add 8 screws to the 
daughterboard, the error becomes warning:


[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2); 
Boost_106600; UHD_3.13.0.1-MacPorts-Release


[INFO] [USRP2] Opening a USRP2/N-Series device...

[INFO] [USRP2] Current recv frame size: 1472 bytes

[INFO] [USRP2] Current send frame size: 1472 bytes

[WARNING] [DBMGR] Unknown transceiver board ID combination.

Is your daughter-board mounted properly?

RX dboard ID: RFX900 (0x0025)

TX dboard ID: RFX900 (0x0025)


_

/

| Device: USRP2 / N-Series Device

| _

|/

| | Mboard: N210r4

| | hardware: 2577

| | mac-addr: 00:80:2f:19:89:31

| | ip-addr: 192.168.10.2

| | subnet: 255.255.255.255

| | gateway: 255.255.255.255

| | gpsdo: none

| | serial: 30757BE

| | FW Version: 12.4

| | FPGA Version: 11.1

| |

| | Time sources:none, external, _external_, mimo

| | Clock sources: internal, external, mimo

| | Sensors: mimo_locked, ref_locked

| | _

| |/

| | | RX DSP: 0

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX DSP: 1

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX Dboard: A

| | | ID: RFX900 (0x0025)

| | | Serial: E1R14UBR9

| | | _

| | |/

| | | | RX Frontend: 0

| | | | Name: RFX900 (0x0025) - 0

| |

Re: [USRP-users] Problems of using usrp N210 + RFX900 daughterboard

2018-08-31 Thread Qiuyue Xue via USRP-users 
Hi Marcus,

Thanks for the reply! Yes I have tried switching both
uhd and gnuradio versions(on another mac machine, not the previous working
one), the switched back uhd version is 003.010.001, and the switched back
gnuradio version is 3.7.10.1, macports version 2.5.3.

Shouldn't the usrp work with the newest version as well? Is this a version
problem or a hardware problem? Or could you please tell me which version of
uhd and gnuradio will work for USRP N210 and RFX900? Thank you very much
for your help!

Shirley

On Fri, Aug 31, 2018 at 10:02 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 08/31/2018 09:40 PM, Qiuyue Xue via USRP-users wrote:
>
> Hi all,
>
> I have been using the usrp N210 and RFX900 daughterboard, and it was
> working well two days ago, but after I updated my macports(and all the
> ports including uhd and gnuradio), the device can't work anymore.
>
> For now I can detect the usrp (when run uhd_detect_devices command), but
> when I run uhd_usrp_probe or some other commands(like gqrx or
> gnuradio application), I get this kind of error/warning message:
>
> At first it gave error:
>
> [INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2);
> Boost_106600; UHD_3.13.0.1-MacPorts-Release
>
> [INFO] [USRP2] Opening a USRP2/N-Series device...
>
> [INFO] [USRP2] Current recv frame size: 1472 bytes
>
> [INFO] [USRP2] Current send frame size: 1472 bytes
>
> [INFO] [USRP2] Detecting internal GPSDO
>
> [INFO] [GPS] No GPSDO found
>
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable error
> in init.
>
> Loading the "unknown" daughterboard implementations to continue.
>
> The daughterboard cannot operate until this error is resolved.
>
> LookupError: KeyError: key "0" not found in dict(i,
> N14adf4360_regs_t17prescaler_value_tE)
>
>   _
>
>  /
>
> |   Device: USRP2 / N-Series Device
>
> | _
>
> |/
>
> |   |   Mboard: N210r4
>
> |   |   hardware: 2577
>
> |   |   mac-addr: 00:80:2f:19:89:31
>
> |   |   ip-addr: 192.168.10.2
>
> |   |   subnet: 255.255.255.255
>
> |   |   gateway: 255.255.255.255
>
> |   |   gpsdo: none
>
> |   |   serial: 30757BE
>
> |   |   FW Version: 12.4
>
> |   |   FPGA Version: 11.1
>
> |   |
>
> |   |   Time sources:  none, external, _external_, mimo
>
> |   |   Clock sources: internal, external, mimo
>
> |   |   Sensors: mimo_locked, ref_locked
>
> |   | _
>
> |   |/
>
> |   |   |   RX DSP: 0
>
> |   |   |
>
> |   |   |   Freq range: -50.000 to 50.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   RX DSP: 1
>
> |   |   |
>
> |   |   |   Freq range: -50.000 to 50.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   RX Dboard: A
>
> |   |   |   ID: RFX900 (0x0025)
>
> |   |   |   Serial: E1R14UBR9
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Frontend: 0
>
> |   |   |   |   Name: Unknown (0x) - 0
>
> |   |   |   |   Antennas:
>
> |   |   |   |   Sensors:
>
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
>
> |   |   |   |   Gain Elements: None
>
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>
> |   |   |   |   Connection Type: IQ
>
> |   |   |   |   Uses LO offset: No
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Codec: A
>
> |   |   |   |   Name: ads62p44
>
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>
> |   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
>
> |   | _
>
> |   |/
>
> |   |   |   TX DSP: 0
>
> |   |   |
>
> |   |   |   Freq range: -200.000 to 200.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   TX Dboard: A
>
> |   |   |   ID: RFX900 (0x0029)
>
> |   |   |   Serial: E1R14UBR9
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   TX Frontend: 0
>
> |   |   |   |   Name: Unknown (0x) - 0
>
> |   |   |   |   Antennas:
>
> |   |   |   |   Sensors:
>
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
>
> |   |   |   |   Gain Elements: None
>
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>
> |   |   |   |   Connection Type: IQ
>
> |   |   |   |   Uses LO offset: No
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   TX Codec: A
>
> |   |   |   |   Name: ad9777
>
> |   |   |   |   Gain Elements: None
>
> After I tried to reseat the daughterboard and add 8 screws to the
> daughterboard, the error becomes warning:
>
> [INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2);
> Boost_1

Re: [USRP-users] Problems of using usrp N210 + RFX900 daughterboard

2018-08-31 Thread Marcus D. Leech via USRP-users 

On 08/31/2018 10:17 PM, Qiuyue Xue wrote:

Hi Marcus,

Thanks for the reply! Yes I have tried switching both 
uhd and gnuradio versions(on another mac machine, not the previous 
working one), the switched back uhd version is 003.010.001, and the 
switched back gnuradio version is 3.7.10.1, macports version 2.5.3.


Shouldn't the usrp work with the newest version as well? Is this a 
version problem or a hardware problem? Or could you please tell me 
which version of uhd and gnuradio will work for USRP N210 and RFX900? 
Thank you very much for your help!


Shirley
Well, it should all "just work", but you had reported that the earlier 
version worked just fine.


The fact that your RX and TX eeprom are returning the same value 
(0x0025) means that something is wrong, and perhaps you bent a pin

 when you were re-seating it.




On Fri, Aug 31, 2018 at 10:02 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 08/31/2018 09:40 PM, Qiuyue Xue via USRP-users wrote:

Hi all,

I have been using the usrp N210 and RFX900 daughterboard, and it
was working well two days ago, but after I updated my
macports(and all the ports including uhd and gnuradio), the
device can't work anymore.

For now I can detect the usrp (when run uhd_detect_devices
command), but when I run uhd_usrp_probe or some other
commands(like gqrx or gnuradio application), I get this kind of
error/warning message:

At first it gave error:

[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2);
Boost_106600; UHD_3.13.0.1-MacPorts-Release

[INFO] [USRP2] Opening a USRP2/N-Series device...

[INFO] [USRP2] Current recv frame size: 1472 bytes

[INFO] [USRP2] Current send frame size: 1472 bytes

[INFO] [USRP2] Detecting internal GPSDO

[INFO] [GPS] No GPSDO found

[ERROR] [DBMGR] The daughterboard manager encountered a
recoverable error in init.

Loading the "unknown" daughterboard implementations to continue.

The daughterboard cannot operate until this error is resolved.

LookupError: KeyError: key "0" not found in dict(i,
N14adf4360_regs_t17prescaler_value_tE)

_

/

| Device: USRP2 / N-Series Device

| _

|/

| | Mboard: N210r4

| | hardware: 2577

| | mac-addr: 00:80:2f:19:89:31

| | ip-addr: 192.168.10.2

| | subnet: 255.255.255.255

| | gateway: 255.255.255.255

| | gpsdo: none

| | serial: 30757BE

| | FW Version: 12.4

| | FPGA Version: 11.1

| |

| | Time sources:none, external, _external_, mimo

| | Clock sources: internal, external, mimo

| | Sensors: mimo_locked, ref_locked

| | _

| |/

| | | RX DSP: 0

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX DSP: 1

| | |

| | | Freq range: -50.000 to 50.000 MHz

| | _

| |/

| | | RX Dboard: A

| | | ID: RFX900 (0x0025)

| | | Serial: E1R14UBR9

| | | _

| | |/

| | | | RX Frontend: 0

| | | | Name: Unknown (0x) - 0

| | | | Antennas:

| | | | Sensors:

| | | | Freq range: 0.000 to 0.000 MHz

| | | | Gain Elements: None

| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz

| | | | Connection Type: IQ

| | | | Uses LO offset: No

| | | _

| | |/

| | | | RX Codec: A

| | | | Name: ads62p44

| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB

| | | | Gain range fine: 0.0 to 0.5 step 0.1 dB

| | _

| |/

| | | TX DSP: 0

| | |

| | | Freq range: -200.000 to 200.000 MHz

| | _

| |/

| | | TX Dboard: A

| | | ID: RFX900 (0x0029)

| | | Serial: E1R14UBR9

| | | _

| | |/

| | | | TX Frontend: 0

| | | | Name: Unknown (0x) - 0

| | | | Antennas:

| | | | Sensors:

| | | | Freq range: 0.000 to 0.000 MHz

| | | | Gain Elements: None

| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz

| | | | Connection Type: IQ

| | | | Uses LO offset: No

| | | _

| | |/

| | | | TX Codec: A

| | | | Name: ad9777

| | | | Gain Elements: None


After I tried to reseat the daughterboard and add 8 screws to the
daughterboard, the error becomes warning:

[INFO] [UHD] Mac OS; Clang version 9.0.0 (clang-900.0.39.2);
Boost_106600; UHD_3.13.0.1-MacPorts-Release

[INFO] [USRP2] Opening a USRP2