I had messed with psk31 a while back. There's a gnuradio module to decode and some example GRC's to send and receive that I had used here: https://github.com/tkuester/gr-psk31 that may help you out. The flowgraphs in the examples directory already have all the blocks set up to receive.
On Thu, Jun 15, 2017 at 9:29 AM, Federico 'Larroca' La Rocca < [email protected]> wrote: > Hi, > Nice problem you got there. In any case, have you considered performing > matched filtering (thus maximizing SNR), outputting more than one sample > per symbol (in fact, without decimation at all), then equalize (so that the > signal looks as if it was sent and received with a squared-root Nyquist > pulse) and after all that use a standard clock recovery block? Since you > know the shaping pulse, and as long as it does not go to zero over the > range of frequencies of interest, you should be able to transform it into a > Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols > will be difficult, so this may be worth trying. > best > Federico > > 2017-06-15 9:57 GMT-03:00 Phil Frost <[email protected]>: > >> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK >> where the pulses are a raised cosine (impulse, not frequency domain) twice >> the symbol duration[2], no error correction, at 31.25 baud. The transmitted >> signal has no ISI, but after matched filtering it does: >> >> [image: 0SDEq.png] >> >> I had hoped to do matched filtering and compensate ISI with a Viterbi >> equalizer, but I'm unsure how to do clock recovery. >> >> I hoped to use the polyphase clock recovery block, but it seems this >> won't work since the derivative of the signal may not be zero at the ideal >> sampling points. Is that an accurate assessment? >> >> [image: 2017-06-15-083544_393x230_scrot.png] >> >> Perhaps the clock recovery MM block? The zero crossings aren't exactly in >> the middle of the ideal sampling points, but the error is probably >> negligible. I can't get it to work: I think it outputs the correct bits, >> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1 >> depending on the adjacent bits. I'm using the default settings. Is that the >> intended behavior? >> >> [image: 2017-06-15-084108_1038x201_scrot.png] >> [image: 2017-06-15-084340_475x253_scrot.png] >> >> Finally, any other algorithms I should be considering? >> >> [1]: http://bipt106.bi.ehu.es/psk31.html >> [2]: https://ham.stackexchange.com/a/7744/218 >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
