Re: [USRP-users] Fwd: Error handling D when reading data USRP N 210

[Ivan Zahartchuk via USRP-users]

I read at 25 MHz with frequency tuning. And there can be a lot of these
reorganizations. On another PC, I have an Ethernet controller network card:
Intel Corporation 82571EB / 82571GB Gigabit Ethernet Controller D0 / D1
(copper applications) (rev 06) and similar errors occur. Unfortunately, I
cannot test the new network card right now. Perhaps you have ideas how to
get around this programmatically ??

сб, 12 окт. 2019 г. в 07:18, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:

> On 10/11/2019 04:28 PM, Sam Reiter via USRP-users wrote:
>
> Ivan,
>
> Thanks for sending that along. From a software perspective, what
> parameters do you input to your attached code to run it? I'm trying to
> understand the data rates you're trying to sustain over the NIC you have.
> I've been combing through this past USRP-users thread for some additional
> insight:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html
>
> Based on some of those suggestions, it might be wise to try finding
> another NIC to bring into the equation.
>
> Sam
>
> Indeed, I just noticed the 82574L/LM referenced in the original complaint.
>
> Those types of NICs have issues that cause packet loss--there have been a
> few "workarounds" over the years in various kernels, but none of
>   them actually 100% fix the underlying issue with those chips--they're
> basically broken.   You don't notice this with web-browsing and
>   other TCP-based protocols, because those protocols do error recovery.
>
>
>
>
>
> On Wed, Oct 9, 2019 at 2:14 PM Ivan Zahartchuk via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>
>>
>> -- Forwarded message -
>> От: Ivan Zahartchuk 
>> Date: ср, 9 окт. 2019 г. в 06:05
>> Subject: Re: [USRP-users] Error handling D when reading data USRP N 210
>> To: Sam Reiter 
>>
>>
>> CPU intel core i7 -3610QE 2.3 GGz
>> RAM 16 Gb
>>  2 NIC intel 82574L gigabit ethernet and intel 82574LM gigabit ethernet
>>
>>
>> вт, 8 окт. 2019 г. в 16:59, Sam Reiter :
>>
>>> What hardware are you using on the host side? Specifically, I'm
>>> interested in CPU, RAM, and NIC.
>>>
>>> Sam Reiter
>>>
>>> On Tue, Oct 8, 2019 at 6:22 AM Ivan Zahartchuk via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello. When I read data from the board, error D periodically passes.
 It leads to bursts in the spectrum that fits in the figure. Please
 tell me how you can remove this error or how it can be handled? I also
 attach the code file.
 [image: errorD.png]
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

Re: [USRP-users] X310 Temperature Range

[Arun kumar Verma via USRP-users]

Hi Sam
Thanks for the information. My only doubt is about the FPGA.  FPGA is 
industrial grade or Commercial grade ? other parts I have verified and all the 
parts are with Temp Range of -40 to +85. 
As in case of B205mini it is clearly mentioned the grade of the FPGA.
Regards,Arun Verma

 

On Wednesday, October 16, 2019, 01:13:56 AM GMT+5:30, Sam Reiter 
 wrote:  
 
 Hey Arun,
The temperature range for the X310 and the TwinRX is noted as 23 +/- 3 C. This 
is meant to convey that the device is intended for indoor lab use and has not 
been thoroughly tested in extreme environments like you've mentioned. You're 
also correct that you'll see device performance change over that temperature 
range and I think -20C will be dipping below the rating of some of the 
components. Some key components can be found here:
https://kb.ettus.com/X300/X310#Key_Component_Datasheets
Depending on what you're hoping to do, we see folks develop custom enclosures 
for these types of radios with and without thermal regulation. At the end of 
the day if you're subjecting this radio to those kinds of extremes, it's up to 
you to put it through its paces and make sure it'll meet your needs. I'll also 
note that we don't formally endorse any X310 enclosures, but one of the few 
IP67 OTS solutions I've found for the X310 is sold by Pixus: 

http://www.pixustechnologies.com/products/enclosure-system-solutions/specialty-small-form-factor-rugged-x310-other-2/specialty-small-form-factor-rugged-x310-other/
Not sure if this does anything to extend temperature range, but it could be a 
starting point in developing your own ruggedized solution to deploy. Also if 
anyone else has recommendations or experience with X310 enclosure solutions, 
I'd be curious to hear what you've made or worked with in the past.

Best,
Sam

On Sat, Sep 21, 2019 at 3:33 AM Arun kumar Verma via USRP-users 
 wrote:

Hi Users
We would like to know whether X310 with TwinRx boards can be used for 
temperature range -20 to +55 degree. Is temperature range is limited by the 
components used in the boards or the performance is not guaranteed over this 
range.
Are the components used are industrial grade or commercial grade?

Regards,Arun Verma


___
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] USRP B210 ERROR

[Marcus D Leech via USRP-users]

