Re: stop making unneeded improvements

[Marcus D. Leech]

On 01/16/2021 09:00 PM, Glen Langston wrote:

Dear Marcus and all,

Thanks for all your efforts.  I really to appreciate all you’ve done.

Best regards,

Glen

We know you do, Glen.

Sometimes when you haven't been "inside the sausage factory" it can be a 
bit hard to understand why things are

  the way they are.

Heck, I've been involved with software development for longer than many 
on this list have been alive (!!), and I myself find it
  increasingly unpleasant to maintain a working installation of ANY 
piece of software--let alone Gnu Radio.  The inherent complexity
  automatically means a wide/deep dependency graph, which inevitably 
means much opportunity for nail-biting and hand-wringing,

  and general addiction to benzodiazepines :)








On Jan 16, 2021, at 8:30 PM, Marcus Müller  wrote:

Hi!

On 17.01.21 00:56, KB3CS - Chris wrote:


why does not in my mind figure just as prominently as GSoC: other
campaigns like GSoD or GSoGUI ? (does anyone actually need me to fill in
the definitions for those abbreviations?)

Well, the G in GSoC is "Google", not "GNU Radio": Google sponsors a
reasonable pay for a summer for students to work on open source projects
that apply for that kind of support.

The rules of that preclude documentation work, and we are usually in no
situation to spend much money. We work on changing that, but there's
never been significant funds to throw at a technical writer, and what's
more: the best tech writer needs either extensive domain knowledge, or
much close cooperation time with the tech people – and both are very
real limiting factors!

We did have multiple GSoC projects on GUI work. In fact, most years we
had one. Getting someone up to speed with the project, and the usage
patterns of the same, then have them contribute a great, and closed
piece of GUI is definitely a employee management challenge, and don't
forget that while these students are paid to work days like a proper
developer, that's not true for the mentors that are supposed to
supervise and support them – that's just extra workload atop of our
dayjobs, and other GNU Radio contributions.

i am now an elder veteran of much documentation and technical writing
and .. and .. and .. as one might expect after a lengthy and
wide-ranging career.

Is this going where I hope it is going?


where is the sustained outreach to *today's* new promising up-and-coming
Instructors (for tutorials), Technical Writers (to expand descriptions
and elucidate and footnote), and Documentation Writers (answering at
every turn - what is this? what is that? why is this? where are the
'knobs'? where are the 'connectors'?)
oh, it's a matter of money, i hear someone saying.. is it? is it really?

Yes, it is.
Also, our days have 24h, so I can either write, review, merge and
maintain code, or cooperate with a documentation writer. We honestly
wouldn't have the time to even "supervise" someone to spend the time
we're paying them for...

Google even had a GSoD, literally as you recommended. Small catch: it
was unpaid.

Barry has done wonders here: He's coming from a space systems
background, he's extremely clever, and he's picking up all the
documentation slack, in an extremely independent way. That is really,
really, incredible luck for us. Same with Marc, who's been doing a mix
of documentation, management, and SDR teaching. I mean, how unlikely is
it to find *two* people who are willing to do that, out of the goodness
of their heart?


who passed the hat lately? a boot? a plate? a tip cup? something? where?

Good point! We've been organizationally in a bit of a suboptimal
situation to receive extraneous funding, but so far our money came
primarily from sponsorships of companies at GRCon. The students working
on GSoC, as said, were paid directly by Google, who doesn't allow work
that is primarily documentation.

With SETI, we are now (pretty freshly) in a much better place, as
outreach (and that includes user-friendliness) are an official goal,
which might make money from various places at least attainable.

We have companies who dedicate engineer's time to us – that is
invaluable. Monetary contributions can be complicated for some
companies; that's one of the reasons why many companies choose to
sponsor GRCon: that's a controlling-friendly way of making an expense on
something.
We simply didn't have had a steady income that would allow us to sustain
a tech writer's compensation. I honestly don't know whether that has
changed – but with the organizational shift, GRCon'20 going online due
to epidemic problems, and whatnot…

please do press on forward but do not fear to ask for what is needed.

We ask for workpower!
You're a tech writer. We're an underdocumented project with a lack of
tech writers who know the project a bit.

Currently, we're seeing *huge* improvements compared to the past based
on what Marc Lichtmann and Barry Duggan have been doing. That is really
impressive, but I know the time that costs.
If you have an acute


no matter 

Re: stop making unneeded improvements

[Glen Langston]

Dear Marcus and all,

Thanks for all your efforts.  I really to appreciate all you’ve done.

Best regards,

Glen


