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?
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!
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
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. [email protected]:
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
2015-05-22 22:46 GMT-03:00 Martin B. [email protected]:
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
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 [email protected]:
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. [email protected]