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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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
*************************************************