> On Jan 16, 2021, at 8:30 PM, Marcus Müller  wrote:
> 
> Hi!
> 
> On 17.01.21 00:56, KB3CS - Chris wrote:
> 
>> why does not in my mind figure just as prominently as GSoC: other
>> campaigns like GSoD or GSoGUI ? (does anyone actually need me to fill in
>> the definitions for those abbreviations?)
> 
> Well, the G in GSoC is "Google", not "GNU Radio": Google sponsors a
> reasonable pay for a summer for students to work on open source projects
> that apply for that kind of support.
> 
> The rules of that preclude documentation work, and we are usually in no
> situation to spend much money. We work on changing that, but there's
> never been significant funds to throw at a technical writer, and what's
> more: the best tech writer needs either extensive domain knowledge, or
> much close cooperation time with the tech people – and both are very
> real limiting factors!
> 
> We did have multiple GSoC projects on GUI work. In fact, most years we
> had one. Getting someone up to speed with the project, and the usage
> patterns of the same, then have them contribute a great, and closed
> piece of GUI is definitely a employee management challenge, and don't
> forget that while these students are paid to work days like a proper
> developer, that's not true for the mentors that are supposed to
> supervise and support them – that's just extra workload atop of our
> dayjobs, and other GNU Radio contributions.
>> i am now an elder veteran of much documentation and technical writing
>> and .. and .. and .. as one might expect after a lengthy and
>> wide-ranging career.
> 
> Is this going where I hope it is going?
> 
>> where is the sustained outreach to *today's* new promising up-and-coming
>> Instructors (for tutorials), Technical Writers (to expand descriptions
>> and elucidate and footnote), and Documentation Writers (answering at
>> every turn - what is this? what is that? why is this? where are the
>> 'knobs'? where are the 'connectors'?) 
>> oh, it's a matter of money, i hear someone saying.. is it? is it really?
> 
> Yes, it is.
> Also, our days have 24h, so I can either write, review, merge and
> maintain code, or cooperate with a documentation writer. We honestly
> wouldn't have the time to even "supervise" someone to spend the time
> we're paying them for...
> 
> Google even had a GSoD, literally as you recommended. Small catch: it
> was unpaid.
> 
> Barry has done wonders here: He's coming from a space systems
> background, he's extremely clever, and he's picking up all the
> documentation slack, in an extremely independent way. That is really,
> really, incredible luck for us. Same with Marc, who's been doing a mix
> of documentation, management, and SDR teaching. I mean, how unlikely is
> it to find *two* people who are willing to do that, out of the goodness
> of their heart?
> 
>> who passed the hat lately? a boot? a plate? a tip cup? something? where?
> 
> Good point! We've been organizationally in a bit of a suboptimal
> situation to receive extraneous funding, but so far our money came
> primarily from sponsorships of companies at GRCon. The students working
> on GSoC, as said, were paid directly by Google, who doesn't allow work
> that is primarily documentation.
> 
> With SETI, we are now (pretty freshly) in a much better place, as
> outreach (and that includes user-friendliness) are an official goal,
> which might make money from various places at least attainable.
> 
> We have companies who dedicate engineer's time to us – that is
> invaluable. Monetary contributions can be complicated for some
> companies; that's one of the reasons why many companies choose to
> sponsor GRCon: that's a controlling-friendly way of making an expense on
> something.
> We simply didn't have had a steady income that would allow us to sustain
> a tech writer's compensation. I honestly don't know whether that has
> changed – but with the organizational shift, GRCon'20 going online due
> to epidemic problems, and whatnot…
>> please do press on forward but do not fear to ask for what is needed.
> 
> We ask for workpower!
> You're a tech writer. We're an underdocumented project with a lack of
> tech writers who know the project a bit.
> 
> Currently, we're seeing *huge* improvements compared to the past based
> on what Marc Lichtmann and Barry Duggan have been doing. That is really
> impressive, but I know the time that costs.
> If you have an acute
> 
>> no matter what it seems might be the result of honestly asking for help
>> when and where needed.
> 
> I promise money is welcome, very much so. I honestly don't know what
> kind of tax-deductible things we can offer. That's for someone else to
> explain!
> But, even more so: we're suffering success. When you ask [1] github how
> many people forked GNU Radio (and most of them do that to modify it and
> contribute their code back), github tells you:
> 
> 

Re: stop making unneeded improvements

[Marcus Müller]

Hi!

On 17.01.21 00:56, KB3CS - Chris wrote:

> why does not in my mind figure just as prominently as GSoC: other
> campaigns like GSoD or GSoGUI ? (does anyone actually need me to fill in
> the definitions for those abbreviations?)

Well, the G in GSoC is "Google", not "GNU Radio": Google sponsors a
reasonable pay for a summer for students to work on open source projects
that apply for that kind of support.

The rules of that preclude documentation work, and we are usually in no
situation to spend much money. We work on changing that, but there's
never been significant funds to throw at a technical writer, and what's
more: the best tech writer needs either extensive domain knowledge, or
much close cooperation time with the tech people – and both are very
real limiting factors!

We did have multiple GSoC projects on GUI work. In fact, most years we
had one. Getting someone up to speed with the project, and the usage
patterns of the same, then have them contribute a great, and closed
piece of GUI is definitely a employee management challenge, and don't
forget that while these students are paid to work days like a proper
developer, that's not true for the mentors that are supposed to
supervise and support them – that's just extra workload atop of our
dayjobs, and other GNU Radio contributions.
 > i am now an elder veteran of much documentation and technical writing
> and .. and .. and .. as one might expect after a lengthy and
> wide-ranging career.

Is this going where I hope it is going?

> where is the sustained outreach to *today's* new promising up-and-coming
> Instructors (for tutorials), Technical Writers (to expand descriptions
> and elucidate and footnote), and Documentation Writers (answering at
> every turn - what is this? what is that? why is this? where are the
> 'knobs'? where are the 'connectors'?) 
> oh, it's a matter of money, i hear someone saying.. is it? is it really?

Yes, it is.
Also, our days have 24h, so I can either write, review, merge and
maintain code, or cooperate with a documentation writer. We honestly
wouldn't have the time to even "supervise" someone to spend the time
we're paying them for...

Google even had a GSoD, literally as you recommended. Small catch: it
was unpaid.

Barry has done wonders here: He's coming from a space systems
background, he's extremely clever, and he's picking up all the
documentation slack, in an extremely independent way. That is really,
really, incredible luck for us. Same with Marc, who's been doing a mix
of documentation, management, and SDR teaching. I mean, how unlikely is
it to find *two* people who are willing to do that, out of the goodness
of their heart?

> who passed the hat lately? a boot? a plate? a tip cup? something? where?

Good point! We've been organizationally in a bit of a suboptimal
situation to receive extraneous funding, but so far our money came
primarily from sponsorships of companies at GRCon. The students working
on GSoC, as said, were paid directly by Google, who doesn't allow work
that is primarily documentation.

With SETI, we are now (pretty freshly) in a much better place, as
outreach (and that includes user-friendliness) are an official goal,
which might make money from various places at least attainable.

We have companies who dedicate engineer's time to us – that is
invaluable. Monetary contributions can be complicated for some
companies; that's one of the reasons why many companies choose to
sponsor GRCon: that's a controlling-friendly way of making an expense on
something.
We simply didn't have had a steady income that would allow us to sustain
a tech writer's compensation. I honestly don't know whether that has
changed – but with the organizational shift, GRCon'20 going online due
to epidemic problems, and whatnot…
> please do press on forward but do not fear to ask for what is needed.

We ask for workpower!
You're a tech writer. We're an underdocumented project with a lack of
tech writers who know the project a bit.

Currently, we're seeing *huge* improvements compared to the past based
on what Marc Lichtmann and Barry Duggan have been doing. That is really
impressive, but I know the time that costs.
If you have an acute

> no matter what it seems might be the result of honestly asking for help
> when and where needed.

I promise money is welcome, very much so. I honestly don't know what
kind of tax-deductible things we can offer. That's for someone else to
explain!
But, even more so: we're suffering success. When you ask [1] github how
many people forked GNU Radio (and most of them do that to modify it and
contribute their code back), github tells you:

""Woah, this network is huge! We’re showing only some of this network’s
repositories.""

