Doubts on the GRC block PSK_Demod

Hi all,

I’ve some doubts on the GRC block PSK_Demod.
I tried to analyze the inner functions called in the /psk_demod block/
in
order to understand the algorithms approachs implemented for synchronism
recovery.

/psk_demod/ derives from /generic_demod/ and the latter can be found in
/generic_mod_demod.py/.
Here, I can find the FLL performed by a band-Edge filters method through
the
functions /self.freq_recov =
digital.fll_band_edge_cc(self._samples_per_symbol, self._excess_bw,
fll_ntaps, self._freq_bw)./

Furthermore, I can find the timing recovery by polyphase filterbanks
approach, through /self.time_recov =
digital.pfb_clock_sync_ccf(self._samples_per_symbol,self._timing_bw,
taps,nfilts, nfilts//2, self._timing_max_dev) /

Then, in generic_mod_demod.py, I find the call /self.receiver =
digital.constellation_receiver_cb(
self._constellation, self._phase_bw,
fmin, fmax)./
My understanding is that this function performs just a Costas loop in
order
to recover the phase and the remaining frequency error.

Is it correct ?

My doubts derive from the fact that in
/digital_constellation_receiver_cb.h/, the function
digital.constellation_receiver_cb is described also in term of timing
recovery by a Mueller&Muller algorithm.
In my opinion, the clock recovery, as above indicated, is performed by
the
digital.pfb_clock_sync_ccf.

Thank you

Luca


View this message in context:
http://gnuradio.4.n7.nabble.com/doubts-on-the-GRC-block-PSK-Demod-tp38915.html
Sent from the GnuRadio mailing list archive at Nabble.com.

You are correct that the digital_constellation_receiver_cb does not do
any symbol timing recovery and that the documentation is incorrect.

Thanks for pointing this out, and sorry for the confusion.

Ben