discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] gr-radar (OFDM radar specifically)


From: Martin Braun
Subject: Re: [Discuss-gnuradio] gr-radar (OFDM radar specifically)
Date: Mon, 7 May 2018 13:06:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Hey Shane,

On 05/04/2018 03:02 PM, Shane Petcavich wrote:
> I have a couple questions on the simulator_ofdm.grc flowgraph in the
> gr-radar package. I'm actually trying to implement this on 2 USRPs (via
> Matlab /UHD not GNURadio), but that is another story. 
> 
> In the paper here: 
> https://publikationen.bibliothek.kit.edu/1000038892/2987095
> 
> eq 3.16 is built and then processed as discussed in eq 3.30 (FFT of each
> row, then IFFT of each column). However, this processing seems to differ
> from the processing in GNU Radio flowgraph. As attached. It looks like
> the FFT of each OFDM symbol (column) is taken (when it should be an FFT
> of a collection of M symbols) then the IFFT of each row (essentially
> backwards from the proposed algorithm in the paper). What am I missing
> here?  

The algorithms in the paper and the GRC file *do* match. Note that N is
the number of subcarriers. You do FFTs over sub-carriers (in "frequency
direction", or in the direction that you count n), and then do IFFTs in
the perpendicular direction.
The linear property of the FFT lets you do the FFTs and IFFTs in any
order, so in the GRC file, we do the FFTs first, simply because that's a
little more easy to implement (or is it really...? It doesn't matter).

> Also the RCS is huge in the default program (1e25) and seems to not
> detect much for typical rcs of a car ~ 200 m^2.

I was recently looking into this, and can't quite remember what the
outcome was... there didn't seem to be a bug.

Cheers,
Martin



reply via email to

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