discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Does OFDM Carrier Allocator add input tags to syn


From: Martin Braun
Subject: Re: [Discuss-gnuradio] Does OFDM Carrier Allocator add input tags to sync word?
Date: Tue, 10 Jan 2017 12:25:31 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 12/19/2016 12:33 AM, Jeon wrote:
> As I understand, at first run (n_ofdm_symbols = 0), it reads `n =
> symbols_to_allocate` tags from input and puts it into `k =
> nitems_written(0)`, which is the starting position of sync word. At
> second run (n_ofdm_symbols = 1), it reads tags again, and puts it into
> `k = nitems_written(0) + 1 + d_sync_words.size()`. Hence, the first
> group and the second group of tags are apart by offset `d_sync_words.size()`
> 
> Is it my understanding of source code correct? If so, I wonder whether
> there is a reason for placing the first group of tags onto sync word,
> not onto the first data ofdm symbol. If I miss something in interpreting
> the code, please let me know it.

There is a reason to do this, but there's also an issue.
The idea is to put tags as close as possible to the samples they were on
the input stream, *except* if they came in on the first sample, because
in that case, we make the assumption that they were, in fact, meant to
be at the front of this tagged stream.

The issue is that it'll do this for any tag that's on the first OFDM
symbol. The correct test would thus not be n_ofdm_symbols == 0, but
rather tags[t].offset - nitems_read(0) == 0 or whatever correctly tests
for if the tag is actually on the first sample, not just any sample in
the first OFDM symbol.

Cheers,
Martin




reply via email to

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