What does ‘lsusb’ show with the device plugged in?


Sent from my iPhone

> On Oct 15, 2019, at 3:50 PM, Sam Reiter via USRP-users 
>  wrote:
> 
> Khizar,
> 
> Is this still an issue for you? There's an important step in the UHD install 
> process to allow USB devices to be used by non-root users:
> 
> https://files.ettus.com/manual/page_transport.html#transport_usb_udev
> 
> Let me know if this does the trick.
> 
> Sam
> 
>> On Tue, Sep 24, 2019 at 1:10 AM Khizar Abbas via USRP-users 
>>  wrote:
>> I have tried this  /usr/local/lib/uhd/utils/uhd_images_downloader.py 
>> download the image and install it. but the error is still same no device 
>> found. Even i have tried to download the drivers again. still same error. 
>> Please suggest some solution. Below is log in the response of the command . 
>> check the error in Bold text below. 
>> Thanks
>> ncl@rasputin:~/openairinterface5g/cmake_targets/lte_build_oai/build$ sudo -E 
>> ./lte-uesoftmodem -C 262500 -r 25 --ue-rxgain 125 --ue-txgain 90 
>> --ue-scan-carrier -d
>> [CONFIG] get parameters from cmdline , debug flags: 0x0040
>> # /dev/cpu_dma_latency set to 0us
>> [CONFIG] log_config: 2/3 parameters successfully set 
>> [CONFIG] log_config: 42/42 parameters successfully set 
>> [CONFIG] log_config: 42/42 parameters successfully set 
>> [CONFIG] log_config: 15/15 parameters successfully set 
>> [CONFIG] log_config: 15/15 parameters successfully set 
>> log init done
>> Reading in command-line options
>> [CONFIG] (root): 19/22 parameters successfully set 
>> [CONFIG] (root): 4/5 parameters successfully set 
>> [ENB_APP]   nfapi running mode: MONOLITHIC
>> Running with 1 UE instances
>> [CONFIG] TTracer: 4/4 parameters successfully set 
>> CPU Freq is 3.000175 
>> ITTI init
>> [TMR]   Starting itti queue: TASK_UNKNOWN as task 0
>> [TMR]   Starting itti queue: TASK_TIMER as task 1
>> [TMR]   Starting itti queue: TASK_L2L1 as task 2
>> [TMR]   Starting itti queue: TASK_BM as task 3
>> [TMR]   Starting itti queue: TASK_PHY_ENB as task 4
>> [TMR]   Starting itti queue: TASK_MAC_ENB as task 5
>> [TMR]   Starting itti queue: TASK_RLC_ENB as task 6
>> [TMR]   Starting itti queue: TASK_RRC_ENB_NB_IoT as task 7
>> [TMR]   Starting itti queue: TASK_PDCP_ENB as task 8
>> [TMR]   Starting itti queue: TASK_DATA_FORWARDING as task 9
>> [TMR]   Starting itti queue: TASK_END_MARKER as task 10
>> [TMR]   Starting itti queue: TASK_RRC_ENB as task 11
>> [TMR]   Starting itti queue: TASK_RAL_ENB as task 12
>> [TMR]   Starting itti queue: TASK_S1AP as task 13
>> [TMR]   Starting itti queue: TASK_X2AP as task 14
>> [TMR]   Starting itti queue: TASK_SCTP as task 15
>> [TMR]   Starting itti queue: TASK_ENB_APP as task 16
>> [TMR]   Starting itti queue: TASK_FLEXRAN_AGENT as task 17
>> [TMR]   Starting itti queue: TASK_PHY_UE as task 18
>> [TMR]   Starting itti queue: TASK_MAC_UE as task 19
>> [TMR]   Starting itti queue: TASK_RLC_UE as task 20
>> [TMR]   Starting itti queue: TASK_PDCP_UE as task 21
>> [TMR]   Starting itti queue: TASK_RRC_UE as task 22
>> [TMR]   Starting itti queue: TASK_NAS_UE as task 23
>> [TMR]   Starting itti queue: TASK_RAL_UE as task 24
>> [TMR]   Starting itti queue: TASK_MSC as task 25
>> [TMR]   Starting itti queue: TASK_GTPV1_U as task 26
>> [TMR]   Starting itti queue: TASK_UDP as task 27
>> [TMR]   Starting itti queue: TASK_CU_F1 as task 28
>> [TMR]   Starting itti queue: TASK_DU_F1 as task 29
>> [CONFIG] opt: 3/3 parameters successfully set 
>> [OPT]   OPT disabled
>> [PDCP]   pdcp init,usegtp 
>> RRC control socket
>> PDCP PC5S socket
>> [RRC]   Listening to incoming connection from ProSe App 
>> reported resolution = 1 ns
>> [HW]   Version: Branch: develop Abrev. Hash: f8288afe1 Date: Wed Jul 24 
>> 23:00:59 2019 +0200
>> Card 0, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 0, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 0, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 0, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> [PHY]   USRP clock source not specified. defaulting to internal
>> Card 1, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 1, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 1, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 1, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> [PHY]   USRP clock source not specified. defaulting to internal
>> Card 2, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 2, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 

