Re: OOT module 'gr-sdrplay3' and SDRplay API update (supports new model RSP1B)

[Glen Langston]

Dear Franco,

Thanks again for your efforts, two years ago, to get the SDRPlay RSP1A
fully supported in Gnuradio 3.10.   This was for the Raspberry Pi4B and 400.

These are working great.

But now there’s the Pi 5.   It seems like it is tricky to start with the 
previous
Pi4B code and go to Pi5.   I’m wondering if you’ve (or anybody) has thought 
about
the Pi5 and SDRPlay install?

Thanks!

Glen

FYI the latest Lightwork memo is more about telescope construction but also
mentions Gnuradio aspects.

https://github.com/WVURAIL/lightwork/blob/master/LightWorkMemo32-PailOfMilkyWay-r5.pdf


> On Feb 11, 2024, at 11:23 AM, Franco VENTURI  wrote:
> 
> A few weeks ago SDRplay announced a new model, the RSP1B 
> (https://www.sdrplay.com/rsp1b/); at the same time they also upgraded their 
> API to version 3.14 in order to support the new hardware.   I have been 
> working on a new branch ('sdrplay-api-3.14') for the OOT module 'gr-sdrplay3' 
> to work with the new SDRplay API and to support the RSP1B: 
> https://github.com/fventuri/gr-sdrplay3/tree/sdrplay-api-3.14   Our initial 
> tests are successful, and we are are able to use it with both the existing 
> RSP modules and with the new RSP1B; I would like to have a few more people 
> give it a try, and in a week or so merge these changes into the 'main' branch 
> (the code in the current 'main' branch will become the branch 
> 'sdrplay-api-3.07' for those who have to keep the old SDRplay API for some 
> reason, and it won't have any more changes), unless someone finds major 
> problems in the new version.   Also we started a discussion with SDRplay 
> about changing the defaults for AGC, DC offset correction, and IQ imbalance 
> correction (they are currently disabled; they would become enabled be 
> default). Regarding this last item I would like to receive some feedback 
> before making the changes; especially regarding what kind of application you 
> use the 'gr-sdrplay3' OOT module for: if it is more for scientific 
> research/measurement purposes as opposed to listening to radio stations, or 
> other use case scenarios. I just created an 'issue' in my repository where 
> you can write a couple of lines (or more, of course) about your use case, 
> feedback, and suggestions: https://github.com/fventuri/gr-sdrplay3/issues/30 
> - if you don't have an account on GitHub or prefer email, you can email me 
> directly.   73, Franco K4VZ

Re: Python Bindings Out of Sync: Which files are out of sync?

[Glen Langston]

Dear Josh and all Gnuradio-ers,

Thanks your hint helped me fix the problem.

The previous code was written using swig, so I’d not run the
gr_modtool bind  
program like that before.

All is OK and I have two, very simple, new modules for my purposes.
One (vselect) just selects a sub-channel range.  (Probably this already
exists, but I couldn’t find it).   That vselect takes a vector of some
length and outputs a shorter vector, synchronously.   The output vector
is selected based on two input arguments.

For others, the one confusing thing (for me) about gr_modtool is the directory
to run it in.

The files I needed to act on are in

~/test/include/gnuradio/radio_astro/vselect.h

and 

~/test/lib/vselect_impl.cc <http://vselect_impl.cc/> and vselect_impl.h

for the module “vselect”

To fix the problem I had, required executing the command the
top module directory.  Ie :

cd ~/test

gr_modtool bind vselect

The input files are found and the new file is created in directory

~/test/python/radio_astro/bindings

new file is vselect_python.cc <http://vselect_python.cc/>

One must also edit python_bindings.cc <http://python_bindings.cc/> to add this 
new module to the list. (At least I had to).

Best regards,

Glen

In the Swig era, One had to edit files by hand.


> On Jan 5, 2024, at 9:48 AM, Josh Morman  wrote:
> 
> When cmake is run, it does an md5 hash on the public header files and makes 
> sure the value matches what is written in *_python.cc
> Even a single character change in the .h file will disturb the hash and 
> require a rebinding.  If you are sure that you don't want to rebind, then you 
> can call:
> gr_modtool bind -u blockname
> This will only update the hash and not regenerate the *_python.cc file
> 
> Ignoring these errors via a cmake flag would be possible, but it is not 
> implemented currently.
> 
> 
> On Fri, Jan 5, 2024 at 8:14 AM Glen Langston  
> wrote:
> Thanks Josh for your quick response.
> 
> I’ve written c++ code for gnuradio successfully before.   I’m not
> sure what is different about this, very simple, code.
> 
> What does “out of sync” mean specifically?   I’ve got the same calling
> arguments in both files, modulo the different programming styles for
> python and c++.  
> 
> Is there an “ignore this error” flag in “cmake”?
> 
> Thanks
> 
> Glen
> > On Jan 4, 2024, at 4:52 PM, Josh Morman  wrote:
> > 
> > Hi Glen,
> > 
> > The file that is out of sync is 
> > vsum_python.cc
> > 
> > This can be updated using 
> > gr_modtool bind vsum
> > 
> > This ensures that changes in vsum.h are reflected in the python bindings.
> > 
> > Josh
> > 
> > On Thu, Jan 4, 2024 at 2:05 PM Glen Langston  
> > wrote:
> > Hello
> > 
> > I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.
> > 
> > in ~/test/lib 
> > 
> > I have vsum_impl.cc <http://vsum_impl.cc/> and vsum_impl.h
> > 
> > In ~/test/python/radio_astro/bindings
> > 
> > I have vsum.h
> > 
> > I get these messages in the build “make ..” step:
> > 
> > ...
> > -- PYTHON and GRC components are enabled
> > -- Python checking for pygccxml - not found
> > -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
> > -- Performing Test HAS_FLTO
> > -- Performing Test HAS_FLTO - Success
> > -- Found pybind11: /usr/include (found version "2.6.2" )
> > CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
> >   Python bindings for vsum.h are out of sync
> > Call Stack (most recent call first):
> >   python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)
> > 
> > 
> > -- Configuring incomplete, errors occurred!
> > See also 
> > "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
> > See also 
> > "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".
> > 
> > Could someone remind me exactly which files are “out of sync”?
> > 
> > vsum.h must be one, but which is the other?   I think that vsum_impl.h and 
> > vsum.h are consistent
> > (but not, of course, identical).
> > 
> > Thanks!
> > 
> > Glen
> > 
> > 
> > 
> > > On Dec 30, 2023, at 8:16 AM, Marcus Müller  
> > > wrote:
> > > 
> > > Heyo Kimmo,
> > > sorry for the delayed response:
> > > On 29.12.23 01:00, Kimmo Lehtinen wrote:
> > >> I would like to make modifications to the following two GNURadio blocks:
> > >> 1) QT GUI number sink---
> > >> I would like to mo

Re: Python Bindings Out of Sync: Which files are out of sync?

[Glen Langston]

Thanks Josh for your quick response.

I’ve written c++ code for gnuradio successfully before.   I’m not
sure what is different about this, very simple, code.

What does “out of sync” mean specifically?   I’ve got the same calling
arguments in both files, modulo the different programming styles for
python and c++.  

Is there an “ignore this error” flag in “cmake”?

Thanks

Glen
> On Jan 4, 2024, at 4:52 PM, Josh Morman  wrote:
> 
> Hi Glen,
> 
> The file that is out of sync is 
> vsum_python.cc
> 
> This can be updated using 
> gr_modtool bind vsum
> 
> This ensures that changes in vsum.h are reflected in the python bindings.
> 
> Josh
> 
> On Thu, Jan 4, 2024 at 2:05 PM Glen Langston  
> wrote:
> Hello
> 
> I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.
> 
> in ~/test/lib 
> 
> I have vsum_impl.cc <http://vsum_impl.cc/> and vsum_impl.h
> 
> In ~/test/python/radio_astro/bindings
> 
> I have vsum.h
> 
> I get these messages in the build “make ..” step:
> 
> ...
> -- PYTHON and GRC components are enabled
> -- Python checking for pygccxml - not found
> -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
> -- Performing Test HAS_FLTO
> -- Performing Test HAS_FLTO - Success
> -- Found pybind11: /usr/include (found version "2.6.2" )
> CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
>   Python bindings for vsum.h are out of sync
> Call Stack (most recent call first):
>   python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
> See also 
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".
> 
> Could someone remind me exactly which files are “out of sync”?
> 
> vsum.h must be one, but which is the other?   I think that vsum_impl.h and 
> vsum.h are consistent
> (but not, of course, identical).
> 
> Thanks!
> 
> Glen
> 
> 
> 
> > On Dec 30, 2023, at 8:16 AM, Marcus Müller  wrote:
> > 
> > Heyo Kimmo,
> > sorry for the delayed response:
> > On 29.12.23 01:00, Kimmo Lehtinen wrote:
> >> I would like to make modifications to the following two GNURadio blocks:
> >> 1) QT GUI number sink---
> >> I would like to modify it so that it can also display integers and 
> >> strings. Currently it can display floats, shorts and bytes.
> >> I raised an issue about this at the Github page of GNURadio, and I got the 
> >> following reply:"A number of GR blocks infer type from item size, and 
> >> that's what this block does (in its constructor). Unfortunately, float and 
> >> int32 are the same size, so int32 is not usable.It would be possible to 
> >> add another constructor that uses an explicit type instead of item size."
> > Warning: this is probably more involved than you hoped for. If you've 
> > worked with C++ before: No problem, you can at any point always ask for 
> > help. It's also super helpful to use "Draft PR" on github to share your 
> > current state of affairs!
> > If you haven't: I think this might be a bit too hard.
> > Yep, you would need to copy the make function as declared in number_sink.h 
> > in [0]:
> > static sptr make(size_t itemsize,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> > 
> > to a second make function that has a different signature, for example
> > static sptr make(item_type_t itemtype,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> > where item_type_t is a "Scoped enum"/class enum [1]; something like, within 
> > number_sink class,
> > enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever types 
> > you want to support
> > Then you would actually need to implement that in number_sink_impl.cc like 
> > [2]. But for that you need to modify the actual constructor to not take 
> > size_t itemsize as argument [3], but item_type_t itemtype!
> > You would add a field const item_type_t d_itemtype and remove d_itemsize in 
> > number_sink_impl.h [4] and add it to the initializer list [5]; you'd want a 
> > switch()/case construct to set the alignm

Python Bindings Out of Sync: Which files are out of sync?

[Glen Langston]

Hello

I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.

in ~/test/lib 

I have vsum_impl.cc  and vsum_impl.h

In ~/test/python/radio_astro/bindings

I have vsum.h

I get these messages in the build “make ..” step:

...
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - not found
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.6.2" )
CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
  Python bindings for vsum.h are out of sync
Call Stack (most recent call first):
  python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)


-- Configuring incomplete, errors occurred!
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".

Could someone remind me exactly which files are “out of sync”?

vsum.h must be one, but which is the other?   I think that vsum_impl.h and 
vsum.h are consistent
(but not, of course, identical).

Thanks!

Glen



> On Dec 30, 2023, at 8:16 AM, Marcus Müller  wrote:
> 
> Heyo Kimmo,
> sorry for the delayed response:
> On 29.12.23 01:00, Kimmo Lehtinen wrote:
>> I would like to make modifications to the following two GNURadio blocks:
>> 1) QT GUI number sink---
>> I would like to modify it so that it can also display integers and strings. 
>> Currently it can display floats, shorts and bytes.
>> I raised an issue about this at the Github page of GNURadio, and I got the 
>> following reply:"A number of GR blocks infer type from item size, and that's 
>> what this block does (in its constructor). Unfortunately, float and int32 
>> are the same size, so int32 is not usable.It would be possible to add 
>> another constructor that uses an explicit type instead of item size."
> Warning: this is probably more involved than you hoped for. If you've worked 
> with C++ before: No problem, you can at any point always ask for help. It's 
> also super helpful to use "Draft PR" on github to share your current state of 
> affairs!
> If you haven't: I think this might be a bit too hard.
> Yep, you would need to copy the make function as declared in number_sink.h in 
> [0]:
> static sptr make(size_t itemsize,
>  float average = 0,
>  graph_t graph_type = NUM_GRAPH_HORIZ,
>  int nconnections = 1,
>  QWidget* parent = NULL);
> 
> to a second make function that has a different signature, for example
> static sptr make(item_type_t itemtype,
>  float average = 0,
>  graph_t graph_type = NUM_GRAPH_HORIZ,
>  int nconnections = 1,
>  QWidget* parent = NULL);
> where item_type_t is a "Scoped enum"/class enum [1]; something like, within 
> number_sink class,
> enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever types 
> you want to support
> Then you would actually need to implement that in number_sink_impl.cc like 
> [2]. But for that you need to modify the actual constructor to not take 
> size_t itemsize as argument [3], but item_type_t itemtype!
> You would add a field const item_type_t d_itemtype and remove d_itemsize in 
> number_sink_impl.h [4] and add it to the initializer list [5]; you'd want a 
> switch()/case construct to set the alignment_multiple [6].
> Then, you replace the switch (d_itemsize) in get_item [7] with an appropriate 
> switch(d_itemtype). 
> Test it successfully compiles!
> Now you only need to do two things to 
> gr-qtgui/python/qtgui/bindings/number_sink_python.cc 
> • add the new class enum item_type_t to bind_number_sink [8],
> • add the new make function:
> • modify the existing definition and
> • copy it to replace size_t itemsize with number_sink::item_type_t 
> itemtype
> In detail: following [9], you need to change
> py::class_gr::sync_block,
>gr::block,
>gr::basic_block,
>std::shared_ptr>(m, "number_sink", D(number_sink))
> 
> .def(py::init(&number_sink::make), 
> ………
> 
> into
> py::class_gr::sync_block,
>gr::block,
>gr::basic_block,
>std::shared_ptr>
> number_sink_wrapper(m, "number_sink", D(number_sink));
> 
> py::enum_(number_sink_wrapper, "item_type_t");
> 
> number_sink_wrapper
> .def(py::init(&number_sink::make),
> 
> Please compile the result (make sure to make clean before, we've changed 
> bindings), and test it works, from python!
> Now, we need to tell GRC that there's a new way to create a Qt GUI number 
> sink! So, modify qtgui_humber_sink.block.yml [10] to use the new make 
> function instead of 

Re: Pail of Milky Way Horn Radio Telescope

[Glen Langston]

Hi Marcus Leech (and Muller),

Well you beat me to it!

It’s great that you can pre-confirm my results.  I’ll have to look at the
rest of your memos.   Do you mind if we cross-post your memo CERRA memo,
as a LightWork memo too?  Maybe it will be better to just reference your memos
on the LightWork page.  Just thinking while typing…

You produced a beautiful spectrum of the Milky Way, if you love that kind of 
thing, like I do!
Calibrating, by looking at the Ground, is pretty reliable and easy.

Cheers

Glen


> On May 2, 2023, at 7:03 PM, Marcus D. Leech  wrote:
> 
> On 02/05/2023 18:58, Marcus Müller wrote:
>> Hey Glen,
>> 
>> this is really cool stuff!
>> 
>> Tried to give this a bit of reach on Mastodon [1], but I'm far from the 
>> audience I used to have on twitter.
>> 
>> It's pretty cool that a galvanized pail does the job so well, would have 
>> thought zinc wouldn't be low-loss enough a surface coating, but was proven 
>> wrong by awesome results :) The best case of being wrong!
>> 
>> I especially like that this is a solution that needs so little "craftiness" 
>> and seems quite robust. Just drill a hole, watch (and then obviously like) a 
>> few videos and send Glen an email to get a free feed :D
>> 
>> If I had one complaint, it's that you promise a shopping list in the 
>> appendix – but there's no appendix!
>> 
>> I'd also state very early in the guide (maybe actually with a flashy yellow 
>> "sticker" on the title page?) that it comes with video documentation (30 min 
>> in total[2]). I think that's quite a relief to a teacher who doesn't want to 
>> risk building something new based on text only, especially when it involves 
>> mechanical work!
>> 
>> Cheers,
>> Marcus
>> 
>> PS: I think if you're really going to leave it out in the weather, maybe add 
>> a Polymeric Low-Absorption Small-Thickness Inherently Costefficient Best-fit 
>> Antenna enGulfing (PLASTICBAG) radome?
>> 
>> 
>> [1] https://mastodon.social/@funkylab/110301361379949802
>> [2] For those wondering: these videos:
>> https://www.youtube.com/playlist?list=PLFMYhHhJW1VDYESTcHJIiwNbRQXWpFlyF
>> 
>> On 02.05.23 16:53, Glen Langston wrote:
>>> Hello Aficionados!
>>> 
>>> We’ve just released a marvelous summary of how to build a “Pail of Milky 
>>> Way”
>>> horn radio telescope.   This is described in LightWork memo 32.
>>> 
>>> https://github.com/WVURAIL/lightwork/blob/master/memos/LightWorkMemo032-PailOfMilkyWay-r5.pdf
>>>  
>>> 
>>> The memo concludes with a plot of one day’s observations, showing
>>> what you can see with a horn radio telescope.   The Doppler shifted
>>> Cygnus and Perseus Spiral arms of the Milky Way are visible.
>>> 
>>> Comments and improvements welcomed.
>>> 
>>> Data are all obtained using Gnuradio designs available from the DSPIRA web 
>>> site.
>>> https://github.com/WVURAIL/gr-radio_astro
>>> 
>>> Thanks to Kevin Bandura at WVU and the Green Bank Observatory Staff.
>>> 
>>> Cheers
>>> 
>>> Glen
>>> 
>>> 
>>> 
>>> 
>> 
> Some of this reminds me of the memo I published 1.5 years ago on a similar 
> subject:
> 
> http://www.ccera.ca/files/memos/ccera-memo-0014.pdf
> 
> 
> 

Pail of Milky Way Horn Radio Telescope

[Glen Langston]

Hello Aficionados!

We’ve just released a marvelous summary of how to build a “Pail of Milky Way”
horn radio telescope.   This is described in LightWork memo 32.

https://github.com/WVURAIL/lightwork/blob/master/memos/LightWorkMemo032-PailOfMilkyWay-r5.pdf

The memo concludes with a plot of one day’s observations, showing
what you can see with a horn radio telescope.   The Doppler shifted
Cygnus and Perseus Spiral arms of the Milky Way are visible.

Comments and improvements welcomed.

Data are all obtained using Gnuradio designs available from the DSPIRA web site.
https://github.com/WVURAIL/gr-radio_astro

Thanks to Kevin Bandura at WVU and the Green Bank Observatory Staff.

Cheers

Glen

Re: gr-bokehgui in the future?

[Glen Langston]

Hi Cyrille,

Thanks for your quick reply.

I’m afraid I’m missing something fundamental.

Where do you put these lines?  In which block?

Thanks 

Glen

I’m working to document vectordemoWeb.grc
mentioned below.  This works pretty well and does lots of plotting.


