[ input ] -> [ PSK mod ] -> [ PSK Demod ] -> [ output ] => [ input ] != [ output ] - interesting

GNU Radio
1

Greetings,

In gnuradio-companion I connected output of a “PSK Mod” directly to a
“PSK Demod” input. Both of the blocks have the same initializations,

Number of Constellation Points:2
Gray Code:Yes
Differential Encoding:No
Samples/Symbol:8
Excess BW:350m

in PSK Demod other properties are as follows:

Frequency BW:62.8m
Phase BW=62.8m

The output of the PSK Demod is fed into “UHD:USRP Sink” with a zero
center frequency after applying some type conversion blocks, “UChar To
Float” &
“Float To Complex”. I connect an external oscilloscope, i.e. not in PC,
not a GRC block a real one, to the output of the USRP to observe what I
have after appyling PSK mod and demod. As the output of the process, I
have a completely different signal from I generated in the beginning.

I also checked what happens if I directly feed the actual signal to the
“UHD:USRP Sink”, I got a signal nearly same as the original one, that is
as expected, great.

Another surprising thing, when I apply the output of the “PSK Mod” to
the “UHD:USRP Sink” and observe the output of the USRP1 output,
constellation points number is 2, although I see BPSK format, 180 degree
phase shift in the signals as I expected, I see 100 kHz baseband signal
frequency converts into 62.42 kHz, oscilloscope says so :), Samples /
Symbol rate is 8.

What might be the problem?

Thanks,
Abdullah

2

If this helps, the psk mod inputs packed bytes, however the demod
outputs unpacked bytes, where each byte is a decoded symbol. Obviously
you need some kind of framer correlate to reconstruct the packed byte
boundaries outside of the demod. It might be more comparable to use a
unpacked to packed block before the demod. That way both input and
output data is unpacked.

-josh

3

Thank you very muchJosh for your reply.

From: Josh B. [email protected]
To: [email protected]
Sent: Wednesday, August 15, 2012 6:34 PM
Subject: Re: [Discuss-gnuradio] [ input ] → [ PSK mod ] → [ PSK Demod
] → [ output ] => [ input ] != [ output ] - interesting

If this helps, the psk mod inputs packed bytes, however the demod
outputs unpacked bytes, where each byte is a decoded symbol. Obviously
you need some kind of framer correlate to reconstruct the packed byte
boundaries outside of the demod. It might be more comparable to use a
unpacked to packed block before the demod. That way both input and
output data is unpacked.

-josh