I seem to recall that the 8-bit OTW format isn't implemented for RFNoC
yet... I could use that too.
On Mon, Mar 19, 2018 at 9:07 PM Adam Parower via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello everyone,
>
>
> I am trying to figure out how to receive complex 8-bit integer samples
> fro
Hi Michael,
Here is the public repo with the custom block source code:
https://st...@code.oceanit.com/stran/gr-per.git . The block is called Ansect
Per ('Ansect' is the name of my own project I am using it for and 'per' stands
for packet error rate). The source code is under /lib/ansect_per_i
Hi Nate,
Now after I did those changes it looks much better. However, seems still there
is kind of mirrored spectrum on fosphor plot.
I just did simple test with transmitting signal from Zigbee sensor device.
Seems signal is mirrored on plot. I will check more tomorrow,
and will let you know.
T
Hello everyone,
I am trying to figure out how to receive complex 8-bit integer samples from a
USRP containing a custom RFNoC flowgraph. If I didn't require RFNoC and could
use the legacy UHD C++ API instead, this would be trivial; I would simply set
both the host format and on-the-wire format
Hi Tarik,
If you press "F6" instead of the "Run" button, it will bypass this warning
and run the flowgraph.
Regards,
Nate Temple
On Mon, Mar 19, 2018 at 8:59 AM, Tarik Kazaz via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi All,
>
>
> I am using USRP X310 with UBX-160MHz. I tried to run
Hi All,
I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo,
however I am getting errors related to connection of RFNoC:Radio to RFNoC: DDC
and to RFNoC:Window (Source IO size "8" does not match sink IO size "8192"). I
found this discussion on mailing list (from 2016)
https
Hi All,
I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo,
however I am getting errors related to connection of RFNoC:Radio to RFNoC: DDC
and to RFNoC:Window (Source IO size "8" does not match sink IO size "8192"). I
found this discussion on mailing list (from 2016)
http
On 03/19/2018 05:30 AM, Mark Luscombe via USRP-users wrote:
Hi,
The USRP E320 was announced in September 2017, does anybody know when
it will be supported for RFNoC development.
Cheers, Mark.
The E320 hasn't even been released yet, so any predictions about which
versions of RFNoC it will
Hi,
I am building an OFDM receiver on X310 using RFNoC. When I run the
rfnoc_ofdm.grc example in the gr-ettus examples, I met the "timeout on chan
0" failure once I enable the RFNoC: OFDM Sync block. The other blocks seems
to be fine, say the FIFO and FFT block, but if enable the Sync block, the
f
Hi all,
Related to old questions I have previously asked in this mail list, I
think I have found two possible bugs (or at least I think so) inside the
UHD code. (IMPORTANT) Following explanations were proved using the uhd
example tx_waveforms.cpp and an ettus B210.
./tx_waveforms --rate 6144
Hi,
The USRP E320 was announced in September 2017, does anybody know when it
will be supported for RFNoC development.
Cheers, Mark.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
EJ Kreinar wrote:
You can find the "timeout on chan 0" message implemented in
gr-ettus/lib/rfnoc_block_impl.cc. As you suspected (correctly), it is a harmless output that
can be ignored if no data is actually coming from your RFNoC block. It is driven by
receiving a timeout from the streamer->
12 matches
Mail list logo
