Re: Setting DPSK Demod Block Parameters

[Marcus Müller]

Hi Adam,

I'm very sorry, you **really** really shouldn't be using that block (and 
that's the reason it's deprecated): it has bugs that just lose data. So, 
it's not really all that useful if I spend time reading old GNU Radio's 
source code to figure out what /exactly/ you want: You'll have to use a 
different block, sorry. Can't offer you to fix that block, we've tried 
and decided against it.

Since you'll need to know the answers to these even if you implement 
this differently, let me quickly answer in-text:

On 22/12/2020 02.13, Adam Gorski wrote:
>   * Excess bandwidth: I’ve read that in general the more excess
>     bandwidth supplied the better you can expect your synchronization
>     algorithm to perform. This is [0,1], and when I set it to 1 it’s
>     noise resilience appreciably increases.

That's the parameter of the pulse shaping; it defines the roll-off 
factor of the RRC:

https://en.wikipedia.org/wiki/Raised-cosine_filter#Roll-off_factor

>   * FLL Bandwidth (assuming this is the same as filter lock-in
>     bandwidth): This and the two subsequent values default to 6.28/100.
>     I believe the higher this bandwidth is the faster the phase locked
>     loop can adjust the output of the frequency. This leads me to
>     believe I want this as high as possible, however I don’t know where
>     6.28 and 100 come from.

As in any control loop: When making the feedback loop's bandwidth large 
you gain speed, but you lose stability and resilience against noise.
In this case, that means your frequency correction will jump around. 
You'll really want to keep this small.

6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop 
bandwidth of 1/100. This is a large value for a "locked in" loop!

>   * Phase Loop Bandwidth: I know that lower values lead to reduced
>     levels of phase noise and refence spurs at the expense of longer
>     lock times and less phase margin. 

Exactly!

>     I’m assuming I want the least
>     phase noise possible, however I don’t know where 6.28 and 100 come from.

See above.

>   * Timing Bandwidth: A dsp exchange question mentions that optimum loop
>     bandwidth is usually somewhere between R/100 and R/20, where R is
>     the symbol clock rate being recovered. My symbol rate is 2 due to it
>     being BPSK, 

hm, not sure what symbol rate and constellation would have to do with 
another - symbol rate is the number of symbols you send per second.

>     is this the same as symbol clock rate? 

Yes.

>     Where do the 100
>     or 20 denominators come from?

Largely: trial and error. The idea is that you usually need to average 
quite some symbols' timing error estimates to get a low-variance 
estimate of the actual error with less influence of the data on it; much 
lower than 20 won't work, because you don't get sufficiently equal 
numbers of different symbol transitions.
Larger than 100 becomes problematic as you might be too slow.

> Should this value mirror the values of
>     FLL and Phase Loop bandwidths? 

Kind of, yes! If your timing drifts, that probably means that your whole 
system is slightly off in frequency - making the same linear degradation 
phenomenon happen to the phase (if we ignore the existence of the FLL).

The phase might, however, be also shifting due to channel influences, so 
you'd typically would want your phase loop to be slightly more agile 
than your timing loop, but these are, say, tunable screws for a fine 
adjustment. Keeping the factor of 2 pi in the PLL and the relative 
bandwidth here roughly equal does sound like an excellent starting point.

> My end goal is being able to identify the Mode S message preambles 
> within the demodulated bitstream. Any help is appreciated, thank you!

This sounds very cool!

Best regards,
Marcus