On Wed, Mar 20, 2013 at 3:06 PM, Sahoo, Anirudha <anirudha.sa...@nist.gov> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio