I tried executing the python file but it keeps showing errors. I'm new to
this and with my limited knowledge I've set the paths. This is the error
that keeps popping up everytime.
*C:\GNURadio-3.8>python NBFM.pyTraceback (most recent call last): File
"C:\GNURadio-3.8\NBFM.py", line 23, in import
gnuradioModuleNotFoundError: No module named 'gnuradio' *
*Also thank you for your help*.
On Wed, Dec 20, 2023 at 10:33 PM wrote:
> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Vector Sink/Source Type Support (David Reuss)
>2. Survey regarding Open Source Licensing of GR 4.0 (Josh Morman)
>3. Re: Vector Sink/Source Type Support (Jeff Long)
>4. How to run the program without showing the block diagram in
> windows 10? (Sreejith RK Nair)
>
>
> --
>
> Message: 1
> Date: Tue, 19 Dec 2023 09:44:40 -0800
> From: David Reuss
> To: discuss-gnuradio@gnu.org
> Subject: Vector Sink/Source Type Support
> Message-ID:
> <
> calsebrttnmypejuealu_qg4u9ibmnavxhhfjk4qdak2awmh...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> We have a few gnuradio blocks in an OOT module that require double
> precision inputs and outputs. To help us test these blocks we created our
> own vector sink/source blocks that are direct copies of the gnuradio vector
> sink/source but with added support for doubles.
>
> This works well, but I was wondering if there is a reason that vector
> sink/source don't support double, std::int64_t and gr_complexd types, or
> whether this is something that might be useful for me to create a pull
> request for? These blocks are already templated (source:
>
> https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/vector_sink_impl.cc
> ),
> so it should be easy enough to add support for more types.
>
> Thank you,
> David
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231219/c08f7291/attachment.htm
> >
>
> --
>
> Message: 2
> Date: Tue, 19 Dec 2023 12:50:30 -0600
> From: Josh Morman
> To: GNURadio Discussion List
> Subject: Survey regarding Open Source Licensing of GR 4.0
> Message-ID:
> <
> ca+jsbfpxv12p4m+yaucuky4dhy7em0eyqsfv83fgeqdn8wd...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> A quick follow up on one topic that was presented in the Q4 Project Update
> video:
>
> Tl;dr - the core of the code being merged as “GR 4.0” is LGPL. We want
> your opinion on how this will impact you and if further action is needed
> for licensing considerations. Please submit your feedback here:
>
>
> https://forms.gle/u7PjYGhzfrshkngd9
>
> Look forward to your responses.
>
>
> Thanks,
>
> Josh
>
> —--
>
> As has been widely discussed, the upcoming major version of GNU Radio, GR
> 4.0, is based on a new codebase developed by the team at GSI-FAIR and is
> being migrated into the GNU Radio GitHub Repository. Apart from the vast
> and promising changes of this major revision, the code being migrated is
> currently licensed as LGPL, which means that there are different
> ramifications than the entirety of GNU Radio 3.x being GPLv3. The plan is
> that blocks ported over with IP from GR3 (apart from very trivial blocks)
> will remain in modules that are licensed as GPLv3. So for the vast
> majority of GNU Radio use cases, the situation for derived works of
> flowgraphs using signal processing blocks will not change.
>
>
>
> But with the core (base classes and schedulers) being LGPL, this allows
> derived works to link with GR, but have a different license. Source
> changes to the core GR codebase would still need to be provided to those
> receiving any derived works. This could enable the following situations:
>
>1.
>
>A GNU Radio user could create an OOT not bound by GPLv3 - so long as the
>OOT does not link against any of the GR GPL code (e.g. gr-filter or
>gr-digital)
>1.
>
> The OOT could not be distributed in binary form if it is built
> against GPLv3 modules without the artifact being licensed as GPLv3
> 2.
>
> Realistically, this would limit non-GPL usage of GR4 OOTs in
> flowgraphs to custom blocks that have been licensed accordingly
> 2.
>
>An application such as a graphical frontend linking to GR4 under the
>hood could be created under a non-GPL license
