Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Jon Pendlum via USRP-users
Hi Andrew, Have you tried using Chipscope to see where the issue is at in your code? You want to look at the tvalid and tready AXI stream control signals to pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once you know where the stall is located, I can provide more advice.

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread EJ Kreinar via USRP-users
Some more thoughts... Are you programming the axi_rate_change SR_N, SR_M, and SR_CONFIG registers when you run on hardware? You might be able to do this with the XML definition, but you may also need a block controller like the ddc_block_ctrl_impl in uhd. Don't forgot the config register-- this

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Andrew Danowitz via USRP-users
Thanks for the reply. I do set simple_mode and I propagate tuser into and out of axi_rate_change the same way noc_block_ddc does. I also have my block running properly in Vivado simulation. Is there anything else I should check? I also included axi_tag_time. Could that be causing an issue?

Re: [USRP-users] X310 xpr Files

2018-12-18 Thread Nick Foster via USRP-users
You can do "make GUI=1 X310_HG" to open the Vivado GUI and build the project. Nick On Tue, Dec 18, 2018 at 1:33 PM Alexander Olihovik via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > Will running "make X310_HG" generate a .xpr file that I can open with > Vivado? I have a .xpr

[USRP-users] X310 xpr Files

2018-12-18 Thread Alexander Olihovik via USRP-users
Hi all, Will running "make X310_HG" generate a .xpr file that I can open with Vivado? I have a .xpr for the E310 from a previous effort so I think it can be done, but I wasn't the originator of this file. I was following this guide: http://files.ettus.com/manual/md_usrp3_build_instructions.html

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Marcus D. Leech via USRP-users
On 12/18/2018 05:07 AM, Arun kumar Verma wrote: Dear Marcus I found the real problem and problem is that when i use set_command_time in loop then only problem exist, if do not use this my loop is getting executed properly. But for phase synchronization i have to use set_command_time Any

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Philip Balister via USRP-users
Do you really need to install uhd on a machine to install an sdk on it? Philip On December 18, 2018 11:19:38 AM EST, Jason Matusiak via USRP-users wrote: >I got it by running: uhd_images_downloader -t sdk -t n3xx > >based on instructions here:

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread EJ Kreinar via USRP-users
Hi Andrew, Quick thoughts: - Are you setting SIMPLE_MODE(0) in the axi_wrapper? - Are you propagating tuser into and out of the axi_rate_change block? The axi_rate_change block updates tuser, which the axi_wrapper uses to create output packets when SIMPLE_MODE is disabled. Also, have you run in

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread EJ Kreinar via USRP-users
If I recall correctly the only place QT is used would be in the RFNoC Fosphor host code to display the fosphor output. This typically runs on a PC, not an embedded device like E310 or N310. Unless you really need to use QT on the N310, definitely the easiest solution here would be to just disable

[USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Andrew Danowitz via USRP-users
Hi all, I'm trying to create an rfnoc block that takes in a stream of data at Sample rate n, does some processing to turn i-q values into real samples, and outputs data at a rate of n/2 by packing real values into both i and q channels of the output stream. I've tried to incorporate the

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Jason Matusiak via USRP-users
I got it by running: uhd_images_downloader -t sdk -t n3xx based on instructions here: https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk It does not appear to have gnuradio installed OK, gnuradio seems to build fine for cross-compile, it is when I get to the gr-ettus

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Philip Balister via USRP-users
On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote: > It looks like qt4 was not included in the cross-compile build. If I look at > my working e300 cross-compile, I have a folder: > /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/ > > (in fact, there is a

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Jason Matusiak via USRP-users
It looks like qt4 was not included in the cross-compile build. If I look at my working e300 cross-compile, I have a folder: /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/ (in fact, there is a tone of stuff in that include). If I look in the N310 directory, it

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Arun kumar Verma via USRP-users
Dear Marcus I  found the real problem and problem is that when i use set_command_time in loop then only problem exist, if do not use this my loop is getting executed properly. But for phase synchronization i have to use set_command_timeAny suggestion? Arun Verma From: Arun kumar Verma

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Arun kumar Verma via USRP-users
Dear Marcus The problem is solved by setting RF policy manual for RF and DSP both and passing uhd::tune_request_t  object as parameter to set_center_freq function, but now i getting one more issues that after 35-40 iteration my application is getting assertion because of  "EnvironmentError:

Re: [USRP-users] Hello,

2018-12-18 Thread Pablo González Fernández via USRP-users
Thanks Ian! El vie., 14 dic. 2018 a las 17:25, Ian Buckley () escribió: > N310 has a different ADI radio chip and since I did not work on the design > I don’t want to give you misleading advice on that one. > N210 is different, as it uses the standard Ettus interchangeable daughter > board