While playing with DQPSK I have encountered a problem: Scheme: File_source -> DQPSK_mod -> DQPSK_demod -> File_sink
Parameters: samp_rate = 500 DQPSK_mod/demod samples per symbol = 215 DQPSK_mod/demod gray code = no everything else - by default Input bit sequence: 101010101100110011110000111110111011111011101110110110001011101011100100110100011010010000010000111011110101010110101010101111101100110011110010110110111111101010101100110110001111011010110000110010111001010000100100110110110101010110101010101010101100010010110000110101010110011011011000101010000111001010100101110110001101010000010010101010110101010110100010 Output bit sequence: 000000101000001000101010101010110011001111000011111111101111101110111011011000101110101110010010010101101001001101010010101110011001011010101010111110110011001111001011011011111110101010110011011000111101101011000011001111100110001110010010110110000000000101010101010101101100110110111101000100000100011000011100010111001011010101000010000111010001111010100100 I drop first 22 bits of output sequence (while demodulator is warming up) and compare them. This is what I get: 10101010110011001111000011111111101111101110111011011000101110101110010010010101101001001101010010 10101010110011001111000011111011101111101110111011011000101110101110010011010001101001000001000011 As you see, at some point they start to differ. My guess - too big "samples/symbol" to "samp_rate" rate, that causes M&M clock recovery to malfunction. Because at low "samples/symbol" all works well, no mistakes. If so, what is maximal and minimal safe "samples/symbol" to "samp_rate" rates? -- View this message in context: http://old.nabble.com/DQPSK-bug-or-incorrect-settings--tp29356347p29356347.html Sent from the GnuRadio mailing list archive at Nabble.com. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
