# Need of delay=58 in the PSK Symbol Recovery Guided Tutorial

**URL:** <https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056>\
**Category:** GNU Radio\
**Created:** [May 23, 2015, 2:40am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056 "2015-05-23T02:40:29Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [May 23, 2015, 2:40am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/1 "2015-05-23T02:40:29Z")

</div>

Hi, I managed to successfully replicate the results of this tutorial:

[https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided\_Tutorial\_PSK\_Demodulation](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?

Of course this is not happening so I’m making a bad assumption some  
place and thats the reason I’m here asking for help.

(I know I could devise some debugging code for testing all my  
hypothesis, but I’m still to newbie)

Many thanks!

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 23, 2015, 2:52am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/2 "2015-05-23T02:52:45Z")

</div>

On 22.05.2015 17:38, Francisco A. wrote:

> 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

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 23, 2015, 3:15am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/3 "2015-05-23T03:15:32Z")

</div>

Hi Martin and thanks for your answer.

What those zeros added to the original stream align to in the received  
one?

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 B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 23, 2015, 3:48am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/4 "2015-05-23T03:48:15Z")

</div>

On 22.05.2015 18:13, Francisco A. 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.

Cheers,  
M

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 23, 2015, 10:33am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/5 "2015-05-23T10:33:04Z")

</div>

2015-05-22 22:46 GMT-03:00 Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> On 22.05.2015 18:13, Francisco A. 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

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 26, 2015, 10:17am UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/6 "2015-05-26T10:17:58Z")

</div>

Thanks, Nathan.

I tried what you suggested:

Blocks:  
VS) Vector source: value=range(256), repeat=no.  
D) Delay=50.  
TS) 2-input Time Sink.

Connections:  
VS–\>TS(0)  
VS–\>D–\>TS(1)

with this result:

- Pairs fed to the Time Sink:  
(0, 0)  
(1, 0)  
(2, 0)  
[…]  
(49, 0)  
(50, 0)  
(51, 1)  
(52, 2)  
etc.

I expected this result and I have no trouble understanding it.

I’m afraid I wasn’t able to express myself correctly.

I’m not ignoring how the delay block works; I’m asking about the 58  
initial bits that come out of the receiver (which are paired to the  
zeros added by the delay!)

Let me explain it with a diagram:

r: bit from the receiver.  
s: bit from the source.

Pairs fed to the Time Sink:

(r0, 0)  
(r1, 0)  
[…]  
(r57, 0)  
(r58, s0) \<— this is the first that matches nicely!  
(r59, s1)  
etc.

I want to know where the r’s come from. Are they just transient values?

Thanks for your patience!

Francisco.

2015-05-23 11:42 GMT-03:00 West, Nathan [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Francisco\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/51bf81/32.png) [@Francisco\_A](https://www.ruby-forum.com/u/Francisco_A)\
**Post date:** [May 23, 2015, 4:44pm UTC](https://www.ruby-forum.com/t/need-of-delay-58-in-the-psk-symbol-recovery-guided-tutorial/242056/7 "2015-05-23T16:44:00Z")

</div>

Perhaps an experiment will clear this up.

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 A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)