Make a vector source and a two input qt time sink. Make one time sink input a direct connection to the vector source. Make the other go to a delay block which is then connected to the vector source.
Set the vector source to not repeat and you should see what happens in the delay block. Make the vector long enough that you can see something useful on the plot (maybe range(256)).
On Saturday, May 23, 2015, Francisco Albani <
address@hidden> wrote:
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.
Bye
>>
>> 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
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio