[USRP-users] E310 receive architecture

2018-12-04 Thread Ramazan Çetin via USRP-users 

Hello all,

I am trying to understand what is going on while receiving RF data in 
USRP E310. I am using gnuradio in programming of USRP E310.


I investigated AD9361 chip and the baseband data rate of AD9361 is 
maximum of 61.44MHz. So this is equal to master clock rate as i 
understood. For example, if i set the sample rate of USRP source block 
in gnuradio to 10MHz, What will happen?



Q1.

My Approach 1. There are several filters and decimators in AD9361. So, 
in AD9361 the ADC samples at rate of for example at 100MHz and using 
decimators in AD9361, the baseband data rate of 10MHz is obtained. Is 
this what happened ? (In this case FPGA blocks (DDC, DDU and radio) are 
not used)


or,

My Approach 2. The baseband rate of AD9361 is set to for example 40MHz 
using decimators and filters and data is passed to FPGA. In FPGA, using 
the DDC the rate of data is reduced to 10MHz. Is this what happened?



Q2.

Actually, i am confused in FPGA part of receiver. Normally, without 
using the RFNoC do the DDC and DDU blocks in FPGA are used to obtain 
desirable sample rate? or When i use the RFNoC programming in gnuradio, 
i can activate them. Relating to RFNoC and FPGA radio, DDC, DDU blocks, 
can you review my approaches?



My questions are related to each other. FPGA and RFNoC part is big 
question mark in my mind. If you give some information about FPGA part 
with or without RFNoC, after answering my questions, i will appreciate.



Best regards.

Ramazan



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

Re: [USRP-users] twinrx example

2018-12-04 Thread Fabian Schwartau via USRP-users 

Hi,

there is a file called twinrx_freq_hopping.cpp, which is using twinrx.

Best regards,
Fabian

Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:

Hi,


I am not finding an example to receive data for twinrx case of USRP 
x300/310.



I am looking at the following link:


https://github.com/EttusResearch/uhd/tree/master/host/examples





uhd/host/examples at master · EttusResearch/uhd · GitHub 


github.com
The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd 
development by creating an account on GitHub.




Can someone please share the link of c++ code for receiving data from 
twinrx for x300/310?



Regards,

Koyel


___
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] IOError: x300 fw poke32 - reply timed out

2018-12-04 Thread Marcus Müller via USRP-users 
oh wow, that's interesting, though I have little idea how to
reconciliate storage backpressure with dropping out of networking.
My best guess is that the storage system pushing back on too much data
somehow causes additional CPU load (especially: interrupts/context
switches), and that worsens the situation somehow so much that network
stacks get confused.
But that's exactly that: a wild guess in the blue.

Thus: Happy to hear you've got it working!

By the way, what's your kernel's write buffer size? In a pinch, the
following (single line) command should spit out the size in Gigibytes:

echo $(( $(sed -n -e 's/^MemTotal:[[:space:]]*\([[:digit:]]*\).*/\1/p'
/proc/meminfo) * $(sysctl -n vm/dirty_ratio) / 100. / (2**20) ))

If that is less write buffer than you expected, try upping up the
vm.dirty_ratio (i.e. percentage of RAM pages allowed to get filled
before flushing the write cache to disk is enforced and file write
operations become blocking) to something more generous – if your
system's main purpose is to write stuff to disk, and it will still
function well with the remaining 10%, try `sysctl -w vm.dirty_ratio=90`
and see whether that "evens out" the write peaks a bit.

Best regards,
Marcus  

