Re: [USRP-users] Setting N310 TX and RX bandwidth

[Marcus D. Leech via USRP-users]

On 07/17/2018 02:13 PM, Veytser, Leonid - 0665 - MITLL wrote:


I tried various gain settings, including both 0 and 30 for TX and 0 
and 30 for RX.


I also tried setting clock and time sources to “internal” but it 
didn’t seem to make a difference.


How are you inspecting the file that it produces to see if the signal is 
there or not?


How are you doing the loopback?



*From: *"Marcus D. Leech" 
*Date: *Tuesday, July 17, 2018 at 1:02 PM
*To: *Leonid Veytser , 
"usrp-users@lists.ettus.com" 

*Subject: *Re: [USRP-users] Setting N310 TX and RX bandwidth

On 07/17/2018 12:22 PM, Veytser, Leonid - 0665 - MITLL wrote:

I tried both of your suggestions – increasing RX gain and
offsetting RX frequency. However, neither seem to be working.

Lenny

What gain setting are you using for both TX and RX?

What happens if you don't use external time and clock sources?



*From: *"Marcus D. Leech" 

*Date: *Monday, July 16, 2018 at 10:08 PM
*To: *Leonid Veytser 
, "usrp-users@lists.ettus.com"
 

*Subject: *Re: [USRP-users] Setting N310 TX and RX bandwidth

On 07/16/2018 06:53 PM, Veytser, Leonid - 0665 - MITLL wrote:

Hi Marcus,

Thanks for your answer. Perhaps this is not my issue then. I
am having issue with sending and receiving a simple sine wave
using N310. In the simplest case, I can take X310 run
txrx_loopback_to_file with the arguments below, plot reals and
imaginaries of the stored files and I can see the sine wave.
If I do the exact same command against a N310, I appear to
just see noise, which seems to be highly quantized. Just
values in the range between -4 and 4.

 ./txrx_loopback_to_file --tx-args
"addr=192.168.20.2,clock_source=external,time_source=external"
--rx-args
"addr=192.168.20.2,clock_source=external,time_source=external"
--tx-rate 1.25e6 --rx-rate 1.25e6 --tx-freq 1800e6 --rx-freq
1800e6 --tx-channels "0" --rx-channels "1" --wave-type SINE
--wave-freq 1e3

Any help or suggestion is greatly appreciated!

Thanks,

Lenny

The gain-control range on the AD9371 is much larger than on cards
you'll find on the X310.

Try increasing the RX gain, and offset the RX frequency a bit --
you may be losing some in DC-offset removal for a carrier that is
right on top of
  the "DC" region.




*From: *USRP-users 
 on behalf of
"Marcus D. Leech via USRP-users" 

*Reply-To: *"Marcus D. Leech" 

*Date: *Monday, July 16, 2018 at 3:20 PM
*To: *"usrp-users@lists.ettus.com"

 
*Subject: *Re: [USRP-users] Setting N310 TX and RX bandwidth

On 07/16/2018 02:46 PM, Veytser, Leonid - 0665 - MITLL via
USRP-users wrote:

I am unable to set either RX or TX bandwidth on N310. When
attempting to set, I get the following warning:

Setting TX Bandwidth: 40.00 MHz...

*[WARNING] [0/Radio_0] *set_tx_bandwidth take no effect on
AD9371. Default analog bandwidth is 100MHz

Actual TX Bandwidth: 0.00 MHz...

and

Setting RX Bandwidth: 40.00 MHz...

*[WARNING] [0/Radio_0] *set_rx_bandwidth take no effect on
AD9371. Default analog bandwidth is 100MHz

Actual RX Bandwidth: 100.00 MHz...

When looking through the UHD code, I tracked down to these
FIXME comments:


https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp#L322

Is this some sort of limitation with the N310 and the
AD9371 tranceiver? Does this mean I am unable to set TX
and RX bandwidth at all?

Thanks,

Lenny

Based purely on the comment, I'm guessing that there are
notionally registers to control this in the AD9371, but they
don't apparently
  work as documented, hence the warning message.

Keep in mind that *internally*, the AD9371 samples the analog
mixer outputs at several hundred MHz, so if the internal
anti-alias filters
  are set-up for 100MHz by default, there's no danger of
aliases appearing in the outputs, regardless of your ultimate
sample-rate delivered
  to the host.












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

[USRP-users] noc_block_null_source_sink module

[Jason Matusiak via USRP-users]