That means an immense amount of work literally flows into nothing but
making everyone happy (which might be contrary to the interest of the
fewer people who'd like GNU Radio to stay exactly like it was, it seems)
in the sense of keeping it running for their machines, and 

Re: stop making unneeded improvements

[KB3CS - Chris]

On Fri, 08 Jan 2021 22:16:22 -0500, "Marcus D. Leech" <
patchvonbr...@gmail.com> wrote a great many things, and then this excerpt:

> I "get" the whole "oh, but it's so very close to what I need".  But GR
> really is just a specialized programming environment, and GRC
>has the unfortunate (in some sense) side effect of making it seem
> like something else, sometimes tantalizingly so.
>
> Part of the problem here is that GRC isn't particularly *tutorial* in
> nature, and there has historically, and continues to be, a problem with
>providing adequate documentation on a block-by-block basis.  This is
> fixable by the mere application of hundreds of hours of
>tech-writer time.  That time, in the 16 years that GR has existed,
> has yet to materialize.  Coders are notoriously poor documentation people,
>and very-few tech writers seem to be imbued with the same
> public-spiritedness as competent coders.  This is not a problem
>peculiar to GR...
>
> Nobody in the GR "management" would be at all unhappy for folks to
> contribute to making it better-documented and with a
>"slicker" UI framework in GRC.   There's no conscious effort to block
> that.  But the pool of contributors are generally focussed
>on other things.  Just the nature of an open-source project.
>
 [... followed by more things ...]

is it possible part of what is going on here is an unfortunate lack of
imagination on the part of our GNURadio leadership? Wait, hang on a second,
before you greybeards (like mine) get huffy and ready to strike me down for
my insolence and/or impudence ..

what i have seen, for quite a while and ongoing, are the annual efforts to
expand the GNURadio codebase. i have also witnessed honest assessments of
the state of documentation, tutorials, and GUI elements.

why does not in my mind figure just as prominently as GSoC: other campaigns
like GSoD or GSoGUI ? (does anyone actually need me to fill in the
definitions for those abbreviations?)

i am now an elder veteran of much documentation and technical writing and
.. and .. and .. as one might expect after a lengthy and wide-ranging
career.

where is the sustained outreach to *today's* new promising up-and-coming
Instructors (for tutorials), Technical Writers (to expand descriptions and
elucidate and footnote), and Documentation Writers (answering at every turn
- what is this? what is that? why is this? where are the 'knobs'? where are
the 'connectors'?) ?

oh, it's a matter of money, i hear someone saying.. is it? is it really?
who passed the hat lately? a boot? a plate? a tip cup? something? where?

please do press on forward but do not fear to ask for what is needed. no
matter what it seems might be the result of honestly asking for help when
and where needed.

 M-^Wr@M->@EM-QM-^FNO CARRIER

Re: Stop making unneeded improvements

[Lamar Owen]

On 1/13/21 10:13 AM, Marcus D. Leech wrote:

On 01/12/2021 02:51 PM, Lamar Owen wrote:
I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX 
daughterboard; it just quit working, and while I've reported to the 
UHD list no action has been taken to fix the regression.
I was able to reproduce the regression issue with DBS-RX on my own 
ancient USRP1 hardware, and it has been reported.  But I don't know
  how much engineering bandwidth will be devoted to fixing it. The 
regression goes back a few UHD release versions--I didn't go all the way
  "back in time" to figure out where it happened, but it isn't just 
with the latest release :(


There's another module that had a similar problem, let's see, UHD Github 
Issue #304.  I filed my issue as issue #394.  It seems to be a similar 
issue with a simila construct; my C++ skills aren't keen enough to fix 
it myself, because the patch that fixed #304 was not obvious to me.  But 
I'm not very experienced with C++ (regular C, some, Python a bit more, 
Z80 assembly language a whole lot (fat lot of good that language will do 
for me, right? :-) )). Someone who knows the code could probably fix it 
in less than an hour.  Given enough time I can learn what the difference 
in the RFX code was and apply a similar patch to the DBS-RX code, just 
haven't had enough time to dig in to it yet; I figure it will take me, 
since I'll have to do a whole lot of reading to understand the 
constructs in this code first, four to eight hours.  Just hasn't gotten 
back to the top of the pile yet.



Anyway, thanks for confirm my issue isn't local to me, by the way.

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/12/2021 02:51 PM, Lamar Owen wrote:




I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX 
daughterboard; it just quit working, and while I've reported to the 
UHD list no action has been taken to fix the regression.
I was able to reproduce the regression issue with DBS-RX on my own 
ancient USRP1 hardware, and it has been reported.  But I don't know
  how much engineering bandwidth will be devoted to fixing it.  The 
regression goes back a few UHD release versions--I didn't go all the way
  "back in time" to figure out where it happened, but it isn't just 
with the latest release :(

Re: Stop making unneeded improvements

[Lamar Owen]

[Accidentally sent this from the wrong account this is the right 
one]


On 1/5/21 10:30 AM, Glen Langston wrote:
Concerning my previous email, sent in extreme frustration. I 
understand that we all want to make improvements and progress. 
I want to take a moment and thank Glen for posting these messages. I had 
no idea his group was doing some of the things that they are; what a 
timely discovery, since I'm working on better backends for our radio 
telescopes as well, and what Glen has pointed to is very well written 
and implemented as far as I can tell.


I want to echo his frustrations; sometimes it seems things move too 
fast, and sometimes too slow.  I have used various versions of GNUradio 
over the years, and it's been one of the packages that should be the 
poster child for the "don't try to remember anything you learned, since 
it's all going to change anyway" school of development. Python 2 to 
Python 3 is bad enough; although I did a port to Python 3 of an antenna 
control shim for a program to interface a azimuth-elevation control 
setup to run with the right ascension-declination controls of two of our 
instruments; again, I understand the Python devs reasoning but man it 
was a pain to get all the new syntax and semantics (especially for 
string handling, from UTF to byte strings for the TCP/IP backend control 
protocol!) right and just working again; and that was just a few hundred 
lines of code.  And I know you, the GNUradio developers, had it even 
rougher with all the changes; I sympathize.


GNUradio has a large set of dependencies, for sure, and this has always 
been the thing that has made using it on various distributions rather 
difficult at times.  Having to rewrite a module because you updated the 
underlying operating system, and thus dependencies A, B, P, and Z all 
got updates that requires a GNUradio version update that requires a 
rewrite and maybe even a certification/calibration test of the new 
module it does get frustrating.


Updates shouldn't break things willy-nilly!  (this is also the case with 
another piece of software I use, PostgreSQL, where backend data formats 
and modules can break between major versions).  I personally would have 
liked GNUradio 3.8 to have carried a version of 4.0 to indicate that it 
is a major version upgrade; if moving from Python 2 to Python 3 wasn't 
enough to trigger that version bump, what is?


