Hi Ruben, Regarding why the "copy" block is necessary, please see the following post: https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
Specifically, the "Addendum" section at the bottom. The E310 needs to have the TX streamer enabled explicitly if the application doesn't include a stream to the host. This means you must modify the Python generated from gnuradio-companion before it will work. Regarding the RFNoC file format, you're free to use whatever internal data representation you want. But when you're interfacing with other blocks, or with the host, the assumption is that your data is Q15, as you said. If it's not, you'll be responsible for translating it in a way that can be understood by the rest of the system. --n On Fri, Sep 8, 2017 at 6:31 AM LCD PI via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everybody, > > We are working in a PRBS Generator and the idea is to make it works with > the RFNoC structure. But we are having some troubles and need some help on > it. Could you please clarify this four points? : > > > 1. Trying to understand the functionality of a RFNoC Generator, we were > trying to transmit a signal with RFNoC:Siggen block on Ettus E310. This > signal will be received by a laptop through a RTL-SDR dongle with > GNURadio. > > Flowgraph of transmitter that we generated on the E310: > > Note: we also put the RFNoC FIFO between the RFNoc Radio and the SigGen. > > Flowgraph of the receiver on our laptop: > > [image: print2.png] > > Software versions in use: > > UHD: UHD_4.0.0.HEAD-239-g89427e8c > > GNURADIO: 3.7.9.3 > > When we executed the transmitter flowgraph illustrated above, and trigger > “Enable” to 1, the TX indicator led turn red but the receiver doesn’t show > our signal. > > But if we change the flowgraph into this: > > > In this case, when we trigger “Enable” to 1, we can see our signal > spectrum in the receiver. > > > 1. > > Why we cannot generate and transmit data directly in the FPGA without > “up” to the PS? > 2. > > Is there any incompatibility between the RFNoC: Siggen block and the > E310? > 3. > > Are we forgetting some configurations ? > > > 2. The second question is about Datatypes, we are designing a PRBS > Generator with LFSR method, which generates data of 32bits in our IP Core > with this format: > > 16 I bits, 16 Q bits. > > - > > 1 → [16’b1, 16’b0] > - > > 0 → [16’b0, 16’b0] > > > En archivo de configuracion de UHD (xml) configuramos el host type como > fc32 y el otw type como sc16, > > In the configuration file of the UHD “XML” we set the host type in FC32 > and the OTW in SC16, but when we run our example in the GnuRadio the QT > TIME SINK doesn’t show 0’s and 1’s, but instead we see smaller values ( 0’s > and 0,000030519). This make us think that the I and Q values were > interpreted like a Q15 format. > > So, we made some changes in our Verilog Code and generate data using the > fixed-point format (signed Q15), like this: > > 16 I bits , 16 Q bits. > > 1 sign bit - 15 fractional I bits , 1 sign bit - 15 fractional Q > bits . > > - > > 1 → [1’b0 - 15’d32767, 1’b0 - 15’b0] > - > > 0 → [1’b0 - 15’b0, 1’b0 - 15’b0] > > > After that, values of 1’s and 0’s were observed in QT TIME SINK. > > > 1. > > Can we say that the data inside our IPCORE must be mandatory generated > like a signed Q15 type, or we are misunderstanding something? > > > 3. In addition to RFNoC block, we created the same block in Python > language for GNURadio. This, like FPGA block, generate 1's and 0's but in a > "bit to bit" mode. Our problem is that we cannot know the run frequency of > the block in the PS (in the FPGA the blocks are connected to the > radio_clk). When we connect this block to the QT TIME SINK, we can see the > generate data without problem; but when we try to “down” to the FPGA and > transmit that data with the RFNoC:Radio, the TX red led does not turn on > and we obtain Underflow. > > > 1. > > If our block can not generate data at the same rate that RFNoC:Radio > block was configure, is there any way to resolve/avoid the Underflow? > > > 4. The Ettus web page say that this bandwidth between PS and PL is 10MS/s, > but does not explain under what circumstances. > > > 1. > > Is there any way to measure the data bandwidth between the PS and PL? > > > Regards and thanks for your time. > > Ruben Vogel > > > -- > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