On Tue, 2018-12-04 at 08:19 +0100, Stefan van der Linden wrote:
> It tooks us a while, but we seem to have found the root cause of the 
> issue. The RAID array which was being fed the data was able to just
> cope 
> with the dataflow peaks, although the mean dataflow was not a
> problem. 
> Therefore, when some kind of additional process fired up or some
> other 
> imperfection, it caused the buffer being used to overflow in some
> cases. 
> We were able to prevent this from happening by adding an SSD-based
> write 
> cache.
> However, we still don't understand why this effectively caused the
> X300 
> and/or the NIC to lock up, although I'm glad the problem is gone.
> 
> Kind regards,
> 
> Stefan
> 
> On 27/09/2018 11:45, Stefan van der Linden wrote:
> > Hi Marcus,
> > 
> > we've gone and updated UHD (HEAD of remotes/origin/UHD-3.13) and 
> > changed the MTU to 8000, unfortunately the problem still persists.
> > A 
> > TCP dump as discussed before is downloadable via: 
> > https://we.tl/t-zTKY2iHAlK.
> > Note that 192.168.50.1 is the host and 192.168.50.2 is the X300.
> > The 
> > download also contains a dump of the shell output, just in case.
> > The 
> > program ran without problems for a good two hours or so.
> > Hope this helps in debugging!
> > 
> > Kind regards,
> > 
> > Stefan
> > 
> > 
> > On 24/09/2018 22:38, Marcus Müller wrote:
> > > Hi Stefan,
> > > 
> > > so I've talked to our main software sustainance hero, and we
> > > rather
> > > quickly came to the conclusion that it's pretty likely you should
> > > move
> > > on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are
> > > you
> > > building from source, or are you using binary packages?
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:
> > > > Hi Stefan,
> > > > 
> > > > I know it's not of great comfort when an engineer finds a
> > > > problem to
> > > > be
> > > > /interesting/, but yours certainly is.
> > > > So, first things first: if the computational power and memory
> > > > of the
> > > > host that your USRP is connected to allows, it might be good to
> > > > have
> > > > a
> > > > packet capture in some kind of a ring buffer, so that you can
> > > > infer a
> > > > bit on the state at the point where things go wrong:
> > > > 
> > > > tcpdump -n # no DNS lookups
> > > > -i 
> > > > -s 0 # don't stop after a finite amount of packets
> > > > -C 400 # 400 million bytes per capture file
> > > > -W 2 # rotate through three files of capturs
> > > > -w /tmp/rotate.pcap # make sure that you're using a file that's
> > > > on an
> > > > RAM filesystem; if in doubt, make one with `mount -t tmpfs
> > > > tmpfs
> > > > /path`
> > > > 
> > > > So, yes, using an MTU of 8000 would be the first thing that the
> > > > Ettus
> > > > hivemind would recommend, too, but if you say things still go
> > > > wrong,
> > > > we
> > > > might need to dig deeper.
> > > > 
> > > > I do know that we've improved the bus clocking, and that had
> > > > impact
> > > > on
> > > > the X300 firmware. Is trying the last 3.10 release an option
> > > > for you?
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via
> > > > USRP-
> > > > users
> > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > We are in the process of prototyping a setup using an X300
> > > > > with two
> > > > > UBX-40 daughterboards to be used in the validation of an
> > > > > externally
> > > > > provided signal source. The daughterboards are each dedicated
> > > > > to
> > > > > one
> > > > > of two tasks: transmitting a pre-recorded reference signal in
> > > > > a
> > > > > loop
> > > > > at 50 MSps, and capturing that same signal again after
> > > > > passing
> > > > > throug

Re: [USRP-users] Compile error

2018-12-04 Thread Marcus Müller via USRP-users 
Why did you change the GCC to the ancient 4.8? How did you do that?

Best regards,
Marcus

On Tue, 2018-12-04 at 14:15 +0800, Philip_liu via USRP-users wrote:
> Hi all,
> 
> I download and update all the dependency packages base on
> ubuntu 18.04LTS,but the UHD cannot compile successfully.I changed the
> gcc and g++ default vertion from 7 to
> 4.8,is this the reason that affects the result?Do I have to reinstall
> ubuntu to solve it?
> 
> Error text:
> Scanning dependencies of target uhd_rpclib
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/dispatcher.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/server.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/client.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_handler.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_session.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_server.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/rpc_error.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/server_session.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/response.cc.o
> [  2%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/client_error.cc.o
> [  2%] Built target uhd_rpclib
> [  2%] Generating /home/corad/uhd/host/build/lib/transport/vrt_if_pac
> ket.cpp
> [  2%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4350_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4351_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2870_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2871_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4360_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9510_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9777_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad5623_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad7922_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2829_
> regs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2118_
> regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2112_
> regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9862_r
> egs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9522_r
> egs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads62p44
> _regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads62p48
> _regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tuner_49
> 37di5_regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tda18272
> hnm_regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmk04816
> _regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5355_
> regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5356_
> regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmx2592_
> regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmk04828
> _regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/magnesiu
> m_cpld_regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/convert/convert_gene
> ral.cpp
> [  7%] Generating /home/corad/uhd/host/build/lib/rfnoc/nocscript/basi
> c_functions.hpp
> [  8%] Generating /home/corad/uhd/host/build/lib/transport/nirio/lvbi
> tx/x300_lvbitx.cpp
> [  8%] Generating /home/corad/uhd/host/build/lib/transport/nirio/lvbi
> tx/x310_lvbitx.cpp
> Scanning dependencies of target uhd
> [  8%] Building CXX object lib/CMakeFiles/uhd.dir/types/device_addr.c
> pp.o
> [  8%] Building CXX object lib/CMakeFiles/uhd.dir/types/mac_addr.cpp.
> o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/metadata.cpp.
> o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/ranges.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/sensors.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/serial.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/sid.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/time_spec.cpp
> .o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/tune.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/types.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/wb_iface.cpp.
> o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/filters.cpp.o
> [ 11%] Building CXX object lib/CMakeFiles/uhd.dir/types/byte_vector.c
> pp.o
> [ 11%] Bui

Re: [USRP-users] twinrx example

2018-12-04 Thread Neel Pandeya via USRP-users 
Hello Koyel:

Which version of UHD are you using?

You can use the "rx_samples_to_file" program in the "examples" folder to
receive on TwinRX.

--Neel Pandeya



On Tue, 4 Dec 2018 at 00:24, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> there is a file called twinrx_freq_hopping.cpp, which is using twinrx.
>
> Best regards,
> Fabian
>
> Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:
> > Hi,
> >
> >
> > I am not finding an example to receive data for twinrx case of USRP
> > x300/310.
> >
> >
> > I am looking at the following link:
> >
> >
> > https://github.com/EttusResearch/uhd/tree/master/host/examples
> >
> >
> >
> > 
> >
> > uhd/host/examples at master · EttusResearch/uhd · GitHub
> > 
> > github.com
> > The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd
> > development by creating an account on GitHub.
> >
> >
> >
> > Can someone please share the link of c++ code for receiving data from
> > twinrx for x300/310?
> >
> >
> > Regards,
> >
> > Koyel
> >
> >
> > ___
> > 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] synchronizing multiple USRP N310

2018-12-04 Thread Florian Kaltenberger via USRP-users 

Hi there,

I just discovered that in addition to the external 10MHz reference in, 
the USRP N310 also has external local oscilator inputs, one for each 
daughterboard and each TX/RX. So does that mean that in order to 
synchronize multiple N310 in frequency, phase, and time, it is no longer 
sufficient to use an octoclock to provide a 10MHz reference and PPS? If 
so, at what frequency do you have to drive the external LOs and at what 
power?


Florian.

--
Follow us on Google+ , 
LinkedIn , or Twitter 
!
<>___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] synchronizing multiple USRP N310

