[USRP-users] X310 and 8bit complex sampling

[Arun kumar Verma via USRP-users]

Hi Users
I am trying to achieve 50MHz BW (25MHz Each Channel)  with X310 and TwinRX 
using 1G Ethernet. I went through some of the forums regrading this and found 
that X310 does not support 8-bit IQ samples as mentioned in below link. 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-February/046123.html

Is still 8-bit IQ samples are not supported in the latest UHD ?
We are looking for a solution for 50MHz (25MHz Channel each) with laptop 
processing (Ubuntu).  While going through some comments from different users I 
found that using T3NL-T3DIY-AKTU ( https://www.akitio.com/expansion/node-lite)  
and  Intel X710-DA2 more than 50MHz BW can be achieved. Is there any other 
solution available for this kind of bandwidth as we are looking for some 
compact solution.

Regards,Arun Verma

 

On Wednesday, 16 October, 2019, 09:23:33 pm IST, Sam Reiter 
 wrote:  
 
 Arun,
Sorry for the confusion. The X310 uses a commercial grade XC7K410T with a 
temperature range of 0-85C.
Sam
On Tue, Oct 15, 2019 at 10:11 PM Arun kumar Verma  wrote:

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] uhd_fft failure

[Saeid Hashemi via USRP-users]

Hi Michael,

The gnuradio git repository does not have a tag for v3.17.14.5, and using
v3.7.13.5 gives me:

-- Python checking for six - python 2 and 3 compatibility library
-- Python checking for six - python 2 and 3 compatibility library - not
found
CMake Error at volk/CMakeLists.txt:98 (message):
  six - python 2 and 3 compatibility library required to build VOLK


-- Configuring incomplete, errors occurred!
See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeOutput.log".
See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeError.log".


Checking out tag v3.8.0.0 results in Cmake dependency of 3.8 and up, so I
need to install that manually.


On Sat, Oct 12, 2019 at 11:02 AM Michael Dickens 
wrote:

> OK. Thanks for the info Saeid. I'll look into creating a VM using Ubuntu
> 16.04.1 to see what happens. - MLD
>
> On Fri, Oct 11, 2019 at 4:47 PM Saeid Hashemi  wrote:
>
>> It's Ubuntu 16.04.1, but yes, I will follow the source build instructions.
>>
>> On Fri, Oct 11, 2019 at 3:11 PM Michael Dickens <
>> michael.dick...@ettus.com> wrote:
>>
>>> Hi Saeid - Thanks for the followup. I totally agree that if you just
>>> "sudo apt install gnuradio", compatible versions should be installed. Are
>>> you using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to install from
>>> source, you can follow instructions such as the GR recommended way here <
>>> https://wiki.gnuradio.org/index.php/UbuntuInstall#Xenial_Xerus_.2816.04.29
>>> >. I have an Ubuntu 18.04 install that went very smoothly using this guide,
>>> but maybe the guide is outdated for older Ubuntu; or, our packages need to
>>> be updated for that OS version ... Cheers! - MLD
>>>
>>> On Fri, Oct 11, 2019 at 2:24 PM Saeid Hashemi  wrote:
>>>
 I will follow your advice, but it's worth mentioning I simply did
 apt-get gnuradio and should therefore have a compatible version of uhd
 installed automatically as a dependency. I did not install uhd separately.

>>> --
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: supp...@ettus.com
>>> Web: https://ettus.com/
>>>
>>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] FOSDEM 2020: Free Software Radio Devroom CfP

[Nicolas Cuervo Benavides via USRP-users]

Dear friends and fans of software-defined radio and free/open-source radio
topics in general,

FOSDEM 2020 (the free and open-source developer's meeting in Brussels,
Europe) will, once again, feature a track on Software Defined Radio, and
any other radio-related topics in the (now known as) *Free Software
Radio* devroom.
Therefore, we invite developers and users from the free software radio
community to join us for this track and present your talks or demos.


Software Radio has become an important tool to allow anyone to access the
EM spectrum. Using free software radio libraries and applications and cheap
hardware, anyone can now start hacking on wireless communications, remote
sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM,
we hope to network all these projects and improve collaboration, bring new
ideas forward and get more people involved.


The track's web site resides at the link below. The final schedule will be
available through Pentabarf and the official FOSDEM website.

https://fosdem.org/2020/schedule/track/free_software_radio/