> On Mar 24, 2023, at 11:39 AM, Cyrille Morin 
>  wrote:
> 
> Hello Glen,
> Yes, the gnuradio side does not compute anything graphical, which can reduce 
> the load.
> If you want to contribute some changes, you can open a pull request that we 
> can review together before merging.
> 
> To generate the x_axis values within the limit you want:
> Say that you have defined variables with your x_min and x_max (like 
> x_min=1.418e9 and x_max=1.426e9), plus the vector length you want to display 
> (in your case vec_len=2048).
> Use an import block to import the numpy library, writing "import numpy" 
> inside of the Import parameter slot.
> And with that, you can write: numpy.linspace(x_min, x_max, vec_len)  inside 
> the X-axis values parameter field of the Vector sink.
> You can always directly use the actual numbers inside of the linspace 
> function call, of course.
> 
> Cyrille
> 
> ps: The github link you added does not seem to lead anywhere.
> Le 24/03/2023 à 16:02, Glen Langston a écrit :
>> Hi Cyrille,
>> 
>> Thanks for your detailed response.
>> 
>> One thing, on the positive side, for gr-bokehgui is that the CPU load 
>> _decreases_
>> for the processor running the gnuradio code.
>> 
>> What may be happening is that the code on the “receive-side” may be doing 
>> auto-refresh
>> too quickly. I’m not absolutely sure about this yet. Still exploring.
>> 
>> The GUI definitely runs fine for a long while, but maybe there is some side 
>> effect
>> of the design running, like maybe a browser memory leak.
>> 
>> I’ve got 4 radio telescopes running the QT-GUI code. I’ll switch one to 
>> BOKEH-GUI
>> and see how this runs.
>> 
>> To make the minor change I suggested, changing the X-array definition,
>> to "if only 2 X values, then these are the X min and X max” I would like to 
>> push
>> these changes back. I guess I need your permission to push(?)
>> 
>> Thanks for your efforts. 
>> 
>> Glen
>> 
>> PS part of the reason for this was that I could never get gnuradio
>> to generate the X array for 2048 float frequencies (ie 1418. to 1426 (MHz))
>> for the vector plot.
>> 
>> You said this was easy, but an example would be very helpful to me.
>> 
>> I did push some of my gr-bokehgui using designs back. One does not
>> use any SDRs, it is only a test of a certain type of signal processing.
>> 
>> https://www.github.com/WVRAIL/gr-radio_astro/examples/nsf/vectordemoWeb.grc 
>> 
>> The other designs use an SDRPlay RSP1A with 8 MHz sampling:
>> NsfDetect80Web.grc NsfIntegrate80Web.grc NsfWatch80Web.grc
>> 
>> 
>>> On Mar 23, 2023, at 2:32 PM, Cyrille Morin 
>>>  wrote:
>>> 
>>> Hello Glen,
>>> 
>>> I've never actually tried to monitor traffic usage of separate display 
>>> elements.
>>> But looking at the code for both the label and the textbox widgets, I don't 
>>> see anything that would update anything when there is nothing to update.
>>> So I'm not sure where that load you see could be coming from.
>>> 
>>> As for the CPU load, having plots is bound to add some processing, if only 
>>> to get samples, and add them to a buffer.
>>> If it's only widgets, it should be really low.
>>> 
>>> 
>>> As far as I know, bokehgui is the closest thing to a web-based alternative 
>>> to QT-GUI, with different plots, and the ability to control the graph with 
>>> widgets like buttons, sliders, ...
>>> I've heard of web-base waterfall systems, like 
>>> https://github.com/jledet/waterfall
>>> These seem to be quite smooth and responsive, but only plot a waterfall, 
>>> without widgets for control.
>>> 
>>> There was talks (that I sadly didn't follow) about future web based display 
>>> systems, but I don't know much about them.
>>> 
>>> I would say that the main limitation I see from using bokeh is the actual 
>>> display efficiency inside of the browser.
>>> Basically (and if I understood the issue properly), each plot updates 
>>> independently, and independently triggers a redraw. So you can quickly get 
>>> more redraw calls than the browser can handle, slowing everything down, and 
>>> intro

Re: gr-bokehgui in the future?

[Glen Langston]

Hi Cyrille,

Thanks for your detailed response.

One thing, on the positive side, for gr-bokehgui is that the CPU load 
_decreases_
for the processor running the gnuradio code.

What may be happening is that the code on the “receive-side” may be doing 
auto-refresh
too quickly.  I’m not absolutely sure about this yet.  Still exploring.

The GUI definitely runs fine for a long while, but maybe there is some side 
effect
of the design running, like maybe a browser memory leak.

I’ve got 4 radio telescopes running the QT-GUI code.   I’ll switch one to 
BOKEH-GUI
and see how this runs.

To make the minor change I suggested, changing the X-array definition,
to "if only 2 X values, then these are the X min and X max” I would like to push
these changes back.   I guess I need your permission to push(?)
   
Thanks for your efforts.   

Glen

PS part of the reason for this was that I could never get gnuradio
to generate the X array for 2048 float frequencies (ie 1418. to 1426 (MHz))
for the vector plot.

You said this was easy, but an example would be very helpful to me.

I did push some of my gr-bokehgui using designs back.   One does not
use any SDRs, it is only a test of a certain type of signal processing.

https://www.github.com/WVRAIL/gr-radio_astro/examples/nsf/vectordemoWeb.grc 

The other designs use an SDRPlay RSP1A with 8 MHz sampling:
NsfDetect80Web.grc  NsfIntegrate80Web.grc  NsfWatch80Web.grc

> On Mar 23, 2023, at 2:32 PM, Cyrille Morin  
> wrote:
> 
> Hello Glen,
> 
> I've never actually tried to monitor traffic usage of separate display 
> elements.
> But looking at the code for both the label and the textbox widgets, I don't 
> see anything that would update anything when there is nothing to update.
> So I'm not sure where that load you see could be coming from.
> 
> As for the CPU load, having plots is bound to add some processing, if only to 
> get samples, and add them to a buffer.
> If it's only widgets, it should be really low.
> 
> 
> As far as I know, bokehgui is the closest thing to a web-based alternative to 
> QT-GUI, with different plots, and the ability to control the graph with 
> widgets like buttons, sliders, ...
> I've heard of web-base waterfall systems, like 
> https://github.com/jledet/waterfall
> These seem to be quite smooth and responsive, but only plot a waterfall, 
> without widgets for control.
> 
> There was talks (that I sadly didn't follow) about future web based display 
> systems, but I don't know much about them.
> 
> I would say that the main limitation I see from using bokeh is the actual 
> display efficiency inside of the browser.
> Basically (and if I understood the issue properly), each plot updates 
> independently, and independently triggers a redraw. So you can quickly get 
> more redraw calls than the browser can handle, slowing everything down, and 
> introducing latency in the visualization.
> There might be a way to hold redraws temporarily but I would need to do more 
> research on that.
> 
> There might be more efficient libraries with better control over drawing, and 
> better suited to frequent (>20Hz) display updating.
> Apart from that, I don't really see anything that would prevent having a 
> feature set on par with QTgui.
> 
> Cyrille
> 
> Le 23/03/2023 à 17:19, Glen Langston a écrit :
>> Hello Cyrille,
>> 
>> Thanks for your email and notes on bokehgui.   I’ve partially implemented
>> you suggested fixes by reducing the plot update rate.
>> 
>> Separately, I have a GUI that only has a few, rarely changing, text values,
>> to try to completely reduce the internet load.   My suspicion is that these 
>> text displays
>> are being refreshed at some high rate, with the same values.   I don’t know
>> how to test that theory yet, but was wondering if you had any knowledge about
>> text update rates?
>> 
>> Generally I’m very happy with bokehgui, I do find a reduced
>> cpu load on the “raspberry PI” computers running as the telescope
>> data gathering role.
>> 
>> So if bokehgui is the Gnuradio “official” way forward, I’d like to help.
>> 
>> Maybe anyone in Gnuradio would like to comment on the merits of expanding
>> gr-bokehgui, versus any other web-based display approach?
>> 
>> Thanks for your efforts!
>> 
>> Glen
>> 
>>> On Mar 23, 2023, at 5:21 AM, Cyrille Morin 
>>>  wrote:
>>> 
>>> Hi Glen,
>>> 
>>> It seems I replied to you using the wrong email address, so it got dropped.
>>> Sorry for the delay.
>>> 
>>> Cyrille
>>> 
>>> Le 20/03/2023 à 18:49, Cyrille Morin a écrit :
>>>> Hello Glen,
>>>>

Re: gr-bokehgui in the future?

[Glen Langston]

Hello Cyrille,

Thanks for your email and notes on bokehgui.   I’ve partially implemented
you suggested fixes by reducing the plot update rate.

Separately, I have a GUI that only has a few, rarely changing, text values, 
to try to completely reduce the internet load.   My suspicion is that these 
text displays
are being refreshed at some high rate, with the same values.   I don’t know
how to test that theory yet, but was wondering if you had any knowledge about
text update rates?

Generally I’m very happy with bokehgui, I do find a reduced
cpu load on the “raspberry PI” computers running as the telescope 
data gathering role.   

So if bokehgui is the Gnuradio “official” way forward, I’d like to help.

Maybe anyone in Gnuradio would like to comment on the merits of expanding
gr-bokehgui, versus any other web-based display approach?

Thanks for your efforts!

Glen 

> On Mar 23, 2023, at 5:21 AM, Cyrille Morin  
> wrote:
> 
> Hi Glen,
> 
> It seems I replied to you using the wrong email address, so it got dropped.
> Sorry for the delay.
> 
> Cyrille
> 
> Le 20/03/2023 à 18:49, Cyrille Morin a écrit :
>> Hello Glen,
>> 
>> Glad to see that you use bokehgui, and that it works for you :)
>> 
>> I do plan to continue improving the module in the future. Improving the 
>> waterfall sink, adding support for bokeh 3, histogram and BER sinks, fixing 
>> the trigger feature, ...
>> 
>> I've got a bunch of ideas but sadly I currently have quite a few projects 
>> stealing time at work.
>> So yeah, I hope to be able to get back to that in the coming months.
>> And any help is welcome, of course :)
>> 
>> As for the traffic, it's directly related to how many plots you have, and 
>> how quickly they update.
>> The module already transfers only the data points to plot, so it's difficult 
>> do really reduce the throughput (short of adding compression algorithms 
>> inside of the underlying bokeh library)
>> But if you can live with it, you could reduce the update frequency (increase 
>> update time), to show less points per second.
>> 
>> Regarding the vector sink, that shouldn't be very complex, I think one would 
>> just need to modify the .yaml file in the grc folder.
>> The one nice thing with the current setup is that it allows non linear 
>> spacing of the x values, so it's a bit more versatile.
>> In the meantime, you can still generate the range of values you want from a 
>> min and a max.
>> For instance importing numpy with an Import block in GRC, and using 
>> list(numpy.linspace(min, max, num_values)) in the x_values parameter (the 
>> cast to a list may not be necessary).
>> 
>> Cyrille Morin
>> 
>> Le 20/03/2023 à 15:33, Glen Langston a écrit :
>>> Hello,
>>> 
>>> We continued work with high schools experimenting with Radio Astronomy
>>> using Gnuradio.   We’ve found that a simple bucket may be used
>>> to observe our Milky Way Galaxy.
>>> 
>>>   https://youtu.be/bH-k2hsnGa4 <https://youtu.be/bH-k2hsnGa4>
>>> 
>>> 
>>> We’re also trying to bring all our observations on-line from across the
>>> country.  We’ve successfully used the gr-bokehgui to translate our designs
>>> for astronomy into versions that directly display in web browsers.
>>> 
>>> So, We’ve got a couple questions:
>>> 1) Are there plans for anybody to add more features to gr-bokehgui?
>>> We could particularly use a histogram plot.
>>> 2) Although my designs using gr-bokehgui run fine to begin with,
>>> These designs seem to be generating too much internet traffic and are
>>> hanging up my network.   Is there any (known) way of reducing the data flow?
>>> 3) It would be more convenient if the gr-bokehgui sinks matched 1-for-1
>>> with the qt-gui sinks.
>>> 
>>> Any forecasts for progress in this area?   One area that would be
>>> fairly easy to update (and I hope to do so soon) is to change
>>> the definition of the x-axis array input to the vector plot sink.
>>> I’d prefer that, if the x-axis array only had two entries (while the
>>> y had 1024 or 2048 values, etc), that these two x-values would be 
>>> interpreted
>>> as min and max values on the x-axis, creating the other values 
>>> appropriately.
>>> 
>>> Best regards
>>> 
>>> Glen
>>> 
>>> 
>>> <https://youtu.be/bH-k2hsnGa4>
>>>> On Apr 9, 2020, at 4:45 PM, Marcus Müller  wrote:
>>>> 
>>>> Dear hopefully healthiest 

gr-bokehgui in the future?

[Glen Langston]

Hello,

We continued work with high schools experimenting with Radio Astronomy
using Gnuradio.   We’ve found that a simple bucket may be used
to observe our Milky Way Galaxy.

             https://youtu.be/bH-k2hsnGa4  


We’re also trying to bring all our observations on-line from across the
country.  We’ve successfully used the gr-bokehgui to translate our designs
for astronomy into versions that directly display in web browsers.

So, We’ve got a couple questions:
1) Are there plans for anybody to add more features to gr-bokehgui?
We could particularly use a histogram plot.
2) Although my designs using gr-bokehgui run fine to begin with,
These designs seem to be generating too much internet traffic and are
hanging up my network.   Is there any (known) way of reducing the data flow?
3) It would be more convenient if the gr-bokehgui sinks matched 1-for-1
with the qt-gui sinks.

Any forecasts for progress in this area?   One area that would be
fairly easy to update (and I hope to do so soon) is to change
the definition of the x-axis array input to the vector plot sink.
I’d prefer that, if the x-axis array only had two entries (while the
y had 1024 or 2048 values, etc), that these two x-values would be interpreted
as min and max values on the x-axis, creating the other values appropriately.

Best regards

Glen

 

           
> On Apr 9, 2020, at 4:45 PM, Marcus Müller  wrote:
> 
> Dear hopefully healthiest of all SDR communities to ever graze freely on
> the airwaves,
> 
> it's taken me way longer than I wanted, but after the release candidate
> finally follows release 3.8.1.0 of GNU Radio.
> 
> Due to unforeseen crypto hardware trouble, and the presumably temporary
> inability to access key backups, I can't offer a release signed with a
> trustworthy key. Hopefully, we'll have that situation sorted out by the
> next release; to not cause unnecessary confusion through signatures
> nobody can verify, you'll only find signify-signed tarballs for now.
> 
> Regarding what this release means, and what it is:
> 
> This is a release from the GNU Radio 3.8 maintenance release series.
> 3.8 is our current stable release series, i.e. we're focused on keeping
> it running on modern systems and fixing the bugs that we've left in
> there for our own future entertainment at an earlier point ;)
> 
> Feature work happens mostly on the `master` branch, which will become
> GNU Radio 3.9.0.0 at some point. We're at a point where not everything
> most users will do is 100% compatible between 3.8.* and master, so it's
> a good time to try out our master branch if you want to work on
> bleeding-edge stuff. Generally, while we, and I, dedicate very much to
> continuing support for 3.8, master (and thus, 3.9) already is more
> convenient to develop for in quite a few ways, many revolving around
> things we don't do anymore on 3.9 (Python2 compability), and are
> abandoning for something less hazardous (replacing SWIG with Pybind11
> code). Moving forward is a lot of fun! I really missed that in the 3.7 era.
> 
> Best regards,
> and happy hacking!
> 
> Marcus
> 
> #Contributors (a.k.a. people making my maintainer heart feel warm&fuzzy)
> 
> * Alba Mendez 
> * alekhgupta1441 
> * Anders Kalør 
> * Artem Pisarenko 
> * Bastian Bloessl 
> * Brennan Ashton 
> * Chris 
> * Clayton Smith 
> * CMorin 
> * Daniel Estévez 
> * Davide Gerhard 
> * Derek Kozel 
> * duggabe
> * Glenn Richardson 
> * Grant Cox 
> * Gwenhael Goavec-Merou 
> * Håkon Vågsether 
> * Igor Freire 
> * Jacob Gilbert 
> * Jan Kraemer 
> * japm48
> * Johannes Demel 
> * Josh Morman 
> * karel
> * luz.paz
> * Marc L 
> * Marcus Müller 
> * Martin Braun 
> * Michael Dickens 
> * Michael Roe 
> * Nathan West 
> * Nick Østergaard 
> * Nicolas Cuervo 
> * Notou 
> * Philip Balister 
> * rear1019 
> * RedStone002
> * Ron Economos 
> * Ryan Schutt
> * Ryan Volz 
> * Sebastian Koslowski 
> * Sebastian Müller 
> * Sylvain Munaut 
> * Terry May 
> * Thomas Habets 
> * Vasil Velichkov 
> * Volker Schroer
> * wcampbell 
> * William Barnhart 
> 
> 
> ## [3.8.1.0] - 2020-04-08
> 
> ### Changed
> 
>  Project Scope
> 
> - clang-tidy improvements
>  - Throw exceptions by value, catch by reference
>  - `emplace_back` where applicable
>  - `empty()` instead of `vector::size() == 0`
> - Use CMake to check for endianness instead of `BOOST_BIG_ENDIAN`
> 
>  gr-fec
> 
> - Scipy becomes optional dependency (for polar channel code construction)
> 
>  gr_modtool
> 
> - use Boost.UTF instead of cppunit
> 
> ### Fixed
> 
>  Project Scope
> 
> - FindQwt paths
> - floatAlmostEqual unittest assert function wrongly passing on sequence
> types
> - Only require boost unittest when testing is enabled
> - FindLOG4CPP typo
> - numpy.fft(pack) imports
> - several scipy imports that can be done with numpy alone
> 
>  gnuradio-runtime
> 
> - block gateway shadowed system port
> - Flaky message passing unit test contained t

Re: Reverse engineering .py file grc

[Glen Langston]

Hi George,

Editing the python code is certainly possible.  The code that
auto generated is reasonably readable.  

I happen to hate the use of the “yellow” color (invisible in printouts) and 
always
replace this with “gold” with an editor. 

Obviously not brilliant coding changes, but very easy to do.

Good luck,

Glen

> On Mar 10, 2023, at 12:16 PM, George Edwards  wrote:
> 
> Hi Marcus,
> 
> Thanks!
> 
> George
> 
> On Fri, Mar 10, 2023 at 8:22 AM Marcus Müller  wrote:
> Hi George,
> 
> there's no such tool in general, python blocks are just code, and sometimes 
> they're 
> generated from flow graphs, and sometimes written by hand. Anything that 
> contains a "work" 
> method instead of being a hier block, they're definitely not generated from a 
> GRC flow graph.
> 
> So, I'm afraid you'll just have to sit down and recreate the "connect" calls 
> in your 
> python in GRC; the rest will kind of arise from that.
> 
> Best regards,
> Marcus
> 
> 
> On 09.03.23 19:00, George Edwards wrote:
> > Hello GNURadio Community,
> > 
> > 
> > We are looking for a way to reverse engineer some Gnuradio Python blocks 
> > that were created 
> > by folks no longer with our company to the corresponding GRC files. Is 
> > anyone familiar 
> > with a tool that can do this for us?
> > 
> > Thank you!
> > 
> > Regards,
> > George

Re: Incompatibility StreamtoVector-FFT

[Glen Langston]

Hello Raul,

I think you need more samples in your vector to get the FFT to work.
I usually use 1024, but you could probably use a smaller number, but probably no
less than 32

Good Luck

GLne


> On Feb 11, 2023, at 5:36 PM, Raúl Parada Medina 
>  wrote:
> 
> Hi,
> 
> I've followed the tutorial and completed the attached flowchart, however, I 
> cannot make the block steam to vector compatible with the FFT. I add a 
> snapshot from its configuration. I've checked the tutorial too. Please, I ask 
> for some help.
> Thanks in advance.
> Raúl
> <5G-SAv3.pdf>

Re: How to display a part of the GRC spectrum?

[Glen Langston]

Hi George and Marcus,

Yes I agree with Marcus, the Frequency Xlating FIR filter works surprisingly
well.

https://wiki.gnuradio.org/index.php?title=Frequency_Xlating_FIR_Filter

I’ve run some tests with placing (Simulating) audio tones at high frequencies 
ie 1MHz 
+ 880 Hz and the tone is perfectly preserved
at 880 Hz after XLating.

Glen

> On Feb 3, 2023, at 11:08 AM, Marcus D. Leech  wrote:
> 
> On 03/02/2023 11:04, Fabian Schwartau wrote:
>> Hi George,
>> 
>> I don't know if the Frequency sink can do that for you, but I guess it 
>> cannot.
>> One way is to mix the signal with a complex oscillation and a multiplier 
>> with the oscillator running at the negative frequency you wish to downshift 
>> the signal. Then low-pass filter and downsample the signal. You can then 
>> feed that into the Frequency sink and also set you oscillator frequency as 
>> offset frequency in the sink's settings.
>> 
>> Best,
>> Fabian
> That's pretty-much what the frequency-xlating FIR filter/FFT filter block is 
> for...
> 
> Also, sampling at 3GHz?  Into an ordinary computer?  Really?
> 
> 
>> 
>> Am 03.02.23 um 16:52 schrieb George Edwards:
>>> Dear GNURadio Community,
>>> 
>>> Let's say I build a GRC flowgraph operating at a sample rate of 3 GHz and 
>>> wish to display the spectrum over the fixed range of 1GHz +/- 4MHz, how do 
>>> I get the QT GUI Frequency sink to plot over this range?
>>> 
>>> Thank you!
>>> 
>>> George
>> 
>> 
> 
> 

Re: BW(Sample Rate) Issue

[Glen Langston]

Hello Cinaed,

I’ve not experienced this problem with Gnuradio you describe, but
in another context, spacecraft communication, we had a simple test setup
that transmitted a fixed pattern of alternating ones and zeros.

However the way error coding was done the lock was always poor.   

For testing purposes you might have much better luck by sending a “sudo-random”
noise sequence that you define and write into the transmit code.Then
test that this code arrives correctly on the receive side.   

We found the lock was very reliable, for the noise-like sequence.

Hope this helps, but just a guess

Glen


> On Nov 30, 2022, at 3:54 PM, Cinaed Simson  wrote:
> 
> Hi Rohith - Ihe minim sampling rate  for the Pluto is in the ball park of 500 
> KHz. 
> 
> See
> 
>   
> https://ez.analog.com/adieducation/university-program/f/q-a/557730/pluto-sdr-sampling-rate
> 
> -- Cinaed
> 
> 
> On 11/30/22 05:54, Rohith Rajan wrote:
>> I am asking a doubt regarding receiver using an  Adalm Pluto SDR
>> In the receiver section we are using Polyphase Clock Sync, Linear Equalizer 
>> and Costas Loop.
>> My doubt is that is the configuration parameters of these blocks are 
>> dependent on the BW of the signal(Sample Rate)
>> 
>> Keeping the parameters as Normal  (In Polyphase Clock Sync block- No of 
>> filters(nfilts) as 32, Loop Bw .0628, RRC filter as
>> 
>> firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), 0.35, 
>> 11*sps*nfilts), sps as 4
>> 
>> ; In Linear Equalizer No of Taps as 15 ;In CostasLoop Loop BW as .0628) when 
>> I set the BW(sample Rate around)1MHz I can receive the datas.
>> 
>> But when I set the BW(Sample Rate) as 125KHz I cannot receive the datas.
>> 
>> Anyone plese tell me what modification I have to make ?
>> 
> 

Re: [GSoC porting SIMD to gr-web] weekly update

[Glen Langston]

Dear Yao,

It would be great to see an example web browser for
a simple SDR, like an RTLSDR.

Glen

