[USRP-users] RFNoC Radio Issue

Jason Matusiak jason at gardettoengineering.com
Fri Nov 1 14:11:34 EDT 2019


Jonathon, If you look at the more recent commits for UHD, they added in a fix to the split_stream error.  Basically you need to change a 1'b1 to a 2'b11 in the noc_shell section (I think that is the section, I can't recall off the top of my head).  Try that and rebuild.

________________________________
From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of Jonathan Lockhart via USRP-users <usrp-users at lists.ettus.com>
Sent: Thursday, October 31, 2019 3:30 PM
To: USRP-users at lists.ettus.com <usrp-users at lists.ettus.com>; support at ettus.com <support at ettus.com>
Subject: Re: [USRP-users] RFNoC Radio Issue

Apologies, the files are attached.

On Thu, Oct 31, 2019 at 3:30 PM Jonathan Lockhart <jlockhartrt at gmail.com<mailto:jlockhartrt at gmail.com>> wrote:
Greetings,

I was wondering if anyone else has had this issue with the RFNoC radio block.

So I was using the copy block with the rfnoc_fosphor_network_usrp.grc file as I wanted to split off the signal before it went off to the RFNoC Window. So I put in a copy block (since the RFNoC Split block appears to be broken) and passed the data off to a ZMQ Push and back to the window to continue to be processed by the FPGA. GNURadio says this is all well and good since all vectors are 512 and builds the file. However, when I run the .py file on my E312 it throws an error stating that the radio is providing data of size 8 when the copy block expects to get data of size 512 (the vector size).

[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; UHD_3.14.1.HEAD-0-gbfb9c1c7
[INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Detecting internal GPS
.... [INFO] [E300] GPSDO found
[INFO] [E300] Initializing core control (global registers)...

[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000000)
[WARNING] [RFNOC] Can't find a block controller for key FFT, using default block controller!
[INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70000000000000)
[INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053000000000000)
[WARNING] [RFNOC] Can't find a block controller for key fosphor, using default block controller!
[INFO] [0/fosphor_0] Initializing block control (NOC ID: 0x666F000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
Traceback (most recent call last):
  File "rfnoc_fosphor_network_usrp.py", line 282, in <module>
    main()
  File "rfnoc_fosphor_network_usrp.py", line 271, in main
    tb = top_block_cls(fft_size=options.fft_size, fpga_path=options.fpga_path, freq=options.freq, gain=options.gain, host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate, tdecay=options.tdecay, trise=options.trise)
  File "rfnoc_fosphor_network_usrp.py", line 166, in __init__
    self.connect((self.uhd_rfnoc_streamer_radio_0, 0), (self.blocks_copy_0, 0))
  File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 47, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 110, in connect
    self.primitive_connect(*args)
  File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 3482, in primitive_connect
    return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: itemsize mismatch: rfnoc_radio0:0 using 8, copy0:0 using 4096

I have attached my modified examples for anyone who is interested. I have tried to modify the python and that just gets me into more trouble.

Through my tracing of the files it appears that the RFNoC Radio block in the .py file never actually uses the vector size, and that the force vector length block is an additive to allow compliance when working in GNURadio, as it will not generate python with mismatched types and sizes. Trying to force the radio to take the 512 as an argument in the python throws a new error that the Radio is only allowed to have 5 arguments and I have supplied 6, and validated in the Ettus .py file that there is no arg for vector size.

I was wondering if anyone found away around this or got the RFNoC Split block working?

Regards,
Jon Lockhart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191101/0a21d5f3/attachment.html>


More information about the USRP-users mailing list