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
>

Attachment: rfnoc_fosphor_radio_network_host.grc
Description: Binary data

Attachment: rfnoc_fosphor_radio_network_usrp.grc
Description: Binary data

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to