> On Aug 24, 2022, at 11:29 AM, 史 皓航  wrote:
> 
> Hi, everyone!
>  
> I am working on enabling gnuradio to run faster on the browser through `simd 
> on wasm`.
> I will post weekly updates in this thread. The following is from last week:
>  
> Short version report: 
> Later plan: 
> 1. Develop those missing components in gr-web (making it more extensible)
> 2. To support `simd on wasm` this project will go slow pace.
>  
>  
> Full version blog: blog here
>  
>  
> Yours,
> Yao
>  
> 发件人: 史 皓航
> 发送时间: 2022年8月16日 23:37
> 收件人: discuss-gnuradio@gnu.org
> 主题: re: [GSoC porting SIMD to gr-web] weekly update
>  
> Hi, everyone!
>  
> I am working on enabling gnuradio to run faster on the browser through `simd 
> on wasm`.
> I will post weekly updates in this thread. The following is from last week:
>  
> Short version report: 
> Has Done: 
>1. Building debug mode `CPython`. 
> 2. Compare the `webapp` directory output files. (not fully finish)
> 3. Use `wasm2wat` to ensure `volk` is really under `wasm-simd`.
>  
> Delay and TODO in this week: 
> 2. Compare the `webapp` directory output files.
> 4. Enabling open and save files for user-selected paths in gr-web.
>  
> Full version blog: blog here
>  
>  
> Yours,
> Yao
>  
> 发件人: 史 皓航
> 发送时间: 2022年8月9日 23:34
> 收件人: discuss-gnuradio@gnu.org
> 主题: re: [GSoC porting SIMD to gr-web] weekly update
>  
> Hi, everyone!
>  
> I am working on enabling gnuradio to run faster on the browser through `simd 
> on wasm`.
> I will post weekly updates in this thread. The following is from last week:
>  
> Short version report: 
> Has Done: 
> Building with `volk`  `wasm-simd` success, running fail.
>  
> TODO: 
> 1. Building debug mode `CPython`.
> 2. Compare the `webapp` directory output files.
> 3. Use `wasm2wat` to ensure `volk` is really under `wasm-simd`.
> 4. Enabling open and save files for user-selected paths in gr-web.
>  
> Full version blog: blog here
>  
>  
> Yours,
> Yao
>  
> 发件人: 史 皓航
> 发送时间: 2022年8月2日 23:56
> 收件人: discuss-gnuradio@gnu.org
> 主题: re: [GSoC porting SIMD to gr-web] weekly update
>  
> Hi, everyone!
>  
> I am working on enabling gnuradio run faster on browser.
> I will post weekly update in this thread. Following is last week:
>  
> Short version report: 
>  Has Done: 
> running flow graph again success
> TODO: 
> 1. Transplant volk to wasm-simd building
> 2. Enable edit module in flow graph on gnuradio-web (current not support edit 
> module).
>  
> Full version blog: blog here
>  
>  
> Yours,
> Yao
>  
>  
> <271153F54912402C8D9FB6576EFD281D.png>
> 发件人: 史 皓航 
> 发送时间: Monday, July 25, 2022 10:24:15 PM
> 收件人: discuss-gnuradio@gnu.org 
> 主题: 回复: [GSoC porting SIMD to gr-web] weekly update
>  
> Hi, all!
>  
> I will post weekly this project update in this thread, following is last week:
> 
>  
> Short version report:( unfortunaly I need to rebuild gr-web)
> 
>  
> 
>  Has Done: 1. using latest gr commit to build gr-web. 2. Fix commit 
> missing issue.
> 
>  TODO: 1. fix the running fail issue.  2. And push the modification to 
> marc’s repo.
> 
>  
> Full version report: blog here
> 
>  
> Yours,
> Yao
>  
> 发件人: 史 皓航
> 发送时间: 2022年7月18日 22:39
> 收件人: discuss-gnuradio@gnu.org
> 主题: re: [GSoC porting SIMD to gr-web] weekly update
>  
> Hey, all!
> 
>  
> I will post weekly this project update in this thread, following is last week:
> 
>  
> Short version report:(due to covid-19 the progress slows down a little) 
> 
>  
> 
>  Has Done: post a  blog to introduce the dev tool usage(part 1)
> 
>  TODO: post another blog and measure the different implemented volk  
> performance(time cost first) 
> 
>  
> Full version report: blog here
> 
>  
> Yours,
> 
> Yao.
> 
>  
>  
> <271153F54912402C8D9FB6576EFD281D.png>
> 发件人: 史 皓航 
> 发送时间: 2022年7月12日 0:10
> 收件人: discuss-gnuradio@gnu.org 
> 主题: [GSoC porting SIMD to gr-web] weekly update 
>  
> Hey, all!
>  
> This is a weekly update email about the GSoC project.
>  
> Following is last week progress and next week plan:
> Short:
> l  Has Done:  building gr-web wholly and play grc.
> l  Need to be Done: Intend to run a benchmark to measure different implement 
> to `volk`
> Full blog:
>  Week2 | eat4toast.github.io
>  
> Yours,
> Yao
>  
> 发件人: 史 皓航
> 发送时间: 2022年7月5日 00:06
> 收件人: discuss-gnuradio@gnu.org
> 主题: [GSoC porting SIMD to gr-web] weekly update
>  
> Hi, everyone!
> I've been accepted to work with GnuRadio for this year's Google Summer of 
> Code.
>  
> The task I intend to implement is porting SIMD code to gr-web through wasm,
> which enables gnuradio more extensible and popular through the browser.
>  
> I am really sorry, this post seems a bit late due to some unexpected problems 
> with the building gr-web from the source.
>  
> Last week's blog:
>  https://eat4toast.github.io/2022/07/04/week1.html
>  
> I will post a weekly update on the mailing list, well the blog will recor

Radio Astronomy Raspberry Pi image with GNU Radio 3.10.1

[Glen Langston]

Hello Aficionados,

Franco Venturi has been busy cleaning up the Raspberry Pi Operating
system for use with Radio Astronomy.  GnuRadio version 3.10.1.1 is installed in 
the 
Raspberry Pi operating system is now on  the cutting edge.

The Operating system is now 64bit, which is supposed to increase the efficiency 
of the software.

The installation guide and operating system are available for download
in this shared Google Drive:

https://drive.google.com/drive/folders/1t2soWvGIgze7wg-7QGlVgB0m3Q-BR3C-?usp=sharing

The document and OS are tagged with date 22Feb24.
The operating system is compressed to 2.26 Giga-Bytes:
NsfGR310-22Feb24.img.xz
The guide name is:
RadioAstronomyWithRaspberry-2022Feb24.pdf

Hope this is helpful

Glen

This version is tested with these SDRs:

AIRSPY R2, Mini,
SDRPLay RSP1A
RTL-SDR
PlutoSDR

Re: Headless Airspy operation on Raspberry Pi

[Glen Langston]

Thanks,

We’re hoping to soon release a newer version, that has the first gr3.10 release.

Best regards

Glen

> On Jan 14, 2022, at 11:52 AM, Lamar Owen  wrote:
> 
> On 1/3/22 13:04, Glen Langston wrote:
>> Hello and Happy New Year to all,
>> 
>> We’ve just released a version of the Raspberry PI OS that works with Airspy 
>> R2 and Airspy Mini,
>> as well as SDRPlay RSP1A, PlutoSdr and RTL-SDR.
>> 
> Nicely done!

Re: [airspy] Headless Airspy operation on Raspberry Pi

[Glen Langston]

Hi Wayne,

The code will work on a RPi 3, but will drop many (most?) samples if
sampling above about 3 MHz.  Pi 4 and 400 can gather 8 MHz I+Q samples
without drops (except for PlutoSDR, which drops samples above about 4 MHz).

Hopefully the installation guide explains installation.  Several people
have successfully followed previous versions.  
1) “Etch” to the sdcard,
2) figure out your router ip address, 
3) update the file in /boot/dhcpcd.conf for your router IP 
4) Install in the Raspberry PI,
5) VNC into the Pi, no monitor or keyboard needed.

Good Luck,

Glen


