Re: [Discuss-gnuradio] Determining distance from OFDM signals
Hi Marcus, Thanks for your nice words. GNU Radio is an amazing project and the email archive is our first resource for finding help. Benefited me numerous times. Regarding the necessity of back and forth transmission for ranging, you already know this stuff but I write the below note for later searchers. The fundamental question to ask is the following. What are the conditions under which finding the distance is possible? It turns out that unsynchronized nodes have a phase offset Theta and a delay Tau between them. So we have two unknowns. Now if we implement one way transmission, we get only one equation and hence it becomes impossible to separate the phase offset from delay. Time_2 = Time_1 + Theta + Delay However, there are several ways in which an extra equation can be provided to this system for range determination (since phase is just another manifestation of time, so the underlying principles stay the same). *Method 1*: Synchronize the nodes and hence Theta becomes zero. One equation and one unknown, i.e., delay. *Method 2*: Provide an extra independent equation through back and forth transmission where phase offset Theta appears with a negative sign (because measurement is at the initiator now). Time_4 = Time_3 - Theta + Delay Here, we have two equations that can solve the two unknowns. *Method 3*: Move one node around that doesn't affect the phase offset Theta but provides an extra equation for delay Tau. For example, if we take it twice as far, Time_4 = Time_3 + Theta + 2*Delay Again, two equations and two unknowns. The OFDM radar you mentioned is a generalization of this concept where we do graphs in 2 dimensions and find the range/velocity through the respective slopes. So basically we provide the second equation through movement that changes the delay. As a side remark, I just mention that the large number of subcarriers doesn't provide independent equations (multiply both sides of the above equations with 2\piF_k instead of 2\piF_1 to check). However, they help in solving the range ambiguity problem, e.g., with 2.4 GHz, the maximum range determination is only 12.5cm. This comes from one wavelength (c/F). *Method 4*: Place extra anchor nodes around the Tx. Now we have several extra equations but exactly the same number of extra phase offsets! One node (even an anchor) then can respond with a reply message where phase offsets appear with negative signs making the system solvable. This is usually known as ranging through one-way transmission (because target node has to transmit only once) or Blink Mode by some. Cheers, Qasim On Sat, Jun 8, 2019 at 11:33 PM Müller, Marcus (CEL) wrote: > 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.
Re: [Discuss-gnuradio] Determining distance from OFDM signals
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/138892 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 > wrote: > > Send Discuss-gnuradio mailing list submissions to > > discuss-gnuradio@gnu.org > > > > 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 > > discuss-gnuradio-requ...@gnu.org > > > > You can reach the person managing the list at > > discuss-gnuradio-ow...@gnu.org > > > > 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) > >
Re: [Discuss-gnuradio] Determining distance from OFDM signals
On Wed, 05 Jun 2019 at 16:20:12 -0700, Andrew Wolfram wrote:
> I'm trying to alter the file ofdm_txrx.py (
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py)
> to get phase information from the carrier data so I can calculate an
> approximate distance between two USRP devices. Ideally I want to grab
> data from one of the blocks in the rx pipeline in the above python
> file after the frequency/timing corrections have been applied. I tried
> using the data after the serializer block, but it appears that this
> has no phase information. I tried with the equalizer block output but
> I'm not sure how to interpret its output data.
You cannot use the output of the equalizer block to get information on
channel phase (or amplitude). That’s the point of equalization. A
received subcarrier in a OFDM system is given by Y = H·X + N where H is
the channel transfer function at the subcarrier, X is the sent symbol
and N is noise (in frequency domain, i.e. after the FFT; note some
assumption regarding synchronisation must hold, see [1]). The equalizer
returns hat{X} = Y/hat{Y} where hat{·} denotes estimation. Note that
the serializer block is a downstream block of the equalizer in the file
you mention.
> For my particular payload with 300 occupied carriers and an fft size
> of 512 only the first 214 items of the equalizer output vector have
> any phase information, so I'm somewhat confused. Any ideas?
This might be related to the number of used pilots and their position.
Do you use 86 pilots? How do you define their position? It’s rather odd
that the position of carriers without phase information is not
scattered.
[1] https://ieeexplore.ieee.org/document/803501
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Thanks for your responses! I'm trying to implement what's already been done with USRPs in this paper (https://ieeexplore.ieee.org/document/8555795), which is based on this paper (https://ieeexplore.ieee.org/document/5505942). My apologies if you can't access the full versions of these. In the first paper with the USRP's they're using an external clock to perfectly frequency sync the two devices, but otherwise they are taking relative distance measurements. That is, after frequency and time synchronization, they are accounting for the different delays in each device by only measuring changes in distance rather than absolute distance. Assuming I had the same setup as in the paper, does my original question make more sense? On Fri, Jun 7, 2019 at 5:20 AM Müller, Marcus (CEL) wrote: > Well, you can go ahead and at least to a degree enforce a known > relative phase between transmitter and receiver, but yeah, without > extensive external synchronization effort (e.g. GPSDOs – hi there, u- > blox :) ), the receiver phase is random relative to the transmitter's > phase. So, the distance can't be recovered from a one-way transmission. > > Best regards, > Marcus > > On Fri, 2019-06-07 at 10:21 +, Jonas Manthey wrote: > > Hi Andrew, > > > > What do you mean by “information from the carrier data”? I’m no OFDM > expert, but my intuition tells me that in a zero-IF architecture (which I > assume your USRP has) any carrier phase information is lost. There’s some > results when googling for “OFDM ranging” maybe that helps. > > > > Cheers, > > Jonas > > > > From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey= > u-blox@gnu.org] On Behalf Of Andrew Wolfram > > Sent: Donnerstag, 6. Juni 2019 01:20 > > To: discuss-gnuradio@gnu.org > > Subject: [Discuss-gnuradio] Determining distance from OFDM signals > > > > Hi, > > > > I'm trying to alter the file ofdm_txrx.py ( > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) > to get phase information from the carrier data so I can calculate an > approximate distance between two USRP devices. Ideally I want to grab data > from one of the blocks in the rx pipeline in the above python file after > the frequency/timing corrections have been applied. I tried using the data > after the serializer block, but it appears that this has no phase > information. I tried with the equalizer block output but I'm not sure how > to interpret its output data. For my particular payload with 300 occupied > carriers and an fft size of 512 only the first 214 items of the equalizer > output vector have any phase information, so I'm somewhat confused. Any > ideas? > > > > Thanks, > > Andrew > > ___ > > 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
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Well, you can go ahead and at least to a degree enforce a known relative phase between transmitter and receiver, but yeah, without extensive external synchronization effort (e.g. GPSDOs – hi there, u- blox :) ), the receiver phase is random relative to the transmitter's phase. So, the distance can't be recovered from a one-way transmission. Best regards, Marcus On Fri, 2019-06-07 at 10:21 +, Jonas Manthey wrote: > Hi Andrew, > > What do you mean by “information from the carrier data”? I’m no OFDM expert, > but my intuition tells me that in a zero-IF architecture (which I assume your > USRP has) any carrier phase information is lost. There’s some results when > googling for “OFDM ranging” maybe that helps. > > Cheers, > Jonas > > From: Discuss-gnuradio > [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf > Of Andrew Wolfram > Sent: Donnerstag, 6. Juni 2019 01:20 > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Determining distance from OFDM signals > > Hi, > > I'm trying to alter the file ofdm_txrx.py > (https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) > to get phase information from the carrier data so I can calculate an > approximate distance between two USRP devices. Ideally I want to grab data > from one of the blocks in the rx pipeline in the above python file after the > frequency/timing corrections have been applied. I tried using the data after > the serializer block, but it appears that this has no phase information. I > tried with the equalizer block output but I'm not sure how to interpret its > output data. For my particular payload with 300 occupied carriers and an fft > size of 512 only the first 214 items of the equalizer output vector have any > phase information, so I'm somewhat confused. Any ideas? > > Thanks, > Andrew > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Hi Andrew, What do you mean by “information from the carrier data”? I’m no OFDM expert, but my intuition tells me that in a zero-IF architecture (which I assume your USRP has) any carrier phase information is lost. There’s some results when googling for “OFDM ranging” maybe that helps. Cheers, Jonas From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf Of Andrew Wolfram Sent: Donnerstag, 6. Juni 2019 01:20 To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Determining distance from OFDM signals Hi, I'm trying to alter the file ofdm_txrx.py (https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) to get phase information from the carrier data so I can calculate an approximate distance between two USRP devices. Ideally I want to grab data from one of the blocks in the rx pipeline in the above python file after the frequency/timing corrections have been applied. I tried using the data after the serializer block, but it appears that this has no phase information. I tried with the equalizer block output but I'm not sure how to interpret its output data. For my particular payload with 300 occupied carriers and an fft size of 512 only the first 214 items of the equalizer output vector have any phase information, so I'm somewhat confused. Any ideas? Thanks, Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