Re: [USRP-users] USRP B210 ERROR

[Sam Reiter via USRP-users]

Khizar,

Is this still an issue for you? There's an important step in the UHD
install process to allow USB devices to be used by non-root users:

https://files.ettus.com/manual/page_transport.html#transport_usb_udev

Let me know if this does the trick.

Sam

On Tue, Sep 24, 2019 at 1:10 AM Khizar Abbas via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have tried this  /usr/local/lib/uhd/utils/uhd_images_downloader.py
> download the image and install it. but the error is still same no device
> found. Even i have tried to download the drivers again. still same error.
> Please suggest some solution. Below is log in the response of the command .
> check the error in Bold text below.
> Thanks
> ncl@rasputin:~/openairinterface5g/cmake_targets/lte_build_oai/build$ sudo
> -E ./lte-uesoftmodem -C 262500 -r 25 --ue-rxgain 125 --ue-txgain 90
> --ue-scan-carrier -d
> [CONFIG] get parameters from cmdline , debug flags: 0x0040
> # /dev/cpu_dma_latency set to 0us
> [CONFIG] log_config: 2/3 parameters successfully set
> [CONFIG] log_config: 42/42 parameters successfully set
> [CONFIG] log_config: 42/42 parameters successfully set
> [CONFIG] log_config: 15/15 parameters successfully set
> [CONFIG] log_config: 15/15 parameters successfully set
> log init done
> Reading in command-line options
> [CONFIG] (root): 19/22 parameters successfully set
> [CONFIG] (root): 4/5 parameters successfully set
> [ENB_APP]   nfapi running mode: MONOLITHIC
> Running with 1 UE instances
> [CONFIG] TTracer: 4/4 parameters successfully set
> CPU Freq is 3.000175
> ITTI init
> [TMR]   Starting itti queue: TASK_UNKNOWN as task 0
> [TMR]   Starting itti queue: TASK_TIMER as task 1
> [TMR]   Starting itti queue: TASK_L2L1 as task 2
> [TMR]   Starting itti queue: TASK_BM as task 3
> [TMR]   Starting itti queue: TASK_PHY_ENB as task 4
> [TMR]   Starting itti queue: TASK_MAC_ENB as task 5
> [TMR]   Starting itti queue: TASK_RLC_ENB as task 6
> [TMR]   Starting itti queue: TASK_RRC_ENB_NB_IoT as task 7
> [TMR]   Starting itti queue: TASK_PDCP_ENB as task 8
> [TMR]   Starting itti queue: TASK_DATA_FORWARDING as task 9
> [TMR]   Starting itti queue: TASK_END_MARKER as task 10
> [TMR]   Starting itti queue: TASK_RRC_ENB as task 11
> [TMR]   Starting itti queue: TASK_RAL_ENB as task 12
> [TMR]   Starting itti queue: TASK_S1AP as task 13
> [TMR]   Starting itti queue: TASK_X2AP as task 14
> [TMR]   Starting itti queue: TASK_SCTP as task 15
> [TMR]   Starting itti queue: TASK_ENB_APP as task 16
> [TMR]   Starting itti queue: TASK_FLEXRAN_AGENT as task 17
> [TMR]   Starting itti queue: TASK_PHY_UE as task 18
> [TMR]   Starting itti queue: TASK_MAC_UE as task 19
> [TMR]   Starting itti queue: TASK_RLC_UE as task 20
> [TMR]   Starting itti queue: TASK_PDCP_UE as task 21
> [TMR]   Starting itti queue: TASK_RRC_UE as task 22
> [TMR]   Starting itti queue: TASK_NAS_UE as task 23
> [TMR]   Starting itti queue: TASK_RAL_UE as task 24
> [TMR]   Starting itti queue: TASK_MSC as task 25
> [TMR]   Starting itti queue: TASK_GTPV1_U as task 26
> [TMR]   Starting itti queue: TASK_UDP as task 27
> [TMR]   Starting itti queue: TASK_CU_F1 as task 28
> [TMR]   Starting itti queue: TASK_DU_F1 as task 29
> [CONFIG] opt: 3/3 parameters successfully set
> [OPT]   OPT disabled
> [PDCP]   pdcp init,usegtp
> RRC control socket
> PDCP PC5S socket
> [RRC]   Listening to incoming connection from ProSe App
> reported resolution = 1 ns
> [HW]   Version: Branch: develop Abrev. Hash: f8288afe1 Date: Wed Jul 24
> 23:00:59 2019 +0200
> Card 0, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 0, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 0, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 0, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not specified. defaulting to internal
> Card 1, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 1, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 1, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 1, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not specified. defaulting to internal
> Card 2, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 2, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 2, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 2, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not 

