Receiving BPSK signal

Hi,
I’d like to receive a BPSK signal (recovering the phase/freq and timing
synchronism), not differential coded and in particular not shaped by a
srrc
filter (rect pulse).
I guess that psk_demod.py supports only srrc shaped signal and that
digital_mpsk_receiver_cc supports only differential coded signal.

Any suggestions ?
Thank you.


View this message in context:
http://gnuradio.4.n7.nabble.com/Receiving-BPSK-signal-tp38917.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi luca,

check out the examples in gr-digital/examples/demod.
You can set the filter taps as you wish, and do the same with the
modulation used.

MB

On Thu, Jan 10, 2013 at 02:45:43AM -0800, luca wrote:

[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Hi Martin,
thank you…
but it seems to me that no example allows a not-Differential coding
scheme
and not-srcc filter (excess Bw is required).
Maybe only the pam_sync.grc is the most suitable for my purpose…
I find the synchronism recover by means of a FLL Band-Edge (frequency
error), a Polyphase Clock Sync (for timing error) and a Costas (for
phase
and frequency remaining error)…and I can edit the filter taps. It
sounds
good…

but actually,… I’ve got some doubts…

-) In the Polyphase Clock Sinc I expected to find the same taps used in
the
tx side (Polyphase Resampler). But other taps are used… Why ? and
according to which approach are they generated ?

-) then…in case of rect pulse, the taps should be a ones vector… do
you
agree ?

-) in any case, the FLL requires the excess bandwidth, so it seems it
doesn’t support no-srrc modulation.

Regards
Luca


View this message in context:
http://gnuradio.4.n7.nabble.com/Receiving-BPSK-signal-tp38917p38938.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Using rect pulse shapes is generally not a good idea. Why do you want
that?

…but let’s assume you have a good reason:

On Fri, Jan 11, 2013 at 07:41:29AM -0800, luca wrote:

-) In the Polyphase Clock Sinc I expected to find the same taps used in the
tx side (Polyphase Resampler). But other taps are used… Why ? and
according to which approach are they generated ?

They are the same (RRC filter on both Tx an Rx).

-) then…in case of rect pulse, the taps should be a ones vector… do you
agree ?

Yes.

-) in any case, the FLL requires the excess bandwidth, so it seems it
doesn’t support no-srrc modulation.

That’s how the FLL works. In theory, you need a different freq sync for
rectangular pulse shape.
The way it’s implemented, it might even work, though, if you leave the
rolloff at .35.

MB

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Fri, Jan 11, 2013 at 11:17 AM, luca [email protected] wrote:

They are the same (RRC filter on both Tx an Rx).

Are you sure ?
I find out the following taps [firdes.root_raised_cosine(32, 32, 1.0, 0.35,
4432)] in the Polyphase Resampler while
[firdes.root_raised_cosine(nfilts,1.0,1.0/(spb
nfilts), rolloff,
int(11spbnfilts))] are used in Polyphase Clock Sync.

Yes, they are the same. The second implementation is better, though,
since
it uses the proper variables to set things up. But in the end, if
nfilts=32, rolloff=0.35, and spb=4, they are the same filters.

Tom

Using rect pulse shapes is generally not a good idea. Why do you want
that?

…but let’s assume you have a good reason:

yes …in my case… low data rate telemetry-data from satellite are
transmitted without filtering.

They are the same (RRC filter on both Tx an Rx).

Are you sure ?
I find out the following taps [firdes.root_raised_cosine(32, 32, 1.0,
0.35,
4432)] in the Polyphase Resampler while
[firdes.root_raised_cosine(nfilts,1.0,1.0/(spb
nfilts), rolloff,
int(11spbnfilts))] are used in Polyphase Clock Sync.

The way it’s implemented, it might even work, though, if you leave the
rolloff at .35.

ok.


View this message in context:
http://gnuradio.4.n7.nabble.com/Receiving-BPSK-signal-tp38917p38941.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi Tom,
thank you …but I’m sorry …I’m not convinced… :wink:
I try to replace the two terms by usign just one of them…
well if I use rrctaps for both, the signal is not tracked, while if I
use
the firdes.root_raised_cosine(32, 32, 1.0, 0.35, 44*32), it works but it
is
noisier.

Luca


View this message in context:
http://gnuradio.4.n7.nabble.com/Receiving-BPSK-signal-tp38917p38984.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Mon, Jan 14, 2013 at 12:27:25AM -0800, luca wrote:

Hi Tom,
thank you …but I’m sorry …I’m not convinced… :wink:
I try to replace the two terms by usign just one of them…
well if I use rrctaps for both, the signal is not tracked, while if I use
the firdes.root_raised_cosine(32, 32, 1.0, 0.35, 44*32), it works but it is
noisier.

Luca,

both blocks have different sampling rates at the input. This is
reflected in the taps calculation. Otherwise, they’re identical.

Creating taps for PFB blocks is not exactly the same as doing so for
their non-PFB counterparts.

You should definitely read this:
http://gnuradio.org/doc/doxygen/page_pfb.html
http://gnuradio.org/doc/doxygen/classgr__pfb__arb__resampler__ccf.html

These might also help:
http://gnuradio.org/doc/doxygen/classgr__firdes.html
http://gnuradio.org/doc/doxygen/classgr__pfb__clock__sync__ccf.html

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs