<discuss-gnuradio-requ...@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-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. 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.fri...@femto-st.fr) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Jul 2020 18:35:59 +0200 > From: Marcus Müller <muel...@kit.edu> > To: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Project call today > Message-ID: <68eff59d-ab19-cda4-eac1-962a3c024...@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 <rear1...@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.langs...@gmail.com> > To: Marcus Müller <muel...@kit.edu> > Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Re: Project call today > Message-ID: <546a7e57-3ed4-4117-ba43-aad1bda3a...@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 <muel...@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....@gmail.com> > To: discuss-gnuradio@gnu.org > Subject: Re: Problem with Gnuradio convolution encoder/decoder! > Message-ID: > < > caan5zogexrtzngjzqfpxznuytbd6rckjdykovxzpv8wb+j7...@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 <rear1...@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 <muel...@kit.edu> > To: Glen Langston <glen.i.langs...@gmail.com> > Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Re: Project call today > Message-ID: <81bb9d18-26a8-7161-fa4b-7dd9202c2...@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 <muel...@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.v...@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-e150be589...@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.langs...@gmail.com> > To: Ryan Volz <ryan.v...@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-7004c954f...@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.v...@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.wachow...@gmail.com> > To: discuss-gnuradio@gnu.org > Subject: Creating synchronized USRP source block > Message-ID: > <CAOfH71wETCSqAiUigwp+WRkR8GBL3=zQJ= > qpvbkhqc+bo7d...@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.attar...@buckingham.ac.uk> > To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> > Subject: problem in making a project > Message-ID: > < > lo2p265mb06696afb4cc0fa74e7398191d4...@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.fri...@femto-st.fr" > <jean-michel.fri...@femto-st.fr> > To: discuss-gnuradio@gnu.org > Subject: Re: GPIO lines on RPi4 > Message-ID: <70c23bbca93b26a63bbf52d19fc62...@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.fri...@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" <muel...@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.fri...@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" <diver86...@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 > ************************************************* >
