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 <module> import gnuradioModuleNotFoundError: No module named 'gnuradio' * *Also thank you for your help*. On Wed, Dec 20, 2023 at 10:33 PM <discuss-gnuradio-requ...@gnu.org> 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 <david.a.re...@gmail.com> > 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 <jmor...@gnuradio.org> > To: GNURadio Discussion List <discuss-gnuradio@gnu.org> > 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 > > > Note: The above is not legal guidance to any users of this codebase, but a > statement of a licensing change compared to previous GNU Radio revisions. > Each user should consult counsel where needed to understand their own usage > > Links: > > https://github.com/fair-acc/graph-prototype > > https://events.gnuradio.org/event/21/contributions/390/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231219/ebe5d92c/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Tue, 19 Dec 2023 15:34:44 -0500 > From: Jeff Long <willco...@gmail.com> > To: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Re: Vector Sink/Source Type Support > Message-ID: > <CAC5f9jZdKtUkVSToAE23MWAxVBJGK8RrXoP_YTai63M-b= > d...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > We don't seem to have any blocks in-tree that support either of these > types, so it wouldn't be of general use and would be hard to test with CI. > My opinion is that this is something to look into for GR4.0, unless there > is some demand for more precision in 3.X. > > On Tue, Dec 19, 2023 at 2:57 PM David Reuss <david.a.re...@gmail.com> > wrote: > > > 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/cbad1d5f/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Wed, 20 Dec 2023 20:23:05 +0530 > From: Sreejith RK Nair <sreejithrknair...@gmail.com> > To: discuss-gnuradio@gnu.org > Subject: How to run the program without showing the block diagram in > windows 10? > Message-ID: > < > cakfesxd-vjvmx01_dbpzyfhunxppovqawfvqdsf7zz5tkeb...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I have done a project for my internship using gnu radio. I want to run my > project on another pc(windows 10) and show the output but not the block > diagram .My invigilator should only see the output. Can anyone suggest a > way to do this? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231220/9ae9622d/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ------------------------------ > > End of Discuss-gnuradio Digest, Vol 254, Issue 16 > ************************************************* >