I was having trouble finding information on this block. I could see its 
usefulness in an application I am looking into, but I wasn't sure how complete 
the block was (I don't really see anything using it, nor a GRC xml file for it).
 
Thanks
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Problem building RFNoC from Master

[Rob Kossler via USRP-users]

Hi,
I am having trouble building an RFNoC image using the master branch.
Actually, I can build an image, but it produces an error that makes me
believe that some config file is not correct for my N310.  Here are the
steps I followed:

   - download latest UHD and checkout 'master'
   - git submodule init followed by git submodule update
   - Note: at this point I wanted to use the tool "uhd_image_builder.py"
   but it didn't exist in the folder structure.  So, I changed folder to
   "fpga-src" and ran "git checkout master".  This produced the needed
   "uhd_image_builder.py"
   - uhd_image_builder.py ddc ddc duc duc -g -t N310_RFNOC_XG -d N310

I am wondering if someone could comment on what are the correct steps to
get started now that we are using "master" rather than "rfnoc-devel".

See below the error I get with my image.  I do not get this error with the
stock image.

Thank you.
Rob

$ benchmark_rate --rx_rate=12.5e6 --channels=0,1 --pps=internal

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.0.0-86-g606d8fc3
[00:00:00.02] Creating the usrp device with: ...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=
3144673,claimed=False,addr=192.168.160.2
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3144673
[INFO] [MPM.PeriphManager] Found 2 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.160.2,product=n310'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1341 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1348 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: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Error: AssertionError: index < duc_snk_flat.size()
  in void legacy_compat_impl::connect_blocks()
  at /home/irisheyes5/uhd/master/uhd/host/lib/rfnoc/legacy_compat.cpp:907
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Setting N310 TX and RX bandwidth

[Veytser, Leonid - 0665 - MITLL via USRP-users]

I tried various gain settings, including both 0 and 30 for TX and 0 and 30 for 
RX.

 

I also tried setting clock and time sources to “internal” but it didn’t seem to 
make a difference.

 

From: "Marcus D. Leech" 
Date: Tuesday, July 17, 2018 at 1:02 PM
To: Leonid Veytser , "usrp-users@lists.ettus.com" 

Subject: Re: [USRP-users] Setting N310 TX and RX bandwidth

 

On 07/17/2018 12:22 PM, Veytser, Leonid - 0665 - MITLL wrote:

I tried both of your suggestions – increasing RX gain and offsetting RX 
frequency. However, neither seem to be working.

 

Lenny

What gain setting are you using for both TX and RX?

What happens if you don't use external time and clock sources?




 

From: "Marcus D. Leech" 
Date: Monday, July 16, 2018 at 10:08 PM
To: Leonid Veytser , "usrp-users@lists.ettus.com" 

Subject: Re: [USRP-users] Setting N310 TX and RX bandwidth

 

On 07/16/2018 06:53 PM, Veytser, Leonid - 0665 - MITLL wrote:

Hi Marcus,

 

Thanks for your answer. Perhaps this is not my issue then. I am having issue 
with sending and receiving a simple sine wave using N310. In the simplest case, 
I can take X310 run txrx_loopback_to_file with the arguments below, plot reals 
and imaginaries of the stored files and I can see the sine wave. If I do the 
exact same command against a N310, I appear to just see noise, which seems to 
be highly quantized. Just values in the range between -4 and 4.

 

 ./txrx_loopback_to_file --tx-args 
"addr=192.168.20.2,clock_source=external,time_source=external" --rx-args 
"addr=192.168.20.2,clock_source=external,time_source=external" --tx-rate 1.25e6 
--rx-rate 1.25e6 --tx-freq 1800e6 --rx-freq 1800e6 --tx-channels "0" 
--rx-channels "1" --wave-type SINE --wave-freq 1e3

 

 

Any help or suggestion is greatly appreciated!

 

Thanks,

 

Lenny

The gain-control range on the AD9371 is much larger than on cards you'll find 
on the X310.

Try increasing the RX gain, and offset the RX frequency a bit -- you may be 
losing some in DC-offset removal for a carrier that is right on top of
  the "DC" region.





 

From: USRP-users  on behalf of "Marcus D. 
Leech via USRP-users" 
Reply-To: "Marcus D. Leech" 
Date: Monday, July 16, 2018 at 3:20 PM
To: "usrp-users@lists.ettus.com" 
Subject: Re: [USRP-users] Setting N310 TX and RX bandwidth

 

On 07/16/2018 02:46 PM, Veytser, Leonid - 0665 - MITLL via USRP-users wrote:

I am unable to set either RX or TX bandwidth on N310. When attempting to set, I 
get the following warning:

 

Setting TX Bandwidth: 40.00 MHz...

[WARNING] [0/Radio_0] set_tx_bandwidth take no effect on AD9371. Default analog 
bandwidth is 100MHz

Actual TX Bandwidth: 0.00 MHz...

 

and

 

Setting RX Bandwidth: 40.00 MHz...

[WARNING] [0/Radio_0] set_rx_bandwidth take no effect on AD9371. Default analog 
bandwidth is 100MHz

Actual RX Bandwidth: 100.00 MHz...

 

When looking through the UHD code, I tracked down to these FIXME comments:

 

https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp#L322

 

Is this some sort of limitation with the N310 and the AD9371 tranceiver? Does 
this mean I am unable to set TX and RX bandwidth at all?

 

Thanks,

 

Lenny

 

 

Based purely on the comment, I'm guessing that there are notionally registers 
to control this in the AD9371, but they don't apparently
  work as documented, hence the warning message.

Keep in mind that *internally*, the AD9371 samples the analog mixer outputs at 
several hundred MHz, so if the internal anti-alias filters
  are set-up for 100MHz by default, there's no danger of aliases appearing in 
the outputs, regardless of your ultimate sample-rate delivered
  to the host.















smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 with rfnoc-devel branch

[Martin Braun via USRP-users]

On 06/27/2018 11:31 AM, Rob Kossler via USRP-users wrote:
> Hi,
> I am getting some unexpected behavior from my N310 using the example
> 'tx_waveforms' utility and stock FPGA image using 'rfnoc-devel'.  If I
> simply switch to 'maint', things behave as expected.  Here are the issues...
> 
>  1. With 'rfnoc-devel', it is necessary for me to specify a subdev spec
> (A:0 A:1 B:0 B:1) in order to access all 4 channels. Otherwise, I
> can only see 2 channels. This is not a big problem, but wanted to
> mention it because it appears that the default subdev spec is not
> correct.  With 'maint', all 4 channels are available with default
> subdev spec.

Rob,

this is now fixed (on master, which has all the RFNoC stuff).

>  2. With 'rfnoc-devel', I get unexpected TX output power levels on the
> various channels when using the example program 'tx_waveforms' with
> the 'constant' waveform which produces a single tone at the carrier
> frequency (see table below).

Thanks for bringing this up, also, thanks for providing the graph in the
other thread. On master, this is now fixed.

>  3. With 'rfnoc-devel', I can only run 1 channel at a time. If I specify
> more than one channel (e.g., '--channels=0,1'), I get an error
> message that the PPS is not detected (even though using 'internal')
> and the example program crashes.  With 'maint', multiple channels
> work fine.

Even on the same commit hash, I don't see that issue. Can you please
check current HEAD of master again? I'd really like to get you unstuck
here, but I don't see a clear path forward.
It's very interesting this is not an issue on maint.

-- M


> 
> The table below shows the measured RF power levels (dBm) for a single
> tone output at 2400 MHz.  The tx_gain setting was 45 (20 dB below
> maximum) and there was about 31dB external attenuation.  So, for a
> measured power of -28 dBm, this implies that the maximum usrp output
> power is +23dBm (-28 + 20 + 31).
> 
> Channel    maint    rfnoc-devel
>    0   -27.8    -27.8* (some trials ~-67)
>    1   -27.9    -66.6* (some trials ~-27)
>    2   -27.6    -39.9* (some trials ~-67)
>    3   -27.6    -54.6* (consistent)
> 
> Details:
> 
>   * maint hash: ad6b0935
>   * rfnoc-devel hash: 1f8463cc
>   * command line: tx_waveforms --rate 20e6 --freq 2400e6 --gain 45
> --channels 
>   * os: ubuntu 16.04
> 
> Thank you.
> Rob
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


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

Re: [USRP-users] N310 streaming documentation

[Martin Braun via USRP-users]

Louis,

you don't need to start something, but I'm wondering if MPM is maybe
crashing (it's the service that turns the device into a smart USRP).

Can you try ssh'ing in and running

$ ps | grep usrp

You should see something like this:

root@ni-n3xx-***:~# ps | grep usrp
 1422 root 26492 Spython3 /usr/bin/usrp_hwd.py -v
 1423 root 58448 Spython3 /usr/bin/usrp_hwd.py -v
 1424 root 27576 Spython3 /usr/bin/usrp_hwd.py -v
 1546 root  2732 Rgrep usrp

If you don't, MPM is not running. You can simply run

$ usrp_hwd.py [-v]

to manually spawn it. However, that's normally not necessary. The
filesystem will auto-launch it and even run a watchdog to make sure it
stays alive.

The only other thing, but it's a long shot, is to check your MTU sizes,
and verify that you're using an HG image if you're using 1GigE (or an XG
image when using 10GigE). You can also run


$ ethtool -p sfp1

on your device to make sure you're using the correct SFP, but that
shouldn't be the issue since you're pinging.

-- M


On 05/14/2018 08:28 AM, Louis Brown via USRP-users wrote:
> Tried that but it's not working for either on-board or SFP0, though I can 
> ping both :
> 
> uhd_find_devices --args "addr=192.168.1.4,type=n3xx"
> [INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
> Boost_106600; UHD_3.11.1.0-0-g34c56104
> No UHD Devices Found
> 
> uhd_find_devices --args "addr=192.168.10.2,type=n3xx"
> [INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
> Boost_106600; UHD_3.11.1.0-0-g34c56104
> No UHD Devices Found
> 
> The N310 Ethernet looks OK:
> 
> root@ni-n3xx-3145FA0:~# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BD 
>  inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
>  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>  RX packets:171 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000 
>  RX bytes:17223 (16.8 KiB) TX bytes:7577 (7.3 KiB)
>  Interrupt:145 Base address:0xb000 
> 
> lo Link encap:Local Loopback 
>  inet addr:127.0.0.1 Mask:255.0.0.0
>  UP LOOPBACK RUNNING MTU:65536 Metric:1
>  RX packets:86 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000 
>  RX bytes:6542 (6.3 KiB) TX bytes:6542 (6.3 KiB)
> 
> sfp0 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BE 
> 
>  inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0
>  UP BROADCAST RUNNING MULTICAST MTU:8000 Metric:1
>  RX packets:471 errors:0 dropped:22 overruns:0 frame:0
>  TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000 
>  RX bytes:59389 (57.9 KiB) TX bytes:52721 (51.4 KiB)
> 
> sfp1 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BF 
>  UP BROADCAST MULTICAST MTU:8000 Metric:1
>  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000 
>  RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> 
> 
> It can find itself on 127.0.0.1 
> 
> root@ni-n3xx-3145FA0:~# uhd_find_devices 
> [INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; 
> UHD_3.11.0.1-0-unknown
> --
> -- UHD Device 0
> --
> Device Address:
>  serial: 3145FA0
>  claimed: False
>  mgmt_addr: 127.0.0.1
>  product: n310
>  type: n3xx
> 
> 
> But can't find itself on 192.168.10.2:
> 
> root@ni-n3xx-3145FA0:~# uhd_find_devices --args "addr=192.168.10.2,type=n3xx"
> [INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; 
> UHD_3.11.0.1-0-unknown
> No UHD Devices Found
> 
> Like on the E310, do I need to start something?
> 
> Could it be UHD_3.11.0.1 on the N310 image and UHD_3.11.1.0 on my PC?
> 
> Thanks,
> Lou
> 
> 
> 
> 
>>/On 05/11/2018 06:14 PM, Brent Stapleton wrote: />//>/The `type` should be 
>>n3xx, not n300. />//>/--args "addr=192.168.10.2,type=n3xx" />//>/Brent 
>>/>//>/Ah. That's a change from N2xx and B2xx series. Might I suggest putting 
>>/>/in synonyms, so that folks used to previous naming schemes won't become 
>>/>/confused? />//>//>//>/On Fri, May 11, 2018 at 3:06 PM, Marcus D. Leech via 
>>USRP-users < />/usrp-users at lists.ettus.com
> >
> wrote: />//>>/On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote: 
> />>//>>>//>>>/Is there documentation on getting the N310 streaming interface 
> working? />>>/I'm able to ping the SFP0 port at 192.168.10.2 and the on-board 
> at />>>/192.168.1.4, but uhd_find_devices and uhd_usrp_probe find nothing: 
> />>>//>>>/uhd_usrp_probe --args "addr=192.168.10.2" />>>/[INFO] [UHD] linux; 
> GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); />>>/Boost_106600; 
> UHD_3.11.1.0-0-g34c56104 />>>/Error: LookupError: KeyError: No devices found 
> for -> />>>/Device Address: />>>/addr: 192.168.10.2 />>>//>>>/I did 
> update the SD 

Re: [USRP-users] [Discuss-gnuradio] [UHD] Coarse roadmap for USRP E310 Software

[Moritz Fischer via USRP-users]

Philip,

On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister  wrote:
> A couple of notes based on updating the E300 to rocko 
>
> 1) The N310 branch added a bbappend on something called salt which added
> the need for the meta-openstack and meta-virtualization layers. For
> basic E300 support, this is crazy layer bloat. I removed the bbappend.
> If you really need it, I'd create a layer for specific applications,
> salt seems to be some form of enterprise software config management
> system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
> every E300 project needs this.

That's a good point, I'll look into making it more modular.

>
> 2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
> meta-ettus, but it also supports users using other Ettus products with
> other embedded hardware, so the recipe doesn't belong there. It would be
> silly having to add the meta-ettus bsp to use a b200 with a pi-s.

I have made an attempt at splitting up meta-ettus more into separate layers,
the result of that is on github (master). I was hesitant to push it public since
in it current form E31x does not work. N310 will move over to that (and the sumo
release with the next release).

Personally having the uhd recipe in meta-sdr was not convenient and we ended up
building most of the filesystems with bbappends to the UHD recipe
anyways, so I've
decided to host the UHD recipe in meta-ettus in a meta-ettus-core sublayer.

With upcoming products I hope the modularization makes sense and helps keeping
changes separate while not reinventing the wheel every time.

> 3) While messing with uhd, it is time to have the firmware recipe
> package the fpga files on a per device basis, instead of all images on
> one package.

We are/were already working on that. Thanks for your input.

Cheers,
Moritz

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

Re: [USRP-users] Setting N310 TX and RX bandwidth

[Marcus D. Leech via USRP-users]

On 07/17/2018 12:22 PM, Veytser, Leonid - 0665 - MITLL wrote:


I tried both of your suggestions – increasing RX gain and offsetting 
RX frequency. However, neither seem to be working.


Lenny


What gain setting are you using for both TX and RX?

What happens if you don't use external time and clock sources?



*From: *"Marcus D. Leech" 
*Date: *Monday, July 16, 2018 at 10:08 PM
*To: *Leonid Veytser , 
"usrp-users@lists.ettus.com" 

*Subject: *Re: [USRP-users] Setting N310 TX and RX bandwidth

On 07/16/2018 06:53 PM, Veytser, Leonid - 0665 - MITLL wrote:

Hi Marcus,

Thanks for your answer. Perhaps this is not my issue then. I am
having issue with sending and receiving a simple sine wave using
N310. In the simplest case, I can take X310 run
txrx_loopback_to_file with the arguments below, plot reals and
imaginaries of the stored files and I can see the sine wave. If I
do the exact same command against a N310, I appear to just see
noise, which seems to be highly quantized. Just values in the
range between -4 and 4.

 ./txrx_loopback_to_file --tx-args
"addr=192.168.20.2,clock_source=external,time_source=external"
--rx-args
"addr=192.168.20.2,clock_source=external,time_source=external"
--tx-rate 1.25e6 --rx-rate 1.25e6 --tx-freq 1800e6 --rx-freq
1800e6 --tx-channels "0" --rx-channels "1" --wave-type SINE
--wave-freq 1e3

Any help or suggestion is greatly appreciated!

Thanks,

Lenny

The gain-control range on the AD9371 is much larger than on cards 
you'll find on the X310.


Try increasing the RX gain, and offset the RX frequency a bit -- you 
may be losing some in DC-offset removal for a carrier that is right on 
top of

  the "DC" region.



*From: *USRP-users 
 on behalf of "Marcus
D. Leech via USRP-users" 

*Reply-To: *"Marcus D. Leech" 

*Date: *Monday, July 16, 2018 at 3:20 PM
*To: *"usrp-users@lists.ettus.com"
 

*Subject: *Re: [USRP-users] Setting N310 TX and RX bandwidth

On 07/16/2018 02:46 PM, Veytser, Leonid - 0665 - MITLL via
USRP-users wrote:

I am unable to set either RX or TX bandwidth on N310. When
attempting to set, I get the following warning:

Setting TX Bandwidth: 40.00 MHz...

*[WARNING] [0/Radio_0] *set_tx_bandwidth take no effect on
AD9371. Default analog bandwidth is 100MHz

Actual TX Bandwidth: 0.00 MHz...

and

Setting RX Bandwidth: 40.00 MHz...

*[WARNING] [0/Radio_0] *set_rx_bandwidth take no effect on
AD9371. Default analog bandwidth is 100MHz

Actual RX Bandwidth: 100.00 MHz...

When looking through the UHD code, I tracked down to these
FIXME comments:


https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp#L322

Is this some sort of limitation with the N310 and the AD9371
tranceiver? Does this mean I am unable to set TX and RX
bandwidth at all?

Thanks,

Lenny

Based purely on the comment, I'm guessing that there are
notionally registers to control this in the AD9371, but they don't
apparently
  work as documented, hence the warning message.

Keep in mind that *internally*, the AD9371 samples the analog
mixer outputs at several hundred MHz, so if the internal
anti-alias filters
  are set-up for 100MHz by default, there's no danger of aliases
appearing in the outputs, regardless of your ultimate sample-rate
delivered
  to the host.








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

Re: [USRP-users] N310 & rfnoc error "No PPS detected"

[Martin Braun via USRP-users]

On 07/09/2018 03:06 PM, Rob Kossler via USRP-users wrote:
> Using the latest 'rfnoc-devel' (eec24d7b) with my N310, I get the
> following error when running the example program 'benchmark_rate'.  The
> error message indicates no PPS detected whenever the channel count is
> greater than one.  Note that this is not a new error (it was present
> prior to me updating today).  I am wondering if someone from Ettus can
> confirm this error using the simple command line below?

Rob,

sorry for the late response, but I can not reproduce this error (using
master branch). Maybe it's device specific -- I'll try and round up a
few devices and see if any of them has this issue.

-- M
> 
> Rob
> 
> 
> benchmark_rate --pps=internal --rx_rate=125e6 --rx_channels=0,1
> 
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [00:00:00.02] Creating the usrp device with: ...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=n310,mgmt_addr=192.168.160.2'.
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1341 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1344 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 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)
> Using Device: Single USRP:
>   Device: N300-Series Device
>   Mboard 0: ni-n3xx-3144673
>   RX Channel: 0
>     RX DSP: 0
>     RX Dboard: A
>     RX Subdev: Magnesium
>   RX Channel: 1
>     RX DSP: 0
>     RX Dboard: B
>     RX Subdev: Magnesium
>   TX Channel: 0
>     TX DSP: 0
>     TX Dboard: A
>     TX Subdev: Magnesium
>   TX Channel: 1
>     TX DSP: 0
>     TX Dboard: B
>     TX Subdev: Magnesium
> 
> [00:00:34.243555] Setting device timestamp to 0...
> [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> Error: RuntimeError: Board 0 may not be getting a PPS signal!
> No PPS detected within the time interval.
> See the application notes for your device.
> 
> 
> 
> 
> ___
> 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] X300 XG Image Broken

[Martin Braun via USRP-users]

On 07/12/2018 03:24 PM, Jacob Knoles via USRP-users wrote:
> Hey all, 
> 
> I have built the latest version of UHD and am trying to load up my X300
> but having major issues. 
> I have used the image downloader script to get the latest versions of
> the FPGA image and the image loader to burn the image successfully. Then
> when I run uhd_usrp_probe I get to the DDC initialization and it breaks. 
> 
> PS C:\Program Files\UHD\bin> uhd_image_loader.exe --args
> "type=x300,addr=192.168.40.2"
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106700;
> UHD_3.12.0.0-69-ON
> Unit: USRP X300 (3123DBD, 192.168.40.2)
> FPGA Image: C:\Program Files\UHD\share\uhd\images\usrp_x300_fpga_XG.bit
> -- Initializing FPGA loading...successful.
> -- Loading XG FPGA image: 100% (87/87 sectors)
> -- Finalizing image load...successful.
> Power-cycle the USRP X300 to use the new image.
> PS C:\Program Files\UHD\bin> .\uhd_usrp_probe.exe
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106700;
> UHD_3.12.0.0-69-ON
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] No GPSDO found
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1304 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> Error: LookupError: KeyError: Unknown settings register name: DDS_FREQ
> 
> I've tried reloading the image several times. Power cycling the x300,
> downloading the most recent images zip from ettus.com 
> nothing is working. 
> 
> Windows 10, UHD 12.0.0, Boost 1.67 Connected using dual 10g

Jacob,

this is not an issue with the FPGA image, but you have a mismatch
between the XML block descriptors and your UHD version. Your UHD version
is newer than the XML files. If you run UHD with a higher verbosity, you
can see where it is getting the XML files from.

-- M

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

Re: [USRP-users] Setting N310 TX and RX bandwidth

[Veytser, Leonid - 0665 - MITLL via USRP-users]

I tried both of your suggestions – increasing RX gain and offsetting RX 
frequency. However, neither seem to be working.

 

Lenny

 

From: "Marcus D. Leech" 
Date: Monday, July 16, 2018 at 10:08 PM
To: Leonid Veytser , "usrp-users@lists.ettus.com" 

Subject: Re: [USRP-users] Setting N310 TX and RX bandwidth

 

On 07/16/2018 06:53 PM, Veytser, Leonid - 0665 - MITLL wrote:

Hi Marcus,

 

Thanks for your answer. Perhaps this is not my issue then. I am having issue 
with sending and receiving a simple sine wave using N310. In the simplest case, 
I can take X310 run txrx_loopback_to_file with the arguments below, plot reals 
and imaginaries of the stored files and I can see the sine wave. If I do the 
exact same command against a N310, I appear to just see noise, which seems to 
be highly quantized. Just values in the range between -4 and 4.

 

 ./txrx_loopback_to_file --tx-args 
"addr=192.168.20.2,clock_source=external,time_source=external" --rx-args 
"addr=192.168.20.2,clock_source=external,time_source=external" --tx-rate 1.25e6 
--rx-rate 1.25e6 --tx-freq 1800e6 --rx-freq 1800e6 --tx-channels "0" 
--rx-channels "1" --wave-type SINE --wave-freq 1e3

 

 

Any help or suggestion is greatly appreciated!

 

Thanks,

 

Lenny

The gain-control range on the AD9371 is much larger than on cards you'll find 
on the X310.

Try increasing the RX gain, and offset the RX frequency a bit -- you may be 
losing some in DC-offset removal for a carrier that is right on top of
  the "DC" region.




 

From: USRP-users  on behalf of "Marcus D. 
Leech via USRP-users" 
Reply-To: "Marcus D. Leech" 
Date: Monday, July 16, 2018 at 3:20 PM
To: "usrp-users@lists.ettus.com" 
Subject: Re: [USRP-users] Setting N310 TX and RX bandwidth

 

On 07/16/2018 02:46 PM, Veytser, Leonid - 0665 - MITLL via USRP-users wrote:

I am unable to set either RX or TX bandwidth on N310. When attempting to set, I 
get the following warning:

 

Setting TX Bandwidth: 40.00 MHz...

[WARNING] [0/Radio_0] set_tx_bandwidth take no effect on AD9371. Default analog 
bandwidth is 100MHz

Actual TX Bandwidth: 0.00 MHz...

 

and

 

Setting RX Bandwidth: 40.00 MHz...

[WARNING] [0/Radio_0] set_rx_bandwidth take no effect on AD9371. Default analog 
bandwidth is 100MHz

Actual RX Bandwidth: 100.00 MHz...

 

When looking through the UHD code, I tracked down to these FIXME comments:

 

https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp#L322

 

Is this some sort of limitation with the N310 and the AD9371 tranceiver? Does 
this mean I am unable to set TX and RX bandwidth at all?

 

Thanks,

 

Lenny

 

 

Based purely on the comment, I'm guessing that there are notionally registers 
to control this in the AD9371, but they don't apparently
  work as documented, hence the warning message.

Keep in mind that *internally*, the AD9371 samples the analog mixer outputs at 
several hundred MHz, so if the internal anti-alias filters
  are set-up for 100MHz by default, there's no danger of aliases appearing in 
the outputs, regardless of your ultimate sample-rate delivered
  to the host.










smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] branch 3.12 with ENABLE_RFNOC=ON