Additional Information will be also available at:
https://wiki.gnuradio.org/index.php/FOSDEM_2020


** Submit your presentations

To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and
follow the instructions (you need an account, but can use your account from
last year if you have one). You need to create an 'Event'; make sure it's
in the Free Software Radio track! Lengths aren't fixed, but give a
realistic estimate and please don't exceed 30 minutes unless you have
something special planned (in that case, contact one of us). Also, don't
forget to include time for Q
We will typically go for 30-minute slots -- shorter talks, unless they're
really short, usually tend to screw up the schedule too much.

You aren't limited to slide presentations, of course. Be creative. However,
FOSDEM is an open-source conference, therefore we ask you to stay clear of
marketing presentations and present something relevant to free/open
software. We like nitty-gritty technical stuff.

Topics discussed in this devroom include:

* SDR Frameworks + Tools
* Cellular/telecoms software
* Free/Open SDR hardware
* Wireless security
* Random fun wireless hacks
* SDR in education
* Satellite/spacecraft communication
* Ham radio related topics


** Important Dates

FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is
happening on Sunday, the 2nd of February.

The submission deadline is Friday, December 6th. A complete schedule for
the presentations in the devroom will be available on the 15th of December.


In the last years we were always full to the brim with presentations, so if
you want to present, please make sure to submit your abstracts soon!

** Steering Committee
The track committee consists of:

* Phil Balister - "Crofton"
* Sylvain Munaut -"tnt"
* Derek Kozel - "dkozel"
* Nicolas Cuervo - "primercuervo"
* Martin Braun - "mbr0wn"  (Emeritus)


Hope to hear from you soon! And please forward this announcement.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 GPS time source?

[Philip Balister via USRP-users]

On 10/16/19 10:33 AM, zcao--- via USRP-users wrote:
> Hi,
> 
> UHD lib provides a function, get_time_last_pps(), which suppose to provides 
> the time stamp for the latest PPS right edge. I am wondering what is the 
> source of the time information the above function uses? 
> 
> Specifically, we are aiming at synchronize multiple E310 devices for a TDMA 
> system. Each E310 is standalone and has no network connect to a common NTP 
> server. From the schematics of E310, it seems to me that the GPS receiver 
> chip only provides the PPS output to the FPGA. I didn’t find any hardware 
> support that allows E310 to obtain the time information from GPS, other than 
> the edge of each second. 

I know the E300 can sync NTP time to GPS time. Searching the memory
banks makes me think gpsd is providing the time to ntpd and the pps
driver is doing the pps interface to ntpd.

I don't know about the uhd time though.

Pihlip

> 
> Am I right? If so, what time information the function get_time_last_pps() 
> actually returns? Is there a way to sync the time across multiple standalone 
> E310?
> 
> Thanks,
> Arnold 
> 
> C-3 Comm Systems, LLC
> 3100 Clarendon Blvd., Suite 200
> Arlington, VA 22201
> Phone: (703) 829-0588
> Email : z...@c3commsystems.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] Issues Completing Radio Build and Installation

[Robin Coxe via USRP-users]

The E310/E312 has a small-ish FPGA that does not have enough resources to
accommodate the overhead associated with 14 RFNoC blocks.   You have
discovered empirically that you run out of space above 5 blocks.

