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
On 12/12/2017 03:32 PM, Akeem Mufutau via USRP-users wrote:
Hi,
I am implementing openairinterface with usrp b210 and I am getting
UULLUULL responses. I have ASMedia® USB 3.1 controller on my ASUS
x299 motherboard and it seems to be responsible for this response. I
am not very sure of this
Hi,
I am implementing openairinterface with usrp b210 and I am getting UULLUULL
responses. I have ASMedia® USB 3.1 controller on my ASUS x299 motherboard and
it seems to be responsible for this response. I am not very sure of this.
Please does usrp B210 support by ASMedia® USB 3.1 controller
Hi,
I have created a RFNoC block that instantiates a custom FIFO (not one from the
RFNoC library). Everything looks fine in simulation, but when I connect it to
the radio block and run on hardware I get a "Timeout on Ch0". What does this
mean? Is it that my block is not requesting samples from
Hi,
I am trying to change the number of samples per packet (SPP) received at my
RFNoC block. This is trivial within the testbench, but not so obvious in
hardware. I tried using the noc_packet_resizer, but the number of samples per
packet does not correspond to the value set in gnuradio.
My R
> Had a look at if this can be done by catching underrun event and from
> what I can see in how that error is generated and how the message
> triggering it is generated in the firmware code it doesn't seem to be
> a real counter, rather a flag/saturated counter so it won't be good
> enough for my a
Hi,
I'm seeing the same errors on the master branch not using RFNoC.
Probably there is some error in the idle image where the peek is looking
at.
Printing the sts value results in having some other hex value. Until the
idle image is loaded everything is fine though.
Nevertheless this error shou
Hi Mark,
Yes, multiple distinct instances of an rfnoc block can be supported.
In the flowgraph, you need to place a component representing each RFNoC
block you want to attach to-- then set the "block select" parameter to
unique indices. For example, to use two FIFOs, set up with "RFNoC Config"
->
Hi,
Thanks for the reply!
For the moment, if I upgrade to latest version of UHD, my programe does not
work properly(lots of LL). Therefore I could not tell if it helps or not.
The "L" indicator indicates *late* samples--you are setting a send time on your
bursts and by the time the burs
Hi Carry,
This looks like a repeat of an issue from March of this year:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/023950.html
It doesnt look like it measurably impacts E310 performance. I havent tried
recent builds of rfnoc, so I cannot personally confirm if it's fixe
Hi,list,
I complie uhd rfnoc version for e310 follow the link:
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
but when run on e310, I get some error:
[INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-de
12 matches
Mail list logo