[Martin Braun via USRP-users]

On 07/17/2018 09:14 AM, Martin Braun wrote:
> On 07/13/2018 11:41 AM, Rob Kossler via USRP-users wrote:
>> Hi,
>> With the recent changes to the branches, I understand that users doing
>> RFNoC development should be using master branch and users that
>> previously used 'maint' should be using 3.10, 3.11, or 3.12 as
>> appropriate.  I am wondering about the possibility of using the RFNoC
>> API with the 3.12 branch.  Is this a possibility?
>>
>> I tried to use 3.12 and supplied the -DENABLE_RFNOC=ON parameter to
>> cmake.  I can compile UHD successfully, but the subsequent "make test"
>> produces an error on the "blockdef_test".  So, I am wondering if this is
>> not an intended use case.

FYI, the failure is harmless (we have a fix, but you can also ignore it
for now).

-- M

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

Re: [USRP-users] branch 3.12 with ENABLE_RFNOC=ON

[Martin Braun via USRP-users]

On 07/13/2018 11:41 AM, Rob Kossler via USRP-users wrote:
> Hi,
> With the recent changes to the branches, I understand that users doing
> RFNoC development should be using master branch and users that
> previously used 'maint' should be using 3.10, 3.11, or 3.12 as
> appropriate.  I am wondering about the possibility of using the RFNoC
> API with the 3.12 branch.  Is this a possibility?
> 
> I tried to use 3.12 and supplied the -DENABLE_RFNOC=ON parameter to
> cmake.  I can compile UHD successfully, but the subsequent "make test"
> produces an error on the "blockdef_test".  So, I am wondering if this is
> not an intended use case.