Re: [USRP-users] X310 Temperature Range

[Sam Reiter via USRP-users]

Hey Arun,

The temperature range for the X310 and the TwinRX is noted as 23 +/- 3 C.
This is meant to convey that the device is intended for indoor lab use and
has not been thoroughly tested in extreme environments like you've
mentioned. You're also correct that you'll see device performance change
over that temperature range and I think -20C will be dipping below the
rating of some of the components. Some key components can be found here:

https://kb.ettus.com/X300/X310#Key_Component_Datasheets

Depending on what you're hoping to do, we see folks develop custom
enclosures for these types of radios with and without thermal regulation.
At the end of the day if you're subjecting this radio to those kinds of
extremes, it's up to you to put it through its paces and make sure it'll
meet your needs. I'll also note that we don't formally endorse any X310
enclosures, but one of the few IP67 OTS solutions I've found for the X310
is sold by Pixus:

http://www.pixustechnologies.com/products/enclosure-system-solutions/specialty-small-form-factor-rugged-x310-other-2/specialty-small-form-factor-rugged-x310-other/

Not sure if this does anything to extend temperature range, but it could be
a starting point in developing your own ruggedized solution to deploy. Also
if anyone else has recommendations or experience with X310 enclosure
solutions, I'd be curious to hear what you've made or worked with in the
past.

Best,

Sam

On Sat, Sep 21, 2019 at 3:33 AM Arun kumar Verma via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Users
> We would like to know whether X310 with TwinRx boards can be used for
> temperature range -20 to +55 degree. Is temperature range is limited by the
> components used in the boards or the performance is not guaranteed over
> this range.
> Are the components used are industrial grade or commercial grade?
>
> Regards,
> Arun Verma
>
>
>
> ___
> 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] USRP + SDR#

[Nate Temple via USRP-users]

Hi Carl,

USRP support was added with the r1595 build to SDR#.

You can most likely listen to a trunking system with a single USRP (haven't
tried it myself) as it'll have enough bandwidth to cover both the control
and voice channels.

Regards,
Nate Temple

On Tue, Oct 15, 2019 at 12:18 PM Carl MacGentey via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Might I run an Ettus USRP on a Windows 10 Pro lap top with the software
> package SDR#? Simpleton that I am I would imagine all that’s needed is some
> kind of a dynamic link program like ’Zadig’. Am I right or wrong?  Suppose
> a connection might be accomplished. Would I need two USRP’s to decode
> public safety digital or could I get away with one USRP?
>
>
>
> Thanks for listening-
>
>
>
> Sent from Mail  for
> Windows 10
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP + SDR#

[Carl MacGentey via USRP-users]

Might I run an Ettus USRP on a Windows 10 Pro lap top with the software package 
SDR#? Simpleton that I am I would imagine all that’s needed is some kind of a 
dynamic link program like ’Zadig’. Am I right or wrong?  Suppose a connection 
might be accomplished. Would I need two USRP’s to decode public safety digital 
or could I get away with one USRP?

Thanks for listening-

Sent from Mail for Windows 10

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

Re: [USRP-users] DPDK setup with N320

[Nate Temple via USRP-users]

Hi Daniel,

The uhd.conf file should be put at /root/.uhd/uhd.conf

You will also need to run the UHD app as root when using DPDK.

I can follow up with you offlist with some additional notes I have on
getting started with DPDK. We will be publishing a detailed app note soon
to cover the topic.

Regards,
Nate Temple

On Tue, Oct 15, 2019 at 11:37 AM Lundberg, Daniel via USRP-users <
usrp-users@lists.ettus.com> wrote:

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

[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] error to write and read from user register x310

[Martin Braun via USRP-users]

Ishai,

it's a bit hard to tell from this snippet, since we're missing the
definitions of random_word and s. Which one is wrong, is it random_word, or
readback?

-- M

