Stop making unneeded improvements

[Glen Langston]

Hello GNuradio Superheros,

I have to say, after 5 years with gnu radio, I’m either tool old or
something has to change.

I’ve been trying to produce some tools for High School teacher to do radio 
astronomy.
and for that gnuradio 3.7 was perfectly fine.  However some people are 
continuing
to make “improvements” that break everything.   I used to really like gnuradio.

I like the SDRPlay device, but it can not be used in gnuradio 3.8.  According 
to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind.  This 
breaks all my
existing C++ modules.   The modules worked fine, but if using ubuntu 20.40 the 
students can not
easily install gnuradio 3.7.  The pybind instructions are puzzling.  gr-modtool 
all the
modules copy something or other.   This is for no good reason that I’m aware of.
Either make the equivalent of pythons “2to3” or do not make the gnuradio 
fundamental changes.

Stop making useless changes that break all code!

We do NOT need these changes.  The advice on the web, after I’ve spent 2 days 
building 3.9
on a Raspberry pi is use 3.8.  This is frustrating.

The documentation is falling apart because of all these variants.

It is good to make changes that ADD tool capabilities.  It is NOT good to make 
changes that
make small improvements and break such large fractions of the code.

Sorry for the Rant.

Best regards Glen






> 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&amp;data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&amp;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