If the lights are on, the device is streaming, guaranteed. At this point,
make sure your frequencies, gains, and antenna selections are correct.
Nick
On Fri, Mar 9, 2018 at 11:19 AM Kei Nguyen
wrote:
> Sorry I mean the lights were on when I closed the program.
> Thanks Sam for the suggestion I
The lights are on because the device isn't instructed to stop streaming on
program stop, and it will continue loopback operation after the host has
closed the program. You can manually issue a stream command to stop the
stream before program stop if you want to change this behavior.
Kei, why would
Are you using a custom FPGA image? What happens if you just omit the DMA
FIFO?
Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
is a good start.
Nick
On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen
wrote:
> Thanks for the reply and sorry for not providing much information.
ideas as to what could be causing this please help! The
> phase stability of the E312 is amazing within the same fpga image cycle but
> these relatively large jumps after reload/ power cycle are a deal breaker
> for some applications!
>
> Thanks
>
> Sam
>
>
You're going to have to ask a better question than that. Please provide the
following:
* What you are trying to accomplish
* What hardware you are using
* What UHD and Gnuradio version you are using
* The approach you followed
* The result you expected
* The result you actually got
* A flowgraph w
Sam,
Sorry I haven't gotten back -- it sounds like you're doing everything
right. The usual quick fixes probably don't apply here. I haven't had time
to look more in depth into it, or to try to replicate it on my own hardware.
Marcus is right -- the E3xx uses an idle image in order to reduce powe
Could you post your flowgraph or UHD program, or the relevant excerpts? Are
the two RX channels being loaded simultaneously? Are you using timed
commands to start the RX and TX streams?
Nick
On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users <
usrp-users@lists.ettus.com> wrote
Oh! That makes complete sense. The dreaded fill-frame dilemma.
Stop me if this is nuts, but... I wonder if, instead of using AXI
backpressure to stop fill frame creation, you could set up a short custom
FIFO just upstream of the TX radio and pull an "almost empty" watermark out
of it. The custom F
EJ,
Reducing the stream sink FIFO size won't really help here unless I'm
misunderstanding something. You need to send shorter packets, yes, but
changing the stream sink FIFO size won't change that. The FIFO doesn't have
to be full before it passes your packet along. That said, I don't think
I've h
Very glad to hear it! Could you tell me what UHD version (git hash) you're
using? I'd like to know for my own reference.
Nick
On Fri, Feb 23, 2018 at 2:57 PM Adam Kurisko wrote:
> Nick,
>
>
> I actually ended up figuring it out. I had forgotten to actually connect
> my blocks using the 'graph->
Please post your whole example.
On Fri, Feb 23, 2018, 1:35 PM Adam Kurisko wrote:
> Ok I run it and I still don't get the LEDs on the frontend to light up. Is
> this normal or is something wrong?
>
>
> Thanks,
>
> Adam
> --
> *From:* Nick Foster
> *Sent:* Friday, Feb
You don't need to do anything at all. Just loop. Maybe sleep so you don't
soak up a whole CPU.
Nick
On Fri, Feb 23, 2018, 1:10 PM Adam Kurisko wrote:
> Hey Nick,
>
> Below is the code I am using to setup my streamers and issue the stream
> cmd. I know it would exit immediately when run, but I j
That should work.
On Fri, Feb 23, 2018 at 11:45 AM Adam Kurisko wrote:
> Nick,
>
>
> I went back through the loopback tricks you sent and found that my
> at_reset parameter on the SR_RX_CTRL_OUTPUT_FORMAT settings register had
> not been switched to 0, so I have corrected that. and timestamping
Have you verified timestamps are disabled? And have you issued a stream
command to the RX as well as set_rx_streamer()? To be clear, I haven't
tried E310 loopback with any UHD version later than the date of the article
(4/22/17), but I don't believe significant changes have happened which
would aff
1. yes
2. RFNoC
I refer back to a post I wrote detailing loopback in the FPGA. It doesn't
work "out of the box" but can be made to with minor modification.
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
If you haven't used RFNoC before you should probably take on the Getting
Started
What block are you testing? Most of the blocks I've developed are
deterministic in execution time; I can think of only a few applications
which wouldn't be. A little thought and simulation enables good design to
avoid stalls in a deterministic block with multiple data paths. If you
aren't stalling
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ should help.
RFNoC does not support loopback "out of the box".
Nick
On Fri, Feb 2, 2018 at 12:18 PM Pratik Chatterjee via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> This question was posted two years ago (reference link be
I haven't tried loopback since that version was introduced. Can you remind
me if your application was for E300 or X300?
Nick
On Tue, Jan 16, 2018, 1:56 AM Daniel Rauschen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
> I recently upgraded from *UHD_4.0.0.rfnoc-devel-369-g190867
The RFNoC bus can't sustain full-rate input (or output) to/from a single
block on more than 1 port. The addsub block has two inputs and two outputs,
so you can't operate the addsub block at 200Msps.
Nick
On Mon, Jan 8, 2018 at 1:02 PM Adam Parower via USRP-users <
usrp-users@lists.ettus.com> wrot
The best way to get started is to look at the existing RFNoC block
testbenches. There are enough that cover enough different configurations
that you should be able to piece a testbench together fairly quickly.
They're in the _tb subfolders of the RFNoC block library.
Nick
On Tue, Jan 2, 2018 at 3
On a side note, this is a good time to mention that learning to simulate
RFNoC blocks with the excellent and comprehensive testbench framework
Jonathon put together is the single most effective way to write better
RFNoC blocks, faster. This kind of error would be caught almost instantly
in simulati
You're assigning to o_tready and o_tdata instead of s_axis_data_tready and
s_axis_data_tdata.
Incidentally, you're also not setting the "len" input to anything in the
top-level instantiation.
Nick
On Tue, Jan 2, 2018 at 3:22 PM Adam Kurisko wrote:
> Okay, I am now using ce_clk in place of clk
ce_clk is there for you to use as your compute engine clock. If you don't
have a very good reason to generate and use another clock, you should use
that one.
Nick
On Tue, Jan 2, 2018 at 2:57 PM Adam Kurisko wrote:
> I actually found that too and reverted it back to the the original
> bus_clk/rs
Why have you commented out bus_clk/rst and ce_clk/rst in favor of using
clk/reset? And where are clk/reset/clear being generated? What is being
used as bus_clk/rst in your block's noc_shell?
Nick
On Tue, Jan 2, 2018 at 12:54 PM Adam Kurisko wrote:
> Nick,
>
>
> Haven't heard back from you yet a
Yeah, ok. It's that multiple driver that's the problem. Can you post the
rfnoc_ce_auto_inst.v you're using?
Nick
On Tue, Jan 2, 2018, 10:58 AM Adam Kurisko wrote:
> Nick,
>
>
> I just attempted to generate a bitstream and it failed with the following
> errors.
>
>
> Most messages are the same a
That all looks ok to me. Does it successfully generate a bitstream?
There will virtually always be warnings, even some "critical" ones, in any
sufficiently complex FPGA project.
Nick
On Tue, Jan 2, 2018, 9:26 AM Adam Kurisko wrote:
> Hi Nick,
>
>
> Thank you for your fast response.
>
>
> I am
The use of Gnuradio will not affect the FPGA design at all. If you supply
the errors you're seeing we might be able to help further.
Nick
On Tue, Jan 2, 2018 at 8:57 AM Adam Kurisko via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello all,
>
>
> I am trying to design an RFNoC block using
You have neglected to also modify gr-ettus to add these to the API.
Nick
On Fri, Dec 15, 2017 at 11:18 AM John Medrano
wrote:
> Thank you for the code.
>
> I have an E310 and we are using latest version of RFNOC Development and
> these functions return an error:
>
>
> stream_cmd=uhd.stream_cmd_
Thanks. At first blush this looks like it should work to me. I'll try it
out here.
Nick
On Thu, Dec 14, 2017 at 11:37 AM Jack Ziegler wrote:
> *Trying to do loopback with a rfnoc rx radio connect to a rfnoc tx radio.
> (running at 56e6 Msps with the E310/E312). This is with no host connection
Max packet size will be limited by your Ethernet MTU. Default MTU is 1500,
which corresponds to 1456 bytes plus overhead. 1456/4 = 364. If you want
longer packets:
# ip link set mtu 8000
Nick
On Thu, Dec 14, 2017 at 11:18 AM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:
Change the radio block packet size with the "spp=xxx" option in the RFNoC
Radio block arguments.
Nick
On Tue, Dec 12, 2017 at 12:14 PM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
>
> I am trying to change the number of samples per packet (SPP) received at
> my RF
It means only that samples are not streaming back to the host. This could
be for any number of reasons and requires more debug. Get Chipscope
instantiated in the design and start debugging from there.
Nick
On Tue, Dec 12, 2017 at 12:23 PM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.c
You need to help us before we can help you. Can you tell me:
* What you're actually trying to do
* Your hardware setup
* Your UHD version
* Your flowgraph
* The results you expect
* The results you actually observe
Then maybe we can help.
Nick
On Thu, Nov 30, 2017 at 4:44 PM Jack Ziegler wrote
It should still apply. Is there something specific you're having trouble
with?
On Wed, Nov 29, 2017, 10:06 PM Jack Ziegler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Has anyone recently tried rfnoc loopback?
> I tried following these directions:
> https://corvid.io/2017/04/22/stupid-rf
There is nothing you can do with a USRP to expose you to harmful levels of
RF energy. You would need to add an amplifier.
On Fri, Nov 10, 2017 at 11:04 AM Arjun Bakshi
wrote:
> Wanted to further clarify something. Do you mean that a usrp will in most
> cases stay below acceptable levels, or that
Don't worry about it. You are several orders of magnitude below any sort of
permissible exposure limit.
Nick
On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I'm looking to do long duration experiments in a lab which will have
> people in it whi
Piotr,
This is especially baffling to me, because I recall that the SKY13335-187LF
switches used in B210 must be isolated from DC on all RF ports. But they
are! The only components connected to the SMA connectors are a series 470pF
capacitor.
Perhaps the problem is exacerbated by poor impedance m
Jon,
This isn't specific enough to offer a reasonable answer, and might not even
be a reasonable question. The binary representations for different control
parameters are different for each parameter and are what the drivers
(daughterboard, motherboard, transport) are intended to handle for you.
Yes. You can change the rate however you like. Not sure where you'd get the
suggestion of an intrinsic integer limitation. If you're using axi_wrapper
in simple mode you'll just be responsible for handling the AXI stream and
setting the tlast signal to delimit packets at reasonable lengths. If
you'
Yeah, I agree with that assessment. I don't know what the problem is,
either. For reference, though, here's the relevant parts of a
two-input-one-output RFNoC block I did. This works for me.
Note that NUM_PORTS can be anything you want. I'm currently using
NUM_PORTS=2. NUM_CHANNELS is 4, since I'm
Dario,
Glad simulation appears to be working.
Since you aren't using simple mode in the AXI wrapper (I assume because
you're rate-changing inside the block, or some such) can you post the
section of your code which handles the VITA headers?
Nick
On Tue, Sep 26, 2017 at 5:15 AM Dario Pennisi wr
Couple of problems just offhand.
* src_sid is a one-per-input signal. See noc_shell.v for details.
* Settings buses and readback buses are one-per (max(input, output)).
Again, see noc_shell.v. I don't think this is a problem for you, though.
You should be getting errors in simulation (or warnings
Dario,
Can you post your RFNoC block Verilog code?
Nick
On Mon, Sep 25, 2017 at 11:38 AM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> We are developing a block which needs two inputs from the two radios. The
> block works with one input but when adding the second
Hi Ruben,
Regarding why the "copy" block is necessary, please see the following post:
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
Specifically, the "Addendum" section at the bottom. The E310 needs to have
the TX streamer enabled explicitly if the application doesn't include a
strea
I made one for a project, but can't share it as it's customer work. It's a
little bit tricky and I never got it 100% right, but it works well enough
for what it needs to do. The tricky parts are preserving or reconstituting
packet boundaries, and being able to advance and delay the stream without
b
There's no direct path between the FPGA and the PS-side Ethernet controller
which would support this mode of operation. You have to go through the host
at some point.
--n
On Fri, Jul 7, 2017 at 10:16 AM Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello –
>
>
>
> Fo
101 - 146 of 146 matches
Mail list logo
