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.
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.
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)
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/(spbnfilts), 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.
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/(spbnfilts), 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.
Hi Tom,
thank you …but I’m sorry …I’m not convinced…
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.
On Mon, Jan 14, 2013 at 12:27:25AM -0800, luca wrote:
Hi Tom,
thank you …but I’m sorry …I’m not convinced…
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.
