Re: [Discuss-gnuradio] TIMEOUT from "digital_ofdm_sampler.cc"

[Tom Rondeau]

On Wed, Mar 20, 2013 at 3:06 PM, Sahoo, Anirudha
<address@hidden> wrote:
> Hi,
>
>    I am trying to implement an algorithm over the ofdm implementation
> (modifying
>
> benchmark_xx.py) so that the txmitter and rcvr can communicate changing
>
> the subcarriers dynamically.
>
>    The scheme is roughly as follows:
>
> (1)     Inially the txmitter and the rcvr listen on a well-known set of
> subcarriers.
>
> (2)    then the txmitter sends a carrier map (set of subcarriers)
>
> over which the subsequent transmissions will happen.
>
> (3)    the rcvr acks that it has received the new carrier map (and tunes to
> those subcarriers for reception)
>
> (4)    On receiving ACK, the txmitter also sets its carrier map to new
> carrier map.
>
> (5)    Now both the ends are synced to this new carrier map
>
> (6)    some data packets are sent over this new carrier map
>
> (7)    then the txmitter decides to change the carrier map and goes to step
> (2).
>
>
>
>   Here is the problem that I encounter:
>
>   The rcvr gets few packets (usually first two times the carrier map reset
> works and the rcvr
>
>    is able to get the packets).
>
>
>
>     But then the txmitter sends the new carrier map. The rcvr receives it,
> sends an ACK, sets its
>
>    carrier map appropriately. The txmitter receives the ACK, sets its
> carrier map and then starts
>
>   sending data packets.
>
>     But now the rcvr does not get any packets (even though it is tuned to
> the same subcarriers as
>
>    the txmitter is transmitting on).
>
>     Then I see the message “TIMEOUT” on the rcvr (coming from general_work()
> of “digital_ofdm_sampler.cc”).

That timeout indicates that a while ago, it saw the preamble symbol.
But then it failed to find any following symbols and so times out so
it will start looking for a new preamble, which it never finds.

My guess is that the timeout is from the last preamble symbol before
the carrier mapping is changed. I honestly can't quite recall how we
did it, but it's possible that the carrier map affects all symbols in
the OFDM chain, including the preamble. But the preamble is structured
in a very specific way to be received and set the phase and timing at
the receiver. If you mess with the carrier map too much, you could
distort or destroy the necessary properties of the preamble.

There are logging capabilities in the OFDM receiver, and one of them
should be the detection line of the preamble. You can plot this to see
when you stop detecting preambles.

Wow, thinking through this right now makes it so much more apparent
how much better we can do with all of our new tools and tricks in GNU
Radio! We have a new OFDM transmitter based on this, but I can't wait
until we can get into place a new receiver. Specifically, we want to
use stream tags for the control over things like preamble detection,
and we could use the metadata files to log the stages for debugging.
The metadata files would allow us to know exactly when things happened
and all of the tags associated with that event.

Unfortunately, right now, you're just going to have to look at those
log file of samples and try to reconstruct what's happening yourself.

>       I have even put some delays between resetting carrier map and sending
> data (so that the receiver is
>
>     ready with the new carrier map), but that did not help.
>
>
>
>     Any idea why the receiver stops getting packets after few times the
> carrier map is changed?
>
>
>
>    I am running gnuradio version 3.6.2 on USRP N210. The txmitter and the
> rcvr are connected over
>
>   a channel emulator (using RF cable), which emulates a perfect lossless
> channel.
>
>
>
> thanks and regards


My final suggestion to get you going is to maybe send over the same
carrier map every time. We start with a mapping that just drops the
two middle carriers (for DC offset protection). Just use that as your
carrier map every time and make sure that everything still works ok.
If that works, great. If it still fails then you know what I said
above about the preamble isn't the problem.

>
> --Anirudh Sahoo
>
> Advanced Network Technology Div.
>
> National Institute of Standards and Technology (NIST)
>
> 100 Bureau Drive,
>
> Gaithersburg, MD - 20878
>
> Room – B230, bldg.- 222
>
> Phone- 301-975-4439


Hope this helps,
Tom