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