Rob,

we hadn't really intended on that being a common use case, but there's
actually no reason it shouldn't work. UHD-3.12 contains way fewer RFNoC
features, though.

I think I remember us fixing that unit test on master branch, and then
it probably didn't get back ported due to no one using UHD-3.12 for
RFNoC. Maybe I can find that commit and cherry-pick it. But if you want
to do RFNoC on UHD-3.12, give it a shot. Note that we won't be
backporting RFNoC-related stuff to UHD-3.12, though.

Cheers,
Martin

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

[USRP-users] N310 as Target for a custom application with OpenCL

[Janos Buttgereit via USRP-users]

Hello Ettus Experts,

we have a Linux-based SDR application up and running that currently uses X300 
USRPs as Interfaces, does some sample processing on the realtime data stream 
and then does some further OpenCL-based processing on those results. 

Now we are consider buying a N310 for this application. According to the Xilinx 
website, Xilinx supports compiling OpenCL kernels for the Zynq device built 
into the N310. So it would be great if our application could be ported to the 
N310 running the sample processing on the ARM and the OpenCL work would be done 
on the FPGA which has far as I know has some resources left in the standard 
image used by the N310.

However I have no practical experience with Xilinx Tools and never took a deep 
look at the Ettus FPGA configurations, so before buying an N310 and finding out 
that this approach is impossible for some reason I’d ask if the experts round 
here if they see any problem in trying to get this kind of setup working? 
Furthermore, is building a highly custom yocto based image for the ARM an 
option supported by Ettus or is the advice to stick to the prebuilt Linux Image 
supplied by Ettus for the N310?