I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX 
daughterboard; it just quit working, and while I've reported to the UHD 
list no action has been taken to fix the regression.  The DBS-RX has 
been calibrated by us for this application, and now I'm going to have to 
calibrate (or rather, have a couple of spring/summer interns enrich 
their learning experience by doing this calibration) another SDR; 
probably a modified ADALM-Pluto (GPS-locked clocking mod using a Leo 
Bodnar GPS-DO to drive the sample clock) or a LimeSDR; the frequency 
ranges I need are 1.2GHz to 1.7GHz (HI line spectroscopy with larger red 
and blue shifts for extragalactic source work) and 2.0GHz to 2.3GHz.  
SDRPlay, AirSpy, and most of the cheap RTL-SDRs won't tune that last 
range; DBS-RX does and worked well for us back of now.


Yes, I know PROGRESS.  And progress is certainly needed; but 
progress can be painful.  So while I'm not complaining per se, I do want 
to echo the concerns that especially Glen has raised.

--


pari 


Lamar Owen, /Chief Technology Officer/
Pisgah Astronomical Research Institute
/A not-for-profit public organization/
Email lo...@pari.edu 
Telephone 828.862.5554  | Fax 828.862.5877 


1 Pari Drive, Rosman, NC 28772
www.pari.edu 
fb ig 
in 
tw 
yt 

Re: Stop making unneeded improvements

[paul]

Very many thanks, Marcus.
Best wishes. Paul

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/08/2021 12:38 AM, p...@dbnut.com wrote:
[Apologies for the lack of paragraph breaks in that last - taken by 
surprise after using a crude editor]


Thank you, Marcus, for taking so much trouble to respond so 
comprehensively. And with such good grace!


Your detailed section on dependencies is very sobering and helps me 
understand much better how vulnerable GR is in that respect, plus how 
essential it is to restructure from time to time and how painful that 
is going to be. In some ways the timing was unfortunate for me - a few 
years earlier or later your project might have been a little less 
"dynamic".
Nearly-all modern software that is anything other than trivial has a 
"dependency iceberg".  For commercial software, a bit less so, and it's
  driven a lot by licensing terms--the company I worked for most 
recently (now semi-retired, thank Cthulu) did a lot of replication of
  underlying technologies, because the licensing of the "totally 
perfect" open-source stuff interfered with the companies business goals.


But for open-source software, there's a long and strong tradition of 
"standing on the shoulders of giants".  This does mean a bit of

  risk, but overall, it means you can deliver better stuff, faster.


Also I can now understand your (and presumably the majority) 
perspective on the Companion as more of a debugging tool, while for me 
it served more like Visual Studio for a WinForms project (not a very 
accurate comparison, but I think you'll see what I'm getting at). The 
fact remains that GRC exists, it is apparently used quite widely by 
people like me with lesser skills, and its GUI wrappers for on-tree 
blocks enable a fantastic scope for some *highly* complex system 
prototyping.


You may not want to emphasise GRC's stand-alone talents but 
flowgraphing is an increasingly capable and popular tool class, not 
entirely unlike GUI visual designers.


In contrast, my (prototype) flowgraph was so simple as to be almost 
laughable (and I should have made that clear at the start). Yes, it 
was a "radio": reading from an I-Q file, the essentials being several 
stages of frequency translation, decimation, assorted filters, 
Hilberts, Costas, finally audio to sound card. Just rather different 
from the many examples on the web. As for GUI, a couple of spectrums 
and waterfalls, a 'scope, assorted selectors, and tuning.


