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