[Discuss-gnuradio] Computation of RFNoC Blocks in GRC

[Felix Greiwe]

Hello together,

I recently created some RFNoC-Blocks using the RFNoC Modtool and an USRP
x310 from ETTUS for future GRC application. My Simulation in Vivado went
well and thus I built an FPGA-Image and flashed it to my USRP x310 device.
In GRC however, I witnessed very strange behaviour considering addition
operations of my blocks, so I went back to the most simple functioning
block, the RFnOC gain block from the RFNoC getting started page:

https://kb.ettus.com/Getting_Started_with_RFNoC_Development
(All Source Files are linked at the bottom of that page, no need to read
anything to understand my problem)

What that block does, is to receive a signal from GNURadio, split it into
I and Q Phase and multiply it by a constant value inside the FPGA of the
USRP. The outgoing signal is then the product of input and constant, for
example 0.1*5 = 0.5. Important in this case is, that the range of
result_values are limited to [-1,1] by the fpga.

To test addition instead of multiplication (which works), i edited one
single line of the noc_block_gain.v file from

 >> wire [31:0] i_mult_gain = i*gain;
 >> wire [31:0] q_mult_gain = q*gain;

to

 >> wire [31:0] i_mult_gain = i+gain; // in_phase component (real)
 >> wire [31:0] q_mult_gain = q*gain; // quadrature phase (imag)

where gain is a 16 Bit register which can be adressed through GNURadio
Companion.

In GRC I created a simple flowgraph which generates a complex cosine with
I and Q data samples, which then are prossessed by my modified gain block.
I expected the Q-Phase to behave exactly like before, and get multiplied
by the value in the gain register, and the I-Data to move upwoards in my
GRC Time Sink by the value I add to it.

Link to picture of Flowgraph:
https://ibb.co/s2jSZtK

While the expectations considering the multiplication got fulfilled, in
the addition part I see no changes in my results. Only when i pump my gain
up to great numbers (for example 1), i see a shift upwoards in my
diagram. My final observation was, that the shift upwoards is close or
equal to: "gain_value"/(2^15 -1).

Results with "gain" of 5:
https://ibb.co/7zJq2zx

Results with "gain" of 26214 (~ (2^15 -1)*0.8):
https://ibb.co/dtD6cJ7 (Put Q-Data to invisible here, to see I-Data better)

At this point I have a few questions, I hope someone can answer:

 - Why do the operations "multiplication" and "addition" differ in
behaviour and how can I get my desired "normal" behaviour?

 - At which point does GNURadio/RFNoC/theFPGA convert my signals to the
range of [-1,1]? Is it always doing this with a fixed formula or only
when the number exceeds the range? Any other information considering
this?

- Does it interpret my 16 Bit gain vector as a simple integer in the
multiplication path and as something different,(maybe Q-Format) in the
addition path? Why does it not simply add the value of my register to my
signal?

Any help is greatly appreciated, even when only parts get answered or when
it addresses errors in my thougthprocess. I did my best to point out my
problem, feel free to ask if you did not understand everything or my
mediocre english is an obstacle here.

Best regards and thank you reading,

Felix Greiwe





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Alex Roberts]

I'm playing around with an OFDM transmit/receive chain. I've noticed that
if I get underruns at a high enough rate, it becomes a bursty system and
the receiver is unable to lock in and no longer demodulates the symbols.

Would it be possible to generate continuous pilot tones or send OFDM frames
with just preambles and padded data such that even if the source data
stream underruns, the output is continous rather than bursty so that the
receiver can keep lock with time and frequency offests?

-Alex
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Michael Dickens]

Hi Alex - The default OFDM Rx is fully asynchronous: It tries to detect the 
packet preamble on a packet by packet basis only, without using any knowledge 
of historical successful packet detection. I don't think GR provides a 
synchronous receiver, and I don't know of one in any GR out of tree (OOT) 
module ... but I don't know everything so maybe there is one & if so hopefully 
others will chime in to tell us! Hope this is useful! - MLD

On Tue, Aug 13, 2019, at 1:04 PM, Alex Roberts wrote:
> I'm playing around with an OFDM transmit/receive chain. I've noticed that if 
> I get underruns at a high enough rate, it becomes a bursty system and the 
> receiver is unable to lock in and no longer demodulates the symbols. 
> 
> Would it be possible to generate continuous pilot tones or send OFDM frames 
> with just preambles and padded data such that even if the source data stream 
> underruns, the output is continous rather than bursty so that the receiver 
> can keep lock with time and frequency offests?
> 
> -Alex
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Block header parsing tool: Blog update

[Arpit Gupta]

Hello everyone,
I have updated the blog  for the Week
11 updates and the tasks for week 12. Here
 is the link to the updated
Github project.

Week 11 updates:
- Add boolean option to add comments to the header file.
- Extend to handle the case if there is a conflict in the information from
the special comments and the implementation file.
- Fix Bugs for the issues in the PR.

Tasks for Week 12:
- Modify the CMakeLists.txt file to check if PyGCCXML is installed in the
same way it is done for the click library in modtool.
-  Add comments in the code, wherever necessary.
- Fix Bugs for the issues in the PR.

Link to the parser branch  in
the forked repository.
Link for the pull request  for
code review on my forked repository.

Thanks,
Arpit Gupta
Indian Institute of Technology Roorkee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio