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.
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 se
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?
Thanks!
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 fo
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
B
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 sug
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:
>https://files.ettus.com/manual/page_usrp_n3xx.htm
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
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 q
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
axi_rate_c
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 s
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 to
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 doe
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 via
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: IOEr
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 standa
16 matches
Mail list logo