Hi Ivan,
Try building with the gr-ettus maint-3.7 branch.
Jonathon
On Wed, Nov 18, 2020 at 1:08 PM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> Hello I am trying to install RFNoC for uhd 3.15. As far as I understand,
> this version supports RFNoC. And in order for me
On Wed, 2020-11-18 at 19:12 -0600, Wade Fife wrote:
> Dustin,
>
> It sounds like the software thinks the control port FIFO is filling
> up. Are you issuing a lot of timed commands, maybe far into the
> future? I wonder if issuing commands faster than they are being
> executed could cause the FIFO
Dustin,
It sounds like the software thinks the control port FIFO is filling up. Are
you issuing a lot of timed commands, maybe far into the future? I wonder if
issuing commands faster than they are being executed could cause the FIFO
on the FPGA to fill up with commands.
You could try increasing
On 11/18/2020 07:34 PM, Dustin Widmann wrote:
On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-users
wrote:
Marcus,
Oh, sorry, I missed the first bit. I'm using the on-board clock. And
perhaps I should explain the table with a little bit more detail:
* 1st col: The *target* frequen
On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-users
wrote:
> On 11/18/2020 05:32 PM, Dustin Widmann via USRP-users wrote:
> > Hi usrp-users,
> >
> > I've noticed something strange with an experiment I've been doing.
> > The
> > experiment is set up like a reflectometer. I'm using an
On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-users
wrote:
> On 11/18/2020 05:32 PM, Dustin Widmann via USRP-users wrote:
> > Hi usrp-users,
> >
> > I've noticed something strange with an experiment I've been doing.
> > The
> > experiment is set up like a reflectometer. I'm using an
On 11/18/2020 05:32 PM, Dustin Widmann via USRP-users wrote:
Hi usrp-users,
I've noticed something strange with an experiment I've been doing. The
experiment is set up like a reflectometer. I'm using an X310 with a
UBX-160 for transmit and both channels of a TwinRX for receive. In
short, I put u
Hi usrp-users,
I've noticed something strange with an experiment I've been doing. The
experiment is set up like a reflectometer. I'm using an X310 with a
UBX-160 for transmit and both channels of a TwinRX for receive. In
short, I put up a tone with the transmitter by applying a DC offset,
tune to
Thanks Wade,
I added this line to the switchboard.yml file in the install share folder
and then re-built and it seems to have worked fine.
Rob
On Wed, Nov 18, 2020 at 2:59 PM Wade Fife wrote:
> Rob,
>
> The -I option is meant for out-of-tree blocks, which are supposed to
> follow the same struct
On 11/18/2020 07:27 AM, Josh via USRP-users wrote:
I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api:
Setup:
B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync
Receive only flowgraph
With gr-uhd, there is always a "OOD" when the flowgraph first starts
But, if I
Rob,
The -I option is meant for out-of-tree blocks, which are supposed to follow
the same structure as the example. The switchboard.yml file is missing a
line that indicates where its makefile.srcs is:
makefile_srcs:
"${fpga_lib_dir}/blocks/rfnoc_block_switchboard/Makefile.srcs"
See one of the
Hi,
I'm wondering what is the intended procedure for building an FPGA image
using non-default Ettus RFNoC blocks in RFNoC 4.0. I am referring to using
Ettus-developed blocks other than Radio, DDC, DUC, and Replay which by
default are included (see Makefile.n3xx.inc which mentions that only these
d
Hello I am trying to install RFNoC for uhd 3.15. As far as I understand,
this version supports RFNoC. And in order for me to have blocks in
gnuradio, as I understand it, I need to install gr-ettus. But when
installing, I get this error The found UHD version (3.15.0.0-3build2) is
not compatible with
Hi usrp-users,
terminate called after throwing an instance of 'uhd::op_timeout'
what(): RfnocError: OpTimeout: Control operation timed out waiting
for space in command buffer
I've been getting the error above occasionally, usually after hours of
operation. I've got a few questions about it:
*
On Thu, 2020-11-12 at 13:25 -0500, Marcus D. Leech wrote:
> On 11/11/2020 11:11 PM, Dustin Widmann wrote:
> > Hi Marcus
> >
> > I've given this a try, unfortunately I'm running into a problem
> > with
> > that. I've always gotten strange crashes with UHD 3.15 with this
> > codebase (probably my fa
Ivan,
to the best of my knowledge, there should not be any RX1 port.
Instead, you should have two (coherent) channels "A" and "B" both
allowing you to select one out of two available antenna ports when
receiving ("TX/RX" or "RX2").
Cheers,
Julian
On 11/18/20 10:31 AM, Ivan Zahartchuk via USR
Hi,
In case anyone finds this unresolved entry, I think I found the error I was
making, it probably had to do with thread handling. I would recommend
always creating a thread group (boost::thread_group tg), and then calling
two separate threads, one for RX
(tg.create_thread(boost::bind(&receive_th
I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api:
Setup:
B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync
Receive only flowgraph
With gr-uhd, there is always a "OOD" when the flowgraph first starts
But, if I replicate the setup in a simple compiled program usin
Another question of interest is which channels are coherent? Rx1 and RX2 or
RX1 and RX / TX?
вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice :
> Right!
> Be careful, DOA estimation using only 2 antennas works but it’s not so
> accurate.
> Enjoy!
>
> Ivan
>
> > Il giorno 17 nov 2020, alle ore 00:35, Iva
19 matches
Mail list logo
