after a few more experiments with synthetic signals, I figured out that the Constellation Decoder output is already the set of bit pairs expected from the QPSK constellation, not the families themselves. So as expecter -1-j->00, -1+j->01, 1+j->11 and 1-j->10, it all makes sense with an output rate twice the input rate in the case of QPSK.
JM > I am investigating Meteor M2 decoding. So far I had tackled BPSK > decoding (RDS, GPS) and it is the first time I analyze QPSK signals. > Based on github.com/otti-soft/meteor-m2-lrpt.git, decoding works > fantastically well, but I don't understand why. Costas and MM Clock > recovery are understood, but it is the first time I meet the > Constellation Soft Decoder. I am unable to find any information on its > output and operating principle, but most worrying to me is that I > believed that the real output would exhibit four levels following the > decision of which bit pair was the most probable, but when displaying > on a scope the output of the Constellation Soft Decoder I only see two > well defined levels. > Can anyone bring some insight on this processing block, which would > help me understand the structure of the resulting file and hence start > tackling the digital decoding part of the protocol. > The flowgraph I use in this investigation is visible at > http://jmfriedt.sequanux.org/airspy_m2_lrpt_rxtest.png with an input > file containing complex I/Q samples collected during a Meteor M2 pass. > > Thanks, JM > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