Thanks in Advance
Janos Buttgereit
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] x300 unrecoverable timeouts

[Brophy, William via USRP-users]

Hi Dario,

Are you saying you patched UHD to wait for AKS? Would you be able to provide a 
patch for this?

Thanks
Will

From: Dario Pennisi 
Sent: Friday, July 13, 2018 1:49 AM
To: Brophy, William ; Keith k 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] x300 unrecoverable timeouts

Hi,
We recently investigated a similar issue and have a clear understanding on what 
this comes from.
Commands sent by PC to usrp device are responded with an acknowledge. Each 
command has a sequence number and is sent asynchronously. On the receiving side 
there is a check on acknowledge sequence number and if one is lost system will 
basically give up. The reason why packets can get lost is simply that 
communication is using udp which gives no guarantee on packet delivery and 
linux may drop packets, incoming or outgoing, at any time, even worse if you 
are passing through a switch instead of having a 1:1 link.
We fixed this by patching code so that when sending commands we immediately 
wait for acknowledge and if it doesn't get back in time we retry. This of 
course does not allow pipelined command transfers but provides a reliable 
solution as trying to cache commands and resend them if ack is out of sequence 
won't work since resending commands at that point would change the order 
commands are executed and could be potentially very wrong.
Would be great if someone from usrp could discuss this a bit further and come 
out with a better solution...
Best regards,
Dario Pennisi


