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

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