[USRP-users] DPDK setup with N320

[Lundberg, Daniel via USRP-users]

My end goal is to use Gnuradio with an N320 to support 250 MS/s streaming.  I 
am posting to the USRP users list first, because I think that's the current 
area of the problem.  I suspect I have a permissions or uhd.conf issue, but the 
documentation on how to set this up correctly is lacking.

I can stream to the N320 in the "normal" way (without DPDK) via gnuradio at 
rates of 125 MS/s in each direction, so I know that all of the hardware and 
regular uhd and/or gnuradio setup is working.

I have gone through and tried to set up DPDK to work with the N320 and the 
Ettus connectivity kit (2X SFP+) following this: 
https://files.ettus.com/manual/page_dpdk.html
I can successfully bind the spf+ ports to the vfio-pci using the 
dpdk-devbind.py script.  If I check with dpdk-devbind.py -status after this 
they show up as assigned to the DPDK driver.

I updated /etc/uhd/uhd.conf as suggested, including the mac addresses, cpu 
assignment, etc..., but I don't think UHD is finding it correctly.  When I try 
to call uhd (via /usr/local/lib/uhd/examples/benchmark_rate) with a use_dpdk=1 
argument, I get a number of errors, including:

[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[ERROR] [MPMD] No viable transport path found!
[ERROR] [MPMD] Failure during block enumeration: RuntimeError: No viable 
transport path found!
...
...
Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()

I've tried running benchmark_rate as a regular user and via sudo, as well as 
via gnuradio as a regular user.  My gnuradio and UHD were installed from 
source.  Same issues with all approaches.  I see a very similar thread here in 
the 3.14.0.0 release notes and it doesn't look like these issues were resolved 
within that thread:
http://ettus.80997.x6.nabble.com/USRP-users-UHD-Announcing-3-14-0-0-Release-Candidate-1-td11840.html

Can someone from Ettus chime in?  Do I need to be running UHD and/or gnuradio 
as root, as implied in that thread?  If this requires installing things in a 
manner different from your published "Getting started with the N320 guide..." 
can you please help me understand the steps needed to get DPDK working with an 
N320?

I am running Ubuntu 18.03.4, UHD is 3.14.0 (specifically 
UHD_3.14.0.HEAD-0-gf6cacec8).

Thank you,

DL

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

Re: [USRP-users] Processor requirements for full-rate streaming on N320

[Lundberg, Daniel via USRP-users]

Thank you all, I will look into DPDK (didn't know about it until now!) and 
investigate what is available with those processors.

Marcus, all we need to do is generate samples from a set of pre-canned files, 
record a loopback to file, and also Tx to another system, which sends samples 
back that we also record to file.  Time sync between the two Rx channels is 
important.  We don't do any additional signal processing in this application, 
so we really just need hardware to support file I/O and streaming, but these 
systems tend to stick around and get used for other things, so I will likely 
try to include some headroom in the processor.

Thank you again,
DL

From: Nate Temple 
Sent: Friday, September 6, 2019 6:39:26 PM
To: Marcus Müller
Cc: Lundberg, Daniel; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Processor requirements for full-rate streaming on N320

Hi  Daniel,

As Marcus mentioned, an i3 is not ideal for streaming at such high rates.

For 200 MS/s of usable bandwidth, you'll need to stream at 250 MS/s per channel.

A colleague has ran 2x2 @ 250 MS/s using an Intel Xeon E5-1620 v3 @ 3.50GHz, 
and I've ran at those rates with an i9-9900x @ 4.4 GHz.

Generally speaking, you'll want to have a CPU with a clock freq of 3.5 GHz or 
higher with as many cores as possible, ideally 4.0+ GHz.

To stream at 250 MS/s you'll need to use DPDK. The Mellanox MCX4121A-ACAT NIC 
is a good option as you do not need to use the vfio-pci driver with it for DPDK.


Regards,
Nate Temple

On Fri, Sep 6, 2019 at 3:24 PM Marcus Müller via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi Daniel,

i3 doesn't sound like the processor family of choice here; a few more
cores can't hurt. Basically, assume one CPU core per stream for the
wire- to CPU-format conversion, plus a bit of demand for someone
handling OS/network card interrupts.
What're you doing with the samples afterwards?

Best regards,
Marcus

On Fri, 2019-09-06 at 21:53 +, Lundberg, Daniel via USRP-users
wrote:
> Does anyone have a known good hardware configuration to support full
> (or at least close to full) 200 MS/s streaming from the N320?
> Preferably with 1 Tx and 2 Rx channels.
> As a data point, a recent i3 (4 cores) seems to be choking above 62.5
> MS/s.  This is over dual SFP+ ports.  At higher sampling rates, it is
> producing U’s, which I interpret to mean that the cpu can’t shovel
> samples into the radio fast enough, not that there is a network jam.
>
> Thank you,
> DL
> ___
> USRP-users mailing list
> 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>
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] Processor requirements for full-rate streaming on N320

[Lundberg, Daniel via USRP-users]

Does anyone have a known good hardware configuration to support full (or at 
least close to full) 200 MS/s streaming from the N320?  Preferably with 1 Tx 
and 2 Rx channels.
As a data point, a recent i3 (4 cores) seems to be choking above 62.5 MS/s.  
This is over dual SFP+ ports.  At higher sampling rates, it is producing U's, 
which I interpret to mean that the cpu can't shovel samples into the radio fast 
enough, not that there is a network jam.

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

Re: [USRP-users] B210: 1/f noise and LO offset

[Lundberg, Daniel via USRP-users]

Just a couple of sanity checks on this...You have to make sure that

1)  You don't already have a GPSDO installed on your B210.  If you do, the 
external reference won't make it in.

2)  Assuming you don't have the GPSDO, you have to tell the B210 to use the 
external reference instead of its own.

Also, from past experience, I have found that avoiding an LO offset that is an 
integer multiple of the sampling rate will avoid some pretty bad spurs.  I 
think these are integer boundary spurs in the PLL.

Dan Lundberg

From: USRP-users  On Behalf Of Erik Heinz 
via USRP-users
Sent: Tuesday, June 4, 2019 10:10 AM
To: Torell, Kent L 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210: 1/f noise and LO offset


Thank you for the explanation.

I tried using an external reference clock (HP 58503A). Unexpectedly, this made 
no difference at all. The noise is still exactly the same.



Erik Heinz


--

Supracon AG
Dr. Erik Heinz
An der Lehmgrube 11
07751 Jena
Tel.: +49 3641 2328-165
Fax: +49 3641 2328-109
Internet: http://www.supracon.com

Handelsregister:  Amtsgericht Gera HRB  208970
Umsatzsteuer-Id.:  DE 216 111 685

Kaufm. Vorstand:   Matthias Meyer
Vorsitz Aufsichtsrat:  Prof. Dr. Michael Siegel

Von: Torell, Kent L mailto:kent.tor...@gd-ms.com>>
Gesendet: Montag, 3. Juni 2019 17:10
An: Erik Heinz
Cc: usrp-users@lists.ettus.com
Betreff: RE: B210: 1/f noise and LO offset

The phase noise comes from the B210 LO (RF synthesizer), and is present 
regardess of the frequency offset...you are misled by the log axis of the plot.

The close-in noise can be improved by using a high quality external 10 MHz 
source.  The control loop action of the synthesizer translates the reference 
phase noise to the LO phase noise.  You may have a lab standard available; or 
you could purchase a GPSDO version for the B210 (Ettus part 783454-01).

If this doesn't meet your needs, you will need to shift the signal lower in 
frequency with an external mixer and a high quality microwave synthesizer (e.g. 
$20K Rhode/Keysight/etc.) that has the phase noise you require.   The B210 uses 
an Analog Devices AD9361 chip, which generates the RF local oscillator signal 
with a high frequency phase locked loop, then divides it down to the requested 
frequency.  5 GHz is at the upper end of it's range, so the division is small 
and the phase noise will be at it's highest.   Moving down several octaves will 
improve the phase noise, dropping 6 dB for every octave (e.g. 500 MHz would 
have 20 dB lower phase noise than 5 GHz).

Kent Torell

From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
On Behalf Of Erik Heinz via USRP-users
Sent: Monday, June 3, 2019 3:06 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B210: 1/f noise and LO offset


Hello everyone,



preliminary remark: I am an physicist - so please excuse some possible 
knowledge gaps in radio engineering :-).



I would like to use a B210 to measure the IQ response of superconducting 
resonators at about 5 GHz. This is done by feeding the resonators a signal from 
the transmitter with a frequency near the resonance, amplifying by LNAs, 
coupling to the receiver, demodulating to base band, and recording the 
resulting IQ signal. The signal bandwidth of interest will be small, in the kHz 
range.



Since noise of the resonators has to be measured as well, I first had a look at 
 the noise of the B210 output without an external signal. The result is plotted 
in figure 1 (vertical axis is scaled to the output range of the ADC). It seems, 
below 100kHz the B210 receiver has strong 1/f noise. I would guess this is 
hardware noise from the mixer. Anyone knows if this assumption is correct?



So I thought it would be a good idea to demodulate not directly to base band, 
but to an IF of may be 100 kHz and do the rest in software. I did a quick test 
using gnu radio, feeding the output of the USRP source and a 100 kHz signal to 
a multiplier. This indeed has the desired effect (figure 2, blue curve vs. red 
curve).

If I understand the concept of the B210 local oscillators correctly, the same 
should be possible directly on the B210, using an LO offset of 100 kHz. The 
result, however, is completely different (figure 2, green curve).



Any ideas why? Thank you.



Best regards,

Erik


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

Re: [USRP-users] How to periodically write files using USRP and GNUradio

[Lundberg, Daniel via USRP-users]

I had a similar problem where I wanted to measure the phase and magnitude 
stability of a system over long periods of time, but only needed small chunks 
of data to characterize the drift.  I solved this by creating a top block that 
uses the head block and a file sink to write a defined number of samples after 
doing some other processing.  That block was called by a loop like this:

def main(top_block_cls=phase_diff_measure_filechange, options=None):

for x in range(0,600):
time.sleep(8)
tb = top_block_cls()
tb.start(100)
time.sleep(2)
tb.stop()
tb.wait()


