discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Reconnecting OFDM rx


From: Julius Durst
Subject: Re: [Discuss-gnuradio] Reconnecting OFDM rx
Date: Tue, 14 Jul 2015 19:03:36 +0200

Hi Martin,

I don't exactly understand what you mean. I connected the Tag Debug to both outputs of Schmidl&Cox, but that does not seem to add any tags even when running in the "normal" mode. I don't think it is supposed to as it doesn't get any keys.

When disconnecting the rx, the detect output of S&C stops (no new samples come out of it). When reconnecting the rx, I get a flow of zeros from the detect output (no more detections). This is where I'm really wondering if it is doing what it is supposed to.

Here is the other flowgraph approach:
http://i.imgur.com/TgrVdCi.png (at least the important parts)
grc file: http://pastebin.com/cHRJgJyg

The full buffers seem not very likely as the QT Frequency Sink still gets new data.

BR

Julius

On 14.07.2015 18:25, Martin Braun wrote:
Hey Julius,

the OFDM codes work over the air, so I don't think statefulness is the
issue. Maybe you just have super-full buffers or something like that.

The packet detection is the most stable part -- can you see if that
works? Just use the Schmidl&Cox block from the rx and see if it prints tags?

M

On 14.07.2015 08:26, Julius Durst wrote:
Hi list,

I want to reconfigure an OFDM system. For this, I am so far simply
trying to reconnect the tx and rx in the loopback example from the
gr-digital ofdm examples. I made only very small modifications to it
with two selector blocks, so now the flowgraph looks like this:
http://i.imgur.com/Otr0VUt.png
grc file: http://pastebin.com/pTDFhgvq

As soon as the OFDM rx is not connected from the beginning of execution
or is reconnected after being disconnected, it is not able to receive
the data.

When being disconnected and reconnected again, one of the following
scenarios occurs:

1. Nothing happens, just nothing more is received:

----------------------------------------------------------------------
Tag Debug: Rx Packets
Input Stream: 00
Offset: 24150 Source: n/a Key: packet_num Value: 483
Offset: 24150 Source: n/a Key: ofdm_sync_carr_offset Value: 0
Offset: 24150 Source: n/a Key: rx_len Value: 50
----------------------------------------------------------------------

Done


2. Sometimes I get output like this: (Is there a list with return codes?
What is -9? Is it normal when killing flowgraph with the button in grc?)

----------------------------------------------------------------------
Tag Debug: Rx Packets
Input Stream: 00
    Offset: 33700  Source: n/a     Key: packet_num   Value: 674
    Offset: 33700  Source: n/a     Key: ofdm_sync_carr_offset   Value: 0
    Offset: 33700  Source: n/a     Key: rx_len   Value: 50
----------------------------------------------------------------------
INFO: Detected an invalid packet at item 32400
INFO: Parser returned #f

  >>> Done (return code -9)


3. The return code seems to not necessarily having to do with the INFO,
because also got this:

----------------------------------------------------------------------
Tag Debug: Rx Packets
Input Stream: 00
    Offset: 26100  Source: n/a     Key: packet_num   Value: 522
    Offset: 26100  Source: n/a     Key: ofdm_sync_carr_offset   Value: 0
    Offset: 26100  Source: n/a     Key: rx_len   Value: 50
----------------------------------------------------------------------
INFO: Detected an invalid packet at item 25104
INFO: Parser returned #f

  >>> Done


4. When first connecting the null sink and then connecting rx to the
already running tx:

Using Volk machine: avx_64_mmx_orc
INFO: Detected an invalid packet at item 0
INFO: Parser returned #f
INFO: Detected an invalid packet at item 48
INFO: Parser returned #f
INFO: Detected an invalid packet at item 96
INFO: Parser returned #f
INFO: Detected an invalid packet at item 144
INFO: Parser returned #f
INFO: Detected an invalid packet at item 192
INFO: Parser returned #f
INFO: Detected an invalid packet at item 240
INFO: Parser returned #f
   ... and so on


Note that the ">>> Done" is from manually killing the flowgraph, it did
not stop by itself, just added it because of the exit code.

So my question is: Why is this not working? In the cases where I just
did not get any new packets (1., 2. and 3.), it seems like the Schmidl &
Cox block does not even detect a new packet, so maybe something is wrong
with that block? I also checked the "detected" output of the Schmidl &
Cox block, it only had zeros.

Thanks in advance for your help and ideas

Julius

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

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