https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
Sent from my iPhone
> On Jan 13, 2021, at 11:51 AM, Ephraim Moges via USRP-users
> wrote:
>
>
> Good morning,
>
> Is their a simple command like tx_streamer.get_max_num_samps that sets the
> maximum number samples per packet
Hi Wade,
On 13/01/21 10:00, Wade Fife wrote:
> On Wed, Jan 13, 2021 at 4:58 AM Cédric Hannotier via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Is there a way to reconcile both modes (cli & GUI) without editing
> > my testbench every time I need to switch between these two modes?
>
> You
Good morning,
Is their a simple command like tx_streamer.get_max_num_samps that sets the
maximum number samples per packet?
Thank you,
Moges
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists
Wade,
It is very possible that the FPGA side is doing exactly what you are saying
and keeping the packet size intact as it goes over the wire. The only
reason I mentioned SEP in my previous email was that I wasn't sure one way
or another. But, the UHD side of things could clearly manipulate packe
I don't think the streamer changes the packet size. I believe what the
block sends is what goes out on the wire (plus network headers). I wonder
if the size is not being set correctly by the block, or maybe the way
you're checking the length isn't looking at the actual packet size? That's
why I sug
Hi Cédric,
You can probably just call $finish() instead of test.end_tb() to stop the
simulation in both CLI and GUI modes. If you want the summary at the end,
take a look at what end_tb() does in PkgTestExec.sv. Also, note that the
test object isn't required. You can remove all the test calls from
Hi Wade,
Right. The block controls the packet size. But, I am attempting to verify
that my block is actually behaving properly with respect to this packet
length. In order to test this, I created a graph "host => myblock => host"
and I am looking at the packet sizes I receive on the host. However
The block ultimately determines the size of the packets that are sent out.
Some block controllers (like the radio) use the spp argument to set the
length that the block generates. I don't know what's going on in your case,
but I would suggest looking at how the packet length is being controlled by
I haven't :( I have been looking at packaged testing for volk and
gnuradio. Once I have this sorted, I'll spend a little time looking into
setting this up for fftw to try and catch this problem faster in the future.
Philip
On 1/9/21 3:29 PM, Ben Magistro via USRP-users wrote:
> Finally getting a
On 01/13/2021 01:08 AM, Koyel Das (Vehere) via USRP-users wrote:
Hi,
The USRP sample rate and bandwidth are two different parameters in
gnuradio so if I want 20 MHz bandwidth and 100 MSps sample rate then
will setting bandwidth = 20 MHz and sample rate = 100 MHz serve my
purpose? Normally sam
On 12/01/21 13:42, Jonathon Pendlum via USRP-users wrote:
> Hi Cedric,
Hi Jonathon,
> "Fatal: The connected block has an incompatible backend interface".
>
>
> Try adding a short delay, such as #1 or @posedge( at the start of the
> testbench to get past this.
Thanks for the workaround, it work
Hello Koyel:
Yes, BUT please be warned that most USRP daughterboards have fixed filter
bandwidth, and they may simply ignore the bandwidth parameter (without
notifications).
Regards,
Kyeong Su Shin
보낸 사람: Koyel Das (Vehere) via USRP-users 대신
USRP-users
보낸 날짜:
12 matches
Mail list logo
