Re: [Discuss-gnuradio] Reconnecting OFDM rx

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

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