Ah, tuning. I ended up with one slider for *each* decade digit from 1 
MHz down to 0.01 Hz (don't ask). That's why I was looking for up/down 
buttons to configure tuning step using a single slider. Now you'll 
probably tell me I'm a moron because XYZ will deliver exactly that. Oh 
well, I'm a hermit and don't ask questions but should have done.
I understand the "just a radio" user-interface widget you're going for 
with that--many of the popular SDR-for-casual-airwave-surfers
  applications include something like that.  I've never found it 
particularly useful for *myself*.   Part of the problem is that GR is 
"stuck" using
  whatever bits and pieces of UI that toolkits like Qt provide. 
Creating new UI componentry would be:


  (A) A distraction from the DSP core-purpose
  (B) Lead to complicated questions about whether those new GUI 
elements get "upstreamed" to Qt or held as "private" extensions





That brings me with trepidation to DSP understanding/skills. My maths 
degree is ancient with a thick coating of rust and, however deep you 
dig, not a mention of difference equations. So I'm a baby in this new 
world. But please give me credit for having read hundreds of pages on 
DSP at various levels - not enough to use Matlab or write Python 
routines, but enough to configure ready-made GRC filter blocks and be 
aware when I'm over my head.


The point is, I take the view that (broadly speaking) there are two 
levels of understanding: creator and informed/educated user. You are 
the first type, I'm somewhere near the other end of the scale. By 
analogy, I can use a highly sophisticated communications receiver to 
great effect with almost no expertise in electronics design.
Right, and it is the "I can use a sophisticated communications receiver" 
aspect where there's a cognitive disconnect, I think.   GR is NOT
  "just a sophisticated radio with a lot of buttons", but is rather a 
*toolkit* that would certainly allow you to *create* "a sophisticated radio

  with a lot of buttons".

Diving back into the analog/hardware world.  If I come upon a box full 
of parts and I want to build "the coolest radio ever", I would not
  be surprised to find that the box of parts in and of itself, is of no 
use in helping me achieve that goal without some considerable background
  knowledge.  Yet, if I insisted that said box *should* somehow provide 
me with instant ability and skill, I'd be, correctly, thought of as a bit

  of a kook.

Now, the analog with GR and GRC is imperfect, and I fully acknowledge that.



And the bottom line on this one is [as always, from my perspective] 

Re: Stop making unneeded improvements

[Kevin McQuiggin]

Hi Paul:

FYI, I was in largely the same position re DSP and SDR several years ago, that 
is, of a newbie with strong computing science and math background, and fairly 
good radio systems knowledge, but with dust on the mathematics side for a 
couple of decades.

I found a fantastic introductory textbook online at http://www.dspguide.com, 
“The Scientists and Engineers' Guide to Digital Signal Processing by Dr. Steve 
Smith.  It starts with the basics and builds up a fairly good understanding of 
the topic, and for me that was a good starting point to begin working with 
Gnuradio and understanding how things are put together.

The book is downloadable as a PDF, but I liked it so much I bought a hard copy. 
 

I’m still a neophyte in the field compared to a lot of the experts here and 
those deeply involved with the project, but with this basic knowledge and the 
ability to tinker with the blocks, and sometimes read the C++ source code for 
more insight, I have gotten some pretty interesting projects going and learned 
a lot.  

I tend to use Gnuradio for the front end of projects and then pass demodulated 
bits to my own C code for processing (and vice versa), but this approach works 
well enough for me, for what I am trying to accomplish.  GRC is great for 
“playing around” easily and figuring out what works.

Hope you or someone else on the list finds the book suggestion helpful, 
although I should also mention Gnuradio tutorials which have been revamped 
lately, and the excellent examples which come with every Gnuradio installation. 
 

The book doesn’t cover radio specifically, and in fact that is good because the 
signal processing concepts it discusses apply as well to audio, for example, as 
they do to radio signal processing.

Kevin

Sent from my iPad

> On Jan 7, 2021, at 21:38, p...@dbnut.com wrote:
> 
> [Apologies for the lack of paragraph breaks in that last - taken by surprise 
> after using a crude editor]
> 
> Thank you, Marcus, for taking so much trouble to respond so comprehensively. 
> And with such good grace!
> 
> Your detailed section on dependencies is very sobering and helps me 
> understand much better how vulnerable GR is in that respect, plus how 
> essential it is to restructure from time to time and how painful that is 
> going to be. In some ways the timing was unfortunate for me - a few years 
> earlier or later your project might have been a little less "dynamic".
> 
> Also I can now understand your (and presumably the majority) perspective on 
> the Companion as more of a debugging tool, while for me it served more like 
> Visual Studio for a WinForms project (not a very accurate comparison, but I 
> think you'll see what I'm getting at). The fact remains that GRC exists, it 
> is apparently used quite widely by people like me with lesser skills, and its 
> GUI wrappers for on-tree blocks enable a fantastic scope for some *highly* 
> complex system prototyping.
> 
> You may not want to emphasise GRC's stand-alone talents but flowgraphing is 
> an increasingly capable and popular tool class, not entirely unlike GUI 
> visual designers.
> 
> In contrast, my (prototype) flowgraph was so simple as to be almost laughable 
> (and I should have made that clear at the start). Yes, it was a "radio": 
> reading from an I-Q file, the essentials being several stages of frequency 
> translation, decimation, assorted filters, Hilberts, Costas, finally audio to 
> sound card. Just rather different from the many examples on the web. As for 
> GUI, a couple of spectrums and waterfalls, a 'scope, assorted selectors, and 
> tuning.
> 
> Ah, tuning. I ended up with one slider for *each* decade digit from 1 MHz 
> down to 0.01 Hz (don't ask). That's why I was looking for up/down buttons to 
> configure tuning step using a single slider. Now you'll probably tell me I'm 
> a moron because XYZ will deliver exactly that. Oh well, I'm a hermit and 
> don't ask questions but should have done.
> 
> That brings me with trepidation to DSP understanding/skills. My maths degree 
> is ancient with a thick coating of rust and, however deep you dig, not a 
> mention of difference equations. So I'm a baby in this new world. But please 
> give me credit for having read hundreds of pages on DSP at various levels - 
> not enough to use Matlab or write Python routines, but enough to configure 
> ready-made GRC filter blocks and be aware when I'm over my head.
> 
> The point is, I take the view that (broadly speaking) there are two levels of 
> understanding: creator and informed/educated user. You are the first type, 
> I'm somewhere near the other end of the scale. By analogy, I can use a highly 
> sophisticated communications receiver to great effect with almost no 
> expertise in electronics design.
> 
> And the bottom line on this one is [as always, from my perspective] for a 
> wide range of applications you *can* get by without anything more than GRC 
> (i.e. no coding). And where GRC does fall "short of 

Re: Stop making unneeded improvements

[paul]

[Apologies for the lack of paragraph breaks in that last - taken by 
surprise after using a crude editor]


Thank you, Marcus, for taking so much trouble to respond so 
comprehensively. And with such good grace!


Your detailed section on dependencies is very sobering and helps me 
understand much better how vulnerable GR is in that respect, plus how 
essential it is to restructure from time to time and how painful that is 
going to be. In some ways the timing was unfortunate for me - a few 
years earlier or later your project might have been a little less 
"dynamic".


Also I can now understand your (and presumably the majority) perspective 
on the Companion as more of a debugging tool, while for me it served 
more like Visual Studio for a WinForms project (not a very accurate 
comparison, but I think you'll see what I'm getting at). The fact 
remains that GRC exists, it is apparently used quite widely by people 
like me with lesser skills, and its GUI wrappers for on-tree blocks 
enable a fantastic scope for some *highly* complex system prototyping.


You may not want to emphasise GRC's stand-alone talents but flowgraphing 
is an increasingly capable and popular tool class, not entirely unlike 
GUI visual designers.


In contrast, my (prototype) flowgraph was so simple as to be almost 
laughable (and I should have made that clear at the start). Yes, it was 
a "radio": reading from an I-Q file, the essentials being several stages 
of frequency translation, decimation, assorted filters, Hilberts, 
Costas, finally audio to sound card. Just rather different from the many 
examples on the web. As for GUI, a couple of spectrums and waterfalls, a 
'scope, assorted selectors, and tuning.


Ah, tuning. I ended up with one slider for *each* decade digit from 1 
MHz down to 0.01 Hz (don't ask). That's why I was looking for up/down 
buttons to configure tuning step using a single slider. Now you'll 
probably tell me I'm a moron because XYZ will deliver exactly that. Oh 
well, I'm a hermit and don't ask questions but should have done.


That brings me with trepidation to DSP understanding/skills. My maths 
degree is ancient with a thick coating of rust and, however deep you 
dig, not a mention of difference equations. So I'm a baby in this new 
world. But please give me credit for having read hundreds of pages on 
DSP at various levels - not enough to use Matlab or write Python 
routines, but enough to configure ready-made GRC filter blocks and be 
aware when I'm over my head.


The point is, I take the view that (broadly speaking) there are two 
levels of understanding: creator and informed/educated user. You are the 
first type, I'm somewhere near the other end of the scale. By analogy, I 
can use a highly sophisticated communications receiver to great effect 
with almost no expertise in electronics design.


And the bottom line on this one is [as always, from my perspective] for 
a wide range of applications you *can* get by without anything more than 
GRC (i.e. no coding). And where GRC does fall "short of that goal", 
*maybe* GRC warrants a bit more effort to widen the goal mouth. It just 
feels a bit harsh hearing "nothing requires that you use GRC" if GRC is 
ostensibly up to the job while the skills gap to make do without it is 
so daunting.


Sorry to have laboured that point.

As previously, I have learned a lot from your exposition, Marcus. And 
I'm grateful for your time responding. It's not my intention to try and 
have the last word, so I'll shut up now and go back to my cave.


[BTW good to read Geof Nieboer's 4 Jan update on Windows installer]

Paul White

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/07/2021 03:32 PM, p...@dbnut.com wrote:
Prompted to write by Glen Langston's post, I'm an old man resurrecting 
an old moan, and in a minority that (I believe) is just not catered for:


* Windows user
* Non-programmer (of any great consequence)
It was NEVER a goal of GR to make it easy for those without skills in 
programming, radio, and DSP to be successful despite those
  handicaps.  There has been a growing perception that GR is "just a 
radio with a lot of knobs".  It isn't.  It's a programming
  environment for a highly-specialized discipline, notably signal 
processing.   GRC has had the unfortunate side-effect of making
  GR seem like "a radio with a lot of knobs", and certainly if that's 
your perception of what GR is, then GRC will fall fare short of that goal.


If you expect to be brilliantly successful despite a lack of the 
requisite skills, and blame the *tools* for your lack of success, then you
  should perhaps take a breath and re-think your position.   I liken 
this attitude to some rich fool buying an A320, taking himself and
  his closest friends up in it for a maiden flight, only to be 
disappointed that he and his friends are now all dead, because they couldn't
  be bothered to learn how to be a pilot, study theory-of-flight, 
avionics, navigation, etc, etc, etc.  But that's clearly the tools 
fault, right?


Let's you think I'm some young punk, I'll be 60 in a couple of years.  
That makes me, decidedly, an "old fart" in this game.


A couple of years ago I became hooked on GRC after watching Balint 
Seeber's YouTube videos that convinced me this was a great 
non-programming solution to a long-standing problem of mine.
You clearly mis-understood what you were seeing.   GRC has this 
unfortunate side-effect.  Could GRC be "better" (for whatever value
  of "better" you want to use)?  Of course.  But don't think for a 
moment that you'll ever get around the fact that you'll need to understand
' what you're doing, both in terms of DSP knowledge and programming 
knowledge and experience.  That's not what GR is, and I'd
  challenge you to find ANY tool in a deeply technical field like 
signal processing that removes the need to understand what you're
  doing, and why.But if you're at the level of "why should I need 
to understand what roles filters play, what sample-rates imply,
  how demodulators work" then you should look elsewhere.  You'll be 
looking for a very long time.


Another proximate example.  There are now lots of really awesome tools 
that neurosurgeons use to help them do their jobs.
  But not a single one of those neurosurgeons go into that operating 
room without any understanding of anatomy, neurology,
  neuro-pharmacology, and years and years of experience as an intern.  
They don't simply waltz in there, turn on the

  "Surgeons Assistant 5000" device, and push the "cure my patient" button.

True, after 6 months I managed to fumble my way to a flowgraph that 
sort-of got the job done. But there were serious limitations, such as 
WX widget deficiencies including only mono audio stream for some 
sources/sinks (just how out-of-date can you be in the 21st century?).
So I tried to migrate to QT, and what happens? Every one of the 
replacement widgets looks and behaves differently from its predecessor 
and, in several cases, has significantly reduced functionality.
I'll point out that GR is, at its core, just a set of library functions, 
a buffer manager, and a thread scheduler. There is ABSOLUTELY NO REQUIREMENT
  to use the facilities of GRC, and no requirement to use its 
world-view of the GUI widgets.  GQRX is one example out there, and I myself
  built a fairly-complex GR-based application using the XForms toolkit 
years and years ago.
Add in inexplicable control gaps like decade "thumb-wheels" (for 
tuning) or command buttons (e.g. to increment a variable by a preset 
amount) and it's clear that Gnu Radio Companion fails to replicate 
anything like a basic RADIO front panel.
Because GR isn't as I've pointed out, "just a big radio with a lot of 
knobs".   BTW sliders can be used and configured for whatever increment and
  range you want--and, again, you are not constrained to use any 
particular GUI toolkit with GR.GRCs GUI toolkit was largely 
initially imagined
  as a way of having some debugging tooling lying around, and not 
necessarily to produce a "gorgeous radio front-panel".  That it has *just*
  enough functionality to convince you that it is heading for the 
"gorgeous radio front-panel" direction, rather than the "help me debug my
  application" direction can certainly lead you to find it seriously 
wanting.  But, again, nothing requires that you use GRC or its particular

  set of widgets.

I won't even start moaning about changes to Python versions and 
libraries.
What kind of a development strategy is that? It's no excuse that you 
rely on a team of volunteers. If you want quality you need leadership, 
direction and team players - every 

Re: Stop making unneeded improvements

[paul]

Prompted to write by Glen Langston's post, I'm an old man resurrecting 
an old moan, and in a minority that (I believe) is just not catered for:


* Windows user
* Non-programmer (of any great consequence)

A couple of years ago I became hooked on GRC after watching Balint 
Seeber's YouTube videos that convinced me this was a great 
non-programming solution to a long-standing problem of mine.
True, after 6 months I managed to fumble my way to a flowgraph that 
sort-of got the job done. But there were serious limitations, such as WX 
widget deficiencies including only mono audio stream for some 
sources/sinks (just how out-of-date can you be in the 21st century?).
So I tried to migrate to QT, and what happens? Every one of the 
replacement widgets looks and behaves differently from its predecessor 
and, in several cases, has significantly reduced functionality.
Add in inexplicable control gaps like decade "thumb-wheels" (for tuning) 
or command buttons (e.g. to increment a variable by a preset amount) and 
it's clear that Gnu Radio Companion fails to replicate anything like a 
basic RADIO front panel.
I won't even start moaning about changes to Python versions and 
libraries.
What kind of a development strategy is that? It's no excuse that you 
rely on a team of volunteers. If you want quality you need leadership, 
direction and team players - every programmer following his own whim to 
produce "cool stuff" on his own agenda is a recipe for disaster. I've 
been a "volunteer" myself for 15 years, trying to put something back 
into the radio community I love, with never a cent in return, and don't 
do "cool stuff".
BTW under "cool stuff", I include the disgraceful self-promotion and 
waste of valuable time in the YouTube video 
https://www.youtube.com/watch?v=bHjITd2HR-g_channel=GNURadio.
The golden rules for development include doing the basics well, 
backwards compatibility, not breaking what already works, incremental 
improvement, giving priority to fixing bugs/defects, and testing, 
testing, testing. GRC has broken all of these big time over the years.
If during my working life I had been so cavalier in my attitude, I would 
have lost my job many times over.
I suppose the real problem (for me) is that GRC is written by DSP 
experts for DSP students who get by with a little help from their 
friends, adding a bit of Python here and C++ there. In other words, GRC 
is *not* the general purpose learner's tool that comes across in the 
Balint intro.
As for the lack of support for Windows, how can you possibly ignore 
(more-or-less) the No. 1 operating system with its large pool of users 
hungry for GRC-type tools? If your fundamentalist fixation on *nix 
prohibits contact with the unclean, please have the honesty to label 
your product accordingly.


I repeat my acceptance of being in a minority, apologise too for the 
rant, and realise it will not make any difference. But best wishes for 
the future.


Paul White

Re: Stop making unneeded improvements

[Andrej Rode]

Hi all, 

to jump in from a point of someone who has contributed "improvements"
over the last couple of years.

Many of your points are vaild, I understand your frustation and pain of
continuouly having to adapt to new methodologies. 
Believe me when I say we are not these changes are not implemented just
for the fun of it. All of the changes you mentioned were mostly forced
with a gun on our chest to either implement a change or to simply not
have a usable GNU Radio for new Linux Operating System Releases. 

One of the reasons is that most of the GNU Radio development is
done by volunteers in their free time. Changes to GNU Radio reflecting
changes in dependencies which would have been useful to implement long
before said dependency is obsolete have been implemented in the last
possible momont, e.g Qt4,Python3. This lead to partially
untested/unmature code being pushed into a release. For at least Debian
and Gentoo GNU Radio has been the last package either on Qt4 or on
Python2 and patches have been backported to GNU Radio 3.7 by the OS
maintainers (Thanks!) to keep it in the operating system.

It's also quite hard to demand 100% backwards compatibility for
breaking changes and tools which provide full coverage for conversion
between breaking changes. I know the Python tools and I love them. But
development of these follow the Pareto principle. 80% of the tool is
written in 20% of the time. 80% or similar is what we are able to
provide and what gr_modtool provides in terms of conversion. For simple
cases conversion just works, but for complex setups you have to add
some additional changes by hand. 

TLDR: these changes are partly forced on GNU Radio by having a list of
dependencies. Core developers are doing their best to give users the
ability to convert between versions, but it's lacking and any help is
appreciated.

Cheers
Andrej

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/05/2021 09:24 AM, Johannes Demel wrote:

Hi Glen,

I fully understand your frustration to make things work long term and 
constant breakage.


There are, however, reasons why breaking changes are unavoidable. Some 
examples are:

1. GRC used Cheetah with XML for block definitions BUT:
Cheetah got unmaintained for years. Cheetah is only available for 
Python2. Python2 support ran out. Instead of relying on an 
unmaintained project, GRC switched to Mako which uses YAML instead.
This is a pretty-generic problem with ANY package that has dependencies 
on other package--which in the open-source world basically amounts
  to "all of them".  If something you depend on is no longer 
maintained, then there's a good chance that in the future, it simply 
will stop working
  on some future release of an OS.  So, it's probably better to make 
the decision earlier rather than later to abandon an unsupported ship.
  This has consequences of variable unpleasantness, but it is prudent 
regardless.



I know that a lot of package maintainers do a fantastic job to make GR 
available for their respective systems. I hope that helps to get the 
installation process going.
I'd like to refer to Geof Nieboers recent email where he explains all 
the difficulties that come up with old software.
In general the process of updating applications from 3.7 to post-3.7 is 
less intrusive than the famous 3.6 to 3.7 transition.  Nowhere near

  as painful, but still painful.

Re: Stop making unneeded improvements

[Glen Langston]

Dear Johannes and all members of the GNURadio community,

Happy New Year.  I hope all are doing well.

Thanks for all your efforts!

Concerning my previous email, sent in extreme frustration.   I understand
that we all want to make improvements and progress.  

Concerning your points below.   I understand that python2 is being replaced by 
python3.
I’ve gotten over that, mostly thanks to simply using the tool:

2to3

Which is fantastic, and should be a model for us all.

My particular goal is to get my code/blocks documented before they are broken 
again by “improvements”.
I know that the group is focused on making GNURadio enhancements to 
capabilities.
However this is killing the “users” of GNURadio, who barely have the capability 
of writing
C++ modules and python code.  Once I got these working I was really, really 
hoping I could
go on to make discoveries in the universe, and not have to scratch my head over 
“improvements”.

So, you’re right about your points 1 and 2 (below).

From my point of view you’re wrong about 3.  Unless there is the equivalent of 

swig2pybind

Please don’t make this change until swig2pybind is written.

I’m neutral about point 4.  I’m not sure exactly which modules your are 
referring to.
It was frustrating to go from WX to QT, but that is done.  
There was not a 1-to-1 match of functions from WX to QT, when installed.
The new functions are great, but not having matching replacements to existing 
functions 
is a challenge to the feeble minded.

Again, thanks for all your great efforts.   Just remember that “established"
users are challenged by improvements and may have completely different 
priorities 
than developers.

Best regards

Glen

> On Jan 5, 2021, at 9:24 AM, Johannes Demel  wrote:
> 
> Hi Glen,
> 
> I fully understand your frustration to make things work long term and 
> constant breakage.
> 
> There are, however, reasons why breaking changes are unavoidable. Some 
> examples are:
> 1. GRC used Cheetah with XML for block definitions BUT:
> Cheetah got unmaintained for years. Cheetah is only available for Python2. 
> Python2 support ran out. Instead of relying on an unmaintained project, GRC 
> switched to Mako which uses YAML instead.
> 
> 2. With Ubuntu 20.04, it would probably be impossible to do a "simple" 
> install of GR 3.7 because it requires Python2 and 20.04 basically dumped 
> Python2 in favor of Python3. Thus, it was important to move to a newer Python 
> version. You might be able to install 3.7 on that system BUT you might very 
> well break it for other applications.
> Ubuntu 20.04 is actually a very good reason to move to a newer GR version 
> because it cuts off a lot of dependencies GR 3.7 has. e.g. Python2, Qt4, etc. 
> That also exemplifies why GNU Radio must evolve because the ecosystem around 
> it evolves as well.
> 
> 3. There has been a lot of discussion if and how SWIG might be replaced by a 
> different system. SWIG seemed like a good solution when it was introduced. 
> But it turned out to be extremely frustrating whenever there are problems to 
> fix.
> 
> 4. Deprecating blocks seems like an annoying thing to do as well. 
> Unfortunately, sometimes things that seemed like a good idea turn out to be a 
> dead end. In this case, we all like a better alternative and some time to 
> move in case we must.
> 
> I know that a lot of package maintainers do a fantastic job to make GR 
> available for their respective systems. I hope that helps to get the 
> installation process going.
> I'd like to refer to Geof Nieboers recent email where he explains all the 
> difficulties that come up with old software.
> 
> Of course, developers tend to be eager to adopt new technology and learn how 
> to use it. Just like Radio astronomers want to discover and learn about new 
> signals.
> Personally, I think Marcus is doing a fantastic job and balancing things 
> between long term usability and progressive changes.
> Also, you'd be very welcome to join discussions about the future of GNU Radio 
> and make sure it is as good as possible for you too.
> 
> Cheers
> Johannes
> 
> On 23.12.20 02:21, Glen Langston wrote:
>> 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 

Re: Stop making unneeded improvements

[Johannes Demel]

Hi Glen,

I fully understand your frustration to make things work long term and 
constant breakage.


There are, however, reasons why breaking changes are unavoidable. Some 
examples are:

1. GRC used Cheetah with XML for block definitions BUT:
Cheetah got unmaintained for years. Cheetah is only available for 
Python2. Python2 support ran out. Instead of relying on an unmaintained 
project, GRC switched to Mako which uses YAML instead.


2. With Ubuntu 20.04, it would probably be impossible to do a "simple" 
install of GR 3.7 because it requires Python2 and 20.04 basically dumped 
Python2 in favor of Python3. Thus, it was important to move to a newer 
Python version. You might be able to install 3.7 on that system BUT you 
might very well break it for other applications.
Ubuntu 20.04 is actually a very good reason to move to a newer GR 
version because it cuts off a lot of dependencies GR 3.7 has. e.g. 
Python2, Qt4, etc. That also exemplifies why GNU Radio must evolve 
because the ecosystem around it evolves as well.


3. There has been a lot of discussion if and how SWIG might be replaced 
by a different system. SWIG seemed like a good solution when it was 
introduced. But it turned out to be extremely frustrating whenever there 
are problems to fix.


4. Deprecating blocks seems like an annoying thing to do as well. 
Unfortunately, sometimes things that seemed like a good idea turn out to 
be a dead end. In this case, we all like a better alternative and some 
time to move in case we must.


I know that a lot of package maintainers do a fantastic job to make GR 
available for their respective systems. I hope that helps to get the 
installation process going.
I'd like to refer to Geof Nieboers recent email where he explains all 
the difficulties that come up with old software.


Of course, developers tend to be eager to adopt new technology and learn 
how to use it. Just like Radio astronomers want to discover and learn 
about new signals.
Personally, I think Marcus is doing a fantastic job and balancing things 
between long term usability and progressive changes.
Also, you'd be very welcome to join discussions about the future of GNU 
Radio and make sure it is as good as possible for you too.


Cheers
Johannes

On 23.12.20 02:21, Glen Langston wrote:

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  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 
 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 

Re: Stop making unneeded improvements

[Chris Vine]

On Tue, 22 Dec 2020 20:21:42 -0500
Glen Langston  wrote:
[snip]
> 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.

I use SDRPlay with gnuradio-3.8 with linux and it works fine.  The
gr-soapy backend works better than the gr-osmosdr one however.

In my case I use sdrplay-2.13.1, soapy-sdr (git master branch as at
2020-07-13), soapy-sdrplay (git master branch as at 2020-06-29),
gnuradio-3.8.2.0 and gr-soapy (git master branch as at 2020-06-07).

In addition, to use SDRPlay with gqrx, I use gr-iqbal (git master
branch as at 2019-12-01) and gr-osmosdr (git master branch as at
2020-08-05).  However, you should use the gr-osmosdr block's soapy
backend with soapy's sdrplay driver (pass the arguments
"soapy=0,driver=sdrplay" to the gr-osmosdr block), and not the sdrplay
backend which no longer works properly.

Re: Stop making unneeded improvements

[Jeff Long]

Glen - which of your modules do you need to port? Maybe one or more of us
can give you a hand, since this is for education and RA.

Backward compatibility is important. The choice the GR devs are trying to
make in some cases is between backward compatibility and software that can
continue to grow in the future.

SDRPlay went through the same thing. They revamped their entire API
recently to support newer products, and now even require a service to be
running on Linux in order to use it. Fortunately, there are Soapy modules
for the new and old API, and there is a gr-soapy (for 3.8).



On Tue, Dec 22, 2020 at 8:28 PM Glen Langston 
wrote:

> 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  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  vt-arc@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_factordata=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3Dreserved=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 

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 12/22/2020 08:21 PM, Glen Langston wrote:

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


Glen, I sympathize.  But compared to the 3.6-->3.7 debacle, the changes 
have been easier, in my experience.


The switch to pybind11 was because SWIG is no longer a supported 
subsystem, from what I understand.


The change from XML to YAML for .grc files and .grc block descriptions 
is a bit more gratuitous, IMHO, but there may be subtle
  improvements in YAML compared to XML (apart from the easier syntax) 
that I'm not aware of.


MOST of my own library of radio astronomy code is still stuck at GR 3.7 
-- because of the pain you note.  I did manage to get
  stupid_simple_pulsar working on GR3.9, but it required some patches 
to be applied to the underlying code-base because certain
  *crucial* setters for frequently-used blocks like multiply_const and 
add_const and subtract_const hadn't actually had
  pybind11 bindings produced for them.  Which lead to silent and 
very-perplexing failure.  It may be the case that there is no
  automated tooling to go from SWIG to PyBind11, which means that it's 
easy to miss stuff.  Dunno.


The GR developers, per se, cannot be blamed for things like 
hardware-specific drivers not being available--those are the clear 
responsibility
  of the purveyors of those drivers.  Now, granted, the lack of 
availability may be BECAUSE of the "pain" factor.  Similarly, the particular
  configurations of GR in *specific* Linux distributions is NOT the 
mandate of the GR project, per se.  If your fave Linux distro happens
  to package GR in a way that is unpleasant in your particular 
circumstance, that isn't, generally, the fault of the GR team here.


I've been a C/C++/Python developer now for just over 4 decades, and the 
modern "let a thousand flowers bloom" nature of Linux is
  **daunting** not just for *users*, but for *developers* as well.I 
get grief for my own code because someone wants to build/install
  it on some version of Linux with which I am utterly unfamiliar. If I 
had to become intimately familiar with the machinations of every
  single Linux variant out there (in the multiple dimensions of 
version, hardware platform, package-management-framework, etc), I'd

  only be able to produce perhaps 1 piece of software every 5 years or so.

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  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 
>  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_factordata=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3Dreserved=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