[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Need of delay=58 in the PSK Symbol Recovery Guide
Re: [Discuss-gnuradio] Need of delay=58 in the PSK Symbol Recovery Guided Tutorial
Fri, 22 May 2015 18:46:54 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
On 22.05.2015 18:13, Francisco Albani wrote:
> Hi Martin and thanks for your answer.
> What those zeros added to the original stream align to in the received one?
When you init a delay block with a positive value, it creates a
'history' (this is actually also the correct GNU Radio term). This is,
by default, a bunch of zeros.
Read our docs w.r.t. history to find out more.
> In other words, where are those 58 "spurious" bits at the beginning of
> the received stream coming from?
> Are they just the result of transient behavior inside the sync blocks?
> 2015-05-22 21:51 GMT-03:00 Martin Braun <address@hidden>:
>> On 22.05.2015 17:38, Francisco Albani wrote:
>>> Hi, I managed to successfully replicate the results of this tutorial:
>>> and, of course I understand the reason for a delay between the bits of
>>> the source and the receiver.
>>> But then I was struck by this: considering that the 2-input QT GUI
>>> Time Sink consumes one sample of each at the same time and waits
>>> otherwise, wouldn't this act as an "involuntary" synchronizer for the
>>> bit streams?
>> The time sink will consume input streams synchronously, that's correct,
>> but in this example, we also want to make sure the actual content is
>> sync'd as well. So the delay block will insert some zeros before the
>> signal starts, shifting signal in time such that they become aligned in
>> the time sink.
>> Discuss-gnuradio mailing list