On Thu, Oct 3, 2019 at 12:56 AM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I work with X310 and I try to write to user register and read to verify
> that the value was update.
>
> I change the code like in the instruction at the following  website:
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> The relevant code from the test-bench is:
>
>
>
>
>
>
>
>
> */** Test
> 4 -- Write / readback user registers
> /
> `TEST_CASE_START("Write / readback user registers");random_word = 5; //
> $random();tb_streamer.write_user_reg(sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_MIN_BW, random_word[21:0]);
> tb_streamer.read_user_reg(sid_noc_block_TxChannelSrc, 0, readback);
> `ASSERT_ERROR(readback[21:0] == random_word[21:0], s);*
>
> The relevant code from the noc block is:
>
> *  localparam SR_USER_REG_BASE = 128;*
>
> *  localparam [7:0] SR_MIN_BW = SR_USER_REG_BASE;*
>
> *  wire [21:0] min_BW;*
>
>
>
>
>
>
> * setting_reg #(.my_addr(SR_MIN_BW), .awidth(8), .width(22))
> sr_min_BW (.clk(ce_clk), .rst(ce_rst),.strobe(set_stb),
> .addr(set_addr), .in(set_data), .out(min_BW), .changed()); *
>
>
>
>
>
>
>
>
>
> *  always @(posedge ce_clk) begincase(rb_addr)  8'd0 : rb_data <=
> {42'd0, min_BW};  8'd1 : rb_data <= {42'd0, max_BW};  8'd2 :
> rb_data <= {42'd0, BW_change_rate};  8'd3 : rb_data <= {48'd0,
> payload_length};default : rb_data <= 64'h0BADC0DE0BADC0DE;
> endcase  end*
>
> when i run the make command with the noc_block_TxChannelSrc_tb , I get the
> following warning:
>
>
>
>
>
>
>
>
> *WARNING: [XSIM 43-3431] One or more environment variables have been
> detected which affect the operation of the C compiler. These are typically
> not set in standard installations and are not tested by Xilinx, however
> they may be appropriate for your system, so the flow will attempt to
> continue.  If errors occur, try running fuse with the "-mt off -v 1"
> switches to see more information from the C compiler. The following
> environment variables have been detected:LIBRARY_PATHStarting static
> elaborationWARNING: [VRFC 10-278] actual bit length 3 differs from formal
> bit length 4 for port rb_addr
> [/home/user/rfnoc_01/rfnoc-modules/rfnoc/testbenches/noc_block_TxChannelSrc_tb/noc_block_TxChannelSrc_tb.sv:35]WARNING:
> [VRFC 10-278] actual bit length 4 differs from formal bit length 2 for port
> dest
> [/home/user/rfnoc_01/src/uhd-fpga/usrp3/lib/rfnoc/noc_shell.v:230]WARNING:
> [VRFC 10-278] actual bit length 4 differs from formal bit length 2 for port
> dest
> [/home/user/rfnoc_01/src/uhd-fpga/usrp3/lib/rfnoc/noc_block_export_io.v:183]WARNING:
> [VRFC 10-526] concatenation with unsized literal; will interpret as 32 bits
> [/home/user/rfnoc_01/rfnoc-modules/rfnoc/testbenches/noc_block_TxChannelSrc_tb/noc_block_TxChannelSrc_tb.sv:75]WARNING:
> [VRFC 10-526] concatenation with unsized literal; will interpret as 32 bits
> [/home/user/rfnoc_01/rfnoc-modules/rfnoc/testbenches/noc_block_TxChannelSrc_tb/noc_block_TxChannelSrc_tb.sv:76]WARNING:
> [VRFC 10-1783] select index -1 into value is out of bounds
> [/home/user/rfnoc_01/src/uhd-fpga/usrp3/lib/control/synchronizer_impl.v:38]*
>
> The test don't stop to run, and when I get the test results the same value
> is always read.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *TESTBENCH
> STARTED:
> noc_block_TxChannelSrc[TEST
> CASE   1] (t=0) BEGIN: Wait for Reset...[TEST CASE   1]
> (t=01002) DONE... Passed[TEST CASE   2] (t=01002) BEGIN: Check NoC
> ID...Read TxChannelSrc NOC ID: [TEST CASE   2]
> (t=01238) DONE... Passed[TEST CASE   3] (t=01238) BEGIN: Connect
> RFNoC blocks...Connecting noc_block_tb (SID: 1:0) to noc_block_TxChannelSrc
> (SID: 0:0)Connecting noc_block_TxChannelSrc (SID: 0:0) to noc_block_tb
> (SID: 1:0)[TEST CASE   3] (t=06075) DONE... Passed[TEST CASE   4]
> (t=06075) BEGIN: Write / readback user registers...Error: User register
> 0 incorrect readback! Expected: 3359812, Actual 5Time: 6602500 ps
>  Iteration: 0  Process: /noc_block_TxChannelSrc_tb/Initial43_1195  File:
> /home/user/rfnoc_01/rfnoc-modules/rfnoc/testbenches/noc_block_TxChannelSrc_tb/noc_block_TxChannelSrc_tb.sv*
>
> please someone can explain me what is wrong here.
>
> BR
> Ishai
>
> --
> ישי אלוש
> 054-5823400
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list

Re: [USRP-users] Getting started with our new N310s

[Ettus Research Support via USRP-users]

Hi Johannes,


Verify that your MTU's match on both your host and N3xx. (1Gb should have a
MTU of 1500, 10Gb MTU should be 8000).


Is your .213 interface connected to the SFP port?


Regards,
Nate Temple

On Tue, Oct 15, 2019 at 9:14 AM Johannes Demel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Robin,
>
> thanks for your hint. The SD card image helped. And `bmaptool` seems the
> better tool to flash the SD card. Now, `ip a` shows the sfp ports again.
> Furthermore, `uhd_find_devices` shows all the info I'd expect.
> Also, the 'dtc' error during FPGA image update went away.
> After I updated the FPGA image, I did a `reboot now` on the device. I
> hope this is enough to make sure the device uses the new FPGA image?
>
> I followed the instructions:
>
> https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations
> to update my network configuration. Actually, I did that before as well.
>
> Unfortunately, the `uhd_usrp_probe` error persists. How do I proceed
> from here?
>
> $ uhd_usrp_probe --args="addr=X.X.X.213"
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.14.1.HEAD-0-g0347a6d8
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>
> mgmt_addr=X.X.X.129,type=n3xx,product=n310,serial=XXX,claimed=False,addr=X.X.X.213
> [INFO] [MPM.PeriphManager] init() called with device args
>
> `time_source=internal,clock_source=internal,mgmt_addr=X.X.X.129,product=n310'.
> [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 /src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
> this->send_cmd_pkt(0, 0, true); -> 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 /src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
> IOError: recv error on socket: Connection refused
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
> Cheers
> Johannes
>
>
>
> I hope the following output helps with the debugging process.
>
> $ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.14.1.HEAD-0-g0347a6d8
> --
> -- UHD Device 0
> --
> Device Address:
>  serial: XXX
>  addr: X.X.X.213
>  claimed: False
>  mgmt_addr: X.X.X.129
>  product: n310
>  type: n3xx
>
>
> On my HOST machine:
>
> $ uhd_config_info --print-all
> UHD 3.14.1.HEAD-0-g0347a6d8
> Build date: Tue, 15 Oct 2019 15:16:27
> C compiler: GNU 7.4.0
> C++ compiler: GNU 7.4.0
> C flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> C++ flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> -fvisibility=hidden -fvisibility-inlines-hidden
> Enabled components: LibUHD, LibUHD - C API, LibUHD - Python API,
> Examples, Utils, Tests, USB, B100, B200, E300, USRP1, USRP2, X300, N230,
> MPMD, N300, N320, E320, OctoClock
> Install prefix: 
> Boost version: 1.65.1
> Libusb version: 1.0.23
> Package path: 
> Images directory: /share/uhd/images
> ABI version string: 3.14.1
>
>
> ON the DEVICE itself:
> I noticed that `uhd_images_downloader' with my previous install got me
> an image where UHD reports: `Build date: Tue, 19 Feb 2019 00:05:23`. Now
> the build date is: `Thu, 26 Sep 2019 01:26:32'.
>
> This is the output on the device:
> $ uhd_config_info --print-all
> UHD 3.14.1.1-0-g0347a6d8
> Build date: Thu, 26 Sep 2019 01:26:32
> C compiler: GNU 7.3.0
> C++ compiler: GNU 7.3.0
> C flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 -DUHD_LOG_CONSOLE_LEVEL=2
> -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR -DHAVE_LIBERIO
> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
> --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot
>
>   -O2 -pipe -g -feliminate-unused-debug-types
> -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1=/usr/src/debug/uhd/3.14.1.1-r1
>
> -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot=
>
> -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot-native=
>
>-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
>
> --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot
> C++ flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> 

Re: [USRP-users] Getting started with our new N310s

[Johannes Demel via USRP-users]

Hi Robin,

thanks for your hint. The SD card image helped. And `bmaptool` seems the 
better tool to flash the SD card. Now, `ip a` shows the sfp ports again. 
Furthermore, `uhd_find_devices` shows all the info I'd expect.
Also, the 'dtc' error during FPGA image update went away.
After I updated the FPGA image, I did a `reboot now` on the device. I 
hope this is enough to make sure the device uses the new FPGA image?

I followed the instructions:
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations
to update my network configuration. Actually, I did that before as well.

Unfortunately, the `uhd_usrp_probe` error persists. How do I proceed 
from here?

$ uhd_usrp_probe --args="addr=X.X.X.213"
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.14.1.HEAD-0-g0347a6d8
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=X.X.X.129,type=n3xx,product=n310,serial=XXX,claimed=False,addr=X.X.X.213
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=internal,clock_source=internal,mgmt_addr=X.X.X.129,product=n310'.
[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 /src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
this->send_cmd_pkt(0, 0, true); -> 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 /src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142

[ERROR] [MPMD] Failure during block enumeration: EnvironmentError: 
IOError: recv error on socket: Connection refused
Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()

Cheers
Johannes



I hope the following output helps with the debugging process.

$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.14.1.HEAD-0-g0347a6d8
--
-- UHD Device 0
--
Device Address:
 serial: XXX
 addr: X.X.X.213
 claimed: False
 mgmt_addr: X.X.X.129
 product: n310
 type: n3xx


On my HOST machine:

$ uhd_config_info --print-all
UHD 3.14.1.HEAD-0-g0347a6d8
Build date: Tue, 15 Oct 2019 15:16:27
C compiler: GNU 7.4.0
C++ compiler: GNU 7.4.0
C flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
C++ flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR 
-fvisibility=hidden -fvisibility-inlines-hidden
Enabled components: LibUHD, LibUHD - C API, LibUHD - Python API, 
Examples, Utils, Tests, USB, B100, B200, E300, USRP1, USRP2, X300, N230, 
MPMD, N300, N320, E320, OctoClock
Install prefix: 
Boost version: 1.65.1
Libusb version: 1.0.23
Package path: 
Images directory: /share/uhd/images
ABI version string: 3.14.1


ON the DEVICE itself:
I noticed that `uhd_images_downloader' with my previous install got me 
an image where UHD reports: `Build date: Tue, 19 Feb 2019 00:05:23`. Now 
the build date is: `Thu, 26 Sep 2019 01:26:32'.

This is the output on the device:
$ uhd_config_info --print-all
UHD 3.14.1.1-0-g0347a6d8
Build date: Thu, 26 Sep 2019 01:26:32
C compiler: GNU 7.3.0
C++ compiler: GNU 7.3.0
C flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 -DUHD_LOG_CONSOLE_LEVEL=2 
-DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR -DHAVE_LIBERIO 
-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot
 
  -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1=/usr/src/debug/uhd/3.14.1.1-r1
 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot=
 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot-native=
 
   -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot
C++ flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR 
-DHAVE_LIBERIO -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard 
-mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot
 
  -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1=/usr/src/debug/uhd/3.14.1.1-r1
 

Re: [USRP-users] Getting started with our new N310s

[Robin Coxe via USRP-users]

Hi Johannes.  Things tend to go badly when the UHD and FPGA bitstream
versions on the N310 SD card don't match those on the host for the N3xx.
 Avoid using master with the N310 out of the box because the
filesystem/FPGA images most likely don't exist.

Burn this SD card image:
http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.14.1.1/n3xx_common_sdimg_default-v3.14.1.1.zip
(yes, the location is non-obvious) then build UHD v.3.14.1.1 on the host PC.

Starting with UHD v.3.14, the SFP+ ports are mapped to IP addresses
192.168.10.2 and 192.168.20.2, to be more consistent with the X310.  When
you issue the uhd_usrp_probe command, try adding the --args
"addr=192.168.x0.2" command.
I can't remember for certain if the HG (SFP0 = 1gigE and SFP1=10 gigeE) or
XG image (both 10gigE) is loaded by default.   I think it's HG.   Set the
MTU on the host side to 8000 for the 10gigE port.

The N310 Getting Started guide outlines the mender method of updating the
filesystem, which should also work, but I tend to prefer downloading the SD
card image and burning it myself.  Good luck.

-Robin



On Tue, Oct 15, 2019 at 2:47 AM Johannes Demel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> we just received some new N310s. Yeah!
>
> They don't work! N.
>
> Let me explain what I tried so far and what I found out. So far, I work
> with 2 devices.
>
> Summary:
> With factory default image I can find the device but `uhd_usrp_probe`
> fails.
> With a newly flashed image on the SD card, The SFP ports don't show up
> anymore.
>
>
> How do I recover my device that doesn't show the SFP ports anymore?
>
> What do I need to do to successfully run `uhd_usrp_probe`? Since this
> command errors out with the same error as a flowgraph, I assume if I get
> passed `uhd_usrp_probe` there is a good chance I'll be able to run a
> flowgraph.
>
> What is dtc? It errors out during FPGA image updates.
>
> What is the latest `sdimg` to install? I want to make sure I'm up to
> date. As soon as I figured out why the devices don't work.
>
> I append all the information I could find so far for my devices.
>
> Cheers
> Johannes
>
>
>
> On Host:
> $ uhd_config_info --print-all
> UHD 3.15.0.git-79-gf353db8f
> Build date: Tue, 08 Oct 2019 12:08:10
> C compiler: GNU 7.4.0
> C++ compiler: GNU 7.4.0
> C flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> C++ flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> -fvisibility=hidden -fvisibility-inlines-hidden
> Enabled components: LibUHD, LibUHD - C API, LibUHD - Python API,
> Examples, Utils, Tests, USB, B100, B200, USRP1, USRP2, X300, N230, MPMD,
> N300, N320, E320, E300, OctoClock
> Install prefix: /gnuradio38
> Boost version: 1.65.1
> Libusb version: 1.0.23
> Package path: /gnuradio38
> Images directory: /gnuradio38/share/uhd/images
> ABI version string: 3.15.0
>
>
> $ uhd_image_loader --args "type=n3xx,addr=X.X.X.212,fpga=HG"
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-79-gf353db8f
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>
> mgmt_addr=X.X.X.128,type=n3xx,product=n310,serial=XXX,claimed=False,skip_init=1
> [INFO] [MPMD] Claimed device without full initialization.
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
> [INFO] [MPM.PeriphManager] Updating component `fpga'
> [INFO] [MPM.PeriphManager] Updating component `dts'
> [ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc',
> '--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n310.dtbo',
> '/lib/firmware/n310.dts']' returned non-zero exit status 1
> [INFO] [MPM.RPCServer] Resetting peripheral manager.
> [INFO] [MPM.PeriphManager] Device serial number: XXX
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected
> compat for component `FPGA'. Expected: 5.2 Actual: 5.3
> [INFO] [MPM.PeriphManager] init() called with device args `'.
> [INFO] [MPMD IMAGE LOADER] Update component function succeeded.
>
> Rebooted devices, then:
>
> $ uhd_find_devices
> --
> -- UHD Device 0
> --
> Device Address:
>  serial: XX
>  addr: X.X.X.212
>  claimed: False
>  mgmt_addr: X.X.X.128
>  product: n310
>  type: n3xx
>
>
> --
> -- UHD Device 1
> --
> Device Address:
>  serial: n/a
>  claimed: False
>  mgmt_addr: X.X.X.123
>  product: n/a
>  reachable: No
>  type: n/a
>
>
> On Device 0:
>
> $ uhd_config_info --print-all
> UHD 3.13.0.2-0-unknown
> Build date: Fri, 08 Mar 2019 18:43:32
> C compiler: GNU 7.3.0
> C++ compiler: GNU 7.3.0
> C flags: -DUHD_IMAGES_DIR=OFF 

[USRP-users] Getting started with our new N310s

[Johannes Demel via USRP-users]

Hi all,

we just received some new N310s. Yeah!

They don't work! N.

Let me explain what I tried so far and what I found out. So far, I work 
with 2 devices.

Summary:
With factory default image I can find the device but `uhd_usrp_probe` fails.
With a newly flashed image on the SD card, The SFP ports don't show up 
anymore.


How do I recover my device that doesn't show the SFP ports anymore?

What do I need to do to successfully run `uhd_usrp_probe`? Since this 
command errors out with the same error as a flowgraph, I assume if I get 
passed `uhd_usrp_probe` there is a good chance I'll be able to run a 
flowgraph.

What is dtc? It errors out during FPGA image updates.

What is the latest `sdimg` to install? I want to make sure I'm up to 
date. As soon as I figured out why the devices don't work.

I append all the information I could find so far for my devices.

Cheers
Johannes



On Host:
$ uhd_config_info --print-all
UHD 3.15.0.git-79-gf353db8f
Build date: Tue, 08 Oct 2019 12:08:10
C compiler: GNU 7.4.0
C++ compiler: GNU 7.4.0
C flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
C++ flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR 
-fvisibility=hidden -fvisibility-inlines-hidden
Enabled components: LibUHD, LibUHD - C API, LibUHD - Python API, 
Examples, Utils, Tests, USB, B100, B200, USRP1, USRP2, X300, N230, MPMD, 
N300, N320, E320, E300, OctoClock
Install prefix: /gnuradio38
Boost version: 1.65.1
Libusb version: 1.0.23
Package path: /gnuradio38
Images directory: /gnuradio38/share/uhd/images
ABI version string: 3.15.0


$ uhd_image_loader --args "type=n3xx,addr=X.X.X.212,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.15.0.git-79-gf353db8f
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=X.X.X.128,type=n3xx,product=n310,serial=XXX,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc', 
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n310.dtbo', 
'/lib/firmware/n310.dts']' returned non-zero exit status 1
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: XXX
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected 
compat for component `FPGA'. Expected: 5.2 Actual: 5.3
[INFO] [MPM.PeriphManager] init() called with device args `'.
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.

Rebooted devices, then:

$ uhd_find_devices
--
-- UHD Device 0
--
Device Address:
 serial: XX
 addr: X.X.X.212
 claimed: False
 mgmt_addr: X.X.X.128
 product: n310
 type: n3xx


--
-- UHD Device 1
--
Device Address:
 serial: n/a
 claimed: False
 mgmt_addr: X.X.X.123
 product: n/a
 reachable: No
 type: n/a


On Device 0:

$ uhd_config_info --print-all
UHD 3.13.0.2-0-unknown
Build date: Fri, 08 Mar 2019 18:43:32
C compiler: GNU 7.3.0
C++ compiler: GNU 7.3.0
C flags: -DUHD_IMAGES_DIR=OFF -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR 
-DHAVE_LIBERIO -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard 
-mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0/recipe-sysroot
 
  -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0=/usr/src/debug/uhd/3.13.0.2-r0
 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0/recipe-sysroot=
 
-fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0/recipe-sysroot-native=
 
   -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0/recipe-sysroot
C++ flags: -DUHD_IMAGES_DIR=OFF -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 
-DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR 
-DHAVE_LIBERIO -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard 
-mcpu=cortex-a9 
--sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.13.0.2-r0/recipe-sysroot
 
  -O2 -pipe -g -feliminate-unused-debug-types