On Dec 22, 2020, at 3:43 PM, Adam Gorski <Adam.Gorski@vt-arc.org> wrote:
Marcus,
Thank you for the detailed response! This enriches my understanding of the
demod process as well as the knobs involved; looks like I'll have to go back to
the drawing board to implement something similar using non-deprecated blocks.
Thanks,
Adam Gorski
Virginia Tech Applied Research Corporation (VT-ARC)
Lead Communications Engineer
410-818-3188
-----Original Message-----
From: Discuss-gnuradio
<discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus
Müller
Sent: Tuesday, December 22, 2020 8:11 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Setting DPSK Demod Block Parameters
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
* 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