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....@gnu.org
<discuss-gnuradio-bounces+waalamiri42=tntech....@gnu.org> on behalf of
Marcus D. Leech <patchvonbr...@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...
