Re: [USRP-users] RFNoC Software Emulation

[Dario Pennisi via USRP-users]

Hi Brian,
as you may have guessed I’m not from ettus so maybe you can get better insight 
from them. On my side I would recommend you look at the APIs to write/read 
registers and the ones that set up streams to/from the device. These are the 
main building blocks and you will find that the register access APIs have a 
fire and forget approach by which if you lose a packet everything will stop 
working (packet out of sequence error), which is typical in high load udp 
scenarios.
Once you have looked at this you need to also emulate the software running on 
the ZPU processor (or ARM if you use embedded series).
Note that interface to devices is handled by device3 block which will enumerate 
all the available devices and allows you to bind each block to a given device. 
Don’t think you will need to modify that if you emulate completely but it’s for 
sure a place to look at.
Best regards,

Dario Pennisi

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

[USRP-users] Gnuradio do_configure error

[Antoine Laval via USRP-users]

Hi,


I am trying to build the gnuradio-demo-image for an USRP E310, and I need
to use gnuradio-companion.


As pygtk is deprecated, I I have modified the gnuradio_git.bb recipe from
meta-sdr/recipes-core to update the GNU-Radio version up to 3.8.0 with the
following revision :

SRCREV = 53ddb74a315c800268ab83e0dc8f67bbcab54be8 (branch next, 18 July
2018)


This revision uses qi package to import Gtk modules


When I run bitbake gnu radio, it ends with a do_configure error saying that
CMake can’t find the good python version (cf. Error output below)



Log data follows:

| DEBUG: Executing shell function do_configure

| -- The CXX compiler identification is GNU 7.3.0

| -- The C compiler identification is GNU 7.3.0

| -- Check for working CXX compiler:
/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- works

| -- Detecting CXX compiler ABI info

| -- Detecting CXX compiler ABI info - done

| -- Detecting CXX compile features

| -- Detecting CXX compile features - done

| -- Check for working C compiler:
/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc

| -- Check for working C compiler:

/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- works

| -- Detecting C compiler ABI info

| -- Detecting C compiler ABI info - done

| -- Detecting C compile features

| -- Detecting C compile features - done

| -- Build type not specified: defaulting to release.

| -- Build type set to Release.

| -- Could NOT find Git (missing:  GIT_EXECUTABLE)

| -- Performing Test HAVE_VISIBILITY_HIDDEN

| -- Performing Test HAVE_VISIBILITY_HIDDEN - Success

| -- Performing Test HAVE_WARN_SIGN_COMPARE

| -- Performing Test HAVE_WARN_SIGN_COMPARE - Success

| -- Performing Test HAVE_WARN_ALL

| -- Performing Test HAVE_WARN_ALL - Success

| -- Performing Test HAVE_WARN_NO_UNINITIALIZED

| -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success

| -- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 7.3.0

| Copyright (C) 2017 Free Software Foundation, Inc.

| This is free software; see the source for copying conditions.  There is NO

| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

| -- Compiler Flags:
/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc:::-DNDEBUG
 -march=armv7-a
-marm -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9
--sysroot=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot
 -O2
-pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0=/usr/src/debug/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0
-fdebug-prefix-map=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native=
-fdebug-prefix-map=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot=
  -march=armv7-a
-marm -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9
--sysroot=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized

|
/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++:::-DNDEBUG
 -march=armv7-a
-marm -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9
--sysroot=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot
 -O2
-pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0=/usr/src/debug/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0
-fdebug-prefix-map=/home/william/Bureau/yocto/openembedded-core-rocko/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/gnuradio/3.8.0+gitAUTOINC+53ddb74a31-r0/recipe-sysroot-native=
-fdebug-prefix-map=/h

Re: [USRP-users] TDMA receiver on E310

[David Zamorano Fernández via USRP-users]

Hi Marcus,

First, I thought that recv() is not thread-safe (according to recv()
section in UHD manual

).

I understand the use of two or more threads with recv() in a loop. But,
when do I program the time_spec for next slot? When I receive all the
samples from a slot and I want to program the next time_spec, it is already
obsolete because the recv() lasts slightly longer than the duration of a
slot. The first slot starts at 0 and lasts 40 ms, and the next one starts
at 40 ms and ends at 80 ms. And so it continues...

The reception is all done on the same channel, so I can not create two
rx_stream (or a multichannel rx_streamer) and do issue_stream_cmd with a
different time_spec for each one.

Best regards,

David


--


[image: logo_170x100px.png] 



David Zamorano Fernández
Investigador - Desarrollador | Área de Comunicaciones Avanzadas
Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3012
dzamor...@gradiant.org   |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]

Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.

2018-07-19 10:03 GMT+02:00 Marcus Müller :

> Hi David,
>
> so, NUM_SAMPS_AND_DONE sounds right for this application, and pre-
> determining the time at when the observation will start with time_specs
> sounds absolutely like what I'd recommend.
>
> You say there's a "delay when leaving the recv function"; I'm not quite
> sure I understand what you're referring to, here?
>
> Recv() just takes the data coming in, takes it from the hardware
> buffer, converts it to the number format you requested, and writes it
> into the buffer you gave it, and repeats until the requested number of
> items have been received (or some timeout or extranormal condition
> happened). There's no delay that we added there!
>
> Note that these calculations might actually take some time. Hence, it's
> absolutely desirable to have two (or even more, but stick with two for
> now) threads that just call recv() in endless loops – recv() is thread-
> safe, and that way, you can already handle the next hardware buffer,
> while the first is still being processed (subject to CPU limitations).
>
> Best regards,
> Marcus
>
> On Thu, 2018-07-19 at 09:48 +0200, David Zamorano Fernández via USRP-
> users wrote:
> > Hi.
> >
> > We have implemented a TDMA receiver on an E310. We have to receive
> > slots of 40 ms duration and we must capture and process each of them.
> > These capture instants must be very precise, so we have used GPS to
> > discipline the internal clock of the E310.
> >
> > What is the most appropriate stream mode for this task?
> >
> > Currently, STREAM_MODE_START_CONTINUOUS is used but the first slot
> > has too much delay when leaving the recv function (about 14 ms). It
> > has also been tested with STREAM_MODE_NUM_SAMPS_AND_MORE, programming
> > the next slot time_spec each time.
> >
> > Thanks.
> > --
> >
> >
> >
> > David Zamorano Fernández
> > Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> > Researcher - Developer | Advanced Communications Department
> >
> > Ph. (+34) 986 120 430  Ext. 3012
> > dzamor...@gradiant.org  |  www.gradiant.org
> >
> >
> >
> > Take care of the environment. Try not to print this email.
> > The information contained in this email message may be confidential
> > information, and may also be the subject of legal professional
> > privilege. If you are not the intended recipient, any use,
> > interference with, disclosure or copying of this material is
> > unauthorized and prohibited. Please inform us immediately and destroy
> > the email. Thank you for your cooperation.
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] use X310 Ref Out for sync