On Fri, Jul 13, 2018 at 2:29 AM +0200, "Keith k via USRP-users" 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello Will
This sounds eerily similar to issues I've had using N200s. I basically found 
that working at high rates, using either STREAM_MODE_NUM_SAMPS_AND_DONE or 
using starts and stops was completely unusable. The system would go into an 
unrecoverable set of timeouts or overflows. I had to switch to using non 
interrupted continuous streaming and I had to make sure that the UHD threads 
were isolated to their own cpu cores in order to eliminate being preempted. 
This was the only way I could get stable runtime of the rx side during a long 
running application.

On Thu, Jul 12, 2018 at 1:22 PM, Brophy, William via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
While working to get coherent streams working, I ran into an issue using an 
x310 with two TwinRX daughterboards.
The issue starts with a series of "ERROR_CODE_OVERFLOW (Out of sequence error)" 
errors. In an attempt to recover from that, the rx streamer is thrown out and 
recreated. The next stream errors change to "ERROR_CODE_TIMEOUT". Once in this 
state, all future streams end with this error.
The x310 is connected over 10G ethernet.

I managed to reproduce this error with an example program based off of 
“rx_multi_samples.cpp”. I had to make the following changes:

  1.  STREAM_MODE_START_CONTINUOUS is now used, ending the stream with 
STREAM_MODE_STOP_CONTINUOUS
  2.  The stream delay was set to .01 (mostly to speed up the rate the error 
would occur)
  3.  Multi stream commands (and stop commands) are issued in repetition 
(start, stop, start, stop, etc.) rather than just one long stream
  4.  Each stream uses a different sampling rate (alternates between 25Msps and 
50Msps)
  5.  A small loop was added to the collect loop to slow down the thread enough 
to get overflow errors (but only sometimes, nothing crazy)
  6.  Once the out of sequence error is encountered 10 times in a row, the rx 
streamer is destroyed and re-created
  7.  Every stream command after step 5 ends in a timeout error

It is also worth pointing out that this does not happen if the sample rate does 
not change. The out of sequence errors will still happen until the rx streamer 
is re-created, but the timeout errors do not occur after that…

I attached the entire example program (with modifications) to this email.
I started it with the args:
rx_multi_samples --args addr=192.168.30.2 --subdev "A:0 A:1 B:0 B:1" --channels 
"0,1,2,3" --dilv --rate 5000 --nsamps 800

Is there something wrong with how we are using the interface? Is there steps we 
can take to either avoid or recover from this state?

I appreciate any help we can get…

Will

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



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