discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementation of OFDM TX and RX using GNURadio and USRP


From: Marcus D. Leech
Subject: Re: Implementation of OFDM TX and RX using GNURadio and USRP
Date: Sat, 26 Nov 2022 22:01:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 26/11/2022 20:56, Al Amiri, Wesam (waalamiri42) wrote:
Thanks for your reply, Mr. Leech!

This is what I am trying to do in this stage, but my embedded python block causes the flowgraph to freeze when I run it. 
I will try to figure out how to fix that!

Regards,
Wesam

From: discuss-gnuradio-bounces+waalamiri42=tntech.edu@gnu.org <discuss-gnuradio-bounces+waalamiri42=tntech.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Saturday, November 26, 2022 6:44 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Implementation of OFDM TX and RX using GNURadio and USRP
 

External Email Warning

This email originated from outside the university. Please use caution when opening attachments, clicking links, or responding to requests.


On 26/11/2022 15:19, Al Amiri, Wesam (waalamiri42) wrote:
Dears, 

I am working on the implementation of OFDM TX and RX using GNURadio 3.10.3 and USRP N210 (with UHD_4.2.0). In the implementation, I followed the GRC flow graph provided by GNU Radio Workshop (Slides 259 - 260) with changing the carrier frequency to 2 GHz, Sampling rate 1MHz at TX, and 10 MHz for Rx. 
The Tx USRP is connected to a Log Periodic antenna and similarly for the Rx USRP. There is no LOS between the TX and Rx antennas. They directed toward a reflective board so that the transmitted signal will be reflected by the board and received by the receiver. The implementation works fine, and I was able to receive the OFDM signal by the RX USRP.  
What I am trying to do is to extract some carriers from the FFT bins at the demodulator to do phase measurements on each one of the extracted carriers
I tried to create my own block to do that, but that didn't work and caused the GRC graph to freeze. Then, I tried to do that offline using Matlab, where I attached the FFT block to a file sink. 
In Matlab, I plotted the absolute of I/Q samples of the file sink as shown in the attached figure. But still, I am not able to distinguish between the subcarriers. 

Could anyone please give me advice how to extract certain carriers from the FFT bins of the demodulator?

Regards,
Wesam Al Amiri
Without completely dissecting your flow-graph, if this were MY problem, I might make an embedded Python block that allows me
  to select a single FFT bin and pass that along to an analysis function.  The FFT output is a vector, so it should be straightforward
  to implement a "pick a single carrier" function in Python, since your sample-rate is only 1Msps, and your FFT size is (I think) 64,
  that means your function has to deal with a new vector at 15kHz, which is achievable for a Python embedded block.

That's a quick thought based on an only superficial analysis of the problem, and others here might have better ways of
 doing it.


I just thought of this little "idiom" for picking a single item from a vector, that doesn't require that you write your own block.
  It takes advantage of "busports" (as a notational convenience).



The key here is the multiply-const, where you set the constant to a vector with a "1" in the position that you want to
 "pick", and 0s elsewhere.  Convert that to a set of streams, and then add the streams--in this case we use a bus-port
  on the output of the vector-to-streams and the input of the 'add'.  Since only one of those streams will contain
  non-zero data after the multiply-const, you can see that this has the effect of picking only a single FFT "bin" as a
  sample stream, and doesn't require that you navigate the intricacies of writing your own embedded Python block.
  It's likely much faster, too.

This is a common need, I suspect, and I wonder if there's another block that does this, but with some other,
  clever, domain-specific name.



There are probably other idiomatic ways to do this, but this is what I thought of just a few minutes ago...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]