[Top][All Lists]

[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

From: Francisco Albani
Subject: Re: [Discuss-gnuradio] Need of delay=58 in the PSK Symbol Recovery Guided Tutorial
Date: Sat, 23 May 2015 05:31:32 -0300

2015-05-22 22:46 GMT-03:00 Martin Braun <address@hidden>:
> 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?

Excuse me for my bad English. This is what I wanted to write:

{To} what {are} those zeros (added to the original stream) aligned 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.

I can imagine that, but my point is: that bunch of zeros is going to
be consumed, by the 2-input sink, together with 58 samples coming out
of the demodulator/decoder.

That represents 7 bytes and 2 bits or 29 psk symbols, which actually
are upsampled by a factor of 4, resulting in 116 complex samples.

I don't understand where are they coming from.

> Read our docs w.r.t. history to find out more.

I couldn't find them. Can you point them?

> Cheers,
> M

Many thanks!, Martin.


>> 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:
>>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation
>>>> 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.
>>> M
>>> _______________________________________________
>>> 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]