[Johannes Demel via USRP-users]

Hi all,

we have 2 USRP X310 which we need to synchronize. Hopefully to make 
things easier, we only need frequency synchronization. Is it possible to 
connect 'Ref Out' to 'Ref In' on another X310 for that purpose?
Previously, we used a signal generator to supply two USRPs with a 
reference 10MHz signal. If we could get rid of the signal generator, 
that would be really helpful.


Cheers
Johannes

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

Re: [USRP-users] use X310 Ref Out for sync

[Derek Kozel via USRP-users]

Hello Johannes,

Yes, in that case you can take the 10 MHz Ref Out from the primary X310 and
connect it to the 10 MHz Ref in of the second X310. What cannot be done is
extend that to a third X310 by daisy chaining or use the 1 PPS to achieve
the exact timing sync needed for precise phase alignment of multiple X310s.

Regards,
Derek

On Mon, Jul 23, 2018 at 10:17 AM, Johannes Demel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> we have 2 USRP X310 which we need to synchronize. Hopefully to make things
> easier, we only need frequency synchronization. Is it possible to connect
> 'Ref Out' to 'Ref In' on another X310 for that purpose?
> Previously, we used a signal generator to supply two USRPs with a
> reference 10MHz signal. If we could get rid of the signal generator, that
> would be really helpful.
>
> Cheers
> Johannes
>
> ___
> 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] RFNoc Blocks with Xilinx IP

[Chetwynd, Brendon - 0551 - MITLL via USRP-users]

EJ,

 

The help is much appreciated!

 

-   Brendon

 



Brendon Chetwynd Technical Staff

MIT Lincoln Laboratory   

 Cyber Systems and Operations (Group 51)

 

244 Wood StreetLexington, MA  02420-9185

   781-981-8212 (office)

brendon.chetw...@ll.mit.edu781-879-4635 (cell)

   781-387-3030 (pager)

   781-981-7548 (fax)



 

From: EJ Kreinar  
Sent: Saturday, July 21, 2018 6:59 PM
To: Neel Pandeya 
Cc: Chetwynd, Brendon - 0551 - MITLL ; 
USRP-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoc Blocks with Xilinx IP

 

Hi Brendon,

 

I went ahead and updated the OOT example repo to be compatible with Vivado 
2017.4 and the uhd-fpga "master" branch: 
https://github.com/ejk43/rfnoc-ootexample

 

The simulation testbenches now run using uhd-fpga master. Let me know if this 
works for you. Thanks!

EJ

 

On Fri, Jul 20, 2018 at 1:01 PM EJ Kreinar mailto:ejkrei...@gmail.com> > wrote:

Hi Brendon,

 

I have an example repo that shows how to use out-of-tree makefiles with xilinx 
IP (.xci definitions): github.com/ejk43/rfnoc-ootexample 
 

 

Please feel free to copy this format-  a few other rfnoc developers on the 
mailing list indicated it has worked for them too. 

 

Note that the rfnoc blocks are currently targeting the uhd-fpga source code as 
of Vivado 2015.4, and the testbenches will NOT currently run against most 
recent uhd-fpga and Vivado 2017.4. I would really appreciate a PR to update the 
IP to use vivado 2017.4 and noc blocks with the new inputs to the noc_shell :) 
I'll update it "eventually" but no idea when exactly. 

 

Hope this helps! Looking forward to seeing your OOT fpga blocks :)

 

EJ

 

On Fri, Jul 20, 2018, 12:19 PM Neel Pandeya via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:

Hello Brendon:

 

Could you describe in more detail what you're trying to do, or how you want to 
add your Xilinx IP?

 

Are you still using "rfnocmodtool" to add your custom RFNoC blocks?

 

The flow described in that document, and in the Application Note below, is the 
primary/intended way to add IP to an RFNoC installation.

 

https://kb.ettus.com/Getting_Started_with_RFNoC_Development

 

Please note that you should use the head of the UHD master branch, not the 
"rfnoc-devel" branch, when using RFNoC.

 

--​Neel Pandeya

 

 

 

 

On 20 July 2018 at 07:01, Chetwynd, Brendon - 0551 - MITLL via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:

I have been following the following blog post:

 

http://www.synchronouslabs.com/blog/creating-a-custom-rfnoc-block-with-using-xillinx-ip

 

Near the end, it instructs the user to add the Xilinx IP files (.xci for 
example) to the UHD project directory.

 