On Wed, Oct 16, 2019 at 10:06 AM Jonathan Lockhart via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Greetings Nate,
>
> So been working through your instructions you linked and everything
> appears to be good on the software end. It is all cross-compiling and
> running on the E312. Unfortunately there appears to be a new issue. So when
> running the GUI for building an FGPA bit file, per the instructions, I have
> included an FFT, Window, and Fosphor, and selected the option to "File with
> FIFOS," which causes the build to fail. The GUI reports for the E310_SG3 it
> can support 14 blocks. I tested this with the command line version and 14
> also fails. The instructions show a command line option of 5 modules
> (blocks) which builds fine. If I up it to 6 it immediately fails. I have
> attached a copy of the failure output as a .txt file for 6 blocks.
>
> Regards,
> Jon
>
>
> On Fri, Oct 11, 2019 at 2:51 PM Jonathan Lockhart 
> wrote:
>
>> Greetings Nate,
>>
>> Thanks for getting back to me so quickly. I will be sure to flash the OS
>> to release 4 and roll back my dev environment to match the instructions.
>>
>> Regards,
>> Jon Lockhart
>>
>>
>> On Fri, Oct 11, 2019, 1:20 PM Nate Temple  wrote:
>>
>>> Hi Jon,
>>>
>>> If you are following this app note [0], I would recommend starting with
>>> the release-4 image. The pre-3.15 MPM based image that has been released is
>>> currently a "beta" release. It lacks several of the dependencies required
>>> to build out GNU Radio. We are working on a new release and hope to have it
>>> posted soon.
>>>
>>> [0] -
>>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>>
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart <
>>> jlockhar...@gmail.com> wrote:
>>>
 Greetings Ettus Radio List,

 I have recently acquired and began using an Ettus E312 and have been
 trying to configure the dev host and the cross compile environment.
 Unfortunately I am having issues completing some of these tasks with the
 pre-release version of 3.15 image that Ettus mentions you should use in the
 manual for the E312. I forward those issues to support but have heard no
 reply. Please refer below to the issues I am reporting. The GNURadio cross
 compile issue with the SDK and environment is the more crucial one at the
 moment. I was wondering if anyone else has been experiencing these issues
 and if so how did you proceed to get it resolved. Is there an image, sdk,
 GNURadio version that I should be using other than the 3.15 image and
 instructions that Ettus currently recommends using until a stable RC is
 provided?

 Thanks for your help and feedback.

 Regards,
 Jon Lockhart


 -- Forwarded message -
 From: Jonathan Lockhart 
 Date: Mon, Oct 7, 2019 at 3:16 PM
 Subject: Issues Completing Radio Build and Installation
 To: 


 Greetings Ettus Support,

 I recently acquired an Ettus E312 and I was looking to do some
 development on it. Unfortunately I am have been having some issues. The
 manual via files.ettus.com and the "Getting Started" both failed to
 provide a working environment.

 The farthest I got was downloading the meta section direction for the
 E312 to get 3.15.0 image and sdk for the radio, and then following this
 guide page for 3.14, correcting the UHD install accordingly to comply with
 3.15. (Guide
 https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
 )

 When mounting the cross compiled UHD folders via the instructions on
 the radio, and using the uhd_usrp_probe command, there is an error checking
 for the libusb_init information.

 root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
 [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
 UHD_3.15.0.HEAD-0-g6563c537
 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [INFO] [MPMD] Initializing 1 device(s) 

Re: [USRP-users] Issues Completing Radio Build and Installation

[Jonathan Lockhart via USRP-users]

Greetings Nate,

So been working through your instructions you linked and everything appears
to be good on the software end. It is all cross-compiling and running on
the E312. Unfortunately there appears to be a new issue. So when running
the GUI for building an FGPA bit file, per the instructions, I have
included an FFT, Window, and Fosphor, and selected the option to "File with
FIFOS," which causes the build to fail. The GUI reports for the E310_SG3 it
can support 14 blocks. I tested this with the command line version and 14
also fails. The instructions show a command line option of 5 modules
(blocks) which builds fine. If I up it to 6 it immediately fails. I have
attached a copy of the failure output as a .txt file for 6 blocks.

Regards,
Jon


On Fri, Oct 11, 2019 at 2:51 PM Jonathan Lockhart 
wrote:

> Greetings Nate,
>
> Thanks for getting back to me so quickly. I will be sure to flash the OS
> to release 4 and roll back my dev environment to match the instructions.
>
> Regards,
> Jon Lockhart
>
>
> On Fri, Oct 11, 2019, 1:20 PM Nate Temple  wrote:
>
>> Hi Jon,
>>
>> If you are following this app note [0], I would recommend starting with
>> the release-4 image. The pre-3.15 MPM based image that has been released is
>> currently a "beta" release. It lacks several of the dependencies required
>> to build out GNU Radio. We are working on a new release and hope to have it
>> posted soon.
>>
>> [0] -
>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart 
>> wrote:
>>
>>> Greetings Ettus Radio List,
>>>
>>> I have recently acquired and began using an Ettus E312 and have been
>>> trying to configure the dev host and the cross compile environment.
>>> Unfortunately I am having issues completing some of these tasks with the
>>> pre-release version of 3.15 image that Ettus mentions you should use in the
>>> manual for the E312. I forward those issues to support but have heard no
>>> reply. Please refer below to the issues I am reporting. The GNURadio cross
>>> compile issue with the SDK and environment is the more crucial one at the
>>> moment. I was wondering if anyone else has been experiencing these issues
>>> and if so how did you proceed to get it resolved. Is there an image, sdk,
>>> GNURadio version that I should be using other than the 3.15 image and
>>> instructions that Ettus currently recommends using until a stable RC is
>>> provided?
>>>
>>> Thanks for your help and feedback.
>>>
>>> Regards,
>>> Jon Lockhart
>>>
>>>
>>> -- Forwarded message -
>>> From: Jonathan Lockhart 
>>> Date: Mon, Oct 7, 2019 at 3:16 PM
>>> Subject: Issues Completing Radio Build and Installation
>>> To: 
>>>
>>>
>>> Greetings Ettus Support,
>>>
>>> I recently acquired an Ettus E312 and I was looking to do some
>>> development on it. Unfortunately I am have been having some issues. The
>>> manual via files.ettus.com and the "Getting Started" both failed to
>>> provide a working environment.
>>>
>>> The farthest I got was downloading the meta section direction for the
>>> E312 to get 3.15.0 image and sdk for the radio, and then following this
>>> guide page for 3.14, correcting the UHD install accordingly to comply with
>>> 3.15. (Guide
>>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
>>> )
>>>
>>> When mounting the cross compiled UHD folders via the instructions on the
>>> radio, and using the uhd_usrp_probe command, there is an error checking for
>>> the libusb_init information.
>>>
>>> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
>>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
>>> UHD_3.15.0.HEAD-0-g6563c537
>>> [ERROR] [UHD] Device discovery error: AssertionError:
>>> libusb_init(&_context) == 0
>>>   in libusb_session_impl::libusb_session_impl()
>>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>>
>>> [ERROR] [UHD] Device discovery error: AssertionError:
>>> libusb_init(&_context) == 0
>>>   in libusb_session_impl::libusb_session_impl()
>>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>>
>>> [ERROR] [UHD] Device discovery error: AssertionError:
>>> libusb_init(&_context) == 0
>>>   in libusb_session_impl::libusb_session_impl()
>>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>>
>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False
>>> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
>>> [INFO] [MPM.PeriphManager] init() called with device args
>>> `product=e310_sg3,mgmt_addr=127.0.0.1'.
>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>> 0x12AD10003310)
>>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>>> [INFO] [0/DUC_0] Initializing block 

[USRP-users] E310 GPS time source?

[zcao--- via USRP-users]

Hi,

UHD lib provides a function, get_time_last_pps(), which suppose to provides the 
time stamp for the latest PPS right edge. I am wondering what is the source of 
the time information the above function uses? 

Specifically, we are aiming at synchronize multiple E310 devices for a TDMA 
system. Each E310 is standalone and has no network connect to a common NTP 
server. From the schematics of E310, it seems to me that the GPS receiver chip 
only provides the PPS output to the FPGA. I didn’t find any hardware support 
that allows E310 to obtain the time information from GPS, other than the edge 
of each second. 

Am I right? If so, what time information the function get_time_last_pps() 
actually returns? Is there a way to sync the time across multiple standalone 
E310?

Thanks,
Arnold 

C-3 Comm Systems, LLC
3100 Clarendon Blvd., Suite 200
Arlington, VA 22201
Phone: (703) 829-0588
Email : z...@c3commsystems.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

[Sam Reiter via USRP-users]

Arun,

Sorry for the confusion. The X310 uses a commercial grade XC7K410T with a
temperature range of 0-85C.

Sam

On Tue, Oct 15, 2019 at 10:11 PM Arun kumar Verma 
wrote:

> 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 <
> sam.rei...@ettus.com> 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 <
> 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] Getting started with our new N310s

[Johannes Demel via USRP-users]

Hi list,

since I had a few problems with our new N310s I thought it might be 
helpful to share my experience so far.
First off, my initial error during `uhd_usrp_probe` (and also when I 
tried to run a GR flowgraph) is fixed.
1. I followed Robins advice to install UHD 3.14.1.1 and use the SD card 
image from the link.
2. As far as I can tell: don't plug your SFP ports and management ports 
into the same switch in parallel. Since I unplugged the management port 
on my N310s, they work.

Another observation I made is, you can't give custom names to N310s. I 
really liked this feature. With our X310s you can just do 
"name=mycoolusrpname" instead of "addr=X.X.X.X". `usrp_burn_mb_eeprom` 
throws a not implemented error when I try to burn a name into the device.

Further, the N310s behave really different in terms of gains then our 
X310s. If I set RXgain=10, TXgain=20 for our X310s my demo works like a 
charm. For the N310s it's more like RXgain=60, TXgain=70. And still, the 
constellation diagram looks worse. It's noisier.
I wonder why the RX values that come out of a UHD source in GNU Radio 
have such small values. (~0.002 max) This does not seem to change for 
different TX/RX gains.
I assume that max dynamic range is at 1.0. If my signal goes beyond 1.0 
it is clipped. Is this still the case with N310s?

Thanks for your help and your answers.

Johannes

On 16.10.19 12:05, Johannes Demel via USRP-users wrote:
> Hi Nate,
> 
> thanks for the hint. I just double checked. The MTU size is set to 1500
> on the device for sfp0. I just attached the output of `ip a` for that.
> The MTU is set to 1500 on the host as well.
> And yes, the .213 is connected to the sfp0 port.
> 
> I ran 2 additional tests. I connected my host and device directly via a
> switch and disconnected this switch from our network. But the error
> still persisted.
> Next I plugged the .213 aka sfp0 interface into another port on the
> switch and now it works. I was already able to run a basic GNU Radio
> example flowgraph. The examples in 'gr-uhd' need an update to be
> compatible with GR3.8 though.
> The port I used initially was a special port on the switch for uplink or
> so and that port didn't work. Now it does.
> 
> Thanks for your support. I'll update my devices and see if all of them
> work now.
> 
> Johannes
> 
> 1: lo: [...]
> 2: eth0:  mtu 1500 qdisc pfifo_fast
> qlen 1000
>   link/ether 00:80:2f:26:6c:b8 brd ff:ff:ff:ff:ff:ff
>   inet X.X.X.129/24 brd X.X.X.255 scope global dynamic eth0
>  valid_lft 24082sec preferred_lft 24082sec
> 3: sfp0:  mtu 1500 qdisc pfifo_fast
> qlen 1000
>   link/ether 00:80:2f:26:6c:b9 brd ff:ff:ff:ff:ff:ff
>   inet X.X.X.213/24 brd X.X.X.255 scope global sfp0
>  valid_lft forever preferred_lft forever
> 4: sfp1:  mtu 8000 qdisc pfifo_fast
> qlen 1000
>   link/ether 00:80:2f:26:6c:ba brd ff:ff:ff:ff:ff:ff
> 
> 
> 
> On 15.10.19 18:40, Ettus Research Support wrote:
>> 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
>> mailto: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 - 

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

[Johannes Demel via USRP-users]

Hi Nate,

thanks for the hint. I just double checked. The MTU size is set to 1500 
on the device for sfp0. I just attached the output of `ip a` for that.
The MTU is set to 1500 on the host as well.
And yes, the .213 is connected to the sfp0 port.

I ran 2 additional tests. I connected my host and device directly via a 
switch and disconnected this switch from our network. But the error 
still persisted.
Next I plugged the .213 aka sfp0 interface into another port on the 
switch and now it works. I was already able to run a basic GNU Radio 
example flowgraph. The examples in 'gr-uhd' need an update to be 
compatible with GR3.8 though.
The port I used initially was a special port on the switch for uplink or 
so and that port didn't work. Now it does.

Thanks for your support. I'll update my devices and see if all of them 
work now.

Johannes

1: lo: [...]
2: eth0:  mtu 1500 qdisc pfifo_fast 
qlen 1000
 link/ether 00:80:2f:26:6c:b8 brd ff:ff:ff:ff:ff:ff
 inet X.X.X.129/24 brd X.X.X.255 scope global dynamic eth0
valid_lft 24082sec preferred_lft 24082sec
3: sfp0:  mtu 1500 qdisc pfifo_fast 
qlen 1000
 link/ether 00:80:2f:26:6c:b9 brd ff:ff:ff:ff:ff:ff
 inet X.X.X.213/24 brd X.X.X.255 scope global sfp0
valid_lft forever preferred_lft forever
4: sfp1:  mtu 8000 qdisc pfifo_fast 
qlen 1000
 link/ether 00:80:2f:26:6c:ba brd ff:ff:ff:ff:ff:ff



On 15.10.19 18:40, Ettus Research Support wrote:
> 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 
> mailto: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