2018-12-04 Thread Robin Coxe via USRP-users 
https://kb.ettus.com/N300/N310#Front_Panel

The AD9371 has a divide-by-2 PLL and the input baluns are optimized for RF 
center frequencies 300 MHz-4 GHz (external LO inputs 600 MHz-8 GHz).  Consult 
the AD9371 user guide on the Analog Devices website for more details on what 
goes on inside the RF integrated transceiver.

Robin Coxe | Chief R&D Program Manager, SDR | Santa Clara, CA | 408.610.6363


From: USRP-users  on behalf of Florian 
Kaltenberger via USRP-users 
Sent: Tuesday, December 4, 2018 7:15 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] synchronizing multiple USRP N310


Hi there,

I just discovered that in addition to the external 10MHz reference in, the USRP 
N310 also has external local oscilator inputs, one for each daughterboard and 
each TX/RX. So does that mean that in order to synchronize multiple N310 in 
frequency, phase, and time, it is no longer sufficient to use an octoclock to 
provide a 10MHz reference and PPS? If so, at what frequency do you have to 
drive the external LOs and at what power?

Florian.

--
Follow us on Google+, 
LinkedIn, or 
Twitter!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310's sample rate

2018-12-04 Thread Jason Matusiak via USRP-users 
I have a X310 with a pair of CBX-130s installed and am running RFNoC.  The 
flowraph looks like this:
 
 
Radio (running at 200MHz) -> DDC (200MHz down to 50MHz) -> splitter ->  off to 
some other blocks.
 
What is weird to me is that I wasn't thinking and I set the sample_rate to to 
be the master_clock_rate (200MHz in this case), but the CBX-120 only has a 
sample-rate of 120MHz.  This process seems to work and my flowgraph is running 
as I expect it should.  There are no warning or errors from UHD when I run this 
saying that I had an incorrect sample_rate.
 
Now, if I leave the master_clock_rate alone, but set the sample_rate to be 
120MHz, the flowgraph barfs immediately and I get timeouts non-stop. 
 
So I am guessing that there is a concept between the 
master_clock_rate/sample_rate, or some combination of them and the DDC that I 
am missing.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] twinrx example

2018-12-04 Thread Koyel Das (Vehere) via USRP-users 
Hi Neel,

I am stuck as usrp 2954 R has gone for repair. As I said earlier I was using 
gnuradio in windows but now I am switching to Ubuntu.

What is the latest stable UHD version?

Do you mean to run rx_samples_to_file in two separate threads? Or how can I use 
that to receive from 2 antennas?

Regards,
Koyel

From: Neel Pandeya 
Sent: Tuesday, December 4, 2018 8:23:44 PM
To: Koyel Das (Vehere)
Cc: usrp-users; fab...@opencode.eu
Subject: Re: [USRP-users] twinrx example

Hello Koyel:

Which version of UHD are you using?

You can use the "rx_samples_to_file" program in the "examples" folder to 
receive on TwinRX.

--Neel Pandeya



On Tue, 4 Dec 2018 at 00:24, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi,

there is a file called twinrx_freq_hopping.cpp, which is using twinrx.

Best regards,
Fabian

Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:
> Hi,
>
>
> I am not finding an example to receive data for twinrx case of USRP
> x300/310.
>
>
> I am looking at the following link:
>
>
> https://github.com/EttusResearch/uhd/tree/master/host/examples
>
>
>
> 
>
> uhd/host/examples at master · EttusResearch/uhd · GitHub
> 
> github.com
> The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd
> development by creating an account on GitHub.
>
>
>
> Can someone please share the link of c++ code for receiving data from
> twinrx for x300/310?
>
>
> Regards,
>
> Koyel
>
>
> ___
> 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's sample rate

2018-12-04 Thread Brian Padalino via USRP-users 
On Tue, Dec 4, 2018 at 10:35 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have a X310 with a pair of CBX-130s installed and am running RFNoC.  The
> flowraph looks like this:
>
>
> Radio (running at 200MHz) -> DDC (200MHz down to 50MHz) -> splitter ->
> off to some other blocks.
>
> What is weird to me is that I wasn't thinking and I set the sample_rate to
> to be the master_clock_rate (200MHz in this case), but the CBX-120 only has
> a sample-rate of 120MHz.  This process seems to work and my flowgraph is
> running as I expect it should.  There are no warning or errors from UHD
> when I run this saying that I had an incorrect sample_rate.
>