However, as this is a clone of the Ettus Research repo 
(https://github.com/EttusResearch/fpga.git), I am wondering if there is another 
way to do it that is compliant with the RFNOC build process.

 

Specifically, I would like to drop my customized Xilinx IP within my own rfnoc 
repository. 

 

Any advice?

 

Thanks,

Brendon

 

 


___
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



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

[USRP-users] X310 software reset revisted

[Jason Matusiak via USRP-users]

I know it has been questioned many times on here, but I wanted to verify 
something.  It has always been said that there is no way to do a software reset 
on the X310; I am curious if that is "currently" or "ever?" 
 
I wasn't sure if there was a way to send a packet either via UHD or RFNoC that 
could trigger a reset of some kind (this assumes that you have a functioning 
X310 on the other end), and no one has had time to look into it?  Or if it has 
been looked into and there truly is no way to do it.
 
I have some situations where I cannot get to my X310s easily, so if I need to 
reflash the bitfile (which is going to be necessary for RFNoC flowgraphs, I 
will have to add an external appliance to get the job done.  I was thinking 
about looking into it, but if it already has and was deemed a non-starter, I 
don't want to waste the cycles.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Announcing the RFNoC Workshop at the GNU Radio Conference

[Neel Pandeya via USRP-users]

==
   *** Announcing the RFNoC Workshop at the GNU Radio Conference ***

Ettus Research will be running free, hands-on,
   technical workshops at the GNU Radio Conference,
   and you are welcome to attend!

 GNU Radio Conference
 17-21 September 2018
Las Vegas, Nevada, USA
  https://www.gnuradio.org/grcon-2018/

==
   *** RFNoC Workshop ***

   Three Sessions

 Monday September 17
   13:15 to 17:00

Tuesday September 18
   08:45 to 12:15

Wednesday September 19
   08:45 to 12:15

 Registration Link:
  https://www.ettus.com/GNU-Radio-Conference

Full Title:

Introduction to FPGA Programming on the USRP Using the RFNoC Framework

Abstract:

Ettus Research's RFNoC (RF Network-on-Chip) software framework is designed
to decrease the development time for experienced FPGA engineers seeking to
integrate IP into the USRP FPGA signal processing chain. RFNoC is the
framework for USRP devices that use Xilinx 7-series FPGAs (E310, E312,
X300, X310). RFNoC is built around a packetized network infrastructure in
the FPGA that handles the transport of control and sample data between the
host CPU and the radio. Users target their custom algorithms to the FPGA in
the form of RFNoC blocks, which are processing blocks that attach to this
network. RFNoC blocks act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another RFNoC block, the
radio block, or the host CPU). Users can create modular, FPGA-accelerated
SDR applications by chaining RFNoC blocks into a flowgraph. RFNoC is
supported in UHD and GNU Radio. In this workshop, we will present an
interactive hands-on tutorial on RFNoC, including a discussion on its
design and capabilities, demonstrations of several existing examples, and
provide a walk-through on implementing a user-defined RFNoC block,
integrating the RFNoC block into UHD and invoking it from C++, and
integrating the RFNoC block into GNU Radio and invoking it from a
flowgraph. We will also demonstrate how to send command and receive
response packets between RFNoC blocks, as well as discuss test benches in
detail.

Prerequisites:

Attendees should have some previous experience with Linux and using the
Linux command line, and basic familiarity with a programming language such
as C, C++, or Python, and have basic understanding of fundamental concepts
in DSP and RF. Attendees should also have some basic familiarity with
Verilog. Extensive or deep experience with these topics is not necessary.

Attendees do not have to bring any USRP radios or laptop computers.

All necessary hardware and software will be provided in the workshop.

Attendees may optionally bring their own laptops for use in the workshop,
but this is not required. The laptop should have a minimum of 8 GB memory,
60 GB of free disk space, one Ethernet port, and one USB 3.0 port. The
laptop may run Microsoft Windows (7, 8.1, or 10), Apple macOS (10.12 or
10.13), or Linux (Ubuntu 16.04.4, 18.04, or Fedora 27, 28), and must have
both Oracle VirtualBox 5.2 and the VirtualBox Extension Pack installed (we
test with Ubuntu 18.04 and VirtualBox 5.2.14).

==
Details and Logistics:

* The workshops are technical and hands-on, and contains new additional
content.

* Each of the three sessions has the same content. Please only register for
one session.

* The workshop itself is free, but registration with the GNU Radio
Conference is required.

* The registrations for the GNU Radio Conference and for the RFNoC Workshop
are separate.

* Space is limited and will be allocated on a first-come, first-serve basis.

* For questions, please email "supp...@ettus.com".

* Register for the workshop at the link below:
https://www.ettus.com/GNU-Radio-Conference

* We look forward to seeing you there!!

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

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

[Rob Kossler via USRP-users]

Martin,
Re-flashing the SD card with the 3.12 image fixed my issue!
Rob

On Thu, Jul 19, 2018 at 6:13 PM Rob Kossler  wrote:

> I think 3.11, but how do I check?
> I'm not sure if I mentioned or not, but I am running benchmark_rate from a
> host, not embedded.
>
> Rob
>
> On Thu, Jul 19, 2018 at 6:03 PM Martin Braun 
> wrote:
>
>> On 07/19/2018 02:50 PM, Rob Kossler wrote:
>> > Oops, I meant to say in the last email that I had confirmed the other
>> > fixes - sorry about my misleading remark.
>>
>> Actually, it was a misunderstanding on my part. Glad it works for you!
>>
>> >
>> > Yes, I tried with externally supplied PPS and configured with
>> > time_source arg setting.  Same result as with internal PPS.
>>
>> Hm, this isn't really telling us anything.
>> Which SD card are you using? One from 3.12, or 3.11?
>>
>> -- M
>>
>> > Rob
>> >
>> > On Thu, Jul 19, 2018 at 5:46 PM Martin Braun > > > wrote:
>> >
>> > On 07/19/2018 11:45 AM, Rob Kossler wrote:
>> > > Hi Martin,
>> > > I wanted to confirm that the recent fixes mentioned for some of
>> > the N310
>> > > issues I mentioned are indeed working well for me. These include
>> > > - Tx power output levels
>> > > - get_usrp_rx_info(), get_usrp_tx_info()
>> >
>> > Yes, these are fixed...
>> >
>> > > However, I am still stuck on this "No PPS Detected" error which
>> occurs
>> > > in the function "set_time_unknown_pps()" and is caused by
>> >
>> > ...but this, unfortunately, is not.
>> >
>> > > "get_time_last_pps()" always returning zero.  I realize that you
>> have
>> > > been unable to duplicate this behavior on your own N310
>> hardware.  Any
>> > > suggestions for me to try?
>> >
>> > What happens when you do connect an external clock/PPS and select
>> > external clock/time source? Does that make any difference?
>> >
>> > -- M
>> >
>> >
>> >
>> > > I have previously tried this using multiple workstations and
>> multiple
>> > > UHD versions.  With 3.11 or  maint, there is no error.  With 3.12
>> or
>> > > master or rfnoc-devel, the error occurs.  I have not tried with
>> > multiple
>> > > N310 because I only have one.
>> > >
>> > > rob
>> > >
>> > >
>> > > On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler > > 
>> > > >> wrote:
>> > >
>> > > I just tried a separate computer and pulled the latest from
>> Master
>> > > (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
>> > > images_downloader and image_loader and rebooted N310.  Same
>> bad
>> > > result as indicated previously (see 1st result below).  Then,
>> > > without changing anything, I used a 3.11 version (I did not
>> bother
>> > > pulling the latest), ran images downloader and image loader
>> and
>> > > rebooted the N310.  The same command line worked fine on this
>> > > version (see 2nd result below).
>> > >
>> > > *  1st RESULT 
>> > > $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
>> > > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
>> Boost_105800;
>> > > UHD_3.13.0.0-101-g2787e2de
>> > > [00:00:00.03] Creating the usrp device with: ...
>> > > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> > >
>> >
>>   
>> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
>> > > [INFO] [MPM.PeriphManager] init() called with device args
>> > > `mgmt_addr=192.168.160.2,product=n310'.
>> > > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> > > 0xF1F0D004)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
>> > > [INFO] [0/Radio_0] Initializing block control (NOC ID:
>> > > 0x12AD10011312)
>> > > [INFO] [0/Radio_1] Initializing block control (NOC ID:
>> > > 0x12AD10011312)
>> > > [INFO] [0/DDC_0] Initializing block control (NOC ID:
>> > 0xDDC0)
>> > > [INFO] [0/DDC_1] Initializing block control (NOC ID:
>> > 0xDDC0)
>> > > [INFO] [0/DUC_0] Initializing block control (NOC ID:
>> > 0xD0C2)
>> > > [INFO] [0/DUC_1] Initializing block control (NOC ID:
>> > 0xD0C2)
>> > > Using Device: Single USRP:
>> > >   Device: N300-Series Device
>> > >   Mboard 0: ni-n3xx-3144673
>> > >   RX Channel: 0
>> > > RX DSP: 0
>> > > RX Dboard: A
>> > > RX Subdev: Magnesium
>> > >   RX Channel: 1
>> > > 

[USRP-users] External LO with N310

[Rob Kossler via USRP-users]

Hi,
I was playing around with external LO capability with the N310.  I used the
arg "tx_lo_source=external" and I discovered that if I only connected 1 of
the 2 external Tx LO inputs, the multi_usrp make fails.  For my use case, I
only planned to use Tx channels 0 and 1 (daughterboard A) and so I only
planned to connect the 1st external Tx LO input.

A couple of questions:
1) Is this behavior intentional?  In other words, do I need to change my
plans such that I supply both external Tx LO inputs even if I am only
planning to transmit from one daughterboard?
2) It appears that a calibration occurs during the make (which is what
fails when one input is not connected).  What if I later change the
external LO frequency?  Do I need to ensure that this calibration occurs
again, and if so, how?

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

[USRP-users] Alternate transmission of frames on 2 TX USRP port

[Ayaz Mahmud via USRP-users]

Hi,

USRP UHD B210 – GnuRadio 3.7.10

I am generating frames and transmitting by using OFDM_tx example.
Now I want to use 1 USRP sink (with 2 Tx port). And want every alternate packet 
from each sink.

Example :
Frame 1 (every odd number of frame) – USRP tx port 1
Frame 2 (every even number of frame) – USRP tx port 2

Also note I don’t want to transmit the frames at same time. So while, tx port 1 
will transmit tx should remain silent.

Does GnuRadio has some blocks that can do this alternate transmission?

Thanks,
Ayaz

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

Re: [USRP-users] X310 software reset revisted

[Nick Foster via USRP-users]

I've solved this with the USB JTAG interface and an external machine. An
RPi will happily run Vivado Lab.

AFAIK there are no plans to integrate a software reset into the X310.

Nick

On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I know it has been questioned many times on here, but I wanted to verify
> something.  It has always been said that there is no way to do a software
> reset on the X310; I am curious if that is "currently" or "ever?"
>
> I wasn't sure if there was a way to send a packet either via UHD or RFNoC
> that could trigger a reset of some kind (this assumes that you have a
> functioning X310 on the other end), and no one has had time to look into
> it?  Or if it has been looked into and there truly is no way to do it.
>
> I have some situations where I cannot get to my X310s easily, so if I need
> to reflash the bitfile (which is going to be necessary for RFNoC
> flowgraphs, I will have to add an external appliance to get the job
> done.  I was thinking about looking into it, but if it already has and was
> deemed a non-starter, I don't want to waste the cycles.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

[Martin Braun via USRP-users]

On 07/23/2018 06:57 AM, Rob Kossler wrote:
> Martin,
> Re-flashing the SD card with the 3.12 image fixed my issue!

Rob,

that's great news, and I'm happy you're unstuck! I'm still not entirely
sure what the exact reason is for this is, but here's a short analysis:

On the N310, we use an architecture where a piece of software called
'MPM' runs on the device and handles most of the device-specific
controls. Sometimes we need to fix bugs in MPM, which is a little more
annoying than fixing bugs in UHD because it's a bit harder to update.
However, whenever we change something which *requires* you to update
MPM, we will bump a compat number.
It looks like we made a change that would have required a compat number
update, but we missed that and didn't change the compat number. The end
result is that UHD 3.12 continued to happily work with MPM 3.11, but
really shouldn't have. This explains why your 3.11 UHD was fine (because
the device was running MPM 3.11), but your UHD 3.12 was only fine when
you only updated MPM.

Like I said, we normally would force users to upgrade by changing the
compat number, which we didn't in this case. However, when issues like
this pop up, a good thing to try is to update your SD card image. You
don't have to remove the SD card in most cases, you can use our
Mender-based workflow (see here:
http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rasm_mender).

Cheers,
Martin

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

Re: [USRP-users] SFP Transceivers for N310 1/10Gbps Fiber Ethernet

[Ashish Chaudhari via USRP-users]

Hi Zhongyuan,

>> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?

No it's not. Depending on what N310 FPGA image you build/use, the port
speeds are locked down. The HG image is 1G on SFP0 and 10G on SFP1
whereas the XG image has 10G on both SFP ports. The transceiver might
support both speeds but the USRP won't.

>> Could you recommend any SFP transceivers that work on your case? both
>> 1Gbps and 10Gbps.

What speed do you need for your application? What is the speed of the
switch that you are working with? The solutions for 1Gbps and 10Gbps
are vastly different. Generally speaking fiber-optics that support
10GBASE-SR, -LR and -ER should work with the N310 when the SFP port is
in 10G mode and optics that support 1000BASE-LX, -SX and -CX should
work in 1G mode. For Ethernet, I should mention that certain switch
and NIC vendors explicitly disallow certain non-approved optical
modules, so on the switch side I would double check with the vendor
that the transceiver works with your switch. On the USRP side, we
accept all optics. I haven't used the specific Finisar module
(FTLX1475D3BCV) but in general we have seen good results with Finisar,
Amphenol FCI and Elpeus transceivers. We do most of our testing with
full cable assemblies, although those might be a bit harder to find
for the lengths that you are looking for.

As a data point here are the ones that are known to work:
https://www.mouser.com/ProductDetail/Finisar/FCBG110SD1C03?qs=sGAEpiMZZMsi6nco80NB4Pt5EfrefmupuvEijLXVquZ4ABfDcakyUQ%3d%3d
https://www.serversupply.com/NETWORKING/TRANSCEIVER/10%20GIGABIT/INTEL/FTLX8571D3BCVIT1.htm

Thanks,
Ashish


On Sat, Jul 21, 2018 at 2:17 PM, Zhongyuan Zhao via USRP-users
 wrote:
> Has anyone tried 10G/1G Dual Rate (10GBASE-LR/LW and 1000BASE-LX) 10km
> 1310nm Single Mode Datacom SFP+ Optical Transceiver?
> https://www.finisar.com/optical-transceivers/ftlx1475d3bcv
>
> Thanks.
>
>
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
> Suite 117, Schorr Center,
> Lincoln, Nebraska 68588-0115
>
> On Fri, Jul 20, 2018 at 2:06 PM, Zhongyuan Zhao  wrote:
>>
>> Hi,
>>
>> I am working on a project where several N310s are connected to a
>> fiber-Ethernet switch. The fibers are of single mode with length from 1km to
>> 10km. My problem is selecting the right SFP transceivers.
>>
>> Currently, I used the official SFP to RJ45 converter (come from Ettus with
>> N310) followed by another pair of RJ45 to SFP converter.
>>
>> https://www.amazon.com/gp/product/B06XC1VDMD/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
>> This is a work around solution. I tried to connect N310 and Dell N3048
>> switch (2 SFP ports)
>> directly through a pair of 10Gtek SFP transceivers (1Gbps) that come with
>> the RJ45 to SFP converter but it does not work.
>>
>> Could you recommend any SFP transceivers that work on your case? both
>> 1Gbps and 10Gbps.
>> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?
>>
>> Thank you very much!
>>
>> Regards,
>> Zhongyuan Zhao
>>
>> PhD Candidate,
>> Department of Computer Science & Engineering,
>> University of Nebraska-Lincoln
>> Suite 117, Schorr Center,
>> Lincoln, Nebraska 68588-0115
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

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

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

[Rob Kossler via USRP-users]

Thanks for the explanation.  That make sense.  I suppose that I also could
have just pulled and recompiled MPM directly on the N310 (in lieu of
re-flashing the SD externally or using mender).

Rob

On Mon, Jul 23, 2018 at 12:55 PM Martin Braun 
wrote:

> On 07/23/2018 06:57 AM, Rob Kossler wrote:
> > Martin,
> > Re-flashing the SD card with the 3.12 image fixed my issue!
>
> Rob,
>
> that's great news, and I'm happy you're unstuck! I'm still not entirely
> sure what the exact reason is for this is, but here's a short analysis:
>
> On the N310, we use an architecture where a piece of software called
> 'MPM' runs on the device and handles most of the device-specific
> controls. Sometimes we need to fix bugs in MPM, which is a little more
> annoying than fixing bugs in UHD because it's a bit harder to update.
> However, whenever we change something which *requires* you to update
> MPM, we will bump a compat number.
> It looks like we made a change that would have required a compat number
> update, but we missed that and didn't change the compat number. The end
> result is that UHD 3.12 continued to happily work with MPM 3.11, but
> really shouldn't have. This explains why your 3.11 UHD was fine (because
> the device was running MPM 3.11), but your UHD 3.12 was only fine when
> you only updated MPM.
>
> Like I said, we normally would force users to upgrade by changing the
> compat number, which we didn't in this case. However, when issues like
> this pop up, a good thing to try is to update your SD card image. You
> don't have to remove the SD card in most cases, you can use our
> Mender-based workflow (see here:
> http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rasm_mender).
>
> Cheers,
> Martin
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 software reset revisted

[Nate Temple via USRP-users]

Hi Jason,

This magic poke should do the trick:

python $UHD_INSTALL_DIR/firmware/usrp3/x300/x300_debug.py --addr=
--poke=0x100058 --data=1


Regards,
Nate Temple

On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've solved this with the USB JTAG interface and an external machine. An
> RPi will happily run Vivado Lab.
>
> AFAIK there are no plans to integrate a software reset into the X310.
>
> Nick
>
> On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I know it has been questioned many times on here, but I wanted to verify
>> something.  It has always been said that there is no way to do a software
>> reset on the X310; I am curious if that is "currently" or "ever?"
>>
>> I wasn't sure if there was a way to send a packet either via UHD or RFNoC
>> that could trigger a reset of some kind (this assumes that you have a
>> functioning X310 on the other end), and no one has had time to look into
>> it?  Or if it has been looked into and there truly is no way to do it.
>>
>> I have some situations where I cannot get to my X310s easily, so if I
>> need to reflash the bitfile (which is going to be necessary for RFNoC
>> flowgraphs, I will have to add an external appliance to get the job
>> done.  I was thinking about looking into it, but if it already has and was
>> deemed a non-starter, I don't want to waste the cycles.
>> ___
>> 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 list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] SFP Transceivers for N310 1/10Gbps Fiber Ethernet

[Rob Kossler via USRP-users]

I am successfully using this 10gbe SFP+/LC singlemode 1310nm transceiver
from fs.com.
FS SFP-10GLR-31
I am also using this QSFP+/MTP transceiver (for Intel XL-710 in 4x10gbe
mode)
FS QSFP-PLR4-40G

On Mon, Jul 23, 2018 at 1:10 PM Ashish Chaudhari via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Zhongyuan,
>
> >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?
>
> No it's not. Depending on what N310 FPGA image you build/use, the port
> speeds are locked down. The HG image is 1G on SFP0 and 10G on SFP1
> whereas the XG image has 10G on both SFP ports. The transceiver might
> support both speeds but the USRP won't.
>
> >> Could you recommend any SFP transceivers that work on your case? both
> >> 1Gbps and 10Gbps.
>
> What speed do you need for your application? What is the speed of the
> switch that you are working with? The solutions for 1Gbps and 10Gbps
> are vastly different. Generally speaking fiber-optics that support
> 10GBASE-SR, -LR and -ER should work with the N310 when the SFP port is
> in 10G mode and optics that support 1000BASE-LX, -SX and -CX should
> work in 1G mode. For Ethernet, I should mention that certain switch
> and NIC vendors explicitly disallow certain non-approved optical
> modules, so on the switch side I would double check with the vendor
> that the transceiver works with your switch. On the USRP side, we
> accept all optics. I haven't used the specific Finisar module
> (FTLX1475D3BCV) but in general we have seen good results with Finisar,
> Amphenol FCI and Elpeus transceivers. We do most of our testing with
> full cable assemblies, although those might be a bit harder to find
> for the lengths that you are looking for.
>
> As a data point here are the ones that are known to work:
>
> https://www.mouser.com/ProductDetail/Finisar/FCBG110SD1C03?qs=sGAEpiMZZMsi6nco80NB4Pt5EfrefmupuvEijLXVquZ4ABfDcakyUQ%3d%3d
>
> https://www.serversupply.com/NETWORKING/TRANSCEIVER/10%20GIGABIT/INTEL/FTLX8571D3BCVIT1.htm
>
> Thanks,
> Ashish
>
>
> On Sat, Jul 21, 2018 at 2:17 PM, Zhongyuan Zhao via USRP-users
>  wrote:
> > Has anyone tried 10G/1G Dual Rate (10GBASE-LR/LW and 1000BASE-LX) 10km
> > 1310nm Single Mode Datacom SFP+ Optical Transceiver?
> > https://www.finisar.com/optical-transceivers/ftlx1475d3bcv
> >
> > Thanks.
> >
> >
> >
> > Zhongyuan Zhao
> >
> > PhD Candidate,
> > Department of Computer Science & Engineering,
> > University of Nebraska-Lincoln
> > Suite 117, Schorr Center,
> > Lincoln, Nebraska 68588-0115
> >
> > On Fri, Jul 20, 2018 at 2:06 PM, Zhongyuan Zhao 
> wrote:
> >>
> >> Hi,
> >>
> >> I am working on a project where several N310s are connected to a
> >> fiber-Ethernet switch. The fibers are of single mode with length from
> 1km to
> >> 10km. My problem is selecting the right SFP transceivers.
> >>
> >> Currently, I used the official SFP to RJ45 converter (come from Ettus
> with
> >> N310) followed by another pair of RJ45 to SFP converter.
> >>
> >>
> https://www.amazon.com/gp/product/B06XC1VDMD/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
> >> This is a work around solution. I tried to connect N310 and Dell N3048
> >> switch (2 SFP ports)
> >> directly through a pair of 10Gtek SFP transceivers (1Gbps) that come
> with
> >> the RJ45 to SFP converter but it does not work.
> >>
> >> Could you recommend any SFP transceivers that work on your case? both
> >> 1Gbps and 10Gbps.
> >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?
> >>
> >> Thank you very much!
> >>
> >> Regards,
> >> Zhongyuan Zhao
> >>
> >> PhD Candidate,
> >> Department of Computer Science & Engineering,
> >> University of Nebraska-Lincoln
> >> Suite 117, Schorr Center,
> >> Lincoln, Nebraska 68588-0115
> >
> >
> >
> > ___
> > 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 list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 software reset revisted

[Nick Foster via USRP-users]

What is this witchery?? Is this a reset to the  PCIe controller?

Nick

On Mon, Jul 23, 2018 at 10:44 AM Nate Temple  wrote:

> Hi Jason,
>
> This magic poke should do the trick:
>
> python $UHD_INSTALL_DIR/firmware/usrp3/x300/x300_debug.py --addr=
> --poke=0x100058 --data=1
>
>
> Regards,
> Nate Temple
>
> On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I've solved this with the USB JTAG interface and an external machine. An
>> RPi will happily run Vivado Lab.
>>
>> AFAIK there are no plans to integrate a software reset into the X310.
>>
>> Nick
>>
>> On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I know it has been questioned many times on here, but I wanted to verify
>>> something.  It has always been said that there is no way to do a software
>>> reset on the X310; I am curious if that is "currently" or "ever?"
>>>
>>> I wasn't sure if there was a way to send a packet either via UHD or
>>> RFNoC that could trigger a reset of some kind (this assumes that you have a
>>> functioning X310 on the other end), and no one has had time to look into
>>> it?  Or if it has been looked into and there truly is no way to do it.
>>>
>>> I have some situations where I cannot get to my X310s easily, so if I
>>> need to reflash the bitfile (which is going to be necessary for RFNoC
>>> flowgraphs, I will have to add an external appliance to get the job
>>> done.  I was thinking about looking into it, but if it already has and was
>>> deemed a non-starter, I don't want to waste the cycles.
>>> ___
>>> 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 list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC flowgraph runs right the second time

[Jason Matusiak via USRP-users]

I have a flowgraph with a custom RFNoC block in the middle.  That block has 2 
inputs and 2 outputs.  Just to get started and work out the MIMO functionality, 
all I do is cross the the inputs to the outputs (so input 0 comes out output 1).
 
What I am seeing is that if I run the flowgraph after loading a fresh bitfile, 
I don't get anything out of my output who should be passing the data from an 
RFNoC radio->DDC  and I see "timeout on chan 0" scrolling past on the screen.  
But, if I run the same flowgraph a second time, it suddenly works fine (as well 
as subsequent runs afterwards until I reload the bitfile).  
 
It doesn't matter if I swap the inputs to the special block, it always reads 
"timeout on chan 0" and the output stream on my block that should be displaying 
that data is dead the first run after a reload.
 
I am guessing that "timeout on chan 0" is releated to either the Radio or DDC 
block as it is consistently 0 even when I move it around on my 2 inputs (if I 
pull out the DDC, I see the same issues, so it seems to be something between 
the radio and my block).
 
That said, I don't see this issue if I run the rfnoc_ddc.grc example from Ettus 
which also uses a Radio and DDC.
 
I could believe that it has something to do with a reset in my block (like the 
fact that there are two clear_tx_seqnum flags), I am just confused why the 
issue moves around depending on where the rfnoc/ddc is connected (yet the 
timeout does not). 
 
If I remove the radio/ddc and use an rfnoc split stream to take my GR signal 
source, I don't see these issues.  So I cannot figure out what is not playing 
nicely between my block and the RFNoC radio. BUT... If I go from the radio into 
a split stream to my two inputs, it works right the first time, and then 
doesn't work again after that (so almost the reverse issue as I've started 
with, but I REALLY feel like something with my block dealing with 2 inputs and 
2 outputs is causing this issue.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Log all signals in simulation

[Erik Malone via USRP-users]

Hi

I'm looking for a way to log all signals when simulating an RFNoC design in
batch mode.  This would help me to run longer tests and then bring up a
waveform whenever an error occurred.  Preferably, I'd like to keep within
Ettus' current simulation flow.

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

Re: [USRP-users] Reception of signals problem

[Marcus D. Leech via USRP-users]

What are the connections between your computers and USrPs? Are you driving them 
with dedicated Ethernet cards on each PC?



Sent from my iPhone

> On Jul 23, 2018, at 5:08 AM, Kirthana Rao  wrote:
> 
> What do you mean by computer configurations,  do you want details of the 
> system I am using or the details of the usrp.Pardon my naivety, I am very new 
> to this topic.
> Thank you for your time and intrest in helping me solve my problem.
> 
>> On Sun, 22 Jul 2018, 11:44 p.m. Marcus D. Leech,  wrote:
>>> On 07/22/2018 01:07 PM, Kirthana Rao wrote:
>>> No the usrps are connected to two different hosts.When I entered the other 
>>> usrp's address in the uhd:usrp source block in gnuradio,I got an error 
>>> saying that the address was not found.
>> Well, that makes sense, because said USRP is on another computer.
>> 
>> Please gives us an overview of what you're trying to do, and what your 
>> computer configurations are.
>> 
>> 
>>> 
 On Sun, 22 Jul 2018, 10:31 p.m. Marcus D. Leech,  wrote:
> On 07/22/2018 01:03 AM, Kirthana Rao wrote:
> I meant through ip addresses.I am a beginner in the field of software 
> defined radio, so I am not sure whether I am suppose to use ping command 
> to check whether one usrp recognises the other usrp on the same network.
 So you have two USRPs connected to the same, or different, hosts?
 
 There's no real concept of "one USRP recognizing the other over the 
 network".   This indicates to me some significant conceptual gaps,
   and I'm trying to figure out where those conceptual gaps are, so we all 
 stand a better chance of helping you.
 
 
> 
>> On Sat, 21 Jul 2018, 7:25 p.m. Marcus D. Leech via USRP-users, 
>>  wrote:
>> On 07/21/2018 09:54 AM, Kirthana Rao via USRP-users wrote:
>> > Respected Members,
>> > I am working with usrp n210.I have two of these devices one for 
>> > transmitting and other for receiving. But the problem is that when I 
>> > do a basic transmission of a sine signal using gnu radio, what I 
>> > receive is noise. When I try pinging one device from the other it 
>> > gives host unreachable inspite of being in the same network. Is there 
>> > any synchronization to be done between the 2 devices? Please help.
>> > Thanks in advance.
>> >
>> What do you mean by "pinging one device from another" ??
>> 
>> How are your USRPs connected to your computer?  What addresses do they 
>> have?
>> 
>> 
>> 
>> ___
>> 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] distinguishing FPGA images

[Rob Kossler via USRP-users]

I have a couple of questions about the best way to approach a couple of
things:

Q1) How can I tell the difference between a stock RFNoC FPGA image and one
that I custom modified?  I made a small change to one of the existing
blocks and so the resulting output from uhd_usrp_probe is the same for the
stock image and my custom image.  What is a good way for me to be able to
be able to know if the custom image is presently loaded?  Add a register
with static info, perhaps?  Modify the block ID of the modified block?

Q2) For a custom host app (C++) that calls UHD directly, which is a better
method for message logging: using the existing UHD message logging system
or keeping the UHD and my custom messages separate?  The capabilities of
the existing UHD logging look adequate to me so the question is not so much
about capability but more about whether its a good idea to hijack the UHD
system.

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

[USRP-users] timestamps and overruns

[RizThon via USRP-users]

Hi all,

I have a question concerning the timestamps while getting an overrun.

I'm sampling at 28MS/s and reading blocks of 1024 samples. So it takes 36571
to 36572ns to sample each block.

I try to read x blocks, calling receive for each block. I get something like

block 93: correctly read 1024 samples, timestamp as expected (ie +36571ns
compared to block 92)
block 94: only received 364 samples, timestamp still as expected
block 95: overrun, timestamp is bigger than expected (+94286)
block 96: correctly read 1024 samples, but timestamp is lower than block 95
(-81286)
block 97: correctly read 1024 samples, timestamp as expected
block 98: correctly read 1024 samples, timestamp as expected
block 99: correctly read 1024 samples, but timestamp is bigger than
expected (+2818750)

The exact same pattern repeats itself from time to time
block n: receive fewer than expected samples
block n+1: overrun with timestamp jump
block n+2: get timestamp smaller by always 81285 or 81286
block n+3: ok
block n+4: ok
block n+5: big timestamp jump

Can someone explain what is happening, and what the proper way to handle
overruns is?

I'm using SoapySDR, so I don't know if it's specific to UHD or if there's
some bug in Soapy (I'm not seeing that behaviour with the same program
running a LimeSDR).

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

Re: [USRP-users] timestamps and overruns

[Marcus D. Leech via USRP-users]

On 07/23/2018 09:51 PM, RizThon via USRP-users wrote:

Hi all,

I have a question concerning the timestamps while getting an overrun.

I'm sampling at 28MS/s and reading blocks of 1024 samples. So it takes 
36571 to 36572ns to sample each block.


I try to read x blocks, calling receive for each block. I get 
something like


block 93: correctly read 1024 samples, timestamp as expected 
(ie +36571ns compared to block 92)

block 94: only received 364 samples, timestamp still as expected
block 95: overrun, timestamp is bigger than expected (+94286)
block 96: correctly read 1024 samples, but timestamp is lower than 
block 95 (-81286)

block 97: correctly read 1024 samples, timestamp as expected
block 98:correctly read 1024 samples, timestamp as expected
block 99:correctly read 1024 samples, but timestamp is bigger than 
expected (+2818750)


The exact same pattern repeats itself from time to time
block n: receive fewer than expected samples
block n+1: overrun with timestamp jump
block n+2: get timestamp smaller by always 81285 or 81286
block n+3: ok
block n+4: ok
block n+5: big timestamp jump

Can someone explain what is happening, and what the proper way to 
handle overruns is?


I'm using SoapySDR, so I don't know if it's specific to UHD or if 
there's some bug in Soapy (I'm not seeing that behaviour with the same 
program running a LimeSDR).


Thanks.



What type of USRP is this from?

There aren't too many people on this list who can help debug SOAPYSDR 
stuff, so debugging it might require doing a "throw away" purely using

  the UHD API, to see if the problem persists there.


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

Re: [USRP-users] timestamps and overruns

[RizThon via USRP-users]

Hi Marcus,

It's a B210. So you confirm this is strange, and is probably a problem on
the Soapy part?

I can try to write the same straight in UHD to see what I get.

Thanks.

On Tue, Jul 24, 2018 at 10:00 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/23/2018 09:51 PM, RizThon via USRP-users wrote:
>
> Hi all,
>
> I have a question concerning the timestamps while getting an overrun.
>
> I'm sampling at 28MS/s and reading blocks of 1024 samples. So it takes 36571
> to 36572ns to sample each block.
>
> I try to read x blocks, calling receive for each block. I get something
> like
>
> block 93: correctly read 1024 samples, timestamp as expected (ie +36571ns
> compared to block 92)
> block 94: only received 364 samples, timestamp still as expected
> block 95: overrun, timestamp is bigger than expected (+94286)
> block 96: correctly read 1024 samples, but timestamp is lower than block
> 95 (-81286)
> block 97: correctly read 1024 samples, timestamp as expected
> block 98: correctly read 1024 samples, timestamp as expected
> block 99: correctly read 1024 samples, but timestamp is bigger than
> expected (+2818750)
>
> The exact same pattern repeats itself from time to time
> block n: receive fewer than expected samples
> block n+1: overrun with timestamp jump
> block n+2: get timestamp smaller by always 81285 or 81286
> block n+3: ok
> block n+4: ok
> block n+5: big timestamp jump
>
> Can someone explain what is happening, and what the proper way to handle
> overruns is?
>
> I'm using SoapySDR, so I don't know if it's specific to UHD or if there's
> some bug in Soapy (I'm not seeing that behaviour with the same program
> running a LimeSDR).
>
> Thanks.
>
>
> What type of USRP is this from?
>
> There aren't too many people on this list who can help debug SOAPYSDR
> stuff, so debugging it might require doing a "throw away" purely using
>   the UHD API, to see if the problem persists there.
>
>
> ___
> 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] timestamps and overruns

[Marcus D. Leech via USRP-users]

On 07/23/2018 10:04 PM, RizThon wrote:

Hi Marcus,

It's a B210. So you confirm this is strange, and is probably a problem 
on the Soapy part?


I can try to write the same straight in UHD to see what I get.

Thanks.
Yes an overrun should result in an overrun indication, and a timestamp 
that is a "jump", but always in the positive direction.





On Tue, Jul 24, 2018 at 10:00 AM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 07/23/2018 09:51 PM, RizThon via USRP-users wrote:

Hi all,

I have a question concerning the timestamps while getting an overrun.

I'm sampling at 28MS/s and reading blocks of 1024 samples. So it
takes 36571 to 36572ns to sample each block.

I try to read x blocks, calling receive for each block. I get
something like

block 93: correctly read 1024 samples, timestamp as expected
(ie +36571ns compared to block 92)
block 94: only received 364 samples, timestamp still as expected
block 95: overrun, timestamp is bigger than expected (+94286)
block 96: correctly read 1024 samples, but timestamp is lower
than block 95 (-81286)
block 97: correctly read 1024 samples, timestamp as expected
block 98:correctly read 1024 samples, timestamp as expected
block 99:correctly read 1024 samples, but timestamp is bigger
than expected (+2818750)

The exact same pattern repeats itself from time to time
block n: receive fewer than expected samples
block n+1: overrun with timestamp jump
block n+2: get timestamp smaller by always 81285 or 81286
block n+3: ok
block n+4: ok
block n+5: big timestamp jump

Can someone explain what is happening, and what the proper way to
handle overruns is?

I'm using SoapySDR, so I don't know if it's specific to UHD or if
there's some bug in Soapy (I'm not seeing that behaviour with the
same program running a LimeSDR).

Thanks.



What type of USRP is this from?

There aren't too many people on this list who can help debug
SOAPYSDR stuff, so debugging it might require doing a "throw away"
purely using
  the UHD API, to see if the problem persists there.


___
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