# Re: DQPSK bug or incorrect settings? **URL:** \ **Category:** GNU Radio\ **Created:** [August 11, 2010, 3:52pm UTC](https://www.ruby-forum.com/t/re-dqpsk-bug-or-incorrect-settings/193115 "2010-08-11T15:52:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ikjtel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/bc8723/32.png) [@ikjtel](https://www.ruby-forum.com/u/ikjtel)\ **Post date:** [August 11, 2010, 3:52pm UTC](https://www.ruby-forum.com/t/re-dqpsk-bug-or-incorrect-settings/193115/1 "2010-08-11T15:52:13Z")
> In a word, NEVER. No self respecting communication systems designer would allow > that much excess bandwidth on the air or any realistic transmission medium. To me this doesn’t make sense. The spectral bandwidth required is never a function of the samples per symbol (SPS); it’s a function of the symbol rate (usually there are pulse shaping/filtering considerations too, but these are likewise unrelated to the SPS). Whether SPS equals two or ten, it comes out [of the LPF] the same. Of course the host bus bandwidth _might_ be impacted, but that’s a different question. > 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. In the op25-dev project we deal with signals with a 4800 baud rate and with soundcards for which 48,000 is the most common standard rate. This suggests a natural value for SPS (i.e., ten) and that value has always worked very well for us. This includes my modified version of gr\_mpsk\_receiver\_cc() - the two main mods that come to mind: - A simplified Gardner loop is used (in place of the M&M loop) - There’s a special hack to the Costas loop that’s needed to lock to PI/4 DQPSK I’ve been highly impressed with the error performance of the Gardner loop relative to the M&M loop. If there’s interest, I’ll publish a tgz of the code as it stands today - or (shameless plug) folks are encouraged to join the op25 project and help out… Best Regards Max ---
**Author:** ![ikjtel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/bc8723/32.png) [@ikjtel](https://www.ruby-forum.com/u/ikjtel)\ **Post date:** [August 11, 2010, 4:23pm UTC](https://www.ruby-forum.com/t/re-dqpsk-bug-or-incorrect-settings/193115/2 "2010-08-11T16:23:16Z")
On Wed, Aug 11, 2010 at 9:49 AM, ikjtel [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > In a word, NEVER. No self respecting communication systems designer would allow > > that much excess bandwidth on the air or any realistic transmission medium. > > To me this doesn’t make sense. The spectral bandwidth required is never a function of the > samples per symbol (SPS); it’s a function of the symbol rate (usually there are pulse > shaping/filtering considerations too, but these are likewise unrelated to the SPS). > > Whether SPS equals two or ten, it comes out [of the LPF] the same. Of course the host bus > bandwidth _might_ be impacted, but that’s a different question. Remember your Nyquist (at least with uniform sampling and dense signal space): you only need twice the sample rate as the bandwidth to fully represent the signal. If you are using more than 2 samples per symbol, you are oversampling. That is, you are wasting your radio’s time and power processing more samples than is required. The computational burden of a signal processing algorithm is pretty much proportional to the sample rate, so you always want to get to the lowest sample rate required as quickly as possible. > > 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. > > In the op25-dev project we deal with signals with a 4800 baud rate and with soundcards for which > 48,000 is the most common standard rate. This suggests a natural value for SPS (i.e., ten) and > that value has always worked very well for us. Sure, you bring the signal in at 10 sps. When working with the USRP(2)s, we do something similar. The USRP2 samples at 100 Msps, but we really don’t need all of those samples for most signals we are working with. So we first as the USRP2 to decimate down to something as small as possible while still representing the signal. Then, we usually go through stages of decimation as we are processing the signal to continually reduce the number of samples per symbol (and therefore the sample rate). > Max > I have no objections to having the Gardner loop in GNU Radio as a > matter of course; I think it’s good to have many different algorithms > available. However, we have actually moved past the analog-based clock > recovery schemes. If you look at the super-secret new D(B/Q)PSK > receiver code, we have implemented the use of a polyphase filterbank > clock recovery system (called gr\_pfb\_clock\_recovery\_cc or \_ff) that > works much better (it’s super-secret because it’s called dbpsk2.py or > dqpsk2.py and you have to use all of the examples with a 2 suffix to > access them; they will replace the current implementation soon > enough). Tom ---
**Author:** ![ikjtel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/bc8723/32.png) [@ikjtel](https://www.ruby-forum.com/u/ikjtel)\ **Post date:** [August 11, 2010, 4:37pm UTC](https://www.ruby-forum.com/t/re-dqpsk-bug-or-incorrect-settings/193115/3 "2010-08-11T16:37:54Z")
— On Wed, 8/11/10, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > If you are using more than 2 samples > per symbol, > you are oversampling. That is, you are wasting your radio’s > time and > power processing more samples than is required. The That wasn’t the point - the specific question concerned the required amount of occupied spectral “bandwidth on the air”, which isn’t affected by SPS. > filterbank > clock recovery system (called gr\_pfb\_clock\_recovery\_cc or > \_ff) that > works much better Probably because I didn’t spend sufficient time monkeying with that, it didn’t work for me, at least as compared to the Gardner. Until I’ve eliminated the newbi-ness factor w.r.t. that code, I can’t give any authoritative complaints about it yet… :-\ Max