The 120 is the analog filter bandwidth of the radio card.  The samplerate
is very limited on the X310 to be either 200MHz or 184.32MHz and must be
set during device initialization, I believe.


>
> Now, if I leave the master_clock_rate alone, but set the sample_rate to be
> 120MHz, the flowgraph barfs immediately and I get timeouts non-stop.
>
> So I am guessing that there is a concept between the
> master_clock_rate/sample_rate, or some combination of them and the DDC that
> I am missing.
>

Need to use integer division to get to 120MHz, and that isn't going to
happen from 200MHz or 184.32MHz.

Take master_clock_rate and divide by positive integers, and that's how you
get valid sample rates.  Moreover, if you want to ensure good passband
behavior, it should be even, and if you want better passband behavior, it
should be divisible by 4.  In the even cases, halfband FIR filters are used
instead of strictly a CIC filter, which has some passband rolloff.

Hopefully this helps.

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

Re: [USRP-users] twinrx example

2018-12-04 Thread Marcus Müller via USRP-users 
Hi Koyel,

if you install Ubuntu 18.10 (which you really should if you want to use
newest versions of software), you'll get UHD 3.12.0.0 as built from
Ubuntu. That should be recent enough for you to use with the TwinRX.
If you use Ubuntu 18.04, you only get UHD 3.10, and that's a bad choice
for this endeavour. So, go directly for Ubuntu 18.10.
You'll then find the example executable/ready to use in
/usr/lib/uhd/examples/twinrx_freq_hopping.

Best regards,
Marcus

On Tue, 2018-12-04 at 15:38 +, Koyel Das (Vehere) via USRP-users
wrote:
> Hi Neel,
> 
> I am stuck as usrp 2954 R has gone for repair. As I said earlier I
> was using gnuradio in windows but now I am switching to Ubuntu. 
> 
> What is the latest stable UHD version?
> 
> Do you mean to run rx_samples_to_file in two separate threads? Or how
> can I use that to receive from 2 antennas?
> 
> Regards,
> Koyel 
> From: Neel Pandeya 
> Sent: Tuesday, December 4, 2018 8:23:44 PM
> To: Koyel Das (Vehere)
> Cc: usrp-users; fab...@opencode.eu
> Subject: Re: [USRP-users] twinrx example
>  
> Hello Koyel:
> 
> Which version of UHD are you using?
> 
> You can use the "rx_samples_to_file" program in the "examples" folder
> to receive on TwinRX.
> 
> --Neel Pandeya
> 
> 
> 
> On Tue, 4 Dec 2018 at 00:24, Fabian Schwartau via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Hi,
> > 
> > there is a file called twinrx_freq_hopping.cpp, which is using
> > twinrx.
> > 
> > Best regards,
> > Fabian
> > 
> > Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:
> > > Hi,
> > > 
> > > 
> > > I am not finding an example to receive data for twinrx case of
> > USRP 
> > > x300/310.
> > > 
> > > 
> > > I am looking at the following link:
> > > 
> > > 
> > > https://github.com/EttusResearch/uhd/tree/master/host/examples
> > > 
> > > 
> > > 
> > > 
> > >   
> > > uhd/host/examples at master · EttusResearch/uhd · GitHub 
> > > 
> > > github.com
> > > The USRP™ Hardware Driver Repository. Contribute to
> > EttusResearch/uhd 
> > > development by creating an account on GitHub.
> > > 
> > > 
> > > 
> > > Can someone please share the link of c++ code for receiving data
> > from 
> > > twinrx for x300/310?
> > > 
> > > 
> > > Regards,
> > > 
> > > Koyel
> > > 
> > > 
> > > ___
> > > 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] twinrx example

2018-12-04 Thread Neel Pandeya via USRP-users 
Hello Koyel:

I agree with Marcus, I would recommend using Ubuntu 18.10 for GNU Radio.

I would suggest using the most recent tagged release of UHD, which is
"v3.13.1.0-rc1", especially if you have TwinRX.

https://github.com/EttusResearch/uhd/tree/v3.13.1.0-rc1

The "rx_samples_to_file" program is single-threaded and only supports
receive on one channel.

https://github.com/EttusResearch/uhd/blob/v3.13.1.0-rc1/host/examples/rx_samples_to_file.cpp

The "rx_multi_samples.cpp" program should allow you to receive on two
channels simultaneously.

https://github.com/EttusResearch/uhd/blob/v3.13.1.0-rc1/host/examples/rx_multi_samples.cpp

--Neel Pandeya



On Tue, 4 Dec 2018 at 08:38, Marcus Müller  wrote:

> Hi Koyel,
>
> if you install Ubuntu 18.10 (which you really should if you want to use
> newest versions of software), you'll get UHD 3.12.0.0 as built from
> Ubuntu. That should be recent enough for you to use with the TwinRX.
> If you use Ubuntu 18.04, you only get UHD 3.10, and that's a bad choice
> for this endeavour. So, go directly for Ubuntu 18.10.
> You'll then find the example executable/ready to use in
> /usr/lib/uhd/examples/twinrx_freq_hopping.
>
> Best regards,
> Marcus
>
> On Tue, 2018-12-04 at 15:38 +, Koyel Das (Vehere) via USRP-users
> wrote:
> > Hi Neel,
> >
> > I am stuck as usrp 2954 R has gone for repair. As I said earlier I
> > was using gnuradio in windows but now I am switching to Ubuntu.
> >
> > What is the latest stable UHD version?
> >
> > Do you mean to run rx_samples_to_file in two separate threads? Or how
> > can I use that to receive from 2 antennas?
> >
> > Regards,
> > Koyel
> > From: Neel Pandeya 
> > Sent: Tuesday, December 4, 2018 8:23:44 PM
> > To: Koyel Das (Vehere)
> > Cc: usrp-users; fab...@opencode.eu
> > Subject: Re: [USRP-users] twinrx example
> >
> > Hello Koyel:
> >
> > Which version of UHD are you using?
> >
> > You can use the "rx_samples_to_file" program in the "examples" folder
> > to receive on TwinRX.
> >
> > --Neel Pandeya
> >
> >
> >
> > On Tue, 4 Dec 2018 at 00:24, Fabian Schwartau via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> > > Hi,
> > >
> > > there is a file called twinrx_freq_hopping.cpp, which is using
> > > twinrx.
> > >
> > > Best regards,
> > > Fabian
> > >
> > > Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:
> > > > Hi,
> > > >
> > > >
> > > > I am not finding an example to receive data for twinrx case of
> > > USRP
> > > > x300/310.
> > > >
> > > >
> > > > I am looking at the following link:
> > > >
> > > >
> > > > https://github.com/EttusResearch/uhd/tree/master/host/examples
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > uhd/host/examples at master · EttusResearch/uhd · GitHub
> > > > 
> > > > github.com
> > > > The USRP™ Hardware Driver Repository. Contribute to
> > > EttusResearch/uhd
> > > > development by creating an account on GitHub.
> > > >
> > > >
> > > >
> > > > Can someone please share the link of c++ code for receiving data
> > > from
> > > > twinrx for x300/310?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Koyel
> > > >
> > > >
> > > > ___
> > > > 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310, basicRX - using all channels in real mode with DDC

2018-12-04 Thread Rob Kossler via USRP-users 
I have not used the Basic Rx before, but my expectation is that the subdev
spec for your use case should be: "A:A A:B B:A B:B".  If that causes an
error, then I don't know what the subdev should be.
Rob

