# DQPSK bug or incorrect settings?

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.

Thunder87 wrote:

If so, what is maximal and minimal safe “samples/symbol” to “samp_rate”
rates?

## Minimal “samples/symbol” is 2. Is there a maximal ?

View this message in context:
http://old.nabble.com/DQPSK-bug-or-incorrect-settings--tp29356347p29381418.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Sun, Aug 8, 2010 at 1:41 PM, Thunder87 [email protected]
wrote:

Thunder87 wrote:

If so, what is maximal and minimal safe “samples/symbol” to “samp_rate”
rates?

Minimal “samples/symbol” is 2.
Is there a maximal ?

215 is a pretty outrageous number to use; you should never need to
oversample that much.

2 to 4 is typical, 6-10 is about the highest you probably want to go.

Tom

In a word, NEVER. No self respecting communication systems designer
would allow that much excess bandwidth on the air or any realistic
transmission medium.

Typically 2-3 samples per baud is more than enough. You then use a
polyphase filter bank based clock recovery tool to FIND the correct
upsampled phase (at SAY, 6-10 samples per baud) but you never operate
the demodulator at that much oversampling.

I think Tom has finished and checked in the PFB based clock recovery
based on the work by fred harris last summer-ish. Am I right? If not,
if I may be off assistance in finishing, I will.

Bob

On 8/8/2010 5:00 PM, Tom R. wrote:

215 is a pretty outrageous number to use; you should never need to

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
â€œBe yourself, because the people who mind don’t
matter. And the people that matter don’t mind."
-Dr. Seuss

Tom R. wrote:

## Ok, thank you. 10 = max. Understood.

View this message in context:
http://old.nabble.com/DQPSK-bug-or-incorrect-settings--tp29356347p29383054.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Mon, Aug 9, 2010 at 8:46 AM, Bob McGwier [email protected] wrote:

I think Tom has finished and checked in the PFB based clock recovery based
on the work by fred harris last summer-ish. Am I right? If not, if I may be
off assistance in finishing, I will.

Bob

Yes, the PFB clock recovery and the PFB resampler are both working and
in the code. The version ‘2’ of the digital modulation examples
(benchmark_rx2.py, dbpsk2.py, etc) use both of these. In the receiver,
the PFB clock recovery algorithm is used to both find the clock and
downsample. In the transmitter, the PFB resampler is used in order to
allow any arbitrary bit rate to be used as opposed to the older
versions which used integer interpolation values to give discrete
symbol rate values.

We want to make these version 2 scripts the main modulator and
demodulator components but are waiting for a bit more robust testing.
From what I’ve heard from people using them (and in my own
experience), they work much better than the old ones. However, I
haven’t really heard from enough people to see what problems they are
experiencing, and I don’t want to rock the boat too much if people are
comfortable using the old versions. When we replace the old versions,
I’d like it to be as robust and seamless a change as possible. I feel
like we’re there, and so will probably be making the transition soon,