TIMEOUT from "digital_ofdm_sampler.cc"

GNU Radio
#1

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”).

  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

–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

#2

On Wed, Mar 20, 2013 at 3:06 PM, Sahoo, Anirudha
[email protected] wrote:

(4) On receiving ACK, the txmitter also sets its carrier map to new

sends an ACK, sets its

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 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.

Room B230, bldg.- 222

Phone- 301-975-4439

Hope this helps,
Tom