The only other trick was to make the file names of the files I was saving 
contain a time stamp, which was done within def __init__(self): in the 
variables section like this:
self.file_phase = file_phase = 
path/phase"+datetime.now().strftime("%Y.%m.%d.%H.%M.%S") +".dat"
self.file_mag = file_mag = 
path/mag"+datetime.now().strftime("%Y.%m.%d.%H.%M.%S") +".dat"

Those timestamp commands required "import time"

There's probably a more elegant way to do this, but it got the job done.

Hope that helps,

Daniel P. Lundberg, Ph.D.
Senior Research Scientist
Georgia Tech Research Institute
Sensors and Electromagnetic Applications Laboratory
Intelligence, Surveillance, & Reconnaissance Division
404.407.7613
daniel.lundb...@gtri.gatech.edu


-Original Message-
From: USRP-users  On Behalf Of Marcus D. 
Leech via USRP-users
Sent: Monday, April 29, 2019 8:24 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] How to periodically write files using USRP and 
GNUradio

On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote:
> Hey all,
>
> I'd like to know how to write short files of streamed USRP data 
> periodically using GNUradio. For instance, I'd like the USRP to 
> automatically record 5 seconds of data every 10 minutes. It does not 
> matter to me whether the USRP is constantly on and most of the data is 
> being discarded, or if the USRP wakes up every 10 minutes to record 
> the data before sleeping. Whichever is easiest to achieve is fine by 
> me. Does anyone have experience doing this kind of thing?
>
> -Mark
>
>
>
> --
> Mark Wagner
> University of California San Diego
> Electrical and Computer Engineering
>
>
If you're using Gnu Radio, you can simply use the file sink, and have it record 
to "/dev/null" most of the time, then have something (perhaps via
   the XMLRPC built-in feature) change the filename to whatever your desired 
filename is, and then revert it back to "/dev/null".

I think I said the same thing on the discuss-gnuradio mailing list a few days 
ago.

The usrp-users mailing list isn't the best place to ask Gnu Radio questions, a 
question like this, which is inherently radio-type agnostic, probably
   belongs on the discuss-gnuradio mailng list, because it's more about "how do 
I make Gnu Radio dance".



___
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] Memory limitations for N310 using replay block

[Lundberg, Daniel via USRP-users]

Wade,
Great, thanks!  At least in about 30 minutes of preliminary testing, that does 
seem to have solved the issue.

I am successfully able to replay a 750 MB file (~1.5 seconds of data at 125 
MS/s) on the N310.  Now on to tuning!
-Dan

From: Wade Fife 
Sent: Wednesday, November 7, 2018 7:00 PM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] Memory limitations for N310 using replay block

Dan,

I've been testing and I was able to reproduce something that might be your 
issue. I'm still testing, but if you want to try the following change, it might 
fix your issue. Simply delete this line and rebuild the FPGA:

https://github.com/EttusResearch/fpga/blob/4f25ed1b4129c94677b66540894a03a4f80306ea/usrp3/lib/axi/axi_replay.v#L758

I'll have some other fixes/improvements soon.

Thanks,

Wade

On Mon, Nov 5, 2018 at 3:39 PM Wade Fife 
mailto:wade.f...@ettus.com>> wrote:
I assume the N3xx code used to use the 2x version and it wasn't renamed when it 
was switched to 4x. Normally the instance name would correspond to the module 
name.

I'll see if I can reproduce this on an N310.

Wade

On Mon, Nov 5, 2018 at 1:58 PM Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>> wrote:
Hi Wade,
Thanks Wade, I’ve been digging around in those files, and I agree that if it is 
invoking the 4x64 version it looks like the limit is 1 GB, not 32 MB.  I am 
somewhat confused by the existence of both a 2x and a 4x axi_intercon set of 
files for the N310.  In particular, in n3xx_core.v, there is a line:

