Greetings Jason, I will give that a look. Seems like that is a change in the rfnoc block verilog and not the Python, so I can handle that if I find it.
I am currently in 3.14.1.0 because that is the os version I am running. If I try 3.15 it errors out on the E312 bc the SD card image is missing necessary installed files. I have yet to venture into docker to try and build my own image. Do you know if this is corrected in the 3.14.1.1 release? Regards, Jon Lockhart On Fri, Nov 1, 2019, 2:11 PM Jason Matusiak <ja...@gardettoengineering.com> wrote: > 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-boun...@lists.ettus.com> on behalf of > Jonathan Lockhart via USRP-users <usrp-users@lists.ettus.com> > *Sent:* Thursday, October 31, 2019 3:30 PM > *To:* USRP-users@lists.ettus.com <usrp-users@lists.ettus.com>; > supp...@ettus.com <supp...@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 <jlockhar...@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 > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
