discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documenting GNURadio Use.


From: Jeff Long
Subject: Re: Documenting GNURadio Use.
Date: Tue, 5 Jan 2021 17:30:51 -0500

Is https://github.com/WVURAIL/gr-radio_astro the code you need to port?

On Tue, Jan 5, 2021 at 4:29 PM Glen Langston <glen.i.langston@gmail.com> wrote:
Dear Gnuradio folks,

Again, I hope the email finds you all well and successful.

This email notes that Gnuradio Radio Astronomy software can be used to measure the
Noise Figure of amplifiers.   We’ve been working on documentation of the process
for home radio astronomers.   The Noise figure (in dB) directly translates into
a measure of the sensitivity of the radio telescopes, which should have an
effective “receiver temperature” of less than 300 Kelvin for good performance.
The measurement process and amplifier results are documented.

The LightWork Memo 28 is just released as a Google Doc:
https://drive.google.com/file/d/1Wgt05-DE5Kyz07wGalyl3w_PbZrketwF/view?usp=sharing

All the LightWork memos will be available in this shared directory:
https://drive.google.com/drive/folders/1SJJTUQ5Q6DLDuiqoSHR5YVY_0TDXaNIH?usp=sharing

I’m in the process of transferring the other memos over.

The code is easy to use if you have Gnuradio 3.7, as it has been run on many many
different computers.   The whole OS is available as an image for Raspberry PI 4 computers.
See the memo for links.  Several high schools use this code.

We’re still struggling with 3.8 and 3.9.  Eventually we may get this to work…

Cheers!

Glen


> On Jan 5, 2021, at 1:52 PM, Andrej Rode <mail@andrejro.de> wrote:
>
> 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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]