> On Jan 3, 2022, at 3:34 PM, W B  wrote:
> 
> AWESOME Glen - - just what I was wanting /needing.  Will it work with RPi  3 
> and 4?
> Do I just flash it to an SD card?
> I have been playing with the SDR for Radio Astronomy on Win 10 OS but still 
> trying to “space legs” on getting it to work.
> Many thanks!!
> Wayne
>  
> “ Old Chemists Don’t die…they just become Inorganic Chemists…”
>  
> From: Glen Langston
> Sent: Monday, January 3, 2022 3:26 PM
> To: air...@groups.io
> Cc: DSPIRA; GNURadio Discussion List; WVURAIL/dspira-lessons
> Subject: [airspy] Headless Airspy operation on Raspberry Pi
>  
> Hello and Happy New Year to all,
> 
> We’ve just released a version of the Raspberry PI OS that works with Airspy 
> R2 and Airspy Mini,
> as well as SDRPlay RSP1A, PlutoSdr and RTL-SDR.
> 
> It is rather specifically configured for Radio Astronomy, but anyone could 
> build other designs
> in it using Gnuradio 3.10 (first release candidate).
> 
> It is available for download (3.1 GB) at:
> https://drive.google.com/file/d/1N0bX20tUO_IyRBlp06aAXGMwbx-ykomz/view?usp=sharing
> 
> The installation guide (pdf) is here:
> 
> https://drive.google.com/file/d/1ssS_zBQWDEXMENc2_aqqPGxGkEEU5Ea3/view?usp=sharing
> 
> Hope this is useful to you.
> 
> Best regards
> 
> Glen
> 
> 
> > On Jan 2, 2022, at 9:23 PM, Dale Farnsworth  wrote:
> > 
> > I recall seeing 3 of your posts in the past 2 days.
> > 
> > On Sun, Jan 2, 2022 at 12:30 PM __jmp  wrote:
> > Is anyone seeing my replies?  I cant' seem to get a response from anything 
> > I post.
> > 
> > 
> > 
> 
> 
> 
> 
> 
> 
>  
> _._,_._,_
> Groups.io Links:
> You receive all messages sent to this group. 
> 
> View/Reply Online (#42096) |  Reply To Group | Reply To Sender |  Mute This 
> Topic | New Topic
> Your Subscription | Contact Group Owner |  Unsubscribe  
> [glen.i.langs...@gmail.com]
> 
> _._,_._,_

Headless Airspy operation on Raspberry Pi

[Glen Langston]

Hello and Happy New Year to all,

We’ve just released a version of the Raspberry PI OS that works with Airspy R2 
and Airspy Mini,
as well as SDRPlay RSP1A, PlutoSdr and RTL-SDR.

It is rather specifically configured for Radio Astronomy, but anyone could 
build other designs
in it using Gnuradio 3.10 (first release candidate).

It is available for download (3.1 GB) at:
https://drive.google.com/file/d/1N0bX20tUO_IyRBlp06aAXGMwbx-ykomz/view?usp=sharing

The installation guide (pdf) is here:

https://drive.google.com/file/d/1ssS_zBQWDEXMENc2_aqqPGxGkEEU5Ea3/view?usp=sharing

Hope this is useful to you.

Best regards

Glen


> On Jan 2, 2022, at 9:23 PM, Dale Farnsworth  wrote:
> 
> I recall seeing 3 of your posts in the past 2 days.
> 
> On Sun, Jan 2, 2022 at 12:30 PM __jmp  wrote:
> Is anyone seeing my replies?  I cant' seem to get a response from anything I 
> post.
> 
> 
> _._,_._,_
> Groups.io Links:
> You receive all messages sent to this group.
> 
> View/Reply Online (#42077) | Reply To Group | Reply To Sender | Mute This 
> Topic | New Topic
> Your Subscription | Contact Group Owner | Unsubscribe 
> [glen.i.langs...@gmail.com]
> 
> _._,_._,_

Re: Synchronization: PPS and Tx signal in a USRP N200

[Glen Langston]

Thanks for your very well described study
of SDRs processing GPS signals and resulting timing accuracy.

Best regards

Glen

> On Dec 11, 2021, at 3:28 AM, jmfriedt  wrote:
> 
> If it can be of any help, we discussed generating a GPS-aligned 1-PPS
> in http://jmfriedt.free.fr/ifcs2021.pdf and the oral presentation at
> http://jmfriedt.free.fr/ifcs2021_presentation_jmfriedt.mp4 prepared
> for the International Frequency Control Symposium (IFCS).
> 
> What we realized when working on this topic is that the only place
> where time is known in an SDR processing sequence is at the ADC sample
> acquisition step, since all subsequent processing and data transfer
> afterwards are asynchronous, including the multitasking non-real time
> operating system GNU Radio is running on. Hence, the control on the
> 1-PPS alignement can only be achieved at the FPGA level clocking the
> ADC: the host clock is irrelevant since we do not know how much time
> was needed to transfer and process data. Luckily, GNU Radio provides a
> timestamp on each sample, assuming no data was lost since streaming
> started, so the control signal can be fed back to the SDR clock if the
> delay between reference and generated 1-PPS is measured using the same
> time reference of the ADC clock.
> 
> Best, JM
> 
>>> On 2021-12-10 17:25, isaac mario tupac davila wrote:  
 Hello everyone!
 
 My name is Isaac. I have a curious situation here... I've
 generated a pulsed signal per second. I've saved one second
 period in a .h5 file, so that I'm sure I'm having a fixed signal
 per second, and then repeat it in my GRC flowgraph. .
 
 To use this signal as Tx I'm trying to synchronize a USRP N200 and
 a trimble in GRC. After run my flowgraph, this is what I see:
 
 imagen.png
 
 imagen.png
 
 The yellow signals are the PPS of my trimble and my purple signals
 are my tx signal per second. They are periodic in time but when
 you see it deeper, the difference between the timble PPS and my Tx
 signal is approx 97 ms. I think this difference should be close to
 cero, as my USRP and trimble are synchronized. ¿What is happening
 here? ¿Is this a normal behavior? I'm using unknown PPS to
 configure my UHD:USRP sink in GRC
 
 I'll appreciate any help to clarify this behavior
 
 Regards
 Isaac T.
 
>>> Your flow-graph made very little sense to me.  If you want to 
>>> synchronize your TX, you have to take explicit measures to ASK the
>>> USRP to schedule your transmits at specific times.
>>>   The 1PPS signal only synchronizes an internal time-stamp clock in
>>> the unit.  It has NO WAY of knowing what the *meaning* of your
>>> samples are, so it can't possibly
>>>   synchronize some arbitrary event in your continuous sample stream
>>> to 1PPS without you explicitly asking for when your bursts need to
>>> be sent.
>>> 
>>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
>>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> Besancon, France

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Hi Marcus,

However SDRPlay3 only builds on gnuradio3.9

One of the many million paths I’ve gone down because different gnuradio versions
break different aspects of other software:

dietpi@DietPi:~/gr-sdrplay3/build$ cd dietpi@DietPi:~/gr-sdrplay3$ cd build
dietpi@DietPi:~/gr-sdrplay3/build$ cmake ..
-- The CXX compiler identification is GNU 10.2.1
-- The C compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found Boost: /usr/lib/aarch64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake 
(found suitable version "1.74.0", minimum required is "1.65") found components: 
filesystem program_options regex thread 
CMake Error at CMakeLists.txt:95 (find_package):
  Could not find a configuration file for package "Gnuradio" that is
  compatible with requested version "3.9".

  The following configuration files were considered but not accepted:

/usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake, version: 
3.8.2.0
> /lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake, version: 
> 3.8.2.0On Nov 23, 2021, at 7:00 PM,


So I’ll keep searching for a gnuradio 3.9 release inside a PI OS image.

Thanks

Glen

> 
> Hi Glen,
> 
> seeing that 3.8 is the standard on Debian 11, Ubuntu 20.04, 20.10, 21.04, and 
> 21.10: nope, the GNU Radio 3.8 user base is rather large and alive :)
> 
> GNU Radio's version has nothing to do with whether your RSP1A works with 
> soapy.
> 
> Can't really tell you anything about what fails on the SDRPlay software side, 
> especially since they're not even supplying source code to their driver, but 
> I can tell you it doesn't even directly "talk" to GNU Radio, so this is not a 
> matter of 3.8 or 3.9.
> 
> Best regards,
> Marcus
> 
> On 23.11.21 23:04, Glen Langston wrote:
>> Thanks to everyone for your various attempts to help me get an SDRPlay RSP1A 
>> working properly on
>> a raspberry PI and gnuradio 3.8
>> So far I’ve failed completely.   Following your instructions, many version 
>> have been installed but I continue
>> to find incompatibilities, crashing due to different assumptions about
>> the coding environment., It seems most folks have left 3.8 and are at 3.9.
>> Does anyone have a Raspberry PI OS image that includes gnuradio 3.9 and also
>> support for SDRPlay’s RSP1A?
>> I’d greatly appreciate being able to download a copy of that version.
>> Best regards
>> Glen
> 

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Thanks to everyone for your various attempts to help me get an SDRPlay RSP1A 
working properly on
a raspberry PI and gnuradio 3.8

So far I’ve failed completely.   Following your instructions, many version have 
been installed but I continue
to find incompatibilities, crashing due to different assumptions about
the coding environment., It seems most folks have left 3.8 and are at 3.9. 

Does anyone have a Raspberry PI OS image that includes gnuradio 3.9 and also
support for SDRPlay’s RSP1A?

I’d greatly appreciate being able to download a copy of that version.

Best regards

Glen

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Hi Chris,

Thanks for  your reply.

After countless hours of messing around, I partially have 
SDRPlay supported on a Raspberry PI 4 with gnuradio 3.8.2

Within gnuradio and osmosdr source blocks, I have SDRPlay data streaming, but 
I’ve not been
able to turn the bias-tee on or make any sense of the gain settings.

With gr-soapy source

I’ve got trouble getting the stream of data to flow.

with  SoapySDRUtil —find  I do find the device with reasonable values

##
## Soapy SDR -- the SDR abstraction library ##
##

Found device 0
  driver = sdrplay
  label = SDRplay Dev0 RSP1A 190316E696
  serial = 190316E696

So, my question is:

Do you (or anyone) have examples of the values to put in
either of the source blocks to control the bias-tee 
gains and notch filters?

Thanks again!

Best regards

Glen

Again this was working perfectly in gnuradio 3.7.13 but is huge headache
in later version.

> On Nov 20, 2021, at 7:54 AM, Chris Vine  wrote:
> 
> On Fri, 19 Nov 2021 10:04:06 -0500
> Glen Langston  wrote:
>> Hello Chris,
>> 
>> I’ve seen your emails concerning SDRPlay and gnuradio 3.8 and 3.9
>> 
>> So far, after countless hours, I’ve yet to get SDRPlay working on a
>> raspberry pi with gnuradio 3.8.
>> 
>> My code works fine with gnuradio 3.7, but all the documentation for
>> 3.8 seems to be out of date as everything was broken in the move to 3.9.
>> 
>> Do you happen to have a Raspberry PI OS complete image that works
>> with gnuradio 3.8 and SDRPlay?
>> 
>> If so would you consider posting a copy of the entire OS?
>> 
>> Thanks
> 
> Hi Glen,
> 
> I am afraid I don't have a raspberry pi so I can't help you with that.
> I am now using gnuradio-3.9, but I had a RSP1A working well on x86_64
> hardware with gnuradio-3.8 with the following:
> 
> * gnuradio-3.8.2.0
> 
> * soapy-sdr (repo https://github.com/pothosware/SoapySDR) master branch
>  as at the commit of 2020-07-13
> 
> * gr-soapy (repo https://gitlab.com/librespacefoundation/gr-soapy)
>  master branch as at the commit of 2021-02-16
> 
> * sdrplay-2.13.1
> 
> * soapy-sdrplay (repo https://github.com/pothosware/SoapySDRPlay2)
>  master branch as at the commit of 2020-06-29
> 
> As an alternative to the last two I have also used:
> 
> * sdrplay-3.7.1
> 
> * soapy-sdrplay (repo https://github.com/pothosware/SoapySDRPlay3),
>  master branch as at commit of 2021-01-12
> 
> gr-osmosdr does not work correctly with gnuradio-3.8 with the RSP1A (nor
> very well with gnuradio-3.7 either).  Use gr-soapy instead, or if you
> are using gqrx, use gr-osmosder with the soapy backend (not the "unfree"
> sdrplay backend).
> 
> Hope this helps.
> 
> Chris

Re: v3.7 End of Maintenance

[Glen Langston]

Thanks for all your efforts.

However still there are MANY external packages that don’t work beyond 3.7,
so we're stuck in 3.7 world.  (We have inched to 3.8 but SDRPlay was not well 
supported).

I know this is difficult, but please try to ADD capabilities without destroying
old capabilities.  From the Nubi point of view, it is easier for an expert to 
enable
both SWIG and PYBIND than it is to figure out the transition, when the Nubi 
does not 
care a bit what the difference is.

Thanks again,

Glen


> On Nov 18, 2021, at 5:32 PM, Jeff Long  wrote:
> 
> We are officially ending maintenance of v3.7. There will be no further 
> v3.7.X.X releases, and pull requests will no longer be accepted for the 
> maint-3.7 branch.
> 
> The last v3.7 release (v3.7.14.0) was over 18 months ago and there are only a 
> handful of unreleased commits on the maint-3.7 branch. 
> Packagers/distributions have moved on to newer versions. Additionally, we are 
> not set up to do automated testing on maint-3.7 and need to apply our 
> development/maintenance efforts to v3.8, v3.9 and the upcoming v3.10.
> 
> Of course, this is open source, so there is no End of Life if packagers are 
> still interested in v3.7. If you still package v3.7, please let us know.
> 

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Hi Jeff,

Thanks again for everyone’s continued efforts.

We did get 3.8 working for several dongles, particularly the Airspy, air spy
mini, rtlsdr and limesdrs.   So that is great.

Unfortunately the SDRPlay folks did not have time to get the SDRplay
included in the 3.8 revision we got running and I’ve been struggling with that.

I’d been able to use apt-get and various build steps working before.
What I find difficult is that each revision has a new preferred build method.
I’d not needed PyBombs before now.

I’m trying to follow the PyBombs instructions but it is
failing at the UHD step, which I don’t want anyway. So at the moment
I’m googling how to not install UHD on a raspberry pi, so that I can go
to the next step.

A fairly simple question.   Is PyBombs required for 3.9 and 3.10
or could I go back to git clone and the build steps?

Thanks

Glen


, except that we could not get 
> On Oct 1, 2021, at 11:35 AM, Jeff Long  wrote:
> 
> SDRPlays work well with 3.8, 3.9 and 3.10 using multiple methods mentioned by 
> various people here. The proprietary drivers can make things a little bit of 
> a challenge. Sure, documentation can always use improvement, and there's a 
> big effort to work on that, all by volunteers. More volunteers who use GR in 
> different ways could always help.
> 
> BTW, I'm sure you could find a more productive way to work on this than 
> responding to our release announcement with a complaint. I did offer to help 
> you figure some stuff out months ago and you never took us up on it.
> 
> On Fri, Oct 1, 2021 at 10:51 AM Glen Langston  
> wrote:
> Hi Marcus and Franco and everyone,
> 
> Thanks again for your help.
> 
> I have to say, the online documentation is such a mess.  I continue
> to wander into documentation that is obsolete but appears to be current.  I 
> thought
> I’d found the perfect way, using pybombs, which suggested
> the latest version, 3.9, would be installed.  
> 
> But sadly, now I’m have way backwards to installing 3.7 gnuradio, but am 
> afraid to stop the 
> build for fear of leaving a big mess behind.  So I’ll try again after this 
> finishes.
> 
> Concerning 3.9, there is, in my opinion, no excuse for killing SWIG for the 
> benefit of the future
> use of pybind.  These should have both been enabled in gnuradio for a 
> transition period. 
> Us who are actually trying to use gnuradio, not develop in it, do not have 
> the time or inclination
> to play around with confusing instructions that are only half correct.
> 
> I’ve purchased too many SDRPlays, which work fine in 3.7 and are not supported
> in 3.8, which we’ve finally struggled to get working.  I continually discover 
> that bar is
> too high for _other_ experts to support the confusing gnuradio whims of the 
> re-organizers.
> 
> Because gnuradio is a collaboration, changes that break the OLD should 
> strongly be avoided.
> Please strive to make changes that improve the code along new branches so 
> that are compatible 
> with the old code.
> 
> Thanks!
> 
> Sorry for the continued rant, but we’ve been struggling to upgrade to the 
> latest branch
> for over a year now…   By the time we get to 3.9 we expect that 3.10 will be 
> out.
> 
> From what I heard from GRcon 21, many will leave gnuradio when everything is 
> broken in 4.0. 
> 
> Cheers
> 
> Glen
> 
> > On Oct 1, 2021, at 9:58 AM, Marcus D. Leech  wrote:
> > 
> > On 2021-10-01 7:34 a.m., Franco VENTURI wrote:
> >> If you are running GNU Radio >= 3.9, there's also the native SDRplay 
> >> module I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you 
> >> can find the announcement to this mailing list here: 
> >> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg1.html
> >> 
> >> Unfortunately it won't build on GNU Radio 3.8 because of SWIG.
> >> 
> >> Since it interfaces to the native SDRplay API (version 3.X), it doesn't 
> >> require SoapySDR or gr-osmocom; I haven't done any comparison with the 
> >> other approaches of interfacing with the SDRplay RSP devices (SoapySDR and 
> >> gr-osmocom), but if someone does, I would be really interested in hearing 
> >> their results.
> >> 
> >> Franco
> >> 
> >> 
> > My personal preference when writing applications is to make them 
> > hardware-agnostic whenever possible, which is why I and am sure lots of 
> > others
> >   prefer the gr-osmosdr or gr-soapysdr approach of abstracting the hardware 
> > interface.  This is particularly important when the flow-graphs you've
> >   developed are going to be used by non-GR people, or even people who have 
> > no particular expertise in modifying software.
> > 
> > 
> > 
> 
> 

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Hi Marcus and Franco and everyone,

Thanks again for your help.

I have to say, the online documentation is such a mess.  I continue
to wander into documentation that is obsolete but appears to be current.  I 
thought
I’d found the perfect way, using pybombs, which suggested
the latest version, 3.9, would be installed.  

But sadly, now I’m have way backwards to installing 3.7 gnuradio, but am afraid 
to stop the 
build for fear of leaving a big mess behind.  So I’ll try again after this 
finishes.

Concerning 3.9, there is, in my opinion, no excuse for killing SWIG for the 
benefit of the future
use of pybind.  These should have both been enabled in gnuradio for a 
transition period. 
Us who are actually trying to use gnuradio, not develop in it, do not have the 
time or inclination
to play around with confusing instructions that are only half correct.

I’ve purchased too many SDRPlays, which work fine in 3.7 and are not supported
in 3.8, which we’ve finally struggled to get working.  I continually discover 
that bar is
too high for _other_ experts to support the confusing gnuradio whims of the 
re-organizers.

Because gnuradio is a collaboration, changes that break the OLD should strongly 
be avoided.
Please strive to make changes that improve the code along new branches so that 
are compatible 
with the old code.

Thanks!

Sorry for the continued rant, but we’ve been struggling to upgrade to the 
latest branch
for over a year now…   By the time we get to 3.9 we expect that 3.10 will be 
out.

From what I heard from GRcon 21, many will leave gnuradio when everything is 
broken in 4.0. 

Cheers

Glen

> On Oct 1, 2021, at 9:58 AM, Marcus D. Leech  wrote:
> 
> On 2021-10-01 7:34 a.m., Franco VENTURI wrote:
>> If you are running GNU Radio >= 3.9, there's also the native SDRplay module 
>> I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you can find 
>> the announcement to this mailing list here: 
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg1.html
>> 
>> Unfortunately it won't build on GNU Radio 3.8 because of SWIG.
>> 
>> Since it interfaces to the native SDRplay API (version 3.X), it doesn't 
>> require SoapySDR or gr-osmocom; I haven't done any comparison with the other 
>> approaches of interfacing with the SDRplay RSP devices (SoapySDR and 
>> gr-osmocom), but if someone does, I would be really interested in hearing 
>> their results.
>> 
>> Franco
>> 
>> 
> My personal preference when writing applications is to make them 
> hardware-agnostic whenever possible, which is why I and am sure lots of others
>   prefer the gr-osmosdr or gr-soapysdr approach of abstracting the hardware 
> interface.  This is particularly important when the flow-graphs you've
>   developed are going to be used by non-GR people, or even people who have no 
> particular expertise in modifying software.
> 
> 
> 

Re: SoapySDR Question

[Glen Langston]

Hi Jeff,

Thanks for your quick reply.

I was having trouble figuring out what to put in the Soapy Source block.   
Do you have a flow graph example?

Thanks

Glen

In the mean time I’ll try pybombs


> On Sep 30, 2021, at 9:11 PM, Jeff Long  wrote:
> 
> I installed gr-soapy for 3.8 (using PyBOMBS), plugged in a RSP1A, and it 
> worked. This is the LibreSpace code, as we don't have in-tree Soapy support 
> in 3.8.
> 
> I'd already installed the soapy libs (v0.8.1-g1cf5a539) and driver modules, 
> also via PyBOMBS. Make sure it's not a soapy or usb problem by running
> 
>   SoapySDRUtil --probe
> 
> My test was just a Soapy Source connected to a QT GUI Sink. Sample rate is 
> 1M, and so is the bandwidth in the Soapy Source on the RF tab. Don't know if 
> that matters. Everything else is defaults.
> 
> On Thu, Sep 30, 2021 at 8:46 PM Glen Langston  
> wrote:
> Thanks for all everyone's efforts.   
> 
> We hope to give them a try.
> 
> I’ve got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
> with Gnuradio 3.8.  I’ve not been able to find a running example.
> 
> Please send a link, if you’ve got a good example.
> 
> Thanks!
> 
> Glen
> 
> For our successes in Radio Astronomy work see the memos at
> https://github.com/WVURAIL/lightwork
> 
> 
> > On Sep 30, 2021, at 7:39 PM, Jeff Long  wrote:
> > 
> > GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target 
> > date with hours to spare. For details, see the Github release pages:
> > 
> > https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> > https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
> > 
> > Next releases are expected in December.
> 

Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Thanks for all everyone's efforts.   

We hope to give them a try.

I’ve got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
with Gnuradio 3.8.  I’ve not been able to find a running example.

Please send a link, if you’ve got a good example.

Thanks!

Glen

For our successes in Radio Astronomy work see the memos at
https://github.com/WVURAIL/lightwork


> On Sep 30, 2021, at 7:39 PM, Jeff Long  wrote:
> 
> GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target 
> date with hours to spare. For details, see the Github release pages:
> 
> https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
> 
> Next releases are expected in December.

Re: Changing the frequency of signal source at runtime

[Glen Langston]

Hello

Maybe you could share your .grc or python file.

I’ve had pretty good luck with gnuradio 3.7.13 and SDRPlay RSP1A,
where changing the frequency works fine.   

I’ve not gotten SDRPlay RSP1A to work with gnuradio 3.8, as they’re
not interested in following gnuradio changes any longer.

What gnuradio version are you using?

Regards

Glen

> On Jul 14, 2021, at 11:59 AM, Pratik Bhogale  wrote:
> 
> Hi team,
> I hope you are well.
> I need help with changing the tuned frequency of the source RSP1A, after a 
> certain amount of time.
> I have tried multiple potential solutions that I found online through mailing 
> lists and FAQs and other solutions fr reconfiguring the flowgraph using lock 
> and unlock, wait and time.sleep(), etc. and then invoking the 
> set_rsp1a_freq_mhz().
> I have not been able to get any result from any of those solutions.
> I need my flowgraph to execute for a certain amount of time at a particular 
> frequency for the RSP1A, then I want to change the frequency and rerun the 
> flowgraph for some time, change the frequency again, so on and so forth.
> Kindly help in figuring this out.
> 
> Best regards
> Pratik Bhogale.
> 

Re: SDR branches selector

[Glen Langston]

> On Jul 6, 2021, at 7:37 AM, Marcus Müller  wrote:
> 
> Hi Yasir,
> 
> On 06.07.21 06:07, Yasir ABBAS wrote:
>> Hello community
>> 
>> I am using Gnuradio 3.7.
> 
> Please don't. GNU Radio 3.7 is our legacy release, which we only still 
> maintain because
> there's existing systems based on it.
> 
> If you're now learning GNU Radio, you should be using GNU Radio 3.9 or 3.8, 
> never 3.7.
> 

Thanks for all your efforts Marcus (and all),

However I still feel that the GNU Radio project made a major error breaking so
much code in the transition from 3.7 to 3.8 and 3.9.  While we can each struggle
to update our own packages, it is very difficult to fix other’s packages that we
depend on.

Please, Please, Please, in the future, make great additions, but 
without destroying older code.  This may mean that you’ll have multiple
methods for new system functions, but my guess it is much easer for ace 
developers to
deal with parallel systems than application specific programers/developers.

Thanks

Glen
> 
> On GNU Radio 3.7, there isn't. On 3.8 and 3.9, we've got one.
> 
> Best regards,
> Marcus

Re: gr-iio now merged onto master branch

[Glen Langston]

Great work.  Thanks.

Which gnuradio versions now include gr-iio in tree, just 3.9?

Glen


> On Jun 4, 2021, at 6:57 AM, Josh Morman  wrote:
> 
> Greetings GR community!
> 
> Thanks to the work of many people over a long period of time, gr-iio, which 
> brings in direct support for Analog Devices hardware including the Pluto SDR 
> into GNU Radio, has been merged in-tree.
> 
> Special thanks the people that put the effort in here to develop this module 
> and bring it in-tree (sorry for anyone I miss):
> Travis Collins and the team at ADI  (original gr-iio OOT and original PR)
> Adam Horden (Managed the feature branch, CI, shepherding the contributions to 
> the latest PR, getting up to 3.9/3.10 interfaces)
> Ryan Long 
> Volker Schroer
> Jeff Long
> Edward Kigwana
> 
> gr-iio will build from source as long as CMake detects appropriately 
> versioned libiio and optionally libad9361.  
> 
> Currently the pluto sdr is supported with Pluto Source and Pluto Sink blocks. 
>  We intend to re-enable the fmcomms2/5 blocks after any issues are worked out 
> with the pluto blocks.  Please report any issues you come across either here 
> or to the github tracker (if you are sure it is an issue).
> 
> Josh

Re: [announcement] Release 3.9.0.0

[Glen Langston]

Dear Marcus and all,

It is great all the effort you’ve put into Gnuradio.

However, there is far far more effort going into trying to figure out
what has been broken, but these upgrades.

In an ideal world, there would be transition period form SWIG to whatever.
While we can each attempt to fix our own, now dead modules, it is very very
difficult to get others to fix their modules.

Please restore Swig for a transition period.  

Thanks

Best regards

Glen



> On Jan 17, 2021, at 2:51 PM, Marcus Müller  wrote:
> 
> Dear SDR community most likely to travel in time to save the present,
> 
> The future is not set, there is no fate but what we make for ourselves. In 
> this
> very spirit, GNU Radio 3.9 packs a whole bunch of power when it comes to
> transforming the way GNU Radio and its ecosytem can be developed in the 
> future.
> 
> You'll find the release tags and signed tarballs now on github, and later on
> https://www.gnuradio.org/releases/gnuradio/ .
> 
> Not only did we have great progressions from old dependencies that proved to 
> be
> all too problematic (SWIG, Python2), but also did we see an incredibly influx 
> of
> people actively working on how maintainable this code base is. This will 
> nurture
> the project for years to come.
> 
> All in all, the main breaking change for pure GRC users will consist in a few
> changed blocks – an incredible feat, considering the amount of shift under the
> hood. Mentioning large shifts, the work that went into the PyBind binding, the
> CMake modernization, the C++ cleanup, the bug-fixing and the CI infrastructure
> is worthy of explicit call out; I especially thank
> 
> * Josh Morman
> * Thomas Habets
> * Jacob Gilbert
> * Andrej Rode
> * Ryan Volz
> 
> here.
> 
> For developers of OOTs, I'm sure PyBind11 will pose a surprise. If you're used
> to SWIG, yes, that's more code to write yourself. But in effect, it's less 
> code
> that breaks, and when it breaks, it breaks in much more understandable ways.
> Josh has put a lot of effort into automating as much of that as possible.
> There's certainly no shortage of demand for that! The ecosystem (remember GNU
> Radio's tagline?) is in a steady upwind. We've seen more, and more stable,
> contributions from OOT maintainers. That's great!
> 
> For in-tree development, newer dependencies and removal of anachronisms will
> make sure things move much smoother. Our CI is getting – lately literally 
> every
> day – better, which means we not only catch bugs earlier, but also allow for
> much quicker review cycles.
> 
> One central change:
> 
> If you're contributing code upstream, we no longer need you to submit a CLA;
> instead, we ask you to just certify, yourself, that you're allowed to 
> contribute
> that code (and not, e.g. misappropriating someone else's code).
> 
> That's what the DCO (Developer Certificate of Origin) is: Just a quick, "hey,
> this code is actually for me to contribute under the project's license"; 
> nothing
> more.
> 
> Which means that our infrastructure will refuse to let your code into the tree
> if you didn't add a
> 
> `Signed-off-by: Maxime Example `
> 
> to your commit message. Luckily, git can do that for you: `git commit -s`.
> 
> ## [3.9.0.0] - 2021-01-17
> ### Changed
> 
>  Project Scope
> 
> - **We now require commits to be signed off (DCO)**; this means you have to
> attach `-s` to your `git commit` command line
> - License headers now SPDX format
> - C++14
> - use C++11 facilities in a lot of places where Boost was still used,
>   especially smart pointers, range loops
> - lambdas where `boost::bind` was used
> - C11
> - Dependency versions:
>  - Python 3.6.5
>  - numpy 1.13.3
>  - VOLK 2.4.1
>  - CMake 3.10.2
>  - Boost 1.65
>  - Mako 1.0.7
>  - PyBind11 2.4.3
> - Compiler options:
>  - GCC 8.3.0
>  - Clang 11.0.0 / Apple Clang 1100
>  - MSVC 1910 (Microsoft VS 2017 15.0)
> - VOLK now "regular" dependency, not in-tree submodule
> - numpy now also a CMake-checked hard dependency for Python support
> - Exception Handling: throw by value, catch by reference (clang-tidy check)
> - C++11: Emplace in vectors where you can; brings performance boni, but not
>  included in clang-tidy-checks
> - Further clang-tidy based code optimizations:
> - empty() instead of size() == 0
> - override where overriding virtual functions (which we do a lot)
> - Logging: removed all `std::cerr` and `fprintf(stderr,…)` by GNU Radio 
> logging
> - Logging: Changed logging format for many multiline error logs
> - purged `snprintf`, `printf` logging
> - There were a lot of places where a malloc'ed object was used internally, 
> where
>  that was inappropriate. Using simple instance-holding fields now.
> - `const` for members that were only set at construction time is now desired,
>  and implemented in most places
> - `const` -> `constexp` in a lot of places.
> - `assert` -> `static_assert`
> - An exception-throwing block will now terminate the flow graph process,
>  configurable through `top_block`
> - `

Re: New Raspberry PI Complete OS release

[Glen Langston]

Hi Gavin,

Thanks again.

What I need is a simple function that is -not- a standard part of Gnuradio
but rather can be built in 3.7, 3.8 or 3.9. that includes a c++ module

I’d prefer these to not be identically named but rather be tagged with gnuradio 
versions,
so that I can compare the differences.  I’m working with vectors. 
This probably already exists, but it is not clear to me what is a good example.

ie I’d like:

git clone http://www.github.com/gnuradio/examplev38
cd examplev38
mkdir build
cd build
cmake ../
make -j 3 (for raspberry pi 4)
sudo make install
sudo ldconfig

then allow me to look at this code and compare it with vector
code in 3.7 and 3.9, so there would need to be

git clone http://www.github.com/gnuradio/examplev37

and 

git clone http://www.github.com/gnuradio/examplev39

These should do exactly the same thing in each of the gnuradio versions.
I’d be calling the same “examplev” block in a .grc file that would show that the
build was successful.   That is what our simple vmedian_impl.cc, vmedian_impl.h
and vectordemo_c2.grc code must do.  (in WVURAIL/gr-radio_astro)

It is just not easy to get from 3.7 to 3.8 or 3.9.   Our code is not tagged
by gnuradio version numbers, but this example code must be, so we can compare 
one
version to another (I hope we don’t need to go to sub-versions, ie 3.8.2 etc).

Again this must already exist somewhere.  I am completely perplexed by CMAKE and
XML/YAML and SWIG/PYBIND differences.

Thanks
Glen



> On Feb 3, 2021, at 6:17 PM, Gavin Jacobs  wrote:
> 
> Glen,
> I'm going through a pain similar to yours.
> For working examples, you can look at the source for the blocks that are part 
> of GNU Radio. For example, the Multiply Constant block shows how to do a 
> callback, and the Add block shows how to do variable number of inputs. 
> Unfortunately, these blocks also have the complexity of allowing Vector 
> inputs, and different types of inputs, so you have to dig through that to get 
> at the parts you want. 
> 
> The closest thing I found for a working OOT module, is documented here:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B
> It only applies to 3.7 & 3.8, so you still have to sleuth out the differences 
> for 3.9.  Also, it does not show how to do variable # of inputs, nor a 
> parameter callback. I'm working on a block that needs those; so as soon as I 
> have it sorted out, I'll put the sources on Github.
> Guided Tutorial GNU Radio in C++ - GNU Radio
> Note: the get_minimum_distances function declaration also needs to be added 
> to the class header (my_qpsk_demod_cb_impl.h).The function 
> get_minimum_distances is a maximum likelihood decoder for the QPSK 
> demodulater. Theoretically, the function should compute the distance from 
> each ideal QPSK symbol to the received symbol (It is mathematically 
> equivalent to determining the Voronoi regions of the ...
> wiki.gnuradio.org
> 
> 
> 
> Date: Tue, 2 Feb 2021 21:19:32 -0500
> From: Glen Langston 
> To: Marcus Müller 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New Raspberry PI Complete OS release
> 
> I appreciate gr-modtool, but it is frustrating that modtool does not generate
> working code.   There really, really, really needs to be an ultra-simple 
> working
> example of C++ code for 3.8 and 3.9 that actually build.
> 
> The code could do anything, but just allow us to use it as the basis for
> creating YAML and SWIG/PYBIND code based on the new requirements.

Re: New Raspberry PI Complete OS release

[Glen Langston]

Thanks Gavin

I’ll take a look.

Best regards

Glen

> On Feb 3, 2021, at 6:17 PM, Gavin Jacobs  wrote:
> 
> Glen,
> I'm going through a pain similar to yours.
> For working examples, you can look at the source for the blocks that are part 
> of GNU Radio. For example, the Multiply Constant block shows how to do a 
> callback, and the Add block shows how to do variable number of inputs. 
> Unfortunately, these blocks also have the complexity of allowing Vector 
> inputs, and different types of inputs, so you have to dig through that to get 
> at the parts you want. 
> 
> The closest thing I found for a working OOT module, is documented here:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B
> It only applies to 3.7 & 3.8, so you still have to sleuth out the differences 
> for 3.9.  Also, it does not show how to do variable # of inputs, nor a 
> parameter callback. I'm working on a block that needs those; so as soon as I 
> have it sorted out, I'll put the sources on Github.
> Guided Tutorial GNU Radio in C++ - GNU Radio
> Note: the get_minimum_distances function declaration also needs to be added 
> to the class header (my_qpsk_demod_cb_impl.h).The function 
> get_minimum_distances is a maximum likelihood decoder for the QPSK 
> demodulater. Theoretically, the function should compute the distance from 
> each ideal QPSK symbol to the received symbol (It is mathematically 
> equivalent to determining the Voronoi regions of the ...
> wiki.gnuradio.org
> 
> 
> 
> Date: Tue, 2 Feb 2021 21:19:32 -0500
> From: Glen Langston 
> To: Marcus Müller 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New Raspberry PI Complete OS release
> 
> I appreciate gr-modtool, but it is frustrating that modtool does not generate
> working code.   There really, really, really needs to be an ultra-simple 
> working
> example of C++ code for 3.8 and 3.9 that actually build.
> 
> The code could do anything, but just allow us to use it as the basis for
> creating YAML and SWIG/PYBIND code based on the new requirements.

Re: stop making unneeded improvements

[Glen Langston]

Dear Marcus and all,

Thanks for all your efforts.  I really to appreciate all you’ve done.

Best regards,

Glen


> On Jan 16, 2021, at 8:30 PM, Marcus Müller  wrote:
> 
> Hi!
> 
> On 17.01.21 00:56, KB3CS - Chris wrote:
> 
>> why does not in my mind figure just as prominently as GSoC: other
>> campaigns like GSoD or GSoGUI ? (does anyone actually need me to fill in
>> the definitions for those abbreviations?)
> 
> Well, the G in GSoC is "Google", not "GNU Radio": Google sponsors a
> reasonable pay for a summer for students to work on open source projects
> that apply for that kind of support.
> 
> The rules of that preclude documentation work, and we are usually in no
> situation to spend much money. We work on changing that, but there's
> never been significant funds to throw at a technical writer, and what's
> more: the best tech writer needs either extensive domain knowledge, or
> much close cooperation time with the tech people – and both are very
> real limiting factors!
> 
> We did have multiple GSoC projects on GUI work. In fact, most years we
> had one. Getting someone up to speed with the project, and the usage
> patterns of the same, then have them contribute a great, and closed
> piece of GUI is definitely a employee management challenge, and don't
> forget that while these students are paid to work days like a proper
> developer, that's not true for the mentors that are supposed to
> supervise and support them – that's just extra workload atop of our
> dayjobs, and other GNU Radio contributions.
>> i am now an elder veteran of much documentation and technical writing
>> and .. and .. and .. as one might expect after a lengthy and
>> wide-ranging career.
> 
> Is this going where I hope it is going?
> 
>> where is the sustained outreach to *today's* new promising up-and-coming
>> Instructors (for tutorials), Technical Writers (to expand descriptions
>> and elucidate and footnote), and Documentation Writers (answering at
>> every turn - what is this? what is that? why is this? where are the
>> 'knobs'? where are the 'connectors'?) 
>> oh, it's a matter of money, i hear someone saying.. is it? is it really?
> 
> Yes, it is.
> Also, our days have 24h, so I can either write, review, merge and
> maintain code, or cooperate with a documentation writer. We honestly
> wouldn't have the time to even "supervise" someone to spend the time
> we're paying them for...
> 
> Google even had a GSoD, literally as you recommended. Small catch: it
> was unpaid.
> 
> Barry has done wonders here: He's coming from a space systems
> background, he's extremely clever, and he's picking up all the
> documentation slack, in an extremely independent way. That is really,
> really, incredible luck for us. Same with Marc, who's been doing a mix
> of documentation, management, and SDR teaching. I mean, how unlikely is
> it to find *two* people who are willing to do that, out of the goodness
> of their heart?
> 
>> who passed the hat lately? a boot? a plate? a tip cup? something? where?
> 
> Good point! We've been organizationally in a bit of a suboptimal
> situation to receive extraneous funding, but so far our money came
> primarily from sponsorships of companies at GRCon. The students working
> on GSoC, as said, were paid directly by Google, who doesn't allow work
> that is primarily documentation.
> 
> With SETI, we are now (pretty freshly) in a much better place, as
> outreach (and that includes user-friendliness) are an official goal,
> which might make money from various places at least attainable.
> 
> We have companies who dedicate engineer's time to us – that is
> invaluable. Monetary contributions can be complicated for some
> companies; that's one of the reasons why many companies choose to
> sponsor GRCon: that's a controlling-friendly way of making an expense on
> something.
> We simply didn't have had a steady income that would allow us to sustain
> a tech writer's compensation. I honestly don't know whether that has
> changed – but with the organizational shift, GRCon'20 going online due
> to epidemic problems, and whatnot…
>> please do press on forward but do not fear to ask for what is needed.
> 
> We ask for workpower!
> You're a tech writer. We're an underdocumented project with a lack of
> tech writers who know the project a bit.
> 
> Currently, we're seeing *huge* improvements compared to the past based
> on what Marc Lichtmann and Barry Duggan have been doing. That is really
> impressive, but I know the time that costs.
> If you have an acute
> 
>> no matter what it seems might be the result of honestly asking for help
>> when and where needed.
> 
> I promise money is welcome, very much so. I honestly don't know what
> kind of tax-deductible things we can offer. That's for someone else to
> explain!
> But, even more so: we're suffering success. When you ask [1] github how
> many people forked GNU Radio (and most of them do that to modify it and
> contribute their code back), github tells you:
> 
> ""Woah,

Re: Documenting GNURadio Use.

[Glen Langston]

Hi Jeff,

Thanks for your question.  Yes that is the code we need to port to 3.8 + 3.9.

Prof. Kevin Bandura, at West Virginia University, almost has the code working
in Gnuradio 3.8, but unfortunately not the SDRPlay support code.  (By
pulling the correct branch).

Rumor has it that SDRPlay works in 3.9, but I ran out of steam when
I got to the SWIG vs PYBind step.  Note that I have gnuradio-companion
working on a Raspberry pi 4, but just not the Swig vs Pybind conversion.

Best regards

Glen

> On Jan 5, 2021, at 5:30 PM, Jeff Long  wrote:
> 
> Is https://github.com/WVURAIL/gr-radio_astro the code you need to port?
> 
> On Tue, Jan 5, 2021 at 4:29 PM Glen Langston  
> wrote:
> Dear Gnuradio folks,
> 
> Again, I hope the email finds you all well and successful.
> 
> This email notes that Gnuradio Radio Astronomy software can be used to 
> measure the 
> Noise Figure of amplifiers.   We’ve been working on documentation of the 
> process
> for home radio astronomers.   The Noise figure (in dB) directly translates 
> into
> a measure of the sensitivity of the radio telescopes, which should have an
> effective “receiver temperature” of less than 300 Kelvin for good performance.
> The measurement process and amplifier results are documented.
> 
> The LightWork Memo 28 is just released as a Google Doc:
> https://drive.google.com/file/d/1Wgt05-DE5Kyz07wGalyl3w_PbZrketwF/view?usp=sharing
> 
> All the LightWork memos will be available in this shared directory:
> https://drive.google.com/drive/folders/1SJJTUQ5Q6DLDuiqoSHR5YVY_0TDXaNIH?usp=sharing
> 
> I’m in the process of transferring the other memos over.
> 
> The code is easy to use if you have Gnuradio 3.7, as it has been run on many 
> many
> different computers.   The whole OS is available as an image for Raspberry PI 
> 4 computers.
> See the memo for links.  Several high schools use this code.
> 
> We’re still struggling with 3.8 and 3.9.  Eventually we may get this to work…
> 
> Cheers!
> 
> Glen
> 
> 
> > On Jan 5, 2021, at 1:52 PM, Andrej Rode  wrote:
> > 
> > Hi all, 
> > 
> > to jump in from a point of someone who has contributed "improvements"
> > over the last couple of years.
> > 
> > Many of your points are vaild, I understand your frustation and pain of
> > continuouly having to adapt to new methodologies. 
> > Believe me when I say we are not these changes are not implemented just
> > for the fun of it. All of the changes you mentioned were mostly forced
> > with a gun on our chest to either implement a change or to simply not
> > have a usable GNU Radio for new Linux Operating System Releases. 
> > 
> > One of the reasons is that most of the GNU Radio development is
> > done by volunteers in their free time. Changes to GNU Radio reflecting
> > changes in dependencies which would have been useful to implement long
> > before said dependency is obsolete have been implemented in the last
> > possible momont, e.g Qt4,Python3. This lead to partially
> > untested/unmature code being pushed into a release. For at least Debian
> > and Gentoo GNU Radio has been the last package either on Qt4 or on
> > Python2 and patches have been backported to GNU Radio 3.7 by the OS
> > maintainers (Thanks!) to keep it in the operating system.
> > 
> > It's also quite hard to demand 100% backwards compatibility for
> > breaking changes and tools which provide full coverage for conversion
> > between breaking changes. I know the Python tools and I love them. But
> > development of these follow the Pareto principle. 80% of the tool is
> > written in 20% of the time. 80% or similar is what we are able to
> > provide and what gr_modtool provides in terms of conversion. For simple
> > cases conversion just works, but for complex setups you have to add
> > some additional changes by hand. 
> > 
> > TLDR: these changes are partly forced on GNU Radio by having a list of
> > dependencies. Core developers are doing their best to give users the
> > ability to convert between versions, but it's lacking and any help is
> > appreciated.
> > 
> > Cheers
> > Andrej
> > 
> 
> 

Documenting GNURadio Use.

[Glen Langston]

Dear Gnuradio folks,

Again, I hope the email finds you all well and successful.

This email notes that Gnuradio Radio Astronomy software can be used to measure 
the 
Noise Figure of amplifiers.   We’ve been working on documentation of the process
for home radio astronomers.   The Noise figure (in dB) directly translates into
a measure of the sensitivity of the radio telescopes, which should have an
effective “receiver temperature” of less than 300 Kelvin for good performance.
The measurement process and amplifier results are documented.

The LightWork Memo 28 is just released as a Google Doc:
https://drive.google.com/file/d/1Wgt05-DE5Kyz07wGalyl3w_PbZrketwF/view?usp=sharing

All the LightWork memos will be available in this shared directory:
https://drive.google.com/drive/folders/1SJJTUQ5Q6DLDuiqoSHR5YVY_0TDXaNIH?usp=sharing

I’m in the process of transferring the other memos over.

The code is easy to use if you have Gnuradio 3.7, as it has been run on many 
many
different computers.   The whole OS is available as an image for Raspberry PI 4 
computers.
See the memo for links.  Several high schools use this code.

We’re still struggling with 3.8 and 3.9.  Eventually we may get this to work…

Cheers!

Glen


> On Jan 5, 2021, at 1:52 PM, Andrej Rode  wrote:
> 
> Hi all, 
> 
> to jump in from a point of someone who has contributed "improvements"
> over the last couple of years.
> 
> Many of your points are vaild, I understand your frustation and pain of
> continuouly having to adapt to new methodologies. 
> Believe me when I say we are not these changes are not implemented just
> for the fun of it. All of the changes you mentioned were mostly forced
> with a gun on our chest to either implement a change or to simply not
> have a usable GNU Radio for new Linux Operating System Releases. 
> 
> One of the reasons is that most of the GNU Radio development is
> done by volunteers in their free time. Changes to GNU Radio reflecting
> changes in dependencies which would have been useful to implement long
> before said dependency is obsolete have been implemented in the last
> possible momont, e.g Qt4,Python3. This lead to partially
> untested/unmature code being pushed into a release. For at least Debian
> and Gentoo GNU Radio has been the last package either on Qt4 or on
> Python2 and patches have been backported to GNU Radio 3.7 by the OS
> maintainers (Thanks!) to keep it in the operating system.
> 
> It's also quite hard to demand 100% backwards compatibility for
> breaking changes and tools which provide full coverage for conversion
> between breaking changes. I know the Python tools and I love them. But
> development of these follow the Pareto principle. 80% of the tool is
> written in 20% of the time. 80% or similar is what we are able to
> provide and what gr_modtool provides in terms of conversion. For simple
> cases conversion just works, but for complex setups you have to add
> some additional changes by hand. 
> 
> TLDR: these changes are partly forced on GNU Radio by having a list of
> dependencies. Core developers are doing their best to give users the
> ability to convert between versions, but it's lacking and any help is
> appreciated.
> 
> Cheers
> Andrej
> 

Re: Stop making unneeded improvements

[Glen Langston]

Dear Johannes and all members of the GNURadio community,

Happy New Year.  I hope all are doing well.

Thanks for all your efforts!

Concerning my previous email, sent in extreme frustration.   I understand
that we all want to make improvements and progress.  

Concerning your points below.   I understand that python2 is being replaced by 
python3.
I’ve gotten over that, mostly thanks to simply using the tool:

2to3

Which is fantastic, and should be a model for us all.

My particular goal is to get my code/blocks documented before they are broken 
again by “improvements”.
I know that the group is focused on making GNURadio enhancements to 
capabilities.
However this is killing the “users” of GNURadio, who barely have the capability 
of writing
C++ modules and python code.  Once I got these working I was really, really 
hoping I could
go on to make discoveries in the universe, and not have to scratch my head over 
“improvements”.

So, you’re right about your points 1 and 2 (below).

From my point of view you’re wrong about 3.  Unless there is the equivalent of 

swig2pybind

Please don’t make this change until swig2pybind is written.

I’m neutral about point 4.  I’m not sure exactly which modules your are 
referring to.
It was frustrating to go from WX to QT, but that is done.  
There was not a 1-to-1 match of functions from WX to QT, when installed.
The new functions are great, but not having matching replacements to existing 
functions 
is a challenge to the feeble minded.

Again, thanks for all your great efforts.   Just remember that “established"
users are challenged by improvements and may have completely different 
priorities 
than developers.

Best regards

Glen

> On Jan 5, 2021, at 9:24 AM, Johannes Demel  wrote:
> 
> Hi Glen,
> 
> I fully understand your frustration to make things work long term and 
> constant breakage.
> 
> There are, however, reasons why breaking changes are unavoidable. Some 
> examples are:
> 1. GRC used Cheetah with XML for block definitions BUT:
> Cheetah got unmaintained for years. Cheetah is only available for Python2. 
> Python2 support ran out. Instead of relying on an unmaintained project, GRC 
> switched to Mako which uses YAML instead.
> 
> 2. With Ubuntu 20.04, it would probably be impossible to do a "simple" 
> install of GR 3.7 because it requires Python2 and 20.04 basically dumped 
> Python2 in favor of Python3. Thus, it was important to move to a newer Python 
> version. You might be able to install 3.7 on that system BUT you might very 
> well break it for other applications.
> Ubuntu 20.04 is actually a very good reason to move to a newer GR version 
> because it cuts off a lot of dependencies GR 3.7 has. e.g. Python2, Qt4, etc. 
> That also exemplifies why GNU Radio must evolve because the ecosystem around 
> it evolves as well.
> 
> 3. There has been a lot of discussion if and how SWIG might be replaced by a 
> different system. SWIG seemed like a good solution when it was introduced. 
> But it turned out to be extremely frustrating whenever there are problems to 
> fix.
> 
> 4. Deprecating blocks seems like an annoying thing to do as well. 
> Unfortunately, sometimes things that seemed like a good idea turn out to be a 
> dead end. In this case, we all like a better alternative and some time to 
> move in case we must.
> 
> I know that a lot of package maintainers do a fantastic job to make GR 
> available for their respective systems. I hope that helps to get the 
> installation process going.
> I'd like to refer to Geof Nieboers recent email where he explains all the 
> difficulties that come up with old software.
> 
> Of course, developers tend to be eager to adopt new technology and learn how 
> to use it. Just like Radio astronomers want to discover and learn about new 
> signals.
> Personally, I think Marcus is doing a fantastic job and balancing things 
> between long term usability and progressive changes.
> Also, you'd be very welcome to join discussions about the future of GNU Radio 
> and make sure it is as good as possible for you too.
> 
> Cheers
> Johannes
> 
> On 23.12.20 02:21, Glen Langston wrote:
>> Hello GNuradio Superheros,
>> I have to say, after 5 years with gnu radio, I’m either tool old or
>> something has to change.
>> I’ve been trying to produce some tools for High School teacher to do radio 
>> astronomy.
>> and for that gnuradio 3.7 was perfectly fine.  However some people are 
>> continuing
>> to make “improvements” that break everything.   I used to really like 
>> gnuradio.
>> I like the SDRPlay device, but it can not be used in gnuradio 3.8.  
>> According to the web.
>> But the web indicates it might be usable in 3.9
>> So I installed 3.9 only to find that swig h

Stop making unneeded improvements

[Glen Langston]

Hello GNuradio Superheros,

I have to say, after 5 years with gnu radio, I’m either tool old or
something has to change.

I’ve been trying to produce some tools for High School teacher to do radio 
astronomy.
and for that gnuradio 3.7 was perfectly fine.  However some people are 
continuing
to make “improvements” that break everything.   I used to really like gnuradio.

I like the SDRPlay device, but it can not be used in gnuradio 3.8.  According 
to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind.  This 
breaks all my
existing C++ modules.   The modules worked fine, but if using ubuntu 20.40 the 
students can not
easily install gnuradio 3.7.  The pybind instructions are puzzling.  gr-modtool 
all the
modules copy something or other.   This is for no good reason that I’m aware of.
Either make the equivalent of pythons “2to3” or do not make the gnuradio 
fundamental changes.

Stop making useless changes that break all code!

We do NOT need these changes.  The advice on the web, after I’ve spent 2 days 
building 3.9
on a Raspberry pi is use 3.8.  This is frustrating.

The documentation is falling apart because of all these variants.

It is good to make changes that ADD tool capabilities.  It is NOT good to make 
changes that
make small improvements and break such large fractions of the code.

Sorry for the Rant.

Best regards Glen






> On Dec 22, 2020, at 3:43 PM, Adam Gorski  wrote:
> 
> Marcus, 
> 
> Thank you for the detailed response! This enriches my understanding of the 
> demod process as well as the knobs involved; looks like I'll have to go back 
> to the drawing board to implement something similar using non-deprecated 
> blocks.
> 
> Thanks,
> 
> Adam Gorski
> Virginia Tech Applied Research Corporation (VT-ARC)
> Lead Communications Engineer
> 410-818-3188
> 
> -Original Message-
> From: Discuss-gnuradio 
>  On Behalf Of Marcus 
> Müller
> Sent: Tuesday, December 22, 2020 8:11 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Setting DPSK Demod Block Parameters
> 
> Hi Adam,
> 
> I'm very sorry, you **really** really shouldn't be using that block (and 
> that's the reason it's deprecated): it has bugs that just lose data. So, it's 
> not really all that useful if I spend time reading old GNU Radio's source 
> code to figure out what /exactly/ you want: You'll have to use a different 
> block, sorry. Can't offer you to fix that block, we've tried and decided 
> against it.
> 
> Since you'll need to know the answers to these even if you implement this 
> differently, let me quickly answer in-text:
> 
> On 22/12/2020 02.13, Adam Gorski wrote:
>>  * Excess bandwidth: I've read that in general the more excess
>>bandwidth supplied the better you can expect your synchronization
>>algorithm to perform. This is [0,1], and when I set it to 1 it's
>>noise resilience appreciably increases.
> 
> That's the parameter of the pulse shaping; it defines the roll-off factor of 
> the RRC:
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
> 
>>  * FLL Bandwidth (assuming this is the same as filter lock-in
>>bandwidth): This and the two subsequent values default to 6.28/100.
>>I believe the higher this bandwidth is the faster the phase locked
>>loop can adjust the output of the frequency. This leads me to
>>believe I want this as high as possible, however I don't know where
>>6.28 and 100 come from.
> 
> As in any control loop: When making the feedback loop's bandwidth large you 
> gain speed, but you lose stability and resilience against noise.
> In this case, that means your frequency correction will jump around. 
> You'll really want to keep this small.
> 
> 6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth 
> of 1/100. This is a large value for a "locked in" loop!
> 
>>  * Phase Loop Bandwidth: I know that lower values lead to reduced
>>levels of phase noise and refence spurs at the expense of longer
>>lock times and less phase margin. 
> 
> Exactly!
> 
>>I'm assuming I want the least
>>phase noise possible, however I don't know where 6.28 and 100 come from.
> 
> See above.
> 
>>  * Timing Bandwidth: A dsp exchange question mentions that optimum loop
>>bandwidth is usually somewhere between R/100 and R/20, where R is
>>the symbol clock rate being recovered. My symbol rate is 2 due to it
>>being BPSK,
> 
> hm, not sure what symbol rate and constellation would have to do with another 
> - symbol rate is the number of symbols you send per second.
> 
>>is this th

Re: GNU Radio on Raspberry Pi 4?

[Glen Langston]

Dear Franco,

Thanks for your efforts,  I’ll try your version ASAP.

Best regards

Glen


> On Dec 17, 2020, at 8:33 PM, Franco VENTURI  wrote:
> 
> Glen,
> if you are interested in using SDRplay API version 3.X (I think the latest 
> version of their API is 3.07), and you are on GNU Radio 3.7, you may want to 
> take a look at the gr-sdrplay GNU Radio OOT module I modified to work with 
> SDRplay API version 3.X: 
> https://github.com/fventuri/gr-sdrplay/tree/API3+RSPduo (notice the 
> non-default branch name: 'API3+RSPduo').
> 
> If instead you are on GNU Radio 3.9/master, I rewrote that OOT module from 
> scratch, called it 'gr-sdrplay3', and you'll find it here: 
> https://github.com/fventuri/gr-sdrplay3
> 
> Let me know if you have problems building or running those modules (possibly 
> by creating a new issue in GitHub to avoid hijacking this thread).
> 
> Franco
> 
> 
>> On 12/17/2020 1:34 PM Glen Langston  wrote:
>> 
>> 
>> Concerning Full Raspberry Pi OS software installed on a single Raspberry Pi 
>> image,
>> we’re encouraging high schools to use this installation document.
>> https://docs.google.com/document/d/1hfS7cRx3emlZz0sTs583zN8o-35nKtIej6BYMKCJLXY/edit?usp=sharing
>> 
>> The document includes the links to the OS and hardware to purchase.
>> 
>> Unfortunately this is a 3.7.13.4 Gnuradio release, as we’ve not had the 
>> strength
>> to get the SDRPlay software support working for newer gnuradio Releases.
>> 
>> Best regards, 
>> 
>> Glen
>> 
>>> On Dec 17, 2020, at 12:03 PM, Kyeong Su Shin  wrote:
>>> 
>>> To whom it may concern:
>>> 
>>> Just a tip: If you are building GNU Radio from the source, dependencies and 
>>> build procedures for Raspberry Pi is available at the GNU Radio Wiki. It 
>>> assumes that you are doing on-board compile.
>>> 
>>> See: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
>>> 
>>> 
>>> Regards,
>>> Kyeong Su Shin
>>> 보낸 사람: Albin Stigö  대신 Discuss-gnuradio 
>>> 
>>> 보낸 날짜: 2020년 12월 18일 금요일 오전 1:13
>>> 받는 사람: Kristoff ; GNURadio Discussion List 
>>> 
>>> 제목: Re: GNU Radio on Raspberry Pi 4?
>>> 
>>> There's no special configuration. Just install dependencies and build from 
>>> source. Put root on SSD or it will be very slow. Ubuntu 65bit is fine. In 
>>> general GNURadio is hell to build and get dependencies right, but in the 
>>> end it works well.
>>> 
>>> --Albin
>>> 
>>> On Thu, Dec 17, 2020, 16:37 Kristoff  wrote:
>>> Albin,
>>> 
>>> 
>>> Can you share your configuration for this? Do you need to set up 
>>> something special?
>>> Can you do this on standard ubuntu 64 bit (20.04LTS or 20.10) on a pi4b 
>>> or do you need another distro for this?
>>> 
>>> 
>>> I read somewhere opengl on the pi4 has not been released yes as it has 
>>> the pi4 has a more recent GPU.
>>> Or am I completely wrong?
>>> 
>>> 
>>> 73
>>> kristoff - ON1ARF
>>> 
>>> 
>>> On 17/12/2020 1:22 p.m., Albin Stigö wrote:
>>>> I suspect a lot of the graphics could run perfectly fine if they took 
>>>> advantage of the gpu better. A lot of the current rendering in 
>>>> GNURadio (and GQRX) is very cpu bound.
>>>> 
>>>> I had a spectrum and waterfall running easily at 60fps on a pi3 by 
>>>> using opengl properly. Using vulkan on pi4 the sky is the limit.
>>>> 
>>>> --Albin
>>>> 
>>>> On Thu, Dec 17, 2020, 13:18 Marcus Müller >>> <mailto:muel...@kit.edu>> wrote:
>>>> 
>>>>Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
>>>>like running Windows 98 on a modern PC and expecting top performance
>>>>from the CPU. You're not making use of the CPU you have, you're only
>>>>making use of a legacy mode that it still supports.
>>>> 
>>>>Best regards,
>>>>Marcus
>>>> 
>>>>On 17.12.20 10:53, Albin Stigö wrote:
>>>>> 64bit mode is most likely better because in addition to being
>>>>64bit it
>>>>> enables additional cpu features (certain new instructions and
>>>>more SIMD
>>>>> NEON registers)
>>>>> 
>>>>> On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-

Re: GNU Radio on Raspberry Pi 4?

[Glen Langston]

Concerning Full Raspberry Pi OS software installed on a single Raspberry Pi 
image,
we’re encouraging high schools to use this installation document.
https://docs.google.com/document/d/1hfS7cRx3emlZz0sTs583zN8o-35nKtIej6BYMKCJLXY/edit?usp=sharing

The document includes the links to the OS and hardware to purchase.

Unfortunately this is a 3.7.13.4 Gnuradio release, as we’ve not had the strength
to get the SDRPlay software support working for newer gnuradio Releases.

Best regards, 

Glen

> On Dec 17, 2020, at 12:03 PM, Kyeong Su Shin  wrote:
> 
> To whom it may concern:
> 
> Just a tip: If you are building GNU Radio from the source, dependencies and 
> build procedures for Raspberry Pi is available at the GNU Radio Wiki. It 
> assumes that you are doing on-board compile.
> 
> See: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
> 
> 
> Regards,
> Kyeong Su Shin
> 보낸 사람: Albin Stigö  대신 Discuss-gnuradio 
> 
> 보낸 날짜: 2020년 12월 18일 금요일 오전 1:13
> 받는 사람: Kristoff ; GNURadio Discussion List 
> 
> 제목: Re: GNU Radio on Raspberry Pi 4?
>  
> There's no special configuration. Just install dependencies and build from 
> source. Put root on SSD or it will be very slow. Ubuntu 65bit is fine. In 
> general GNURadio is hell to build and get dependencies right, but in the end 
> it works well.
> 
> --Albin
> 
> On Thu, Dec 17, 2020, 16:37 Kristoff  wrote:
> Albin,
> 
> 
> Can you share your configuration for this? Do you need to set up 
> something special?
> Can you do this on standard ubuntu 64 bit (20.04LTS or 20.10) on a pi4b 
> or do you need another distro for this?
> 
> 
> I read somewhere opengl on the pi4 has not been released yes as it has 
> the pi4 has a more recent GPU.
> Or am I completely wrong?
> 
> 
> 73
> kristoff - ON1ARF
> 
> 
> On 17/12/2020 1:22 p.m., Albin Stigö wrote:
> > I suspect a lot of the graphics could run perfectly fine if they took 
> > advantage of the gpu better. A lot of the current rendering in 
> > GNURadio (and GQRX) is very cpu bound.
> >
> > I had a spectrum and waterfall running easily at 60fps on a pi3 by 
> > using opengl properly. Using vulkan on pi4 the sky is the limit.
> >
> > --Albin
> >
> > On Thu, Dec 17, 2020, 13:18 Marcus Müller  > > wrote:
> >
> > Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
> > like running Windows 98 on a modern PC and expecting top performance
> > from the CPU. You're not making use of the CPU you have, you're only
> > making use of a legacy mode that it still supports.
> >
> > Best regards,
> > Marcus
> >
> > On 17.12.20 10:53, Albin Stigö wrote:
> > > 64bit mode is most likely better because in addition to being
> > 64bit it
> > > enables additional cpu features (certain new instructions and
> > more SIMD
> > > NEON registers)
> > >
> > > On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr
> > 
> > >  > >
> >  > 
> > >  > >> wrote:
> > >
> > > The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> > > https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
> > > 
> > > last page. I get 3 to 7-fold improvement by volk_config on a
> > dedicated
> > > toolchain for 64-bit CPU.
> > >
> > > JM
> > >
> > > --
> > > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe,
> > 25000
> > > Besancon, France
> > >
> > > December 17, 2020 10:28 AM, "Kristoff"  > 
> > > >> wrote:
> > >
> > > > HI all,
> > > >
> > > > I also have a RPi4 (*).
> > > > Some follow-up question.
> > > >
> > > > What OS would be the best for this?
> > > > Would running 64 bit make a difference?
> > > >
> > > > I don't know to what degree this is related, but I did a
> > test running
> > > > WebGL (**) on that pi, and I got about 1/3 of the frames per
> > > second on
> > > > my RPi4 compared to my laptop (which only has a UHD
> > Graphics 630
> > > Mobile,
> > > > so not the  best or latest neither)
> > > > Is the GPU in the Pi4 good enough to run many GUI elements
> > in GNU
> > > Radio
> > > > at the same time?
> > > >
> > > > Kr.
> > > >
> > > > (*) RPi4B 8 GB, 120 SSD
> > > >
> > > > (*) https://webglsamples.org 
> > > >
> > > > On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
> > > 

Re: gnuradio (+ friends) packages for conda on Linux, macOS, and Windows

[Glen Langston]

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  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 
> 
> where  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
> 

Re: Project call today

[Glen Langston]

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  wrote:
> 
> Hi bestest SDR community,
> 
> Heads up: the July project all is happening in 30 minutes.
> 
> Cheers,
> Marcus
> 

Re: Figures from Dave

[Glen Langston]

Hi Dave,

The shape of your spectrum of the Milky Way, (this one) 
Looks correct.  The two peaks near 1420.5 Hz are  two different arms of the 
Milky Way,
so you’re already seeing structure of our Galaxy!   Since we, and these spiral 
arms
are in a disk, we’re seeing one behind the other in intensity, but because they
are moving at different speeds they are separated in frequency.

All the many regularly spaced peaks are interference.   There are 9 in 0.5 MHz 
so roughly
one every 0.05 MHz.This could be due to a single very strong interfering 
signal
out of band.  This could be due to power lines.  Try to move away from power 
lines and
they might go away.

Also using a Software defined radio (SDR) with more bits of sampling (like the 
AIRSPY mini)
can also partially reduce bad sampling, and clean up the signals.

Glen






> On Jul 7, 2020, at 4:09 PM, David Schultz  wrote:
> 
> Hi Glen,
> 
> Let's see if this works for the figures. 3 attached.
> 
> Dave
> 

Re: Making C++ OOT module and wish to set up a parameter with different choices!

[Glen Langston]

Very nice document.
Thanks
Glen


> On Jun 30, 2020, at 1:17 PM, jean-michel.fri...@femto-st.fr wrote:
> 
> I do not claim to cover all aspect of OOT blocks but I tried to document the 
> basics of 
> passing parameters and public/private variables at 
> http://jmfriedt.free.fr/gr_oscilloscope_eng.pdf
> 
> Unfortunately this document only covers GNU Radio 3.7: while the French 
> version was extended to
> GNU Radio 3.8, the English version was not extended accordingly but I'd be 
> happy to do so if there
> is any interest.
> 
> JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 
> June 30, 2020 7:06 PM, "George Edwards"  wrote:
> 
>> Hello,
>> 
>> I am making a C++ OOT module and wish to have an input parameter 
>> "frame_length" with different
>> choices. I would like to provide short, medium and long frames with a value 
>> attached to each. Based
>> on the OOT syntax, I can enter "frame_length" as an input argument to the 
>> model. Now, how can I set
>> up the inners of the *.cc file so that when the module is built into a 
>> Gnuradio block, I can simply
>> click on 'frame_length' to see the choices and select one?
>> 
>> Thanks for the help.
>> 
>> Regards,
>> George
> 

Re: Where in OOT C++ code to write a boolean variable that is set at startup

[Glen Langston]

Hi George,

This kind of parameter goes in the .h file that defines the classes.

in our event detection software we have a similar issue (If I understand you 
correctly).
in our detect_impl.h

namespace gr {
  namespace radio_astro {

class detect_impl : public detect
{
 private:
  // values computed in this block
...
 bool initialized = 0;   // flag initializing output
…

Then somewhere in the code (detect_impl.cc)

...skipping...
  if (! initialized) {
for (int iii = 0; iii <  d_vec_length; iii++)
  { samples[iii] = input[iii];
  }
initialized = 1; // no need to re-initialize the event
  }

Best regards,

Glen


> On Jun 30, 2020, at 12:35 PM, George Edwards  wrote:
> 
> Hello,
> 
> I am writing my Gnuradio OOT in C++ and wish to add a boolean variable that 
> at startup is set to "true". Then, in Gnuradio "work" method, this variable 
> is tested and if true will cause an initialization method to run and 
> initialize parameters for the signal processing. The initialization method 
> would in turn set this variable to "false" so that Gnuradio "work method" can 
> only call it once (the first time the work method is entered". Which of the 
> methods in the OOT *.cc file do I put this variable in so that it is in scope 
> in the work method and the initialization method?
> 
> Thanks,
> George

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Glen Langston]

Thanks for your explanation.

ssh-ing in as root did work fine.

I find that the rtl_ programs do work, like rtl_fm.

I also understand your approach to embedded real-time applications.

This probably works particularly well for the PlutoSDR.   

My goal is for student use, where they are particularly graphical
user interface aware.

Best regards

Glen


> On May 29, 2020, at 1:57 AM, jean-michel.fri...@femto-st.fr wrote:
> 
> It is indeed my belief that there is no point in running a graphical user
> interface on an embedded system, much less a windowing system. If an embedded
> board is supposed to interact with a user, a Qt5 or SDL dedicated interface
> will be much lighter and efficient than a X-Window server and a window manager
> client.
> 
> This is the reason for providing the examples at the end of the tutorial
> where a Non GUI flowgraph is generated, the resulting Python script sent to 
> the embedded board and running there, possibly streaming the output (in my
> example 0-MQ) to a client. In the case of gr-acars, I just fetch periodically
> the log-file from the RPi4 to the host computer for analysis.
> 
> Nevertheless if you want to go in the windowing system direction, Buildroot
> seems to provide Xorg support: 
> 
> make menuconfig
> Target packages -> Graphic libraries and applications -> X.org X Window System
> 
> I have never used nor tested, so I have no idea how much space/how long it 
> takes
> to compile.
> 
> There is no binary package management system with buildroot: the whole point, 
> which
> makes is different from OpenEmbedded/Yocto, is to generate a custom minimal
> image with only the needed tools and not compile all possible binary packages
> (the disk size difference being about 10-fold, with about 8 GB needed for
> buildroot when my attempt at completing the OpenEmbedded system ended at about
> 80 GB and many unnecessary binary packages).
> 
> The default network configuration is to fetch the IP address from a DHCP 
> server.
> Otherwise add an etc/network/interfaces entry in the output/target directory
> of buildroot with the static IP configuration, and
> make
> to re-generate sdcard.img including this configuration file. Similarly if the
> usr/share/uhd/images binary files are needed: copy in output/target and make.
> 
> JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 
> May 29, 2020 3:33 AM, "Glen Langston"  wrote:
> 
>> Hi
>> 
>> Thanks for your help.
>> 
>> I’ve written the image to an SDCARD and the PI4 boots to
>> the command line prompt. The password is accepted and
>> I’ve looked around.
>> 
>> Gnuradio seems to be installed, but not the xwindow system.
>> 
>> How do you use gnuradio-companion etc?
>> 
>> I could not find “xstartup” or some such program.
>> 
>> Thanks
>> 
>> Glen
>> 
>>> On May 24, 2020, at 3:59 PM, jean-michel.fri...@femto-st.fr wrote:
>>> 
>>> I have uploaded http://jmfriedt.org/sdcard.img
>>> my Buildroot image generated for RPi4 that I have been
>>> using daily for the last 2 months, so pretty sure it is
>>> working. Actually it is 1.1 GB because of lapack needed
>>> for gnss-sdr but GNU Radio 3.8/Python3 will only require
>>> about 500 MB.
>>> Gwenhael Goavec-Merou ported all GNU Radio related software/libraries
>>> to Buildroot: the missing parts for gnss-sdr are found at
>>> https://github.com/oscimp/PlutoSDR in the for_next branch.
>>> 
>>> root passwd=root, no user account, USRP FPGA images to be added
>>> in usr/share/uhd/images manually if libuhd is needed. Tested with
>>> RTL-SDR DVB-T dongle, PlutoSDR (gr-iio) and B210.
>>> 
>>> JM
>>> 
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 25000 Besancon, France
>>> 
>>> May 24, 2020 9:51 PM, "Glen I Langston"  wrote:
>>> 
>>>> Hello
>>>> 
>>>> I’ve been a great proponent of gnuradio, but I’m finding in
>>>> increasing difficult to do anything new, as installation of 3.8 is
>>>> essentially impossible for most people.
>>>> 
>>>> I’ve written and built my own python modules and C++ blocks.
>>>> 
>>>> However, despite months of trying now, I can not get 3.8 to install
>>>> on a raspberry pi.
>>>> 
>>>> Has anyone achieved 3.8 on a raspberry pi?
>>>> 
>>>> If so can you please save the entire OS, gzip compressed and put it
>>>> online somewhere. It will probably be about 3 GB compressed.
>>>> 
>>>> Thanks
>>>> 
>>>> Glen
>>>> 
>>>> Note that there are many many (too many) different guides on line
>>>> 
>>>> 1) apt-get
>>>> 
>>>> 2) pybombs
>>>> 
>>>> 3) git clone then build
>>>> 
>>>> each one fails in a different way.

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Glen Langston]

Hi

Thanks for your help.

I’ve written the image to an SDCARD and the PI4 boots to
the command line prompt.  The password is accepted and
I’ve looked around.

Gnuradio seems to be installed, but not the xwindow system.

How do you use gnuradio-companion etc?

I could not find “xstartup” or some such program.

Thanks

Glen

> On May 24, 2020, at 3:59 PM, jean-michel.fri...@femto-st.fr wrote:
> 
> I have uploaded http://jmfriedt.org/sdcard.img
> my Buildroot image generated for RPi4 that I have been
> using daily for the last 2 months, so pretty sure it is
> working. Actually it is 1.1 GB because of lapack needed
> for gnss-sdr but GNU Radio 3.8/Python3 will only require
> about 500 MB.
> Gwenhael Goavec-Merou ported all GNU Radio related software/libraries
> to Buildroot: the missing parts for gnss-sdr are found at
> https://github.com/oscimp/PlutoSDR in the for_next branch.
> 
> root passwd=root, no user account, USRP FPGA images to be added
> in usr/share/uhd/images manually if libuhd is needed. Tested with
> RTL-SDR DVB-T dongle, PlutoSDR (gr-iio) and B210.
> 
> JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 
> May 24, 2020 9:51 PM, "Glen I Langston"  wrote:
> 
>> Hello
>> 
>> I’ve been a great proponent of gnuradio, but I’m finding in
>> increasing difficult to do anything new, as installation of 3.8 is
>> essentially impossible for most people.
>> 
>> I’ve written and built my own python modules and C++ blocks.
>> 
>> However, despite months of trying now, I can not get 3.8 to install
>> on a raspberry pi. 
>> 
>> Has anyone achieved 3.8 on a raspberry pi?
>> 
>> If so can you please save the entire OS, gzip compressed and put it
>> online somewhere. It will probably be about 3 GB compressed.
>> 
>> Thanks
>> 
>> Glen
>> 
>> Note that there are many many (too many) different guides on line
>> 
>> 1) apt-get
>> 
>> 2) pybombs 
>> 
>> 3) git clone then build
>> 
>> each one fails in a different way.

Re: XML Client Issue - Gnuradio 3.8

[Glen Langston]

Hi 

I’m guessing that you can not use multiple ‘ in the string;
Use double quotes for the ends

> On Apr 21, 2020, at 1:04 PM, Vitt Benv  wrote:
> 
> Good evening,
> 
> I'm experiencing this error while using a XMLRPC Client block:
> 
> #
> Executing: /usr/bin/python3 -u /home/vic/remote-trx/local_6.py
> 
>   File "/home/vic/remote-trx/local_6.py", line 192
> self.xmlrpc_client_0 = xmlrpclib.Server('http://'192.168.1.80':12100’)
ie:
self.xmlrpc_client_0 = xmlrpclib.Server("http://'192.168.1.80':12100 
”)
or
self.xmlrpc_client_0 = xmlrpclib.Server("http://192.168.1.80:12100 
”)

Good Luck,

Glen


>^
> SyntaxError: invalid syntax
> #
> 
> I'm on version 3.8, and I suppose that this issue it's related to this 
> Gnuradio version; in version 3.7 all runs fine (the counterpart of this 
> flowgraph sits on a Gnuradio 3.7 and there isnt any problem)
> 
> Any suggestion / workaround ???
> 
> Thanks in advance,
> 
> Vittorio I3VFJ

Re: Pi GNURadion challenge.

[Glen Langston]

Hi

Yes. 3.8.1 is the version I’d started to install.   I ran into trouble
downloading all the support packages.  Slowly but surely I was
installing everything needed.  But after a few hours of good progress
I ran out of time.So I thought I’d just ask if someone more talented
had already done the install before I put more time into the install.

Definitely, for me, a complete install of the OS is the best, rather than
on a package by package basis.   Remember to compress (and remove all gmail
etc logins) before distributing.

It is fairly quick to do the whole install to the SD card, from the 
compressed .img file.   With “Etcher” they uncompress and write simultaneously,
so you are only working with a couple gigabyte file.   

I have 4 working horn radio telescopes working this way and a few more almost
ready to start observing.  I thought I would get up to date with the
3.8.? Gnuradio then restart observations.

Maybe I have to wait.

Thanks in advance.

Glen

> On Mar 9, 2020, at 1:05 PM, Chris Vine  wrote:
> 
> On Mon, 9 Mar 2020 10:59:04 -0400
> Glen Langston  wrote:
>> Hi
>> 
>> Thanks for your summary of experience with installing Gnuradio 3.8.1 for 
>> Raspberry Pi.
>> 
>> I’ve started the install on a fresh version on the latest Raspberry Pi OS,
>> but ran into a few issues I’m still working on.
>> 
>> One question/request for this group:
>> 
>> The folks at SDRPlay have done a very nice job of porting a good working 
>> version of
>> gnuradio into a working image of the Raspberry OS and compressed it.
>> (https://www.sdrplay.com/downloads/)
>> 
>> After downloading (about 2GB) and writing to the SD card, this version just 
>> works fine.
>> The simple-minded user can then just start enjoying Gnuradio.
>> 
>> However they don’t yet have Gnuradio 3.8.1 on the SD card.
> 
> As far as I can tell there is no gnuradio-3.8.1.  Where did you find it?
> I can see a first release candidate as of some weeks ago, which of
> course is something different.
> 

Re: Pi GNURadion challenge.

[Glen Langston]

Hi

Thanks for your summary of experience with installing Gnuradio 3.8.1 for 
Raspberry Pi.

I’ve started the install on a fresh version on the latest Raspberry Pi OS,
but ran into a few issues I’m still working on.

One question/request for this group:

The folks at SDRPlay have done a very nice job of porting a good working 
version of
gnuradio into a working image of the Raspberry OS and compressed it.
(https://www.sdrplay.com/downloads/)

After downloading (about 2GB) and writing to the SD card, this version just 
works fine.
The simple-minded user can then just start enjoying Gnuradio.

However they don’t yet have Gnuradio 3.8.1 on the SD card.

Question/Request:

If anyone gets 3.8.1 working for Raspberry pi, please remove all personal info
and then compress whole OS on SD card to a ???.img.xz file and distribute it 
for download.

Thanks!

Glen

PS I’ve shared the Raspberry pi OS for our radio astronomy code, but this for 
3.7
Now I’d recommend starting with the SDRPlay OS, as it is more up to date.

PS I’ve had to download/install some code for other SDR devices, but that is 
not too hard
compared to getting gnu radio running in the first place.

Our project is converting to 3.8, but this is not yet complete.
git clone http://www.github.com/WVURAIL/gr-radio_astro
Any assistance is welcome.

> On Mar 8, 2020, at 3:24 PM, Robert Heerekop  wrote:
> 
> Dear GNURadio-friends!
> 
> Thank you so much for your replies on my previous post! It feels good to get 
> feedback and I did read every single line 4 times and did numerous 
> attempts/installations this weekend on the Pi4 and Pi3B1.2 which I have 
> available here. Yes, I'm making progress first steps-by-steps, but...
> ...the speaker is still silent...no WBFM music yet... 
> 
> Marcus M. his clarification on sw building process was very interesting. 
> Thanks for explaining this process! At this (Hello World) beginners on 
> GNURadio I prefer to use a low risk easy to install version and get my 
> RTL-SDR and ADALM-PLUTO sounding WBFM in the first place. Good to know though 
> how development&building works and I will keep an eye on Debian porting to 
> RPi4 and make use of the faster vector optimized processing. interesting to 
> have this insight. Thanks!
> Manolis S. his suggestion to use an existing build sounded also good. I 
> failed however...
> 
> The SD Cards here were over-and-over refreshed with 'latest' fresh 
> 2020-02-13-raspbian-buster images to ensure I used every time an 
> of-the-raspberry-shelf default configuration.
> 
> Summarized my failing GNURadio weekend results:
> 
> 1. The standard beginners level gnuradion Pi installation process fails with 
> the current raspberry NOOBS raspian image.I presume because due to referral 
> to the version "Pi3B+": 
> https://wiki.gnuradio.org/index.php/InstallingGRFromSource_on_Raspberry_Pi
> Unfortunately I one have Pi3B1.2, Pi4(c03112, 4Gb, 32GB-SD) and PiZero
> I figured out I also had to add the commands:
> sudo apt install gr-osmosdr (otherwise the 'blocks' to input data from the 
> USB connected SDR were missing.)
> sudo apt-get install xterm
> 
> 2. I try to get GNURadio Companion 3.8 running as a GUI because I read that 
> that was more stable. I'm happy though if I can get any version working in 
> the first place...
> The provided sugegstion to simply perform "sudo apt install gnuradio" does 
> not install 3.8 but 3.7.13.4. The good news however is that GNU Radio 
> Companion can be started from the GUI and after installing the osmocom, 
> RTL-SDR from the RPi-menu and fixing a lxterminal issue, I am able to proces 
> a WBFM receiver grc-example, but seems facing an audio sink issue resulting 
> in silence I will continue to look to search for a solution but failed so 
> far.
> 
> 3. After "sudo dpkg -i" installing the pre-build repo Manolis suggested, 
> GNURadio did not appear on the GUi so I failed here as well. I guess this is 
> because I am using not the same RPi hardware version...
> 
> 4. the only way to get some WBFM-audio working(yes!) is installing 
> Gqrx2.11.5(which is qt5.11.3 based). The Gqrx is working fine, but the 
> GNURadio which comes with it, gives interrupted audio as I recorded and show 
> here: https://youtu.be/WNpgtsG8Bls
> 
> Yes, this is struggling on rookie level.  I will continue my attemps and am 
> aware that...
> The more a Hello world GNURadio struggle takes, the better the first music in 
> the end sounds ;-)
> If you have a working 'beginers level' instruction, SD-image or build (of any 
> GNURadio) that works on Pi4/Pi3B1.2 I will reserve a place in the Radio Hall 
> of Fame!
> 
> Thanks for sharing any suggestions!
> rrrRbert
> ps. I happy to provide any logs is that helps in finding the rootcause.

Re: gnuRadio 3.8

[Glen Langston]

Thanks

Your suggestions are helpful.

My interpretation of the web page was that I was to create another
set of system variables, like PYTHONPATH etc.
 
Your suggestions did get gnuradio 3.7 working again on my MacBook Pro (late 
2013) running Mojave 10.14.6.
(Initially I thought I had 3.8 running, but I still need to update the links to 
gnuradio 3.8).

I’ll keep at installing 3.8

Thanks!

Glen

Again I do have gnuradio 3.8 working reasonable well on my Ubuntu computer, but 
none
of my programs yet running.

I’m trying to use gr_modtool to get a new gr3.8 module compiled with make,
then I’ll inch through comparisons of the old cmake format and new.

It would be convenient to have a very very simple example of 
both python and c++ programs that were already able to be built, so that
we don’t have to step through the gr-modtool example web page updated 
squareff.cc etc.



> On Feb 6, 2020, at 11:33 AM, Barry Duggan  wrote:
> 
> Glen,
> 
> If you are looking at 
> https://wiki.gnuradio.org/index.php/ModuleNotFoundError#C._Setting_PYTHONPATH 
> , you are supposed to *substitute* the {PREFIX} and {PY-VERSION} in the 
> commands you store. So my ~/.bash_aliases looks like this:
> ```
> alias dir='ls -al'
> alias hist='history'
> alias cp='cp -v'
> PS1='\w \$ '
> export 
> PYTHONPATH=/usr/local/lib/python3/dist-packages:/usr/local/lib/python3/site-packages:$PYTHONPATH
> export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
> ```
> 
> Once you have saved your edits, enter 'exit' on your terminal and then open a 
> new one.
> 
> ---
> Barry Duggan KV4FV
> 
> 
> On 2020-02-06 11:04, Glen Langston wrote:
>> Hello
>> I’m also suffering through the upgrade to Gnuradio 3.8.
>> Gnuradio did install reasonably well on Ubuntu 19.10, but of course,
>> none of my self-designed routines work.
>> I also was hoping to continue to support Mac OS and there I’ve inched
>> my way to the Module not found message.
>> The web page says to set
>> PY-VERSION=python3.7
>> But in bash shell “PY-VERSION”  is an illegal name.
>> glangsto$ export PY-VERRSION=python3.7
>> -bash: export: `PY-VERRSION=python3.7': not a valid identifier
>> How is this overcome?
>> Thanks
>> Glen
>> Also a curse of going to python3.7 is that I use a no longer
>> support library that computes astronomical coordinate transformations.
>> The “pyephem” code very well in python2.7, but there does not
>> seem to be anyone supporting an upgrade to python3.7.
>> Is there a way to use some older python2.7 code in conjunction with
>> python3.7
>>> On Feb 6, 2020, at 6:29 AM, Barry Duggan  wrote:
>>> you are almost there :)
>>> see https://wiki.gnuradio.org/index.php/ModuleNotFoundError to set your 
>>> environment variables.
>>> ---
>>> Barry Duggan KV4FV
>>> On 2020-02-06 04:25, sarandis. Doulgeris wrote:
>>>> Also i execute the next command ( sudo make install and sudo ldconfig )
>>>> and i get this error after trying to execute gnuradio-companion
>>>> "Gtk-Message: 11:21:37.890: GtkDialog mapped without a transient parent.
>>>> This is discouraged."
>>>> Also this tab pops up

Re: gnuRadio 3.8

[Glen Langston]

Hello

I’m also suffering through the upgrade to Gnuradio 3.8.

Gnuradio did install reasonably well on Ubuntu 19.10, but of course,
none of my self-designed routines work.

I also was hoping to continue to support Mac OS and there I’ve inched
my way to the Module not found message.

The web page says to set

PY-VERSION=python3.7

But in bash shell “PY-VERSION”  is an illegal name.

glangsto$ export PY-VERRSION=python3.7
-bash: export: `PY-VERRSION=python3.7': not a valid identifier

How is this overcome?

Thanks

Glen

Also a curse of going to python3.7 is that I use a no longer
support library that computes astronomical coordinate transformations.

The “pyephem” code very well in python2.7, but there does not
seem to be anyone supporting an upgrade to python3.7.

Is there a way to use some older python2.7 code in conjunction with
python3.7



> On Feb 6, 2020, at 6:29 AM, Barry Duggan  wrote:
> 
> you are almost there :)
> see https://wiki.gnuradio.org/index.php/ModuleNotFoundError to set your 
> environment variables.
> 
> ---
> Barry Duggan KV4FV
> 
> 
> On 2020-02-06 04:25, sarandis. Doulgeris wrote:
>> Also i execute the next command ( sudo make install and sudo ldconfig )
>> and i get this error after trying to execute gnuradio-companion
>> "Gtk-Message: 11:21:37.890: GtkDialog mapped without a transient parent.
>> This is discouraged."
>> Also this tab pops up
> 

Re: gnuRadio 3.8

[Glen Langston]

Hi Sarandis,

In the first version of your attempt, I’ve also seen this problem

It is caused by your laptop running out of memory during the

make -j 4

step.   It can probably be fixed by running

make

instead.   The -j 4 command causes 4 simultaneous threads to run, using up
all the memory.
 
It will take hours to “make” however.

Best regards

Glen


> On Feb 5, 2020, at 7:32 AM, sarandis. Doulgeris 
>  wrote:
> 
> Can anyone tell me how can i install gnuradio 3.8 on Ubuntu 18.0.4 LTS? I 
> have tried these two instructions but i have the same result my laptop crashes
> 1)
>   • sudo apt update
> 
>   • sudo apt upgrade
> 
>   • sudo ldconfig
> 
>   • sudo update-alternatives --install /usr/bin/python python 
> /usr/bin/python2.7 1
> 
>   • sudo update-alternatives --install /usr/bin/python python 
> /usr/bin/python3.6 2
> 
>   • sudo update-alternatives --set python /usr/bin/python3.6
>   • sudo apt install python3-pip
>   • pip3 install --upgrade setuptools
>   • pip3 install click
>   • sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig 
> python3-numpy python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev 
> libcomedi-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev 
> python3-pyqt5 liblog4cpp5-dev libzmq3-dev python3-yaml python3-click 
> python3-click-plugins python3-zmq
> 
>   • sudo ldconfig
> 
> sudo apt install python3-scipy libgsm1-dev libcodec2-dev liborc-0.4-dev 
> libgmp3-dev portaudio19-dev
>   • git clone --recursive -b maint-3.8 --single-branch 
> https://github.com/gnuradio/gnuradio.git
> 
>   • cd gnuradio/
> 
>   • mkdir build
> 
>   • cd build
> 
>   • cmake ../
> 
> make -j4 ( right here computer chashes at 87% three times straight)
>   • make test
>   • sudo make install
> 
>   • sudo ldconfig
> 
> gnuradio-companion
> 
> 
> 2)
> sudo apt-get install python-pip python-apt
> sudo -H pip install PyBOMBS
> mkdir 
> ~
> /sdr
> 
> cd ~
> /sdr
> pybombs auto-config
> pybombs recipes add gr-recipes git+
> https://github.com/gnuradio/gr-recipes.git
> 
> pybombs recipes add gr-etcetera git+
> https://github.com/gnuradio/gr-etcetera.git
> 
> pybombs prefix init 
> ~/sdr
> sed -i 's/2\.6/3.6/g'
>  setup_env.sh
> sed -i 
> 's/2\.7/3/g' setup_env.sh
> source ~
> /sdr/setup_env.sh
> pybombs install uhd
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev \
>   swig python3-numpy python3-mako python3-sphinx python3-lxml \
>   doxygen libfftw3-dev libcomedi-dev libsdl1.2-dev libgsl-dev \
>   libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev \
>   libzmq3-dev python3-yaml python3-click python3-click-plugins
> 
> pybombs install gnuradio (crashes at 87% at Buiding stage)
> 
> 
> I have no idea what i am doing. I installed gnuradio 3.7.# by 
> sudo apt-get update
> sudo apt-get install gnuradio 
> 
> I want the 3.8 version. Thanks

Re: [analogdevicesinc/libad9361-iio] LIBIIO_INCLUDEDIR error installing from source. (#51)

[Glen Langston]

Hi Travis,

I've repeatedly installed libiio and libad9361-iio , etc through gr-iio

but I never seem to get any speed up in data transfer.   The maximum data
rate that I can get without
dropping samples is 3.2 MHz.

I'm installing from source, via git clone etc.

One question, which library upgrade is the most likely to improve the pluto
SDR data transfer rate
Ie libad9361-iio ?

I'm doing all this within gnuradio 3.7.13.4  as I've still not gotten all
of 3.8 working on a raspberry pi.

Thanks
Glen


On Wed, Nov 27, 2019 at 9:25 AM Travis Collins 
wrote:

> Yes, or just use the packages from one source.
>
> -Travis
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>

Re: upgrading to 3.8 (was: Re: Stream args on UHD USRP Sink)

[Glen Langston]

Hi Marcus and all super-heros,

Day 3 of trying to get gnuradio 3.8 to work with our custom code.

I've tried following the porting guide, but seem to continue to need
to apt-get or install this that and the other thing.

3.8 does seem to be installed.  and gnuradio companion is launching.
However none of our custom code is surviving the cmake step.

I've googled and installed different cmake versions. THese seem to go
into different places and do not replace my original cmake.

So for ubuntu 19.  where should cmake be installed and which version
is currently fashionable?

Thanks all

Glen

The porting guide seems helpful , particularly for cmake, but i'm
failing in various steps of cmake.
gr-modtool does seem to be working, but naturally does not actually
produce code that compiles.
(it has macros that do not compile).   It would be better if the full
cmake step worked after gr-modtool ran (with comments) for other
variable types.  I've not yet had the strength to tweak gr-foo to get
it to cmake.  Maybe tomorrow.

On Tue, Dec 3, 2019 at 1:26 PM Müller, Marcus (CEL)  wrote:
>
> Hi Glen,
>
> On Tue, 2019-12-03 at 12:20 -0500, Glen Langston wrote:
> > Hi
> >
> > This is a general question about upgrade to python 3 and gnu radio 3.8.
> >
> > We’ve got some custom C++ and Python code that will need to be installed.
> > The python ran in version 2.7.  This is working with gnuradio companion 
> > 3.7.13.4
> >
> > How difficult a task is upgrading?  A day/week/month?
>
> Pretty much impossible to say, but if you say "some", I'd assume it's
> in the range of single-digits hours.
>
> See:
>
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
>
> Best regards,
> Marcus

Re: Stream args on UHD USRP Sink

[Glen Langston]

Hi

This is a general question about upgrade to python 3 and gnu radio 3.8.

We’ve got some custom C++ and Python code that will need to be installed.
The python ran in version 2.7.  This is working with gnuradio companion 3.7.13.4

How difficult a task is upgrading?  A day/week/month?

Thanks again for all your guidance and help,

Glen

The code is modest in size, I’d say.   Is there a way of keeping
backward compatibility to 2.7?   Should I create a whole new
archive for python 3?

ie we’re using 

www.github.com/WVURAIL/gr-radio_astro

so should I make 

gr-radio_astro3

?


> On Dec 3, 2019, at 11:26 AM, Müller, Marcus (CEL)  wrote:
> 
> U that's an ancient version of GNU Radio. Do you use any other UHD-
> linking software, or can you try our new PPA that would give you a
> modern GNU Radio 3.8.0.0?
> 
> https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases
> 
> Anyway, for most USRPs "fullscale" actually should do some scaling (if
> you're so inclined, look for "_host_extra_scaling" in the UHD source
> code).
> 
> What is the USRP you're using?
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
>> Hi all, not sure if I should send this here or at USRP list.
>> 
>> I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
>> block, but it have no effect. The idea is to avoid the use aof one block to 
>> scale the samples to [-1.0, +1.0] range May I be missing something?
>> 
>> For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from 
>> Ubuntu 18.04).
>> Thank you very 
>> 
>> 
>> 
>> -- 
>> Wheberth Damascena Dias
>> ___ _ _ __ ___ __ _ _ _  _ 
>> http://www.linkedin.com/in/wheberth
>> e-mail:whebe...@gmail.com
>> 

Re: GRC embedded Python vector support

[Glen Langston]

Hi Marcus,

I’ve implemented two very simple “vector median” codes,
one in python and the other in c++.

These take run-time defined vectors and in series and decimate, returning the 
median
of the 4 or more vectors.   The vector length is an argument.

see python/ra_vmedian.py in

git clone http://www.github.com/WVURAIL/gr-radio_astronomy

and/or

lib/vmedian_impl.cc lib/vmedian_impl.h

for the c++ version.  C++ is much more efficient.  On a raspberry pi 4, 
replacing the 5 vector medians (in sequence)
in python with the c++ version reduced the cpu load by 1/2 a cpu.

Glen


> On Nov 22, 2019, at 8:57 PM, Marcus D. Leech  wrote:
> 
> So, I'm trying to implement and embedded Python block that handles vectors 
> where the vector length is defined at runtime--like most
>  blocks that take vector-length inputs.
> 
> But GRC only "recognizes" the I/O signature as being vector if the dimension 
> is of a fixed size, and invariate with respect to runtime.  Is there
>  a "trick" I'm missing?
> 
> 
> 

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Glen Langston]

Hi Robin,

When using the AIRSPY (and mini) this summer I was finding some flashes in the 
RF band that
were on for a few 100 micro-seconds, then off.  (The plots are on my home 
computer so I’ll
have to send these on Friday).   The fraction of time the flashes are on is 
very small, less
than a total of one second in 24 hours.  

The spectra from the AIRSPY look very good and the AIRSPY is very reliable in 
sending all
data at the 10 MHz bandwidth (20 MHz I+Q samples).   I could see these 
transients
even when my horns were pointing at the ground, so were not likely due to 
internal sources.

However since my project is looking for transient events, the flashes are an 
issue
for me, but would not be noticed at all by most users.

The PlutoSdr does not seem to be generating many (any?) transients internally, 
which is very 
good. Ie when I point the horns at the ground I get very few/no transients 
appear above 5 sigma, compared
to the noise level.
  
The spectra from the PlutoSDR look good, and I can use a wide range of 
bandwidths, but for bandwidths 
larger than 3.2 MHz I don’t get all the data captured (I know this by 
calculating how long 
I should have to wait for all N samples at a given data rate, and measure the 
actual time it takes 
to get N samples.

The PlutoSDR does not seem to be reliable sending data at rates faster than 3.2 
MHz bandwidth 
(6.4 MHz I+Q samples).  I think it is sending blocks of data on USB but then 
not sending for a while while the data 
are buffered in some part of the USB processing.  The PlutoSDR code in GNuradio 
does not generate the 
Overflow or Underflow letters that other software generates for other devices.  
So the rate issues
are probably not noticed by other users of gnuradio-companion.

I’m working on a version of the Gnuradio code that does not generate any plots 
and
could run entirely internally on the PlutoSDR.  This might be able to capture 
all events
at the full 56 MHz sample rate.

The current code is obtainable by 
git clone http://www.github.com/WVURAIL/gr-radio_astro
This requires some building and compiling.   It works for me on the Raspberry 
Pi 4 and Odroid N2 (Both with 4GB).

I’ve downloaded and installed some else’s PlutoSDR .dfu 
files, that did run gnuradio on the Pluto.  That was working well but I could 
not figure
out how to modify it to build my own c++ libraries.   I might try again.

Regards

Glen


> On Nov 19, 2019, at 2:55 PM, Getz, Robin  wrote:
> 
> On Friday, November 15, 2019 1:22 PM , Glen I Langston wrote:
> [snip]
>> I’ve not yet fully checked the SDRPlay for short term transients.
>> 
>> Note that the Pluto SDR has no (or at least few) short term transients in 
>> the RF.
>> I did find the AIRSPY did have some transients that seem to be due to the 
>> device.
>> These occur a few thousand times a day, but for shorter than 100 micro 
>> seconds.
>> Total time on is less than a second a day.
>> 
> 
> Glen:
> 
> I would be interested in what you mean by this. I assume it's mostly 
> "anomalous data", and while it's "not right", you aren't sure if it is coming 
> from the RF (air interference) or via some transport scheme issue.
> 
> If you have a bursty/intermittent adjacent channel (where adjacent can be 
> within ~200 MHz of your LO, depending on your hardware), it could cause 
> anomalous reception. (This highly depends on your external filters, and 
> shielding)...
> 
> If you have bursty/intermittent data on harmonics of the LO (again, depending 
> on your hardware, external filters, shielding, etc), it could cause anomalous 
> reception.
> 
> If you have a ground loop, and someone next door turns on their electric 
> drill (for example) - this could cause what appear to be receiver problems. 
> (remember - you are pulling out signals at -100dBm, into 50 ohms, that is 
> 6.324 µV(p-p) or 0.12648 µA(p-p)/ That is pretty tiny, and can be effected by 
> lots of issues.
> 
> On AD936x based radios (Pluto, B200, E310, BladeRF 2.0 micro) there is the 
> ability to set the Rx to an LFSR/PRBS (Pseudo-Random Bit Sequence), to verify 
> "data", which I have run for ~ week with no lost/bad data, both at max rate 
> (61.44 MSPS, checking in local in the FPGA), and lower over the various 
> transport layers (~5 MSPS over USB and Ethernet), checking in a C 
> application. I haven't done it in awhile - and have not gone all the way up 
> to GNU Radio, but should be able to pretty easily ... More info at:
> https://ez.analog.com/cfs-file/__key/communityserver-wikis-components-files/00-00-00-02-20/AD9361BISTFAQ.pdf
> 
> If you think you are seeing bad digital/transport data on Pluto - let us know 
> so we can track things down. (it's been awhile since we tested this, and 
> changes have been made, I will add this to the release test)
> Any sort of anomalous device or transport issues - we can try to help look 
> into. If they are anomalous RF issues - that's harder. 😊
> Our goal is zero device issues all the time - the transport to any 

Re: [Discuss-gnuradio] PyBOMBS documentation recommendations

[Glen Langston]

Thanks for all your documentation efforts!

> On Nov 8, 2019, at 8:27 AM, Müller, Marcus (CEL)  wrote:
> 
> Hi Hans,
> 
> I like that idea, but revision dates are a central feature of what a
> Wiki like ours offers: you can click on "Versions" and see when the
> current version was last edited.
> 
> Sure, that might have just been a typo fix, but whether or not to
> update the "state of" written statement is still as subjective, so I'd
> argue: We've got an automatism for that that's just as good as the
> human hand, so save the time of the human hand :)


> What IS very helpful, especially in the context of installations, is
> stating the platforms and versions of these used: they are not part of
> what a Wiki can automatically track.

I very much agree that the documentation is much more helpful if it
includes a reference to the software revision number that is being
described, along with the OS environment being used.   

> Best regards,
> Marcus
> 
> On Fri, 2019-11-08 at 13:31 +0800, HansFong wrote:
>> Adding to this, please always add a revision date to any documentation, 
>> preferably at the top. It is so difficult to guess if documentation is 
>> current or not. Thank you --Hans (BX2ABT)
>> 
>> On 11/8/19 11:12 AM, Barry Duggan wrote:
>>> Greetings,
>>> 
>>> I have found four URLs giving instructions on using PyBOMBS:
>>> 
>>> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS
>>> https://github.com/gnuradio/pybombs/README.md
>>> https://github.com/gnuradio/gnuradio/README.md
>>> https://www.gnuradio.org/blog/2016-06-19-pybombs-the-what-the-how-and-the-why/
>>>  
>>> 
>>> 
>>> 
>>> In various comments in Discuss-gnuradio, I have concluded that most of 
>>> the PyBOMBS users who have failed were due to using old or incomplete 
>>> instructions. Also I think that most new users read the 
>>> InstallingGR#Using_PyBOMBS instructions only.
>>> 
>>> As an advocate of having a single place to document instructions, I 
>>> highly recommend picking one site for those instructions, and then 
>>> having links to that page from all others. From what I see, the 
>>> https://github.com/gnuradio/pybombs/README.md page seems to be the 
>>> logical choice since it is revised as PyBOMBS is revised.
>>> 
>>> If you choose to have the 
>>> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS page 
>>> contain the current instructions as well, I can convert the 
>>> pybombs/README.md instructions to Mediawiki and put them in 
>>> InstallingGR#Using_PyBOMBS.
>>> 
>>> Once you have decided what you want done, I can take care of the 
>>> edits, if you would like.
>>> 
>>> Best regards,

Re: A 21cm sky map of a goodly chunk of the northern sky

[Glen Langston]

Very nice work Marcus!

Did you put your .grc file on GitHub?

FYI I’ve made some good progress on simultaneously mapping in spectral line
mode and detecting transient radio flashes.

This design is obtained with

git clone http://www.github.com/WVURAIL/gr-radio_astro

then building and running

cd gr-radio_astro/examples

gnuradio-companion NsfWatch45.grc

This uses a PlutoSdr, and modification would be required for other SDRs.

The code is running on three Pi 4Bs and an Odroid N2.
I look for coincidences in the transient event times.

Again, great work on the map!   Also I confirm that the outer part of our 
Milky Way galaxy is much brighter than the inner galaxy in HI.   
This puzzled me for a while.

Best Regards,

Glen

> On Oct 28, 2019, at 11:42 PM, Marcus D. Leech  wrote:
> 
> On 10/28/2019 12:55 PM, Daniel Estévez wrote:
>> El 28/10/19 a las 1:02, Marcus D. Leech escribió:
>>> Here's the latest version of our 21cm sky map, derived from nearly 5
>>> months worth of data from our 21cm spectrometer instrument.
>>> 
>>> All of the real-time processing is handled, naturally, with Gnu Radio,
>>> and then some Python post-processing.
>>> 
>>> http://www.ccera.ca/files/21cm.png
>> Hi Marcus,
>> 
>> Very interesting. Is there any information online about how the map was
>> made (both GNU Radio and post-processing)?
>> 
>> Best,
>> 
>> Daniel.
>> 
>> 
> Finally finalized the memo on this:
> 
> http://www.ccera.ca/files/memos/ccera-memo-0011.pdf
> 
> 
> 

Re: [Discuss-gnuradio] Quick CCERA news

[Glen Langston]

Very nice map of the entire sky.   
I’m looking forward to your memo.

Best regards

Glen

> On Sep 20, 2019, at 12:16 AM, Marcus D. Leech  wrote:
> 
> I haven't posted any CCERA updates recently--mostly because there hasn't been 
> much of relevance to this group.
> 
> But the most recent update at least contains a pretty picture:
> 
> http://www.ccera.ca/uncategorized/ccera-completes-first-pass-of-21cm-sky-survey/
> 
> I'll be working on a memo in our "memo" series about the overall system, 
> software, etc.
> 
> Marcus Leech
> President
> Canadian Centre for Experimental Radio Astronomy
> http://www.ccera.ca
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Glen Langston]

Hi Ron,

Thanks for the suggestion.  My experience is that the -j4
works for a while on a Raspberry PI 3B+,  but eventually
runs out of memory on some files and the whole PI crashes.

-j4 might work on a 4 GB PI 4 though.

Best regards,

Glen

On Wed, Jul 31, 2019 at 5:30 PM Ron Economos  wrote:
>
> You can reduce build time significantly by using all the cores in your
> CPU. This is done by using the -j parameter with the make command. Set
> the parameter to the number of available cores. For the Pi 3B+, the CPU
> has four cores, so:
>
> make -j4
>
> Ron
>
> On 7/31/19 10:28, Barry Duggan wrote:
> > Hi Glen,
> >
> > With the help of many of our friends here, I was able to build 3.8
> > from scratch on a Pi 3B+. Here are my notes from that effort:
> >
> > Build gnuradio on Raspberry Pi 3B+
> >
> > Author: Barry Duggan
> > 31 July 2019
> >
> > OS: Raspbian Buster with desktop and recommended software
> > 32GB microSD
> >
> > A. Load prerequisites
> >
> > sudo apt-get update --allow-releaseinfo-change
> > sudo apt-get upgrade
> > sudo apt-get install git cmake g++ libboost-all-dev libgmp-dev swig
> > python3-numpy
> > sudo apt-get install python3-mako python3-sphinx python3-lxml doxygen
> > libfftw3-dev
> > sudo apt-get install libsdl1.2-dev libgsl-dev libqwt-qt5-dev
> > libqt5opengl5-dev python3-pyqt5
> > sudo apt-get install liblog4cpp5-dev libzmq3-dev python3-yaml
> > sudo apt-get install libpthread-stubs0-dev
> > sudo pip3 install click-plugins
> >
> > D. Set up swap file
> >
> > sudo fallocate -l 2G /swapfile
> > sudo chmod 600 /swapfile
> > sudo mkswap /swapfile
> > sudo swapon /swapfile
> >
> > -   To make this permanent, add this line to /etc/fstab
> > /swapfile  none  swap  sw  0  0
> >
> > C. Clone repository
> >
> > cd
> > git clone --recursive https://github.com/gnuradio/gnuradio.git
> >
> > D. Build
> >
> > cd ~/gnuradio
> > mkdir build
> > cd build
> > (this next command is all on one line, starting with cmake and ending
> > with ../)
> > cmake -DENABLE_GR_UHD=OFF -DCMAKE_INSTALL_PREFIX="/usr/local"
> > -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
> > make
> > sudo make install
> > sudo ldconfig
> >
> > Of course, if you want UHD, leave out the "-DENABLE_GR_UHD=OFF".
> >
> > It took about eight hours total.
> >
> > Good luck! Let me know how it went.
> >
> > Best wishes,
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Glen Langston]

Thanks Barry,
Those are great notes.
I will try to follow them.

However it would be great if I could start from an image of the Sd card.
One issue with SD card images is to remember to remove passwords from
browsers

I am also using a 32GB card, but it compressed very well, down to 2.5GB

Best regards
Glen

On Wed, Jul 31, 2019 at 1:28 PM Barry Duggan  wrote:

> Hi Glen,
>
> With the help of many of our friends here, I was able to build 3.8 from
> scratch on a Pi 3B+. Here are my notes from that effort:
>
> Build gnuradio on Raspberry Pi 3B+
>
> Author: Barry Duggan
> 31 July 2019
>
> OS: Raspbian Buster with desktop and recommended software
> 32GB microSD
>
> A. Load prerequisites
>
> sudo apt-get update --allow-releaseinfo-change
> sudo apt-get upgrade
> sudo apt-get install git cmake g++ libboost-all-dev libgmp-dev swig
> python3-numpy
> sudo apt-get install python3-mako python3-sphinx python3-lxml doxygen
> libfftw3-dev
> sudo apt-get install libsdl1.2-dev libgsl-dev libqwt-qt5-dev
> libqt5opengl5-dev python3-pyqt5
> sudo apt-get install liblog4cpp5-dev libzmq3-dev python3-yaml
> sudo apt-get install libpthread-stubs0-dev
> sudo pip3 install click-plugins
>
> D. Set up swap file
>
> sudo fallocate -l 2G /swapfile
> sudo chmod 600 /swapfile
> sudo mkswap /swapfile
> sudo swapon /swapfile
>
> -   To make this permanent, add this line to /etc/fstab
> /swapfile  none  swap  sw  0  0
>
> C. Clone repository
>
> cd
> git clone --recursive https://github.com/gnuradio/gnuradio.git
>
> D. Build
>
> cd ~/gnuradio
> mkdir build
> cd build
> (this next command is all on one line, starting with cmake and ending
> with ../)
> cmake -DENABLE_GR_UHD=OFF -DCMAKE_INSTALL_PREFIX="/usr/local"
> -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
> make
> sudo make install
> sudo ldconfig
>
> Of course, if you want UHD, leave out the "-DENABLE_GR_UHD=OFF".
>
> It took about eight hours total.
>
> Good luck! Let me know how it went.
>
> Best wishes,
> --
> Barry Duggan
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Glen Langston shared "Pi4-19Jul28.img.gz" with you

[Glen Langston (via Dropbox) via Discuss-gnuradio]

Hi there,

Glen Langston (glen.i.langs...@gmail.com) invited you to view the file " 
Pi4-19Jul28.img.gz " on Dropbox.

Glen said:
"We've been working to make it easier to run GNURADIO with a 
specific
set of hardware to enable radio astronomy. 

Here is a 
Raspberry Pi 4 OS copy that has been gzip compressed down
to 
2.5 GB.This version is configured to run Gnuradio, gnu 
radio-companion and radio astronomy graphs.   It seems to work
out of the 
box when using wired ethernet.   The WVURAIL
designs from GitHub are 
pre-installed and tested.
( i.e. git clone 
http://github.com/WVURAIL/gr-radio_astro)

The
 analysis software from is also preloaded and copied into 
the
/home/pi/bin 
directory.   For documentation 
see.

(i.e. git clone 
http://github.com/glangsto/analyze)

The
 un-gziped image is big, 32 GB.   Using dd on a linux box
this can be 
copied directly to an SD card and inserted into
Raspberry PI 4 and Pi 3 
B+.   

The OS has been tweaked for static IP addresses, enabling 
an array of radio telescopes.

For wifi, a tweak is required to 


/etc/dhcpcd.conf

Good 
Luck!

Glen

"

View file[1]

Enjoy!
The Dropbox team 
 Glen and others will be able to see when you view this file. Other files 
shared with you through Dropbox may also show this info. Learn more[2] in our 
help center. 

[1]: https://www.dropbox.com/l/scl/AAAnYy8xUVs0-etEXqAFVpXbWBujAnJh5LQ
[2]: https://www.dropbox.com/l/AAALEA6vTA_di8leXN8I85TFEiB_BGmr8bk___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Glen Langston]

Hi Philip,

Sorry I did not take better notes.

I'll try it again and get back to you.

Glen


On Tue, Jul 30, 2019 at 9:08 PM Philip Balister  wrote:

> On 07/30/2019 07:48 PM, Glen Langston wrote:
> > Hi Marcus and all
> >
> > Thanks for all your efforts.
> >
> > I've built gnuradio 3.7.13.4 successfully on a Raspberry Pi 4
> > and am saving an image of a 32GB SD card.   This image happens to
> > run perfectly fine on a Pi 3B+ as well.  And a copy on another PI 4 I
> just
> > purchased.
> >
> > I'm using AIRSPY and PlutoSDR dongles, but have not tried more advanced
> > devices.
> >
> > However I also tried building 3.8 and had all kinds of troubles.   CMAKE
> > did not
> > work easily.  Eventually found an apt-get remove cmake followed
> > by an apt-get install cmake fixed that, but building cmake did not work.
> >
> > Then I had trouble building Volk and several other components on the PI
> 4.
>
> What distro are you running on the pi4? What are the specific errors?
>
> Philip
>
> >
> > So, the upgrade path to 3.8 is not easy from the build-it-yourself point
> of
> > view.
> >
> > Will it be possible to get
> >
> > apt-get install gnuradio3.8
> >
> > to work? with the new volk?
> >
> > On Raspberry pi 4, mostly I end up using generic versions of Volk in
> > earlier version.
> >
> > Thanks again for your efforts!
> >
> > Glen
> >
> > I'll post the location of the R PI 4, once I've confirmed that others can
> > use it.
> >
> >
> > On Tue, Jul 30, 2019 at 5:29 PM Marcus Müller 
> wrote:
> >
> >> Hello VOLKy people,
> >>
> >> on coming Monday, we'll release the next VOLK version. This is utterly
> >> necessary so that we have a definitive version to use for the GNU Radio
> >> 3.8.0.0 release.
> >>
> >> That VOLK release will be VOLK 2.0.0, marking the start of VOLK using
> >> Semantic Versioning [1].
> >>
> >> If you want code to be part of that release, please finish it by
> >> Thursday, the first of August. Don't fret, we'll be regularly doing
> >> VOLK releases in the future.
> >>
> >> Best regards,
> >> Marcus
> >>
> >> [1] https://semver.org
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Glen Langston]

Hi Marcus and all

Thanks for all your efforts.

I've built gnuradio 3.7.13.4 successfully on a Raspberry Pi 4
and am saving an image of a 32GB SD card.   This image happens to
run perfectly fine on a Pi 3B+ as well.  And a copy on another PI 4 I just
purchased.

I'm using AIRSPY and PlutoSDR dongles, but have not tried more advanced
devices.

However I also tried building 3.8 and had all kinds of troubles.   CMAKE
did not
work easily.  Eventually found an apt-get remove cmake followed
by an apt-get install cmake fixed that, but building cmake did not work.

Then I had trouble building Volk and several other components on the PI 4.

So, the upgrade path to 3.8 is not easy from the build-it-yourself point of
view.

Will it be possible to get

apt-get install gnuradio3.8

to work? with the new volk?

On Raspberry pi 4, mostly I end up using generic versions of Volk in
earlier version.

Thanks again for your efforts!

Glen

I'll post the location of the R PI 4, once I've confirmed that others can
use it.


On Tue, Jul 30, 2019 at 5:29 PM Marcus Müller  wrote:

> Hello VOLKy people,
>
> on coming Monday, we'll release the next VOLK version. This is utterly
> necessary so that we have a definitive version to use for the GNU Radio
> 3.8.0.0 release.
>
> That VOLK release will be VOLK 2.0.0, marking the start of VOLK using
> Semantic Versioning [1].
>
> If you want code to be part of that release, please finish it by
> Thursday, the first of August. Don't fret, we'll be regularly doing
> VOLK releases in the future.
>
> Best regards,
> Marcus
>
> [1] https://semver.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTL-SDR device failed to open in flowgraph

[Glen Langston]

Hi Marcus and Ellie,

Thanks again for the flow graph Marcus.   It's a very impressive piece of
work.
If one has only one SDR, it is necessary to change the input  number of
channels
to 1, I think(?)  Then connect the 2nd channel (chan1) to the output of
the  source
block.   The modified .grc file works right away.

Cheers
Glen




On Thu, Feb 22, 2018 at 11:36 PM, Marcus D. Leech  wrote:

> On 02/22/2018 11:13 PM, Ellie White wrote:
>
> Hi all,
>
>
> I am an amateur radio astronomy enthusiast and I've been using an RTL-SDR
> (R820T) USB dongle for my projects; up until now I had been using a Windows
> 8.1 laptop, but that one is on the blink right now so I've switched to a
> Windows 10 computer. I've tried to plug in my SDR and run the flowgraph
> (attached), but I keep getting the output below:
>
>
> Generating: 'C:\\Users\\Deana White\\Documents\\top_block.py'
>
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Users\Deana White\Documents\top_block.py
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.010.001.001-0-unknown
>
> gr-osmosdr c653754d (0.1.5git) gnuradio 3.7.11.1
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
> Using device #0 Generic RTL2832U OEM
> usb_open error -12
>
> FATAL: Failed to open rtlsdr device.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> gr::pagesize: no info; setting pagesize = 4096
>
>
> I've run zadig for the RTL-SDR, and it works just fine with SDR#. Do you
> have any advice as to why I might be having this problem with the GNURadio
> flowgraph?
>
>
> Thanks very much! Have a great evening and take care,
>
>
> Ellie
>
> I hope someone can help you, Ellie.
>
> My approach would be to install an operating system on your computer.
> :) :)   [That was snarkasm, just in case it wasn't obvious ]
>
> Once you get it working, you (and Glen et al) might want to play with:
>
> https://github.com/ccera-astro/spectro_radiometer
>
> Cheers
> Marcus
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problems with WXGUI

[Glen Langston]

Hi Marcus,  

Thanks for your advice.

Here are all the messages from gnu radio companion.
The symptoms are very easy to reproduce.  The block I tested is simply
a connection between Signal Source (1KHz) and Audio sink, selecting the wxgui
 
Generating: '/Users/glenlangston/Desktop/Research/watch/top_block.py'

Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/glenlangston/Desktop/Research/watch/top_block.py

Traceback (most recent call last):
  File "/Users/glenlangston/Desktop/Research/watch/top_block.py", line 25, in 

from grc_gnuradio import wxgui as grc_wxgui
ImportError: cannot import name wxgui


I’ve done a gnuradio uninstall

sudo port uninstall gnuradio

Then a re-install using brew, following a trail of googled suggestions.

brew install gnuradio

More suggestions?

Thanks

Glen





> On Nov 20, 2017, at 3:45 PM, Marcus D. Leech  wrote:
> 
> On 11/20/2017 03:07 PM, Glen Langston wrote:
>> Hello
>> 
>> I’m wondering if anyone else is having the same trouble with wxgui in 
>> Gnuradio.
>> 
>> I’ve installed gnu radio on several MacBooks and ubuntu systems.   
>> I’ve got an application we’ve been using for years that uses 
>> 
>> wxgui
>> 
>> Now I’ve tried to upgrade to get access to a new SDR but the software is
>> refusing to run as is shown by the same message for gnu radio companion:
>> 
>>  File "/Users/glenlangston/Desktop/Research/watch/top_block.py", line 25, in 
>> 
>> from grc_gnuradio import wxgui as grc_wxgui
>> 
>> Suggestions?
>> 
>> Thanks
>> 
> There's probably more lines of error message there, and they would be helpful 
> in helping you.
> 
> Also, I changed the subject to be more closely related to the topic at hand.
> 
> Keep in mind that WXGUI is *going away*  some time soon.   The underlying 
> libraries haven't been supported in years, and WXGUI suffers significant
>   performance penalties compared to Qt GUI, which is what prompted me to 
> start work on spectro_radiometer as a replacement for
>   simple_ra.
> 
> 
>> Glen
>> 
>> our application is noted at www.opensourceradiotelescopes.org 
>> <http://www.opensourceradiotelescopes.org/>
>> 
>> 
>>> On Nov 20, 2017, at 2:14 PM, Bakshi, Arjun >> <mailto:bakshi...@buckeyemail.osu.edu>> wrote:
>>> 
>>> That was it. I overlooked that setting your setup.
>>> 
>>> Hopefully the last issue. I'm still getting a lot of under flow errors when 
>>> I use the same radio (A/B ) for a rx and tx block. I have a WBX daughter
>>>  board in there so simultaneous rx-tx should not be a 
>>> problem. As mentioned earlier, I was able to get 2rx-tx links running at 
>>> 5Msps previously with N210s.
>>> 
>>> Changing the buffer size, file size, or the sampling rate (not the 200e6 
>>> one) doesn't help.
>>> 
>>> Thank you,
>>> 
>>> AB
>>> From: Michael Carosino mailto:m.caros...@gmail.com>>
>>> Sent: Monday, November 20, 2017 1:24:17 PM
>>> To: Bakshi, Arjun
>>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
>>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex
>>>  
>>> I've had this error before, can't recall the solution however one thing to 
>>> try is setting the DDC block select parameters. On the upper DDC block set 
>>> block select to 0 and on the lower DDC set the block select to 1. 
>>> (sometimes the auto-select function fails to work correctly I think).
>>> 
>>> On Mon, Nov 20, 2017 at 10:14 AM, Bakshi, Arjun 
>>> mailto:bakshi...@buckeyemail.osu.edu>> 
>>> wrote:
>>> Hi,
>>> 
>>> Thanks for the info about the sampling rates. That was the source of the 
>>> issue.
>>> 
>>> The issue was with the output rate of the DUC block, which should  be set 
>>> to 200MHz. Changing that to 200e6 fixes the underflow issues. I guess that 
>>> the input rate is the sampling rate that I'm used to setting in the N210. I 
>>> can now run 2 TXblocks without a problem. 
>>> 
>>> The sampling rate in the RFNoC-radio(tx) block can be set to what you want, 
>>> but it'll get reset to 200e6 along with a warning saying so.
>>> 
>>> I am still having trouble with the RX blocks.
>>> -- When I add an RX flow to a graph with 2 TX flows in it, I get underflows 
>>> again. The application does not hang though.
&

Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex

[Glen Langston]

Hello

I’m wondering if anyone else is having the same trouble with wxgui in Gnuradio.

I’ve installed gnu radio on several MacBooks and ubuntu systems.   
I’ve got an application we’ve been using for years that uses 

wxgui

Now I’ve tried to upgrade to get access to a new SDR but the software is
refusing to run as is shown by the same message for gnu radio companion:

 File "/Users/glenlangston/Desktop/Research/watch/top_block.py", line 25, in 

from grc_gnuradio import wxgui as grc_wxgui

Suggestions?

Thanks

Glen

our application is noted at www.opensourceradiotelescopes.org 



> On Nov 20, 2017, at 2:14 PM, Bakshi, Arjun  
> wrote:
> 
> That was it. I overlooked that setting your setup.
> 
> Hopefully the last issue. I'm still getting a lot of under flow errors when I 
> use the same radio (A/B ) for a rx and tx block. I have a WBX daughter board 
> in there so simultaneous rx-tx should not be a problem. As mentioned earlier, 
> I was able to get 2rx-tx links running at 5Msps previously with N210s.
> 
> Changing the buffer size, file size, or the sampling rate (not the 200e6 one) 
> doesn't help.
> 
> Thank you,
> 
> AB
> From: Michael Carosino 
> Sent: Monday, November 20, 2017 1:24:17 PM
> To: Bakshi, Arjun
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex
>  
> I've had this error before, can't recall the solution however one thing to 
> try is setting the DDC block select parameters. On the upper DDC block set 
> block select to 0 and on the lower DDC set the block select to 1. (sometimes 
> the auto-select function fails to work correctly I think).
> 
> On Mon, Nov 20, 2017 at 10:14 AM, Bakshi, Arjun 
> mailto:bakshi...@buckeyemail.osu.edu>> wrote:
> Hi,
> 
> Thanks for the info about the sampling rates. That was the source of the 
> issue.
> 
> The issue was with the output rate of the DUC block, which should  be set to 
> 200MHz. Changing that to 200e6 fixes the underflow issues. I guess that the 
> input rate is the sampling rate that I'm used to setting in the N210. I can 
> now run 2 TXblocks without a problem. 
> 
> The sampling rate in the RFNoC-radio(tx) block can be set to what you want, 
> but it'll get reset to 200e6 along with a warning saying so.
> 
> I am still having trouble with the RX blocks.
> -- When I add an RX flow to a graph with 2 TX flows in it, I get underflows 
> again. The application does not hang though.
> 
> -- When I have 2 RX flows to the graph, I get the following error:
> self.device3.connect(self.uhd_rfnoc_streamer_radio_2.get_block_id(), 0, 
> self.uhd_rfnoc_streamer_ddc_1.get_block_id(), 0)
>   File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line 
> 1670, in connect
> return _ettus_swig.device3_sptr_connect(self, *args)
> RuntimeError: RuntimeError: On node 0/DDC_0, input port 0 is already 
> connected.
> terminate called after throwing an instance of 'uhd::assertion_error'
>   what():  AssertionError: [0/DDC_0] Attempting to disconnect input port 0, 
> which is not registered as connected!
> 
> It seems to have an issue with the lower DDC block. I changed the setup to 
> have only 1 DDC block with 2 channels, but that resulted in an overrun error 
> like "Ooverrun on chan 0".
> 
> How can I fix these issues?
> 
> Image of error prompt, and grc file attached.
> 
> Thanks,
> 
> AB
> 
> From: Michael Carosino mailto:m.caros...@gmail.com>>
> Sent: Monday, November 20, 2017 12:31:52 AM
> 
> To: Bakshi, Arjun
> Cc: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex
>  
> Hi,
> 
> looks like gnuradio is freezing due to the massive amount of underflows 
> ocurring. First try replacing the constant source with two separate analog 
> fast noise sources connected to the dma fifo - this might help if indeed the 
> problem is that the PC is being too slow to generate samples. Secondly, 
> revert the dma fifo depths to the default 32M and see if it has any effect 
> but I suspect the first option should fix your issues. Also it's definitely 
> helpful to test each single tx chain on its own to make sure it works as 
> expected before trying both together! 
> 
> Assuming you are using an x310, the sampling rate on the radio block should 
> be set to 200 megasamples/per sec, similarly the DUC output rate should also 
> be 200 megasamples/per sec. On the receive side, the radio block's sampling 
> rate should again be set to 200megasamp/sec with the DDC input rate being set 
> to the same as well. Also the analog bandwidth in the context of the tx side 
> just adjusts some filters I believe - so I'd leave it at the default of 
> 56Mhz. On the rx side I'd also leave it at the default of 56Mhz unless you 
> have some interferer in that range that you'd want to avoid.
> 
> On Sat, Nov 18, 2017 at 4:53 PM, Bakshi, Arjun  > wrote:
> Hi,
> 
> I've insta