axi_intercon_4x64_256_bd_wrapper axi_intercon_2x64_256_bd_i (…

Why isn’t this:

axi_intercon_4x64_256_bd_wrapper axi_intercon_4x64_256_bd_i (…

Thank you,
Dan

From: Wade Fife mailto:wade.f...@ettus.com>>
Sent: Monday, November 5, 2018 12:26 PM
To: Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>>
Cc: usrp-users mailto:USRP-users@lists.ettus.com>>
Subject: Re: [USRP-users] Memory limitations for N310 using replay block

Hi Dan,

You can use the viv_modify_bd command to open the BD file in Vivado then use 
the "Address Editor" tab to change how slave ports map to the master port, 
which connects to DRAM. For example, after running "setupenv.sh" you could run 
"viv_modify_bd 
ip/axi_intercon_2x64_256_bd/axi_intercon_4x64_256_bd.bd<http://axi_intercon_4x64_256_bd.bd>
 N310" to edit the 
axi_intercon_2x64_256_bd.bd<http://axi_intercon_2x64_256_bd.bd> file. If you're 
feeling adventurous, then you could also look at the XML contents of the BD 
file directly. The relevant tag is "addressSpaces" then the "addressOffset" and 
"range" tags, but it's probably safer to let Vivado make any changes.

However, as far as I can tell, axi_intercon_4x64_256_bd should already be 
configured to handle more than 32 MiB. If that's the file you're using (which 
is what's normally referenced in n3xx_core.v) then something else might be 
going on. But the 2x64 version looks like it's limited to 32 MiB.

Thanks,

Wade

On Fri, Nov 2, 2018 at 5:07 PM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am following the instructions for using the replay block with the N310 
(https://kb.ettus.com/Using_the_RFNoC_Replay_Block).  I have established that I 
can replay play a relatively small file (~5 MB) without issues.  However, for 
much larger files, I get some strange artifacts on the output (periodic garbage 
mixed in with the desired data), and I think I am hitting the memory 
limitations described in the following note:

“Note: The amount of memory available to the Replay block is limited by the 
size of the DRAM on the USRP and how the memory interface is configured on the 
USRP. For example, the axi_intercon_2x64_128_bd IP used by the X310 is 
configured to give each connected device an address space of 32 MiB. As a 
result, the Replay block will be limited to this amount of memory. The 
axi_intercon_2x64_128_bd file must be modified if more than 32 MiB needs to be 
buffered.”

Can someone comment on the hard limitations in the N310?  It has 2 GB of DRAM, 
but I do not know how much of that is available, and I also do not know how to 
interpret the equivalent axi_intercon*** files for the N310. Also, there are 
two axi_intercon* files for the N310, 
axi_intercon_2x64_256_bd.bd<http://axi_intercon_2x64_256_bd.bd> and 
axi_intercon_4x64_256.bd.bd<http://axi_intercon_4x64_256.bd.bd>.  Does someone 
have an example of how the appropriate file has been modified for an N310?

Alternatively, can someone suggest an application note or something similar to 
get me started on how to modify the memory management of the USRP?

Thank you,
Dan
___
USRP-users mailing list
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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Memory limitations for N310 using replay block

[Lundberg, Daniel via USRP-users]

Hi Wade,
Thanks Wade, I’ve been digging around in those files, and I agree that if it is 
invoking the 4x64 version it looks like the limit is 1 GB, not 32 MB.  I am 
somewhat confused by the existence of both a 2x and a 4x axi_intercon set of 
files for the N310.  In particular, in n3xx_core.v, there is a line:

axi_intercon_4x64_256_bd_wrapper axi_intercon_2x64_256_bd_i (…

Why isn’t this:

axi_intercon_4x64_256_bd_wrapper axi_intercon_4x64_256_bd_i (…

Thank you,
Dan

From: Wade Fife 
Sent: Monday, November 5, 2018 12:26 PM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] Memory limitations for N310 using replay block

Hi Dan,

You can use the viv_modify_bd command to open the BD file in Vivado then use 
the "Address Editor" tab to change how slave ports map to the master port, 
which connects to DRAM. For example, after running "setupenv.sh" you could run 
"viv_modify_bd 
ip/axi_intercon_2x64_256_bd/axi_intercon_4x64_256_bd.bd<http://axi_intercon_4x64_256_bd.bd>
 N310" to edit the 
axi_intercon_2x64_256_bd.bd<http://axi_intercon_2x64_256_bd.bd> file. If you're 
feeling adventurous, then you could also look at the XML contents of the BD 
file directly. The relevant tag is "addressSpaces" then the "addressOffset" and 
"range" tags, but it's probably safer to let Vivado make any changes.

However, as far as I can tell, axi_intercon_4x64_256_bd should already be 
configured to handle more than 32 MiB. If that's the file you're using (which 
is what's normally referenced in n3xx_core.v) then something else might be 
going on. But the 2x64 version looks like it's limited to 32 MiB.

Thanks,

Wade

On Fri, Nov 2, 2018 at 5:07 PM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am following the instructions for using the replay block with the N310 
(https://kb.ettus.com/Using_the_RFNoC_Replay_Block).  I have established that I 
can replay play a relatively small file (~5 MB) without issues.  However, for 
much larger files, I get some strange artifacts on the output (periodic garbage 
mixed in with the desired data), and I think I am hitting the memory 
limitations described in the following note:

“Note: The amount of memory available to the Replay block is limited by the 
size of the DRAM on the USRP and how the memory interface is configured on the 
USRP. For example, the axi_intercon_2x64_128_bd IP used by the X310 is 
configured to give each connected device an address space of 32 MiB. As a 
result, the Replay block will be limited to this amount of memory. The 
axi_intercon_2x64_128_bd file must be modified if more than 32 MiB needs to be 
buffered.”

Can someone comment on the hard limitations in the N310?  It has 2 GB of DRAM, 
but I do not know how much of that is available, and I also do not know how to 
interpret the equivalent axi_intercon*** files for the N310. Also, there are 
two axi_intercon* files for the N310, 
axi_intercon_2x64_256_bd.bd<http://axi_intercon_2x64_256_bd.bd> and 
axi_intercon_4x64_256.bd.bd<http://axi_intercon_4x64_256.bd.bd>.  Does someone 
have an example of how the appropriate file has been modified for an N310?

Alternatively, can someone suggest an application note or something similar to 
get me started on how to modify the memory management of the USRP?

Thank you,
Dan
___
USRP-users mailing list
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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Memory limitations for N310 using replay block

[Lundberg, Daniel via USRP-users]

I am following the instructions for using the replay block with the N310 
(https://kb.ettus.com/Using_the_RFNoC_Replay_Block).  I have established that I 
can replay play a relatively small file (~5 MB) without issues.  However, for 
much larger files, I get some strange artifacts on the output (periodic garbage 
mixed in with the desired data), and I think I am hitting the memory 
limitations described in the following note:

"Note: The amount of memory available to the Replay block is limited by the 
size of the DRAM on the USRP and how the memory interface is configured on the 
USRP. For example, the axi_intercon_2x64_128_bd IP used by the X310 is 
configured to give each connected device an address space of 32 MiB. As a 
result, the Replay block will be limited to this amount of memory. The 
axi_intercon_2x64_128_bd file must be modified if more than 32 MiB needs to be 
buffered."

Can someone comment on the hard limitations in the N310?  It has 2 GB of DRAM, 
but I do not know how much of that is available, and I also do not know how to 
interpret the equivalent axi_intercon*** files for the N310. Also, there are 
two axi_intercon* files for the N310, axi_intercon_2x64_256_bd.bd and 
axi_intercon_4x64_256.bd.bd.  Does someone have an example of how the 
appropriate file has been modified for an N310?

Alternatively, can someone suggest an application note or something similar to 
get me started on how to modify the memory management of the USRP?

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

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Lundberg, Daniel via USRP-users]

Hi All,
The root cause of this was that MPM on our N310 was out of sync with MPM on the 
host.  See the instructions here for how to fix it: 
http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_fsbuild

Kudos to Michael West for pointing this out.

From: Michael West 
Sent: Tuesday, October 30, 2018 8:00 PM
To: Lundberg, Daniel 
Cc: Serge Malo ; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Thank you for everyone's input.  We are aware and taking this very seriously.  
We tried unsuccessfully to reproduce the issue on multiple devices using both 
the v3.13.0.3-rc1 tag and head of master.  We will continue investigating and 
report back with any new information.

Regards,
Michael

On Mon, Oct 29, 2018 at 7:07 AM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I think I am seeing the same or a similar problem using the latest master 
(which I think is roughly equivalent to 3.13.0.3 RC1, correct me if I am wrong) 
on an N310.
When I save a signed 16-bit binary file and feed it into the 
replay_sample_from_file example, I can only provide it with a full-scale 
amplitude of ~8 bits in amplitude (+/- 2^8-1), or I get saturation / strange 
corruption of the waveform.  Changing the gain does not seem to have any 
effect.  The N310 is supposed to have a 14-bit DAC, and conversations with 
Ettus imply that the replay block is too simple to cause this, so the problem 
is probably pretty far upstream?  I have described the problem to Ettus, and 
they suggested checking most of the things you and I have already tested 
(gains, input files, etc…).

From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
On Behalf Of Serge Malo via USRP-users
Sent: Monday, October 29, 2018 9:55 AM
To: sdorm...@eng.ucsd.edu<mailto:sdorm...@eng.ucsd.edu>
Cc: USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD 
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - -
Serge Malo
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com<http://www.skydelsolutions.com/>
Twitter: @skydelsol<https://twitter.com/skydelsol>
Avis : Ce message est confidentiel et protégé par le secret professionnel. Si 
vous n'êtes pas le destinataire, veuillez informer l'expéditeur par courriel 
immédiatement et effacer ce message et en détruire toute copie. / Notice: This 
message is confidential and privileged. If you are not the addressee, please 
inform the sender by return e-mail immediately and delete this message and 
destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Attempt 2. Sorry for breaking mailing list rules with the attachments. Here is 
a google drive link to the screenshots, GRC file, and binary files. (3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
mailto:sdorm...@eng.ucsd.edu>> wrote:
We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Lundberg, Daniel via USRP-users]

I appreciate the responsiveness.  I am fairly new to the N310 and the RFNOC 
blocks, so I would not entirely rule out the possibility of user error at this 
point.  If there are additional diagnostics I could supply, please let me know.
-Dan

From: Michael West 
Sent: Tuesday, October 30, 2018 8:00 PM
To: Lundberg, Daniel 
Cc: Serge Malo ; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Thank you for everyone's input.  We are aware and taking this very seriously.  
We tried unsuccessfully to reproduce the issue on multiple devices using both 
the v3.13.0.3-rc1 tag and head of master.  We will continue investigating and 
report back with any new information.

Regards,
Michael

On Mon, Oct 29, 2018 at 7:07 AM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I think I am seeing the same or a similar problem using the latest master 
(which I think is roughly equivalent to 3.13.0.3 RC1, correct me if I am wrong) 
on an N310.
When I save a signed 16-bit binary file and feed it into the 
replay_sample_from_file example, I can only provide it with a full-scale 
amplitude of ~8 bits in amplitude (+/- 2^8-1), or I get saturation / strange 
corruption of the waveform.  Changing the gain does not seem to have any 
effect.  The N310 is supposed to have a 14-bit DAC, and conversations with 
Ettus imply that the replay block is too simple to cause this, so the problem 
is probably pretty far upstream?  I have described the problem to Ettus, and 
they suggested checking most of the things you and I have already tested 
(gains, input files, etc…).

From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
On Behalf Of Serge Malo via USRP-users
Sent: Monday, October 29, 2018 9:55 AM
To: sdorm...@eng.ucsd.edu<mailto:sdorm...@eng.ucsd.edu>
Cc: USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD 
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - -
Serge Malo
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com<http://www.skydelsolutions.com/>
Twitter: @skydelsol<https://twitter.com/skydelsol>
Avis : Ce message est confidentiel et protégé par le secret professionnel. Si 
vous n'êtes pas le destinataire, veuillez informer l'expéditeur par courriel 
immédiatement et effacer ce message et en détruire toute copie. / Notice: This 
message is confidential and privileged. If you are not the addressee, please 
inform the sender by return e-mail immediately and delete this message and 
destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Attempt 2. Sorry for breaking mailing list rules with the attachments. Here is 
a google drive link to the screenshots, GRC file, and binary files. (3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
mailto:sdorm...@eng.ucsd.edu>> wrote:
We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They ju

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Lundberg, Daniel via USRP-users]

I think I am seeing the same or a similar problem using the latest master 
(which I think is roughly equivalent to 3.13.0.3 RC1, correct me if I am wrong) 
on an N310.
When I save a signed 16-bit binary file and feed it into the 
replay_sample_from_file example, I can only provide it with a full-scale 
amplitude of ~8 bits in amplitude (+/- 2^8-1), or I get saturation / strange 
corruption of the waveform.  Changing the gain does not seem to have any 
effect.  The N310 is supposed to have a 14-bit DAC, and conversations with 
Ettus imply that the replay block is too simple to cause this, so the problem 
is probably pretty far upstream?  I have described the problem to Ettus, and 
they suggested checking most of the things you and I have already tested 
(gains, input files, etc…).

From: USRP-users  On Behalf Of Serge Malo 
via USRP-users
Sent: Monday, October 29, 2018 9:55 AM
To: sdorm...@eng.ucsd.edu
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD 
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - -
Serge Malo
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol
Avis : Ce message est confidentiel et protégé par le secret professionnel. Si 
vous n'êtes pas le destinataire, veuillez informer l'expéditeur par courriel 
immédiatement et effacer ce message et en détruire toute copie. / Notice: This 
message is confidential and privileged. If you are not the addressee, please 
inform the sender by return e-mail immediately and delete this message and 
destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Attempt 2. Sorry for breaking mailing list rules with the attachments. Here is 
a google drive link to the screenshots, GRC file, and binary files. (3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
mailto:sdorm...@eng.ucsd.edu>> wrote:
We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.



On Wed, Oct 10, 2018 at 6:20 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
Hello,

We have the exact same problem. My lab is waiting on some sfp+ cables so in a 
few days I will share our screenshots, code, and data binary files in order to 
provide this thread with a second example of this issue. For now, all I can say 
is this problem is not isolated to your N310 or Windows.

We have two N310's running with the same version of UHD (and GNUradio 3.7.13.4) 
on Linux kernel 4.18. By using amplitude sliders in GNUradio we found that 
there is a very small and strange gain "Goldilocks" zone around .002 that gives 
good results. Going higher starts to raise the noise floor until all signal 
definition is gone.

Ali Dormiani
UCSD Noiselab
What is your RF gain set to in these examples?  Does that change things?

If you raise things to a level where non-linearity is apparent, does 

Re: [USRP-users] Building N310 replay example

[Lundberg, Daniel via USRP-users]

Great, thank you, this did the trick.  Still a bunch of critical warnings in 
the fpga build, but it doesn’t look like anything catastrophic.

I have verified that the N310 will read in a file and play it back with the 
replay block example.  Now I just need to figure out how to write files into 
the replay block format correctly in Matlab so that the output modulation isn’t 
garbage ☺

From: Wade Fife 
Sent: Friday, October 19, 2018 12:48 PM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] Building N310 replay example

Dan,

The UHD exception you saw appears to be due to ce_clk and ce_rst not be 
connected in the RFNoC variant that you built (N310_RFNOC_HG; it works in 
N310_HG). You can fix this for now by connecting them in 
rfnoc_ce_auto_inst_n310.v (see diff below, or refer to 
rfnoc_ce_default_inst_n310.v as an example of how to set ce_clk and ce_rst). 
I'll look into getting this fixed permanently.

diff --git a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v 
b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
index 176dad48..e61038d7 100644
--- a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
+++ b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
@@ -14,6 +14,9 @@
 end
   endgenerate

+  wire ce_clk = bus_clk;
+  wire ce_rst = bus_rst;
+
   noc_block_ddc #(.NOC_ID(64'hDDC0___0001), .NUM_CHAINS(1)) 
inst_noc_block_ddc (
 .bus_clk(bus_clk), .bus_rst(bus_rst),
 .ce_clk(ce_clk), .ce_rst(ce_rst),

Thanks,

Wade


On Thu, Oct 18, 2018 at 4:06 PM Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>> wrote:
I tried nuking everything and doing a clean install of the master branch, but 
still get the same errors.  Here’s a couple of warnings I did not copy in my 
first e-mail that occur when running the uhd_image_loader with the new fpga 
.bit:

[WARNING] [MPMD IMAGE LOADER] RuntimeError:  Component file does not exist: 
/path to build/n3xx.dts
[WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected compat for 
component ‘FPGA’.  Expect 5.2 Actual: 5.3

The second one seems to indicate a minor mismatch between the UHD master and 
the FPGA .bit, correct?

From: Wade Fife mailto:wade.f...@ettus.com>>
Sent: Thursday, October 18, 2018 11:37 AM
To: Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>>
Cc: usrp-users mailto:USRP-users@lists.ettus.com>>
Subject: Re: [USRP-users] Building N310 replay example

Hi Dan,

I'll see if I can reproduce this with the current master. In the meantime I 
suggest just double checking that the fpga-src submodule is also up to date. 
Currently, uhd master is at 7130059 and fpga should be at 340bb07. I know that 
error would occur with older versions of the FPGA code.

Thanks,

Wade

On Thu, Oct 18, 2018 at 9:38 AM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am trying to to work with the RFNoc replay block on an N310.  I have followed 
the instructions here: https://kb.ettus.com/Using_the_RFNoC_Replay_Block

I have Ubuntu 18.04, and the current master branch of UHD.

Those instructions are for the X3xx, but I tried modifying them for the N310, 
by doing “make N310_RFNOC_HG” after changing to “USE_REPLAY=1”
This build of the n3xx.bit completed with no errors, but with 67 “critical 
warnings.  I attempted to forge on anyways, but the uhd_image_loader has 
several errors (copied at the end of this message).

My question is whether or not anyone has successfully enabled the replay block 
on an N310 with the current master build?  I have not intentionally deviated 
from the prescribed script in any way to get to this point, so I am a bit lost 
on how to proceed.

Thank you,
Dan

[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)0]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

[ERROR] [MPMD] Failure during block enumeration: EnvironmentError: IOError: 
Block ctrl (CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: [0/Replay_0] sr_write() failed: 
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - 
AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool,

Re: [USRP-users] Building N310 replay example

[Lundberg, Daniel via USRP-users]

I tried nuking everything and doing a clean install of the master branch, but 
still get the same errors.  Here’s a couple of warnings I did not copy in my 
first e-mail that occur when running the uhd_image_loader with the new fpga 
.bit:

[WARNING] [MPMD IMAGE LOADER] RuntimeError:  Component file does not exist: 
/path to build/n3xx.dts
[WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected compat for 
component ‘FPGA’.  Expect 5.2 Actual: 5.3

The second one seems to indicate a minor mismatch between the UHD master and 
the FPGA .bit, correct?

From: Wade Fife 
Sent: Thursday, October 18, 2018 11:37 AM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] Building N310 replay example

Hi Dan,

I'll see if I can reproduce this with the current master. In the meantime I 
suggest just double checking that the fpga-src submodule is also up to date. 
Currently, uhd master is at 7130059 and fpga should be at 340bb07. I know that 
error would occur with older versions of the FPGA code.

Thanks,

Wade

On Thu, Oct 18, 2018 at 9:38 AM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am trying to to work with the RFNoc replay block on an N310.  I have followed 
the instructions here: https://kb.ettus.com/Using_the_RFNoC_Replay_Block

I have Ubuntu 18.04, and the current master branch of UHD.

Those instructions are for the X3xx, but I tried modifying them for the N310, 
by doing “make N310_RFNOC_HG” after changing to “USE_REPLAY=1”
This build of the n3xx.bit completed with no errors, but with 67 “critical 
warnings.  I attempted to forge on anyways, but the uhd_image_loader has 
several errors (copied at the end of this message).

My question is whether or not anyone has successfully enabled the replay block 
on an N310 with the current master build?  I have not intentionally deviated 
from the prescribed script in any way to get to this point, so I am a bit lost 
on how to proceed.

Thank you,
Dan

[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)0]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

[ERROR] [MPMD] Failure during block enumeration: EnvironmentError: IOError: 
Block ctrl (CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: [0/Replay_0] sr_write() failed: 
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - 
AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155



___
USRP-users mailing list
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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Building N310 replay example

[Lundberg, Daniel via USRP-users]

I am trying to to work with the RFNoc replay block on an N310.  I have followed 
the instructions here: https://kb.ettus.com/Using_the_RFNoC_Replay_Block

I have Ubuntu 18.04, and the current master branch of UHD.

Those instructions are for the X3xx, but I tried modifying them for the N310, 
by doing "make N310_RFNOC_HG" after changing to "USE_REPLAY=1"
This build of the n3xx.bit completed with no errors, but with 67 "critical 
warnings.  I attempted to forge on anyways, but the uhd_image_loader has 
several errors (copied at the end of this message).

My question is whether or not anyone has successfully enabled the replay block 
on an N310 with the current master build?  I have not intentionally deviated 
from the prescribed script in any way to get to this point, so I am a bit lost 
on how to proceed.

Thank you,
Dan

[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)0]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

[ERROR] [MPMD] Failure during block enumeration: EnvironmentError: IOError: 
Block ctrl (CE_03_Port_60) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: [0/Replay_0] sr_write() failed: 
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - 
AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned 
int]
  at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155



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

Re: [USRP-users] N310 MPMD link speed warnings

[Lundberg, Daniel via USRP-users]

I am following the N310 Getting Started Guide, which states to set MTUBytes to 
8000 for 1 GB on SFP0.  If that is incorrect, perhaps the guide should be 
updated?
https://kb.ettus.com/N300/N310_Getting_Started_Guides

From: Ali Dormiani 
Sent: Monday, October 15, 2018 7:21 PM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] N310 MPMD link speed warnings

1 Gbe Ethernet can't handle that much data. Most 1 Gbe class NIC controllers 
prevent you from setting the MTU over 1500 anyway. I would be surprised if the 
GUI settings in network manager actually went through. If you type 'ifconfig' 
in a command console the host NIC is probably still running at 1500 MTU.

https://en.wikipedia.org/wiki/Ethernet_frame#Ethernet_II

The N310 supports two modes.

1. 1.25 Gbe mode

2. 10 Gbe mode

I think the warning is saying that it does not know what to do (link 
negotiation with your host NIC failed) so it defaults to the slower of the two 
modes.



On Mon, Oct 15, 2018 at 3:22 PM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am using Ubuntu 18.04, an N310 with the current master builds.  I am 
currently testing basic operation using a USB/Ethernet adaptor for the 
management connection, and a 1 GB Ethernet connection straight from the 
computer’s NIC port to the SFP0 port on the N310.

I have built from source and can make it through all of the examples and 
benchmarking exercises successfully.  I am also able to successfully run the 
tx_waveform example with a streaming rate of 25e6 with a master clock rate of 
125e6.  This seems to be the limit, 31.25e6 causes underruns.

Despite the streaming link seeming to work, there are chronic warnings such as:
“[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of 
12500

The network connections were set up within Ubuntu’s network manager, with 
MTUBytes = 8000 (also set in the N310’s /etc/system/network/ files).
Autonegotiation is enabled on both ends, per ethtool outputs.

Any input on where these warnings originate, and if there is a way to suppress 
them?

Thank you
Dan
___
USRP-users mailing list
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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N310 MPMD link speed warnings

[Lundberg, Daniel via USRP-users]

I am using Ubuntu 18.04, an N310 with the current master builds.  I am 
currently testing basic operation using a USB/Ethernet adaptor for the 
management connection, and a 1 GB Ethernet connection straight from the 
computer's NIC port to the SFP0 port on the N310.

I have built from source and can make it through all of the examples and 
benchmarking exercises successfully.  I am also able to successfully run the 
tx_waveform example with a streaming rate of 25e6 with a master clock rate of 
125e6.  This seems to be the limit, 31.25e6 causes underruns.

Despite the streaming link seeming to work, there are chronic warnings such as:
"[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of 
12500

The network connections were set up within Ubuntu's network manager, with 
MTUBytes = 8000 (also set in the N310's /etc/system/network/ files).
Autonegotiation is enabled on both ends, per ethtool outputs.

Any input on where these warnings originate, and if there is a way to suppress 
them?

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

[USRP-users] Best path forward on N310

[Lundberg, Daniel via USRP-users]

A bit of background:
I have been using a B205i mini to transmit a variety of pre-computed waveforms. 
 These have ~5 MHz of BW, and I've been streamin binary files sampled at 6.25 
MS/s.  I use a modified version of the tx_samples_from_file example, using a 
host laptop via a USB 3.0 to Ethernet adaptor.  The manner in which it is 
operated allows the process to be slow, i.e., it's OK for me to manually launch 
a new script that selects a different waveform binary file on the host laptop 
each time I want to start transmitting something else.  This all works fine.

However, the quality of the waveform is important, and the B205 has some 
noticeable limitations with respect to IQ imbalance resulting in unwanted 
amplitude modulation, phase noise, a 12 bit DAC, etc...  This is OK, because it 
is a <$1000 device, but now it's time to do better.  I have an N310 to try, and 
I am looking for feedback on the best path forward.  I understand that the 
clock rate selections are somewhat limited on the N310, but that I should be 
able to run it in a comparable way to the B205 if I allow the N310 to perform 
interpolation, i.e., 125 MS/s with an interpolation factor of 20 for a 6.25 
MS/s input.  This is an OK first step.

So now to my question:
I would like to investigate the transmit quality without the N310's 
interpolation, because I have no idea exactly how it does this signal 
processing.  So I think the normal path forward there is to set up an interface 
on a host that can stream at 125 MS/s, which is not trivial (thunderbolt 
adaptors, a computer with the right cards, etc...).  I am curious if it is 
possible for me to run the N310 in embedded mode, have the waveform files 
loaded locally on the N310, and issue commands to transmit in a loop.  These 
files are currently ~80MB each, because they are ~1.5 seconds sampled at 6.25 
MH/s.  They would scale up to ~1.6 GB if sampled at 125 MS/s with no 
interpolation.  Is this something the N310 hardware could handle in embedded 
mode, i.e., streaming from its own hardware resources, rather than through the 
SFP?  I am finding documentation on the embedded mode of the N310 hard to find, 
but I may just be looking in the wrong places.

Thank you,
DL


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