On Mon, Dec 3, 2018 at 11:51 AM Gwenhael Goavec-Merou via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've tried with USRP block instead of RFNoC block (flowgraph attached).
> For subdev spec I have used A:AB A:BA B:AB B:BA because in  other cases uhd
> fails with :
> thread[thread-per-block[0]: ]:
> RuntimeError: On
> node 0/DDC_0, output port 0 is already connected.
>
> For ch1 et ch3 tried A or B without success.
>
> Gwen
>
> Serie of O in console panel and nothing displayed on plot.
>
>
> On Fri, 30 Nov 2018 12:04:06 -0500
> Rob Kossler  wrote:
>
> > I notice that the GRC is using RFNoC blocks.  Perhaps it would be a good
> > test to implement standard UHD USRP blocks.  I think that your
> > functionality is possible with the USRP blocks.
> > Rob
> >
> > On Mon, Nov 19, 2018 at 7:25 AM Gwenhael Goavec-Merou via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> >
> > > Hello,
> > >
> > > No ideas, advice or anything else to solve my problem?
> > >
> > > Thank
> > >
> > > Gwen
> > >
> > > On Tue, 6 Nov 2018 22:34:27 +0100
> > > Gwenhael Goavec-Merou via USRP-users 
> wrote:
> > >
> > > > On Tue, 06 Nov 2018 15:42:10 -0500
> > > > "Marcus D. Leech"  wrote:
> > > >
> > > > > On 11/06/2018 12:23 PM, Gwenhael Goavec-Merou wrote:
> > > > > > On Tue, 06 Nov 2018 12:09:02 -0500
> > > > > > "Marcus D. Leech"  wrote:
> > > > > >
> > > > > >> On 11/06/2018 10:24 AM, Gwenhael Goavec-Merou wrote:
> > > > > >>> On Tue, 06 Nov 2018 09:40:09 -0500
> > > > > >>> "Marcus D. Leech via USRP-users" 
>
> > > wrote:
> > > > > >>>
> > > > >  On 11/06/2018 04:12 AM, Gwenhael Goavec-Merou via USRP-users
> > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > My environment is:
> > > > > > USRP: X310 with basicRX (currently one but 6 in a near
> future)
> > > > > > UHD: 3.13.1.0-rc1
> > > > > > GNURadio: 3.7.13.4-r2
> > > > > > gr-ettus: master branch, up to date
> > > > > >
> > > > > > I need to sample 4 real signal / USRP and to demodulate /
> > > decimate
> > > > > > before transfer to the PC.
> > > > > >
> > > > > > I have created a GNURadio flow with:
> > > > > > - 2 Radio (id 0 and 1), configured with 2 channels
> > > > > > - 2 DDC (id 0 and 1), with 2 channels, with a center
> frequency
> > > fixed
> > > > > > to XX MHz
> > > > > > - 4 complex To Real;
> > > > > > - 1 QT Gui with 4 inputs.
> > > > > >
> > > > > > Each channel of each radio is connected to an DDC input
> (radio0
> > > > > > channel 0 to DDC0 input 0, radio0 channel 1 to DDC0 input
> 1,
> > > etc.)
> > > > > >
> > > > > > With this setup and with an input configured as XX + YY MHz
> (to
> > > have a
> > > > > > beatnote) I'm able to see a sinusoid on the qt for all
> channels
> > > (if I
> > > > > > plug / unplug an input signal the corresponding plot is
> equal to
> > > 0 or
> > > > > > displays the signal).
> > > > > > But:
> > > > > > 1/ the console panel display continuouly messages about
> channels
> > > > > > overrun 2/ the data flow is not continuous (visible in qt
> plot)
> > > (I
> > > > > > suppose is due to 1/ )
> > > > > > 3/ channels are not aligned (I suppose is due to 1/ and/or 2/
> > > > > >
> > > > > > Theorically, by reading HDL files for the X310 firmware
> it's
> > > seems
> > > > > > possible to use this configuration.
> > > > > >
> > > > > > Then, how to fix my issue?
> > > > > > - Is it a USRP/UHD limitation?
> > > > > > - gr-ettus seems not heavily upgraded, is something must be
> > > modified
> > > > > > in this repository?
> > > > > > - I am just wrong somewhere on my design?
> > > > > >
> > > > > > Thank you very much
> > > > > >
> > > > > > Gwen
> > > > > >
> > > > >  What is the sample rate as delivered to the PC?  What kind
> of
> > > PC?
> > > > > >>> The sample rate is 3MS/s for each channels after DDC (200MS/s
> > > before due
> > > > > >>> to the ADC).
> > > > > >>> My PC is a Lenovo thinkpad x230 with a 1Gb ethernet card.
> > > > >  Overrun means that your PC isn't keeping up with the sample
> flow.
> > > > > 
> > > > > >>> I've just done several test with only 2 channels :
> > > > > >>> - 2 radio, 1 channel/radio and 2 DDC with 1 input (first on
> > > radio0, a
> > > > > >>> second radio1) :
> > > > > >>> - data continuous (but not synchronized)
> > > > > >>> - no message on display panel
> > > > > >>> - 2 radio, 1 channel/radio and 1 DDC with 2 input :
> > > > > >>> - console panel displays continuouly "Ooverrun on chan
> 0"
> > > > > >>> - data not continuous
> > > > > >>> - after a short time : freeze
> > > > > >>> - 1 radio with 2 channels and 1 DDC with 2 input :
> > > > > >>>

[USRP-users] DC offset calibration on X310

2018-12-04 Thread Rob Kossler via USRP-users 
Does the X310 have any real-time DC offset calibration?  I am aware of the
separate calibration procedure and resulting CSV file which provides a
lookup for the correction at a given frequency.  But, this is a fixed
correction as opposed to a dynamic one.

I am seeing a large LO leakage signal at the beginning of a capture but
then the level gradually gets canceled as time progresses.  This is
behavior i would expect of the B210 or N310, but not the X310.

So, just wanted to double-check what I should be seeing prior to spending
too much time investigating.

I am using an X310/UBX with custom FPGA image which adds 2 FFT blocks.  I
have my own c++ application linked to UHD master branch and calling
functions out of the RFNoC API to produce a Rx path of
Radio->DDC->FFT->host.

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

Re: [USRP-users] twinrx example

2018-12-04 Thread Rob Kossler via USRP-users 
rx_samples_to_file is generic for many USRPs, but should work for the
specific case of the TwinRx.  Same goes for rx_mult_samples.  There is also
a specific twinrx_freq_hopping example you could look at.

Rob

On Tue, Dec 4, 2018 at 12:30 AM Koyel Das (Vehere) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
> I am not finding an example to receive data for twinrx case of USRP
> x300/310.
>
>
> I am looking at the following link:
>
>
> https://github.com/EttusResearch/uhd/tree/master/host/examples
>
>
>
> 
> uhd/host/examples at master · EttusResearch/uhd · GitHub
> 
> github.com
> The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd
> development by creating an account on GitHub.
>
>
>
> Can someone please share the link of c++ code for receiving data from
> twinrx for x300/310?
>
>
> Regards,
>
> Koyel
>
> ___
> 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] DC offset calibration on X310

2018-12-04 Thread Marcus D. Leech via USRP-users 

On 12/04/2018 12:07 PM, Rob Kossler via USRP-users wrote:
Does the X310 have any real-time DC offset calibration?  I am aware of 
the separate calibration procedure and resulting CSV file which 
provides a lookup for the correction at a given frequency.  But, this 
is a fixed correction as opposed to a dynamic one.


I am seeing a large LO leakage signal at the beginning of a capture 
but then the level gradually gets canceled as time progresses.  This 
is behavior i would expect of the B210 or N310, but not the X310.
DC real-time DC-offset correction has been a part of the "standard" FGPA 
image for most USRPs since the USRP2.   With UHD "Traditional"
  (Non-RFNoC) you can turn it off.   Not sure how you accomplish that 
