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<mailto: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

Reply via email to