Hi,
I figured out the issue. As discussed in this previous thread, https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00194.html, I needed to make a config.cong file at ~/.gnuradio and add the following lines to it:
```
[grc]
local_blocks_path = /usr/local/share/gnuradio/grc/blocks
local_blocks_path = /usr/local/share/gnuradio/grc/blocks
```
Given how well gr_modtool automatically sets everything up, I am not sure why this wasn't automatically done - but seems like it should be in the future.
-Roman
On Sat, Jul 18, 2020 at 9:00 AM <discuss-gnuradio-request@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-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@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. Re: Discuss-gnuradio Digest, Vol 213, Issue 17 (Anselm Karl)
2. Python OOT module not showing up in GRC (Roman A Sandler)
3. Re: Python OOT module not showing up in GRC (Ron Economos)
4. GSoC 2020: New Blog Post for Week 8 (Alekh)
5. Re: Python OOT module not showing up in GRC (Barry Duggan)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Jul 2020 18:04:11 +0200
From: Anselm Karl <e33b1711@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Re: Discuss-gnuradio Digest, Vol 213, Issue 17
Message-ID:
<CAKcS5R0d+BuFDH2FqAsBM_Z7zzYhF4_YzRPMBWXQbaRQaxs5iQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
<discuss-gnuradio-request@gnu.org> schrieb am Fr., 17. Juli 2020, 18:03:
> 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-request@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-owner@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. Project call today (Marcus Müller)
> 2. Re: Problem with Gnuradio convolution encoder/decoder! (rear1019)
> 3. Re: Project call today (Glen Langston)
> 4. Re: Problem with Gnuradio convolution encoder/decoder!
> (George Edwards)
> 5. Re: Project call today (Marcus Müller)
> 6. gnuradio (+ friends) packages for conda on Linux, macOS, and
> Windows (Ryan Volz)
> 7. Re: gnuradio (+ friends) packages for conda on Linux, macOS,
> and Windows (Glen Langston)
> 8. Creating synchronized USRP source block (Marcin Wachowiak)
> 9. problem in making a project (Yasser Attarizi)
> 10. Re: GPIO lines on RPi4 (jean-michel.friedt@femto-st.fr)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 16 Jul 2020 18:35:59 +0200
> From: Marcus Müller <mueller@kit.edu>
> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: Project call today
> Message-ID: <68eff59d-ab19-cda4-eac1-962a3c024102@kit.edu" target="_blank">68eff59d-ab19-cda4-eac1-962a3c024102@kit.edu>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> Hi bestest SDR community,
>
> Heads up: the July project all is happening in 30 minutes.
>
> Cheers,
> Marcus
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 16 Jul 2020 18:53:38 +0200
> From: rear1019 <rear1019@posteo.de>
> To: discuss-gnuradio@gnu.org
> Subject: Re: Problem with Gnuradio convolution encoder/decoder!
> Message-ID: <20200716165338.GA1065@thewire.localdomain>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, 16 Jul 2020 at 07:40:14 -0600, George Edwards wrote:
> > […]
> > I have also tried some of the other CC encoder/decoder blocks and they
> > failed.
> >
> > I will appreciate any help or suggestions about the CCSDS 27 or the CC
> > encoder/decoder in GNURadio.
>
> Which version of GNU Radio do you use? The convolutional decoder is
> known to be broken in 3.8 [1][2].
>
> [1] https://github.com/gnuradio/gnuradio/issues/2642
> [2] https://github.com/gnuradio/gnuradio/issues/3376
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 16 Jul 2020 13:01:10 -0400
> From: Glen Langston <glen.i.langston@gmail.com>
> To: Marcus Müller <mueller@kit.edu>
> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: Re: Project call today
> Message-ID: <546A7E57-3ED4-4117-BA43-AAD1BDA3A5E4@gmail.com" target="_blank">546A7E57-3ED4-4117-BA43-AAD1BDA3A5E4@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi
>
> Could you remind us (ie me) of the link to the call?
>
> Thanks
>
> Glen
>
>
> > On Jul 16, 2020, at 12:35 PM, Marcus Müller <mueller@kit.edu> wrote:
> >
> > Hi bestest SDR community,
> >
> > Heads up: the July project all is happening in 30 minutes.
> >
> > Cheers,
> > Marcus
> >
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 16 Jul 2020 11:59:31 -0600
> From: George Edwards <gedwards.eng@gmail.com>
> To: discuss-gnuradio@gnu.org
> Subject: Re: Problem with Gnuradio convolution encoder/decoder!
> Message-ID:
> <
> CAAn5ZoGExRTZNgjZqfPxznuYTBD6rcKJDykOvXzpV8Wb+j71Jg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> Thanks for the response! I am using 3.8. However, I just found a pair which
> work using the DVB-T Inner Coder and Viterbi Decoder.
>
> Regards,
> George
>
> On Thu, Jul 16, 2020 at 10:54 AM rear1019 <rear1019@posteo.de> wrote:
>
> > On Thu, 16 Jul 2020 at 07:40:14 -0600, George Edwards wrote:
> > > […]
> > > I have also tried some of the other CC encoder/decoder blocks and they
> > > failed.
> > >
> > > I will appreciate any help or suggestions about the CCSDS 27 or the CC
> > > encoder/decoder in GNURadio.
> >
> > Which version of GNU Radio do you use? The convolutional decoder is
> > known to be broken in 3.8 [1][2].
> >
> > [1] https://github.com/gnuradio/gnuradio/issues/2642
> > [2] https://github.com/gnuradio/gnuradio/issues/3376
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200716/45e0a36e/attachment.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 16 Jul 2020 20:34:58 +0200
> From: Marcus Müller <mueller@kit.edu>
> To: Glen Langston <glen.i.langston@gmail.com>
> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: Re: Project call today
> Message-ID: <81bb9d18-26a8-7161-fa4b-7dd9202c2d3a@kit.edu" target="_blank">81bb9d18-26a8-7161-fa4b-7dd9202c2d3a@kit.edu>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> Hi Glen,
>
> sorry, I wrote that email in a hurry and forgot to add the link to the
> stream.
> It's always twitch.tv/gnuradio .
>
> But: we'll also upload it to the GNU Radio youtube channel,
> https://www.youtube.com/c/GNURadioProject/videos
>
> My apologies,
> Marcus
>
> On 16/07/2020 19.01, Glen Langston wrote:
> > Hi
> >
> > Could you remind us (ie me) of the link to the call?
> >
> > Thanks
> >
> > Glen
> >
> >
> >> On Jul 16, 2020, at 12:35 PM, Marcus Müller <mueller@kit.edu> wrote:
> >>
> >> Hi bestest SDR community,
> >>
> >> Heads up: the July project all is happening in 30 minutes.
> >>
> >> Cheers,
> >> Marcus
> >>
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 16 Jul 2020 17:30:38 -0400
> From: Ryan Volz <ryan.volz@gmail.com>
> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: gnuradio (+ friends) packages for conda on Linux, macOS, and
> Windows
> Message-ID: <25d29d97-241d-0ba7-78ad-e150be589e79@gmail.com" target="_blank">25d29d97-241d-0ba7-78ad-e150be589e79@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi everybody,
>
> Over the past few months, I've managed to build conda packages for GNU
> Radio, some out of tree modules, and other related software and make them
> available through conda-forge (https://conda-forge.org/). The partial
> list includes:
>
> gnuradio
> gnuradio-osmosdr
> gnuradio-soapy
> gqrx
> libiio
> pyadi-iio
> rtl-sdr
> uhd
> volk
>
> The packages have been built for Linux, macOS, and Windows for the
> environments that conda-forge supports, which should work pretty widely.
> This means it may now be easier to get the most recent versions of these
> packages (and more can be added!) running on your system! I've personally
> found it useful for getting new users (mostly students) started with an SDR
> stack.
>
> A bit of background for anyone unfamiliar: conda is a cross-platform
> package and environment manager, and conda-forge is a community-supported
> set of build recipes and built packages that you can install into a conda
> environment. The original focus of conda was for Python packages and
> related compiled software, but it has grown from there. You install a conda
> distribution, which provides a base environment, and then you can create
> new contained environments and install different combinations of software
> in them.
>
> To get running with GNU Radio, you'll first need to have a conda
> distribution installed. Anaconda is the main commercially-supported
> distribution and what most people probably use (
> https://docs.anaconda.com/anaconda/install/), but there is also a
> lightweight version called Miniconda (
> https://docs.conda.io/en/latest/miniconda.html) and a community-supported
> one called Miniforge that is put out by the conda-forge folks (
> https://github.com/conda-forge/miniforge). Once you have a distribution
> installed for your platform, I'd then recommend creating an environment
> specifically for GNU Radio (look up 'conda create' and 'conda activate').
>
> Then from your conda environment, you need to add the conda-forge channel
> as a package source:
>
> $ conda config --env --prepend channels conda-forge
> $ conda config --env --set channel_priority strict
>
> Then you can install the packages with
>
> $ conda install <package-name>
>
> where <package-name> can come from the set of GNU Radio and related
> packages listed above.
>
> There are also a couple OOT modules that I have on my personal channel
> 'ryanvolz' (conda config --env --append channels ryanvolz) for which I am
> waiting on a compatible release before they can be brought to conda-forge:
>
> gnuradio-iio
> gnuradio-radar
>
> So if you're interested, give any of these a try! I've done my best so far
> to make sure they work, but I only have my Linux machine, Windows VM, and
> friends running macOS with which to test, so feedback from the wider
> community would be welcome. For that, it's best to file bug reports on the
> conda-forge Github for the corresponding package "feedstock", e.g.
> https://github.com/conda-forge/gnuradio-feedstock.
>
> If anyone is interested in seeing more packages for other related software
> or OOT modules, I'm also happy to assist in writing the recipe and getting
> it onto conda-forge. The nice thing is that anyone can contribute new
> conda-forge packages or improvements in the form of pull requests, so you
> also don't need me at all if you're so inclined!
>
> I'm planning on keeping at least all of the current packages up to date
> with new releases as my time allows, but I would certainly welcome
> co-maintainers or any bits of extra help. Just let me know or get involved
> on github!
>
> Cheers,
> Ryan
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 16 Jul 2020 17:36:44 -0400
> From: Glen Langston <glen.i.langston@gmail.com>
> To: Ryan Volz <ryan.volz@gmail.com>
> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: Re: gnuradio (+ friends) packages for conda on Linux, macOS,
> and Windows
> Message-ID: <75F82ADD-BF10-469F-BF1A-7004C954F2FA@gmail.com" target="_blank">75F82ADD-BF10-469F-BF1A-7004C954F2FA@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Thanks for your efforts. That is great.
>
> I’m looking forward to trying 3.8.
>
> We happen to be primarily using Raspberry PI 4s for Radio Astronomy.
> Certainly the cost is low to get one, but I imagine the installation time
> is
> a headache for testing every OS.
>
> I hope to eventually get our custom code running in 3.8 and 3.9
> then will give your additions a try.
>
> Best regards
>
> Glen
>
> http://www.github.com/WVURAIL/gr-radio_astro
>
>
>
> > On Jul 16, 2020, at 5:30 PM, Ryan Volz <ryan.volz@gmail.com> wrote:
> >
> > Hi everybody,
> >
> > Over the past few months, I've managed to build conda packages for GNU
> Radio, some out of tree modules, and other related software and make them
> available through conda-forge (https://conda-forge.org/). The partial
> list includes:
> >
> > gnuradio
> > gnuradio-osmosdr
> > gnuradio-soapy
> > gqrx
> > libiio
> > pyadi-iio
> > rtl-sdr
> > uhd
> > volk
> >
> > The packages have been built for Linux, macOS, and Windows for the
> environments that conda-forge supports, which should work pretty widely.
> This means it may now be easier to get the most recent versions of these
> packages (and more can be added!) running on your system! I've personally
> found it useful for getting new users (mostly students) started with an SDR
> stack.
> >
> > A bit of background for anyone unfamiliar: conda is a cross-platform
> package and environment manager, and conda-forge is a community-supported
> set of build recipes and built packages that you can install into a conda
> environment. The original focus of conda was for Python packages and
> related compiled software, but it has grown from there. You install a conda
> distribution, which provides a base environment, and then you can create
> new contained environments and install different combinations of software
> in them.
> >
> > To get running with GNU Radio, you'll first need to have a conda
> distribution installed. Anaconda is the main commercially-supported
> distribution and what most people probably use (
> https://docs.anaconda.com/anaconda/install/), but there is also a
> lightweight version called Miniconda (
> https://docs.conda.io/en/latest/miniconda.html) and a community-supported
> one called Miniforge that is put out by the conda-forge folks (
> https://github.com/conda-forge/miniforge). Once you have a distribution
> installed for your platform, I'd then recommend creating an environment
> specifically for GNU Radio (look up 'conda create' and 'conda activate').
> >
> > Then from your conda environment, you need to add the conda-forge
> channel as a package source:
> >
> > $ conda config --env --prepend channels conda-forge
> > $ conda config --env --set channel_priority strict
> >
> > Then you can install the packages with
> >
> > $ conda install <package-name>
> >
> > where <package-name> can come from the set of GNU Radio and related
> packages listed above.
> >
> > There are also a couple OOT modules that I have on my personal channel
> 'ryanvolz' (conda config --env --append channels ryanvolz) for which I am
> waiting on a compatible release before they can be brought to conda-forge:
> >
> > gnuradio-iio
> > gnuradio-radar
> >
> > So if you're interested, give any of these a try! I've done my best so
> far to make sure they work, but I only have my Linux machine, Windows VM,
> and friends running macOS with which to test, so feedback from the wider
> community would be welcome. For that, it's best to file bug reports on the
> conda-forge Github for the corresponding package "feedstock", e.g.
> https://github.com/conda-forge/gnuradio-feedstock.
> >
> > If anyone is interested in seeing more packages for other related
> software or OOT modules, I'm also happy to assist in writing the recipe and
> getting it onto conda-forge. The nice thing is that anyone can contribute
> new conda-forge packages or improvements in the form of pull requests, so
> you also don't need me at all if you're so inclined!
> >
> > I'm planning on keeping at least all of the current packages up to date
> with new releases as my time allows, but I would certainly welcome
> co-maintainers or any bits of extra help. Just let me know or get involved
> on github!
> >
> > Cheers,
> > Ryan
> >
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 17 Jul 2020 11:50:45 +0200
> From: Marcin Wachowiak <marcin.r.wachowiak@gmail.com>
> To: discuss-gnuradio@gnu.org
> Subject: Creating synchronized USRP source block
> Message-ID:
> <CAOfH71wETCSqAiUigwp+WRkR8GBL3=zQJ=
> qPvBKHQc+BO7D0tA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> I am trying to create a synchronized usrp source block in gnu radio
> consisting of multiple B210 USRP devices. Lang: C++.
>
> >From what I have found I need to:
>
> - Instantiate multiple multi_usrp_sptr as each B210 requires one and
> multiple B210 devices cannot be addressed by using single sptr
> - Use external frequency and PPS sources - an option that can be
> selected from block or set programmatically
> - Synchronize re/tuning to achieve repeatable phase offset between nodes
> - this can be achieved using timed commands API
>
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
> - Synchronize sample streams using time_spec property issue_stream cmd
>
> *The problem is how should I insert these timed commands and set time_spec
> of stream in GNU radio block or gr-uhd libs?*
>
> I looked into the gr-uhd folder where the sink/source code resided and
> found functions that could be altered.
> Unfortunately I don't know how to copy or export this library to do these
> modifications and later compile to insert my custom blocks to GNU Radio,
> because gr-uhd seems to be built in and compiled at GR installation.
> I attempted coping and then making the lib but that's not the way - it
> didn't succeed. Should I add my own source block via gr_modtool and insert
> only the commands I need?
> Compatibility with uhd and its functions apart from just adding a few lines
> would be advantageous not to write the source from scratch.
>
> Please advise,
> Kind Regards,
> Marcin Wachowiak
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/cb1ceda3/attachment.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Fri, 17 Jul 2020 09:44:33 +0000
> From: Yasser Attarizi <yasser.attarizi@buckingham.ac.uk>
> To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> Subject: problem in making a project
> Message-ID:
> <
> LO2P265MB06696AFB4CC0FA74E7398191D47C0@LO2P265MB0669.GBRP265.PROD.OUTLOOK.COM" target="_blank">LO2P265MB06696AFB4CC0FA74E7398191D47C0@LO2P265MB0669.GBRP265.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi
> I am making a project in which there are some a module with some blocks.
> it is lora_sdr and in my computer when I want to make it I see some errors
> like this:
>
> /home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_add_crc_sptr_relative_rate_i(PyObject*,
> PyObject*)’:
> /home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx:5862:35:
> error: ‘class gr::lora_sdr::add_crc’ has no member named ‘relative_rate_i’;
> did you mean ‘relative_rate’?
> result = (uint64_t)(*arg1)->relative_rate_i();
>
> I am using python2.7 and gnuradio3.7 and I installed gnuradio with pybomb
> I didn't copay and paste all error lines because they are alot and are the
> same shape. I can bring all of them if necessary
> Best Regards,
> Yasser
>
> [University of Buckingham logo]<
> https://www.buckingham.ac.uk/?utm_source=outlook-signature&utm_medium=email&utm_content=university-logo&utm_campaign=email-signature-generic>
> [TEF Gold - QAA Quality Mark thumbnail - NSS Top for Student Satisfaction
> in England 2018] <
> https://www.buckingham.ac.uk/about/rankings?utm_source=outlook-signature&utm_medium=email&utm_content=rankings-badges&utm_campaign=email-signature-generic
> >
>
> Connect with us: Facebook<http://facebook.com/unibuckingham> - Twitter<
> http://twitter.com/uniofbuckingham> - Instagram<
> https://www.instagram.com/uniofbuckingham> - LinkedIn<
> https://www.linkedin.com/school/university-of-buckingham/>
>
> The University of Buckingham respects your rights with regards to data
> privacy and data protection. Please review our privacy notice<
> https://www.buckingham.ac.uk/privacy-policy/?utm_source=outlook-signature&utm_medium=email&utm_content=privacy-notice&utm_campaign=email-signature-generic>,
> which informs you how we collect, store, use, share, process and protect
> your personal information.
>
> It also tells you how you can access and update your personal information
> and make certain choices about how your personal information is used. By
> communicating with the University, using its websites, making applications
> or by otherwise giving us your personal information you are accepting the
> practices described in this Privacy Notice. If you do not agree to this
> Privacy Notice, please do not give us any of your personal information.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/c385cb75/attachment.html
> >
>
> ------------------------------
>
> Message: 10
> Date: Fri, 17 Jul 2020 12:28:25 +0000
> From: "jean-michel.friedt@femto-st.fr"
> <jean-michel.friedt@femto-st.fr>
> To: discuss-gnuradio@gnu.org
> Subject: Re: GPIO lines on RPi4
> Message-ID: <70c23bbca93b26a63bbf52d19fc6251c@femto-st.fr" target="_blank">70c23bbca93b26a63bbf52d19fc6251c@femto-st.fr>
> Content-Type: text/plain; charset="utf-8"
>
> To complete this demonstration of running a TCP server from within the
> GNU Radio Companion flowchart without modifying the generated Python code,
> and correcting a mistake in the post below so that I can also update the
> Signal
> Source frequency, I have uploaded
>
> http://jmfriedt.org/2020-07-17-140636_2704x1050_scrot_ann.png
>
> (and removed the erroneous screenshots cited in the previous messages).
>
> Gwenhael Goavec explained to me the mistake I was doing: when calling
> tt=t.t()
> (since t is the Id of the flowchart) from the thread, I was creating a new
> instance of the whole flowchart, whose frequency variable did not match
> the
> one defining the frequency source signal that was being displayed.
> Instead of creating a new instance of the flowchart in the thread, the
> argument "self"
> must be provided when creating the thread. Then, the variables and methods
> from the
> calling class can be accessed and indeed, changing the signal source
> frequency does
> lead to a change in the displayed spectrum.
>
> JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
> June 30, 2020 10:10 AM, jean-michel.friedt@femto-st.fr wrote:
>
> > Thanks to this comment, I ended up finding a solution to call a thread
> > running a TCP/IP server able to control the variables from the main
> > processing flowchart, without modifying manually the generated Python
> for a Qt
> > application.
> > A screenshot, which I hope is self-explanatory, illustrating this
> process is at
> > http://jmfriedt.org/2020-06-30-083722_2704x1050_scrot.png
> >
> > However I am facing a surprising result.
> > I initially (see above) created a signal source, set its frequency to a
> variable flo,
> > checked with a slider that changing flo did change the output frequency,
> removed the
> > slider and set the signal source flo from my server. No change in the
> frequency output.
> >
> > So I went back to my initial setup in which I change not only the source
> signal
> > frequency but also the receiver hardware LO frequency of the B210,
> keeping the TX LO
> > fixed. And surely enough both a spectrum analyzer and the coupled output
> from the
> > B210 TX to the RX show the signal shifting.
> >
> > Screenshots at
> > http://jmfriedt.org/2020-06-30-095336_2704x1050_scrot.png show that the
> callback function
> > for the source frequency or LO frequency are exactly the same and so are
> the server handling
> > functions, while
> > http://jmfriedt.org/2020-06-30-095712_2704x1050_scrot.png shows that
> the B210 TX frequency
> > only changes when tuning the hardware LO, not the signal source LO.
> >
> > Is there some signal that needs to be sent to the signal source beyond
> > self.analog_sig_source_x_0.set_frequency(self.flo)
> > to tell it to change frequency ?
> >
> > Thanks, JM
> >
> > --
> > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> > 25000 Besancon, France
> >
> > June 22, 2020 1:25 PM, "Marcus Müller" <mueller@kit.edu> wrote:
> >
> >> It gets even better:
> >>
> >> We've launched a feature in 3.8.1.0 (and on master before that, as we do
> >> with any feature that ends up in a maintenance release) that we hope
> >> doesn't come back to bite us due to enabling unclean design. But, we
> >> must build best practices so that it doesn't go unused, either, so:
> >>
> >> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
> >> something), you can make use of the "Python Snippets" in GRC.
> >>
> >> Cheers,
> >> Marcus
> >>
> >> On 18/06/2020 23.17, Marcus D. Leech wrote:
> >>
> >>> On 06/18/2020 03:54 PM, jean-michel.friedt@femto-st.fr wrote:
> >>
> >> My approach:
> >> * build your grc chart from GNU Radio Companion and generate the .py
> file
> >> * edit the py file and import pygpio
> >> * play with the RPi4 GPIO in your python script.
> >>
> >> See attached script, with a python server included in the Python script
> >> to control an RF switch from a GNU Octave TCP/IP client talking to the
> >> Python
> >> TCP/IP server.
> >>
> >> I am presenting this approach to hardware control at
> >> http://jmfriedt.free.fr/sdra_radar.pdf
> >>
> >> JM
> >>> If you use "Python Module" block, you can write a lot of
> >>> non-GnuRadio-esque python, import anything you want, etc, etc. No
> editing
> >>> of the output python required, necessarily.
> >>
> >> --
> >> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> >> 25000 Besancon, France
> >>
> >> June 18, 2020 9:40 PM, "Da Fy" <diver863uk@gmail.com> wrote:
> >>> Hi All, does anyone have an example of how to control GOIO lines on
> >>> the RPi4 from within a GRC
> >>> flowgraph. I’m guessing it’s an OOT module.
> >>>
> >>> I need to generate a signal of a few 100Hz & control GPIO lines at
> >>> various points though the cycle.
> >>>
> >>> Alternatively, I could generate the signal & lines with external
> >>> hardware & read them with
> >>> GnuRadio.
> >>>
> >>> Tnx, Dave
>
>
>
> ------------------------------
>
> 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 213, Issue 17
> *************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/74c204e6/attachment.html>
------------------------------
Message: 2
Date: Fri, 17 Jul 2020 15:33:02 -0700
From: Roman A Sandler <rsandler00@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Python OOT module not showing up in GRC
Message-ID:
<CAOe5o5oPg8u6oqvp_f8qfZzqrX1iA0UYoZ9W0xUjNgurM8Y_eA@mail.gmail.com" target="_blank">CAOe5o5oPg8u6oqvp_f8qfZzqrX1iA0UYoZ9W0xUjNgurM8Y_eA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have followed Section 3.2 in the tutorial
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python to
setup an OOT python block in GRC.
I followed the instructions on a Linux machine running GNURadio 3.7 and it
worked exactly as described.
I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio 3.8
and all the steps seemed to work. The QA test worked in python, and `cmake;
make; sudo make install; sudo ldconfig` all ran without any errors.
However, when I open GRC, I cannot see the block.
I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or if
maybe there is something weird about the Xavier that is causing the bug.
Let me know,
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/8a96ca57/attachment.html>
------------------------------
Message: 3
Date: Fri, 17 Jul 2020 17:34:38 -0700
From: Ron Economos <w6rz@comcast.net>
To: discuss-gnuradio@gnu.org
Subject: Re: Python OOT module not showing up in GRC
Message-ID: <5c35469b-1f45-620a-4196-f34a423147e7@comcast.net" target="_blank">5c35469b-1f45-620a-4196-f34a423147e7@comcast.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
GNU Radio 3.8 uses YAML instead of XML for the files in the grc
directory. You can convert your .xml files to .yaml files with the command:
gr_modtool update --complete
Ron
On 7/17/20 15:33, Roman A Sandler wrote:
> Hi,
>
> I have followed Section 3.2 in the tutorial
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python to
> setup an OOT python block in GRC.
>
> I followed the instructions on a Linux machine running GNURadio 3.7
> and it worked exactly as described.
>
> I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio
> 3.8 and all the steps seemed to work. The QA test worked in python,
> and `cmake; make; sudo make install; sudo ldconfig` all ran without
> any errors. However, when I open GRC, I cannot see the block.
>
> I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or
> if maybe there is something weird about the Xavier that is causing the
> bug.
>
> Let me know,
> Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/342b95e9/attachment.html>
------------------------------
Message: 4
Date: Sat, 18 Jul 2020 16:05:22 +0530
From: Alekh <alekhgupta1441@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: GSoC 2020: New Blog Post for Week 8
Message-ID: <06b60969-87b2-1386-c52b-12b03c4a6dc4@gmail.com" target="_blank">06b60969-87b2-1386-c52b-12b03c4a6dc4@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello Community!!
Firstly, sorry for late blogpost of earlier week. Here is the link:
https://grdpd.wordpress.com/2020/07/18/week-8-merging-of-branch-alekh_gr-into-master-and-some-improvements/
Major week highlights are:
* Merging of branch /‘master’/ into /alekh_gr/ and vice versa.
* Updation of /predistorter_training/ block to eliminate need of
stream_to_gmp vector.
* Updated /gain_phase_calibrate/ block.
Next week tasks:
* Working on the issues regarding unexpected strange behaviour in RLS
based /predistortion/ especially at high amplitudes.
* Working on getting the data regarding coefficients or weight taps
after each iteration.
* Working towards the addition of LMS based postdistorter.
Regards,
Alekh Gupta
NIT Hamirpur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200718/97347da8/attachment.html>
------------------------------
Message: 5
Date: Sat, 18 Jul 2020 07:43:07 -0500
From: Barry Duggan <barry@dcsmail.net>
To: rsandler00@gmail.com
Cc: Discuss Gnuradio <discuss-gnuradio@gnu.org>
Subject: Re: Python OOT module not showing up in GRC
Message-ID: <ee4f1169-9f56-9498-2bd8-a05f35204ec0@dcsmail.net" target="_blank">ee4f1169-9f56-9498-2bd8-a05f35204ec0@dcsmail.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Roman,
Note the first statement in the tutorial: "NOTE: This tutorial has been
deprecated in GR 3.8."
We chose not to update that one as the material is covered in our other
tutorials which we have updated. See our revised
https://wiki.gnuradio.org/index.php/Tutorials
---
Barry Duggan KV4FV
https://github.com/duggabe
On Fri, 17 Jul 2020 15:33:02 -0700, Roman A Sandler wrote:
Hi,
I have followed Section 3.2 in the tutorial
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python
to setup an OOT python block in GRC.
I followed the instructions on a Linux machine running GNURadio 3.7 and
it worked exactly as described.
I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio
3.8 and all the steps seemed to work. The QA test worked in python, and
`cmake; make; sudo make install; sudo ldconfig` all ran without any
errors. However, when I open GRC, I cannot see the block.
I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or if
maybe there is something weird about the Xavier that is causing the bug.
Let me know,
Thanks!
------------------------------
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 213, Issue 18
*************************************************