discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Determining distance from OFDM signals


From: CEL
Subject: Re: [Discuss-gnuradio] Determining distance from OFDM signals
Date: Sat, 8 Jun 2019 13:32:57 +0000

Hi Qasim,

a) it's so nice to see you drop in here from time to time :)
b) that's true! But reality is even better; the back and forth exchange
isn't strictly necessary.
c) I finally find the time to write down what I wanted to write.

## First, agreeing with you:

One can basically emulate the principle of a correlation-based radar by
making the other end "reflect" info with a known delay.

All one needs to do is ensure that a reply packet is sent a *fixed*
amount of time after a packet is received. That interval doesn't have
to be necessarily short, just known.

From the reply, and its knowledge of the original transmission's time,
the original transmitter can deduce the double of the one-way
transmission latency; that can, given enough bandwidth, SNR and
processing gain, be enough to resolve integer wavelength ambiguities.
In practice, passband bandwidth will often be the fundamentally
limiting factor.

With the phase estimate done on the reply, and info on the phase
estimate done by the replying party, both sides would have relative
phase CSI, and the original transmitter a distance estimate. 

## Then, disagreeing with you (just a little bit):

Now, while the above works with any transmission that allows phase
recovery, OFDM frames have the advantage of allowing a two-dimensional
DFT to be used to estimate range through the time-shift property of the
DFT. However, that requires knowledge of the transmitted symbols at the
receiver – which luckily is recoverable in case of successful OFDM
communication¹.

In fact, that's how OFDM radar works very nicely; it's explained in
[1].

Imagine a receiver with knowledge of the transmitted signal. While
lacking a common time base, a receiver can infer distance from the
development of the phases of entries of a sufficiently large (in both
number of OFDM symbols and number of subcarriers) OFDM frame.

The idea is simple: assume you know the symbols at the transmitter. The
speed-of-light induced delay is constant across all subcarriers.
The resulting phase shift, thus, is proportional to the subcarrier
frequency, and hence the subcarrier number.
Therefor, when you observe linear channel phase change over subcarrier,
you can get a distance estimate. Phase being a linear function of index
implies we're dealing with a sinusoid – and a DFT in subcarrier
direction will give us a range plot.

Same idea for Doppler, but with phase on the same subcarrier, but for
consecutive and hence constant-interval OFDM symbols; do another DFT
for each subcarrier across OFDM symbols, and get a doppler plot.

Overall: Write down your received OFDM symbols as column vectors of a
matrix, point-wise divide by the transmitted symbols (normalize
amplitude if helpful); the result is a matrix full of complex numbers
with the channel phase for each subcarrier at each symbol time. 
Do an appropriate 2D-DFT, get a range/doppler plane "image". Find the
peak; use clever interpolation / post-processing to increase resolution
and/or reduce estimate variance.

Cheers,
Marcus

¹  (unless someone inexplicably decided to use differential PSK on the
subcarriers – looking at DAB, there.)

[1] https://publikationen.bibliothek.kit.edu/1000038892

On Sat, 2019-06-08 at 14:21 +1000, Qasim Chaudhari wrote:
> Phase information is preserved whether the Rx architecture is zero-IF 
> or not. The OP I guess is already using a back and forth exchange
> between two USRPs, from which the distance information can be
> extracted in case of OFDM signals.
> 
> Cheers,
> Qasim
> 
> 
> On Sat, Jun 8, 2019 at 4:05 AM <address@hidden>
> wrote:
> > Send Discuss-gnuradio mailing list submissions to
> >         address@hidden
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > or, via email, send a message with subject or body 'help' to
> >         address@hidden
> > 
> > You can reach the person managing the list at
> >         address@hidden
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Discuss-gnuradio digest..."
> > 
> > 
> > Today's Topics:
> > 
> >    1. Re: test message please ignore (Marcus Müller)
> >    2. Help with sound output (Sara Kim)
> >    3. Re: Help with sound output (Michael Dickens)
> >    4. Re: Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc
> >       failed (Adrian Musceac)
> >    5. Re: query regarding wav file recording through wav file sink
> >       block (Maitry Raval)
> >    6. Re: query regarding wav file recording through wav file sink
> >       block (Müller)
> >    7. Re: query regarding wav file recording through wav file sink
> >       block (Maitry Raval)
> >    8. Re: Request for comment: FFT optimizations (Müller)
> >    9. Re: query regarding wav file recording through wav file sink
> >       block (Müller)
> >   10. Re: query regarding wav file recording through wav file sink
> >       block (Maitry Raval)
> >   11. Re: Determining distance from OFDM signals (Jonas Manthey)
> >   12. ARM optimization update (Albin Stigö)
> >   13. Re: Determining distance from OFDM signals (Müller)
> > 
> > 
> > -----------------------------------------------------------------
> > -----
> > 
> > Message: 1
> > Date: Thu, 06 Jun 2019 18:06:58 +0200
> > From: Marcus Müller <address@hidden>
> > To: Eamon Heaney <address@hidden>, address@hidden
> > Subject: Re: [Discuss-gnuradio] test message please ignore
> > Message-ID:
> >         <
> > address@hidden>
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > Eamon,
> > 
> > please don't do this; there's more than 3000 email addresses on
> > this
> > mailing list. If you have any problems with your subscription, feel
> > free to mail address@hidden with "help" in the
> > subject line.
> > 
> > A much better way to get to know whether the mailing list works
> > would
> > be by sending a self-introduction email and check the mailing list
> > archives for it an hour later, if you're not sure it reached the
> > list.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2019-06-06 at 09:39 -0400, Eamon Heaney wrote:
> > > Another test message, due to my subscription wonkiness. Thank you
> > for
> > > bearing with me.
> > > 
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Thu, 6 Jun 2019 12:37:57 -0400
> > From: Sara Kim <address@hidden>
> > To: address@hidden
> > Subject: [Discuss-gnuradio] Help with sound output
> > Message-ID:
> >         <
> > CAKh9-M4p6cm-B63AY8sR0SX+mDCirTri-vSUAZ=address@hidden>
> > Content-Type: text/plain; charset="utf-8"
> > 
> > Hi,
> > I'm using a USRP205mini-i. I followed the YouTube tutorial online
> > on how to
> > build a FM receiver. I execute the flow graph, and all I hear is
> > very
> > choppy and high pitched audio coming from my computer's speaker (i
> > see
> > aUaUaU and an occasional O. I know this has to to with the
> > input/output
> > frequency being to fast/slow). I can make out the radio station I'm
> > tuned
> > in, but not very clearly. When listening to the .wav file produced,
> > it
> > sounds perfectly normal. I did change the audio sink sample rate to
> > 48kHz
> > and the wave file sink to 68kHz instead of keeping it at the
> > original in
> > the tutorial. Any suggestions or ideas as to how to fix this?
> > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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