[USRP-users] RFNoC Radio Issue
jlockhartrt at gmail.com
Fri Nov 1 14:38:13 EDT 2019
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 126.96.36.199 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 188.8.131.52 release?
On Fri, Nov 1, 2019, 2:11 PM Jason Matusiak <jason at gardettoengineering.com>
> 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>
> I was wondering if anyone else has had this issue with the RFNoC radio
> 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;
> [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:
> [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>
> 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))
> line 47, in wrapped
> func(self, src, src_port, dst, dst_port)
> line 110, in connect
> 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?
> Jon Lockhart
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users