with RFNoC.





So, just wanted to double-check what I should be seeing prior to 
spending too much time investigating.


I am using an X310/UBX with custom FPGA image which adds 2 FFT 
blocks.  I have my own c++ application linked to UHD master branch and 
calling functions out of the RFNoC API to produce a Rx path of 
Radio->DDC->FFT->host.


Rob


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


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

Re: [USRP-users] synchronizing multiple USRP N310

2018-12-04 Thread Marcus D. Leech via USRP-users 

On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users wrote:


Hi there,

I just discovered that in addition to the external 10MHz reference in, 
the USRP N310 also has external local oscilator inputs, one for each 
daughterboard and each TX/RX. So does that mean that in order to 
synchronize multiple N310 in frequency, phase, and time, it is no 
longer sufficient to use an octoclock to provide a 10MHz reference and 
PPS? If so, at what frequency do you have to drive the external LOs 
and at what power?


Florian.


In addition to what Robin posted, I'll observe that the external LO port 
is an *additional feature* of this device.


You should still be able to use the external 10MHz and 1PPS ports the 
same way you would with a B210 or E310, since the AD9371

  front-end chip is similar to the AD9361 chip used in the B210 and E310.

The thing about synchronizing multiple independent PLL synthesizers, 
though, compared to a strictly-shared-LO, is that the former will
  experience both phase ambiguities, and have a higher mutual 
phase-noise than the latter, which is why you might decide to choose

  the latter.


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

Re: [USRP-users] rfnoc problem with custom DDC inputs.

2018-12-04 Thread Carlos Alberto Ruiz Naranjo via USRP-users 
Hi Brian,

I have finished the DDC block 1:8 and it works perfectly!! :) :)

Now I am in my final step, a 2:16 DDC block:
- Channels 0:7 connected to input 0.
- Channels 8:15 connected to input 1.

The verilog module works, but I have a problem with the UHD driver. I have
timeout on chan 8,9,10...15.
When I use GNURadio Signal Source it runs fine, but when I use rfnoc Radio
block no.

I have tried (device3_io_impl.cpp) :

...
// Update args so args.args is always valid for this particular
channel:
args.args = chan_args[stream_i];
size_t mb_index = block_id.get_device_no();
size_t suggested_block_port = args.args.cast("block_port",
rfnoc::ANY_PORT);
// printf("Puerto: %i\n",suggested_block_port);
// change
// size_t radio_block_port = args.args.cast("radio_port",
rfnoc::ANY_PORT) ;
size_t radio_block_port = 0;

if (stream_i<8){
  radio_block_port = 0;
}
else{
  radio_block_port = 1;
}
...

(( I recognize that I am not an expert on the driver)) :/

Thank you :)











El lun., 3 dic. 2018 a las 17:38, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:

> Ok, I had a problem with *radio_block_port. *I had a signed number... :(
>
> I think now it runs. I will pass to 1:8 DCC and later with 2:16 DDC. I
> continue... :)
>
> El lun., 3 dic. 2018 a las 16:09, Carlos Alberto Ruiz Naranjo (<
> carlosruiznara...@gmail.com>) escribió:
>
>> Hello Brian,
>>
>> thanks for your answer! I have returned today and I am testing your
>> changes.
>>
>> I am using grc and I have the error:
>>
>> *thread[thread-per-block[0]: ]: LookupError:
>> KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
>>
>> I assume the error is in the configuration of uhd::device_addr_t. Can you
>> explain how it works? I have not understood it well, I'm sorry :( :(
>>
>> I am configuring it with grc python block:
>>
>> *self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
>> ",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
>>
>> I have never tried to change the settings.
>>
>> Thank you in advance!!! :)
>>
>> El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
>> escribió:
>>
>>> Hey Carlos,
>>>
>>> The attached patch is what I used applied to 3.13.0.1 I want to say.
>>> You get the idea.
>>>
>>> To get the controller, I use get_block_ctrl(uhd::rfnoc::block_id_t(0,
>>> "NAME", 0)) since there is only one instance, for me, in my radio.
>>>
>>> When setting up the uhd::device_addr_t, I populate: block_port%d,
>>> radio_id%d, and radio_port%d where block_port%d is the output block you're
>>> looking at streaming from.
>>>
>>> Hope this is helpful.
>>>
>>> Good luck.
>>>
>>> Brian
>>>
>>> On Fri, Nov 30, 2018 at 4:34 AM Carlos Alberto Ruiz Naranjo <
>>> carlosruiznara...@gmail.com> wrote:
>>>
 Hello Brian,

 I have finished the FPGA code. I got a DDC 1:2 but I have problems with
 1:8. I think I have your same problems: /

 *thread[thread-per-block[0]: ]: LookupError:
 KeyError: [0/Radio_0] sr_write(): No such port: 2*

 In rfnoc code:





 *std::vector >
 upstream_radio_nodes =
 blk_ctrl->find_upstream_node();
 UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
 upstream_radio_nodes.size();for(const
 boost::shared_ptr &node:  upstream_radio_nodes)
 {node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
 xport.send_sid.get_src(), block_port);}*

 I've found your post (
 http://ettus.80997.x6.nabble.com/USRP-users-Multiple-Output-RFNoC-Block-td9587.html
 ), but I'm stuck on the same point.
 Could you give me any suggestions?

 Thank you!! :)




 El mié., 28 nov. 2018 a las 16:17, Carlos Alberto Ruiz Naranjo (<
 carlosruiznara...@gmail.com>) escribió:

> Ok! Thank you :)
>
> El mié., 28 nov. 2018 a las 16:13, Brian Padalino (<
> bpadal...@gmail.com>) escribió:
>
>> On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com> wrote:
>>
>>> Thank you! I already have enough work to continue :)
>>>
>>> One last thing. In the split_stream module, did you concat tuser
>>> with m_axis_data_tuser with m_axis_data_tdata?
>>>
>>
>> No tuser at that point.  Just the stream part - tdata, tlast, tvalid,
>> and tready.
>>
>>
>>>
>>> I'm curious about you election. Why do you think that version 0 is
>>> better than version 1?
>>>
>>
>> Not really sure.  It is just the way I ended up.  I think either way
>> will work.  Whichever way makes sense to you, try it out!  Have fun! :)
>>
>> Brian
>>
>>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.

Re: [USRP-users] rfnoc problem with custom DDC inputs.

2018-12-04 Thread Brian Padalino via USRP-users 
Hey Carlos,

On Tue, Dec 4, 2018 at 1:16 PM Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com> wrote:

> Hi Brian,
>
> I have finished the DDC block 1:8 and it works perfectly!! :) :)
>

Congratulations!


>
> Now I am in my final step, a 2:16 DDC block:
> - Channels 0:7 connected to input 0.
> - Channels 8:15 connected to input 1.
>
> The verilog module works, but I have a problem with the UHD driver. I have
> timeout on chan 8,9,10...15.
> When I use GNURadio Signal Source it runs fine, but when I use rfnoc Radio
> block no.
>
> I have tried (device3_io_impl.cpp) :
>
> ...
> // Update args so args.args is always valid for this particular
> channel:
> args.args = chan_args[stream_i];
> size_t mb_index = block_id.get_device_no();
> size_t suggested_block_port = args.args.cast("block_port",
> rfnoc::ANY_PORT);
> // printf("Puerto: %i\n",suggested_block_port);
> // change
> // size_t radio_block_port = args.args.cast("radio_port",
> rfnoc::ANY_PORT) ;
> size_t radio_block_port = 0;
>
> if (stream_i<8){
>   radio_block_port = 0;
> }
> else{
>   radio_block_port = 1;
> }
> ...
>
> (( I recognize that I am not an expert on the driver)) :/
>

Unfortunately, you've gone outside my experience and knowledge.  Good luck,
and please keep us posted if you are able to figure out how to get it to
work.  It sounds like a fun and interesting block you're working on.

Brian

PS - Do you plan on open sourcing the block?

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

Re: [USRP-users] synchronizing multiple USRP N310

2018-12-04 Thread Florian Kaltenberger via USRP-users 

Hi Marcus and Robin,

thanks for your answers, this is helpful information. I should add, that 
I actually tried the synchronization with an octoclock (10MHz + PPS), 
but it did not give me the expected results, i.e., I saw some residual 
frequency offsets. But maybe I screwed up at some point. Let me do some 
more measurements and get back to you on this.


Florian.


On 04/12/2018 18:57, Marcus D. Leech via USRP-users wrote:

On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users wrote:


Hi there,

I just discovered that in addition to the external 10MHz reference 
in, the USRP N310 also has external local oscilator inputs, one for 
each daughterboard and each TX/RX. So does that mean that in order to 
synchronize multiple N310 in frequency, phase, and time, it is no 
longer sufficient to use an octoclock to provide a 10MHz reference 
and PPS? If so, at what frequency do you have to drive the external 
LOs and at what power?


Florian.


In addition to what Robin posted, I'll observe that the external LO 
port is an *additional feature* of this device.


You should still be able to use the external 10MHz and 1PPS ports the 
same way you would with a B210 or E310, since the AD9371

  front-end chip is similar to the AD9361 chip used in the B210 and E310.

The thing about synchronizing multiple independent PLL synthesizers, 
though, compared to a strictly-shared-LO, is that the former will
  experience both phase ambiguities, and have a higher mutual 
phase-noise than the latter, which is why you might decide to choose

  the latter.



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

--
Follow us on Google+ , 
LinkedIn , or Twitter 
!
<>___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DC offset calibration on X310

2018-12-04 Thread Rob Kossler via USRP-users 
>
> DC real-time DC-offset correction has been a part of the "standard" FGPA
> image for most USRPs since the USRP2.   With UHD "Traditional"
>   (Non-RFNoC) you can turn it off.   Not sure how you accomplish that with
> RFNoC.
>

Since the X310 uses the external CSV calibration file to set the DC offset,
perhaps this operation of manually setting a value also disables the
automatic correction??  Or, perhaps I am fooling myself into thinking that
the correction typically remains static on this device.  In any case, I was
able to disable the correction in my rfnoc project by setting the
appropriate field in the property_tree.  The following shows the tree entry
assuming mboard=0, radio=0, port=0:

/mboards/0/xbar/Radio_0/rx_fe_corrections/0/dc_offset/enable
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com