Watchdog for GNU Radio

[Kopa Rebu]

Hi all, I use GNU Radio with a rtl-sdr dongle, which I tune to some frequency and then leave unattended for some hours. Sometimes, the reception just stops: in my flowgraph, I have some display sinks showing the waveform, and it remains still, like frozen. The GNU Radio interface is not frozen, though: I can click on the buttons, only that they won't make anything useful because the reception is not working anymore.When this happens, I close the flowgraph and launch it again, without having to unplug the dongle, and it starts working. As this can happen and go unnoticed for hours, I was thinking if there would be a way to automatically detect this from somewhere, so the graph can be restarted. Something like a watchdog. I use Linux. Any ideas? Thanks in advance

Help check flow-graph

[AKINYELE ITAMAKINDE]

Can someone help to check whether these transmitter and receiver sliding
correlator channel sounder flowgraph are rightly configured. Thanks

Re: Help check flow-graph

[Marcus Müller]

Hi Akinyele,

GNU Radio companion has an "screen capture" function that allows you to
directly save **good** images of your flow graph. Also, your operating
system has the same. So, I'll respectfully point out that taking photos
with a camera is a complicated and not overly useful method to
communicate flow graphs. Can't read anything in these.

So, checking your flow graph as far as possible:

* uses legacy GNU Radio 3.7.11, which is an old release, even for that
legacy release series. Update to 3.8 as soon as possible. Not a good
idea to start a new project based on old software. I think this looks
like Ubuntu, so a simple update to Ubuntu 20.04 LTS solves that
* WX GUI: don't use that. Use Qt instead.
* Can't tell you whether your channel sounder is correctly configured
without knowing your channel *and* the required precision of your
channel state estimate.

As Marcus D. Leech already explained in May, you might want to make sure
your DSP/channel understanding is good enough and ask a more precise
question!

Best regards,
Marcus M.



On 07.11.20 13:55, AKINYELE ITAMAKINDE wrote:
> Can someone help to check whether these transmitter and receiver sliding
> correlator channel sounder flowgraph are rightly configured. Thanks
> 

Re: GNURadio 3.9 build from source VS THRIFT

[Marcus Müller]

Hi Fabien,

just so you know: We're aware and it's being worked on.
If you don't need controlport, then for now, disabling it (cmake
-DENABLE_GR_CTRLPORT=Off ...) would be a workaround.

Best regards,
Marcus

On 06.11.20 22:51, Fabien PELLET wrote:
> Hello,
> 
> When compiling the actual source that we can clone from github, I'm
> unable to compile with Thrift module. I also build Thrift from source
> 0.10.0 (as read on some forums), 0.11.0, 0.12.0, 0.13.0, none of them
> works.
> 
> With 0.10.0 and 0.13.0 I get some signature error on some functions.
> 
> With 0.11.0 and 0.12.0 I get errors in some files (rpcserver_thrift.h,
> rpcserver_thrift.cc for example) and it complains about "logger" that
> was not declared in "GR_LOG_ERROR(logger, msg.str())" for example.
> 
> I'm interresting in using gr-ctrlport for some test I'm doing and it
> needs thrifts to work as far as I can understand.
> 
> Which sources should I use for Thrift and which dependencies ?
> 
> Thanks a lot,
> 
> Best regards,
> 
> Fabien PELLET, F4CTZ.
> 
> 

Re: Centos7 installing GNU3.8 via pybombs issue

[Marcus Müller]

Hi James,

our software is called "GNU Radio", not just "GNU" :)

Anyway, the relevant python-click-plugins.lwr is most definitely not
empty, otherwise your Pybombs wouldn't be calling `yum info
python3-click-plugins` (it only knows to do that because of that recipe
file).

Can you run `yum info python3-click-plugins` manually and check what it
says? (generally, we're happier about copy&pasted text from a console
than about a screenshot)

Best regards,
Marcus

On 05.11.20 14:46, J P wrote:
> Hello,
> 
> For a project that I am currently doing, i'm required to use GNU3.8 on
> centos 7. 
> My virtual machine is using:
> gcc:9.3.1
> python 3.6.8
> pybombs 2.3.4.
> 
> I followed the steps on GNU website
> (https://github.com/gnuradio/pybombs#prefixes
> ).
> During the pybombs prefix I'm running into an Error as shown below. 
> 
> I have looked into the python-click-plugin.lwr which is empty; but im
> not sure if its meant to be.
> 
> Thank you for the response in advanced.
> 
> Kind Regards
> James 
> 
> 

Re: Watchdog for GNU Radio

[Marcus Müller]

I'd presume there's something going wrong in the communication between
your PC  and the dongle; maybe a USB packet goes missing, maybe the
dongle reboots for some reason, like unstable power supply. It's
probably wisest to fix that instead of building a watchdog around it.

If you really want to build a watchdog: Spawn a thread, e.g. by
embedding a python module in the flow graph, that periodically checks
whether the nitems_written(0) of your osmocom_source has increased since
last call, and otherwise shuts down the flow graph.

Cheers,
Marcus

On 07.11.20 13:40, Kopa Rebu wrote:
> Hi all,
>  
> I use GNU Radio with a rtl-sdr dongle, which I tune to some frequency
> and then leave unattended for some hours. Sometimes, the reception just
> stops: in my flowgraph, I have some display sinks showing the waveform,
> and it remains still, like frozen. The GNU Radio interface is not
> frozen, though: I can click on the buttons, only that they won't make
> anything useful because the reception is not working anymore.
> When this happens, I close the flowgraph and launch it again, without
> having to unplug the dongle, and it starts working.
>  
> As this can happen and go unnoticed for hours, I was thinking if there
> would be a way to automatically detect this from somewhere, so the graph
> can be restarted. Something like a watchdog.
>  
> I use Linux. Any ideas?
>  
> Thanks in advance

Re: Latency Manager from GRCON2019

[Derek Kozel]

Hi Fabien,

The blocks were built for use with the development version of GNU Radio 
for a year ago, and as the OOT name states it's very much a work in 
progress. The blocks function but I haven't updated them for the newest 
development changes, nor have they been tested for actual 3.8 release 
versions.


I do think they'll likely work on 3.8, please let me know how it goes. 
I'll update them for 3.9 officially sometime soon and release the 
repository in a more maintainable form (and better name).


Cheers,
Derek

On 07/11/2020 00:57, Fabien PELLET wrote:

Hi Cinaed,

Thanks a lot. I will try this.

Best regards,

Fabien.

Le 07/11/2020 à 00:32, Cinaed Simson a écrit :
Hi Fabian - the CMakeLists.txt file in the top directory contains the 
following line:


   find_package(Gnuradio "3.9" REQUIRED)

If I change the version from 3.9 to 3.8, and

  git checkout maint-3.8

it builds and passes

  make test

I haven't installed it or tested it.

But it does generate

  _example_swig.so

in the build/swig  directory.


-- Cinaed



On 11/6/20 1:57 PM, Fabien PELLET wrote:

Hello,

The problem is that when I try to compile the module with 3.8 
installed, the CMAKE complains that it can't find 3.9.


When 3.9 is installed, the CMAKE complains that GRSwig is missing so 
I'm a little lost if swig is not used...


Best regards,

Fabien PELLET, F4CTZ.

Le 06/11/2020 à 22:35, Volker Schroer a écrit :

Hello !
Meanwhile gnuradio does not use swig but pybind.
If your OOT requires swig you have to go back to 3.8

-- Volker, dl1ksv

Am 06.11.20 um 22:31 schrieb Fabien PELLET:

Hello,

I'm trying to compile the project OOT of latency manager of Matt 
ETTUS

from he presents at the GRCON2019.

For that I built from source GNURadio to get 3.9 version successfully
but I can't compile the project provided here :
https://github.com/dkozel/gr-workinprogress.

The CMAKE fails and tell that it can't find GRSwig. I'm on Ubuntu 
20.04.


Thanks for any help or suggestions.

Best regards,

Fabien PELLET, F4CTZ.

Re: Watchdog for GNU Radio

[Kopa Rebu]

Regarding your first point, you're right, but I couldn't find the cause yet. At least I couldn't see anything useful in logs like dmesg or GNU Radio's console. Fortunately it doesn't happen very frequently, but it is very annoying when it does. About the second, I'll look into it. My understanding is that I've to shut down the flowgraph when the failure situation is detected, and after that, I have to relaunch it using some OS provided facility, right? Thank you. 07.11.2020, 15:11, "Marcus Müller" :I'd presume there's something going wrong in the communication betweenyour PC and the dongle; maybe a USB packet goes missing, maybe thedongle reboots for some reason, like unstable power supply. It'sprobably wisest to fix that instead of building a watchdog around it.If you really want to build a watchdog: Spawn a thread, e.g. byembedding a python module in the flow graph, that periodically checkswhether the nitems_written(0) of your osmocom_source has increased sincelast call, and otherwise shuts down the flow graph.Cheers,MarcusOn 07.11.20 13:40, Kopa Rebu wrote: Hi all,   I use GNU Radio with a rtl-sdr dongle, which I tune to some frequency and then leave unattended for some hours. Sometimes, the reception just stops: in my flowgraph, I have some display sinks showing the waveform, and it remains still, like frozen. The GNU Radio interface is not frozen, though: I can click on the buttons, only that they won't make anything useful because the reception is not working anymore. When this happens, I close the flowgraph and launch it again, without having to unplug the dongle, and it starts working.   As this can happen and go unnoticed for hours, I was thinking if there would be a way to automatically detect this from somewhere, so the graph can be restarted. Something like a watchdog.   I use Linux. Any ideas?   Thanks in advance 

Re: Centos7 installing GNU3.8 via pybombs issue

[Alex Humberstone]

Dear James,

CentOS 7 is really really old. I would say that you should ask
your customer or project leader to allow you to at least use CentOS 8.
You're just going to have a whole set of challenges and difficulties
using CentOS 7. Why create more unnecessary work for yourself?

Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University (NMSU)
Las Cruces, New Mexico, USA



On Sat, 7 Nov 2020 at 08:07, Marcus Müller  wrote:

> Hi James,
>
> our software is called "GNU Radio", not just "GNU" :)
>
> Anyway, the relevant python-click-plugins.lwr is most definitely not
> empty, otherwise your Pybombs wouldn't be calling `yum info
> python3-click-plugins` (it only knows to do that because of that recipe
> file).
>
> Can you run `yum info python3-click-plugins` manually and check what it
> says? (generally, we're happier about copy&pasted text from a console
> than about a screenshot)
>
> Best regards,
> Marcus
>
> On 05.11.20 14:46, J P wrote:
> > Hello,
> >
> > For a project that I am currently doing, i'm required to use GNU3.8 on
> > centos 7.
> > My virtual machine is using:
> > gcc:9.3.1
> > python 3.6.8
> > pybombs 2.3.4.
> >
> > I followed the steps on GNU website
> > (https://github.com/gnuradio/pybombs#prefixes
> > ).
> > During the pybombs prefix I'm running into an Error as shown below.
> >
> > I have looked into the python-click-plugin.lwr which is empty; but im
> > not sure if its meant to be.
> >
> > Thank you for the response in advanced.
> >
> > Kind Regards
> > James
> >
> >
>
>

Re: Watchdog for GNU Radio

[Kevin Reid]

On Sat, Nov 7, 2020 at 8:03 AM Kopa Rebu  wrote:

> My understanding is that I've to shut down the flowgraph when the failure
> situation is detected, and after that, I have to relaunch it using some OS
> provided facility, right?
>

There are several options:

First, you can call
top_block.stop()
top_block.wait() # every stop() needs a wait()
top_block.start()
For some source/sink blocks, this will cause them to usefully reinitialize,
but I don't think gr-osmosdr is one of them (if that's what you're using to
access your RTL-SDR devices).

Second, you can remove the source block from the flow graph (using
disconnect() to reverse the connect() operations), construct a new one, and
connect that one in place of the old one. This must be done either between
stop() and start() or between lock() and unlock()  (these have almost the
same effects). Also, if the device requires exclusive access (which is true
of RTL-SDR and HackRF), you must make sure the old source block is
destroyed before the new one is created — which can take some careful
dropping of references, if you're working in Python. I believe this option
should be sufficient for your problem.

Third, you can restart the process as you propose. This is the most
thorough and simple solution, but of course means that everything else you
might be doing in that process is reset.

Re: Centos7 installing GNU3.8 via pybombs issue

[Marcus Müller]

Oh, I was skipping past that; I was wrongly assuming you were using
CentOS 8.

Yeah, as Alex said, on CentOS 7, this will be cumbersome. If I was
forced to work on CentOS 7, I'd very much consider a podman or docker
container or simply a chroot to hold a CentOS 8 (or whatever more
modern, really) installation. In the end, if you want to do this
natively on CentOS 7, you're probably in for a bit of manual dependency
installation, pybombs won't be of much help currently, and you'll have
to isolate the newer versions of things that GNU Radio needs from the
older versions of things that your system needs - and then you're
halfway building a container, anyway.

Best regards,
Marcus

On 07.11.20 20:48, Alex Humberstone wrote:
> Dear James,
> 
> CentOS 7 is really really old. I would say that you should ask
> your customer or project leader to allow you to at least use CentOS 8.
> You're just going to have a whole set of challenges and difficulties
> using CentOS 7. Why create more unnecessary work for yourself?
> 
> Sincerely,
> Alex-M-Humberstone
> PhD Student
> Klipsch School of Electrical Engineering
> New Mexico State University (NMSU)
> Las Cruces, New Mexico, USA
> 
> 
> 
> On Sat, 7 Nov 2020 at 08:07, Marcus Müller  > wrote:
> 
> Hi James,
> 
> our software is called "GNU Radio", not just "GNU" :)
> 
> Anyway, the relevant python-click-plugins.lwr is most definitely not
> empty, otherwise your Pybombs wouldn't be calling `yum info
> python3-click-plugins` (it only knows to do that because of that recipe
> file).
> 
> Can you run `yum info python3-click-plugins` manually and check what it
> says? (generally, we're happier about copy&pasted text from a console
> than about a screenshot)
> 
> Best regards,
> Marcus
> 
> On 05.11.20 14:46, J P wrote:
> > Hello,
> >
> > For a project that I am currently doing, i'm required to use GNU3.8 on
> > centos 7. 
> > My virtual machine is using:
> > gcc:9.3.1
> > python 3.6.8
> > pybombs 2.3.4.
> >
> > I followed the steps on GNU website
> > (https://github.com/gnuradio/pybombs#prefixes
> 
> >  >).
> > During the pybombs prefix I'm running into an Error as shown below. 
> >
> > I have looked into the python-click-plugin.lwr which is empty; but im
> > not sure if its meant to be.
> >
> > Thank you for the response in advanced.
> >
> > Kind Regards
> > James 
> >
> >
> 

Re: Problems with GUI Layout

[Marcus Müller]

Hi Joao,

I had to change the subject line of your email to actually contain
something.

So,

On 06.11.20 20:05, j...@phygitall.rio wrote:
> Hello,
> 
> I am new to gnu radio. I installed it in Ubuntu 20.04 through PPA. The
> version installed is 3.8.2.0 (Python 3.8.5).
> 
> Every time I execute a flow graph I receive the following warnings in
> the grc terminal.
> 
> # Start of the grc log #
> …
> # End of the grc log #

Not pretty, but completely unrelated; the Qt GUI blocks don't use GTK.


> Is there something I can do to solve this issue? or is this a bug?

Have you filled in the "GUI Hints" fields in the QT GUI blocks?

Best regards,
Marcus

Ettus Research B205 + Raspberry Pi 4B + GNURADIO

[Jens Hoffmann]

Hi,

it's my intention to use an Ettus B205mini connected to a Raspberry Pi 4 
B (latest model with 8GB RAM) with GNURADIO running on it.


During the first try with the current RASPBIAN OS the complete 
installation seems to be successful but the USRP sink block didn't found 
the B205mini although the uhd_find_device (and related commands) shows 
the correct/necessary output.
After some tinkering, I have decided to use UBUNTU 20.04 (Raspberry 
image) instead of RASPBIAN. But now other problems occur (the USB port 
doesn't detect the connected USRP).


Is anybody in this group with a successful installation of the bundle 
Ettus Research B2xx + Raspberry Pi + GNURADIO and willing to share 
details about it?


Thank you!

Jens / DL1WW

P.S. Related content on the Ettus Knowledge Board is a little bit 
outdated or incomplete.

Re: Problems with GUI Layout

[joao]

Hi Marcus,

Thank you for creating a subject for the email. I completely forgot to fill in 
the subject field before sending the message. I apologize for this.

In a previous message, Nicholas Bruce explained how to fill the "GUI Hints" 
fields of the QT GUI sink blocks. After setting this, everything is working as 
expected, except for the annoying warning messages.

Apparently, from what I researched, a possible solution to solve the warnings 
problem would be to compile gnu radio setting the "WITH_GTK_2_X" parameter to 
"ON"(https://github.com/tum-vision/fastfusion/issues/21, 
 
https://github.com/MRPT/mrpt/issues/627, 
 
). I was looking for an 
alternative solution that would prevent recompilation.


Thank you again,

João

On November 7, 2020 at 6:03:34 pm -03:00, Marcus Müller  
wrote:

> Hi Joao,
> 
> I had to change the subject line of your email to actually contain
> something.
> 
> So,
> 
> On 06.11.20 20:05,  wrote:
> 
> > Hello,
> > 
> > I am new to gnu radio. I installed it in Ubuntu 20.04 through PPA. The
> > version installed is 3.8.2.0 (Python 3.8.5).
> > 
> > Every time I execute a flow graph I receive the following warnings in
> > the grc terminal.
> > 
> > # Start of the grc log #
> > …
> > # End of the grc log #
> > 
> Not pretty, but completely unrelated; the Qt GUI blocks don't use GTK.
> 
> 
> > Is there something I can do to solve this issue? or is this a bug?
> > 
> 
> Have you filled in the "GUI Hints" fields in the QT GUI blocks?
> 
> Best regards,
> Marcus
>

Re: Ettus Research B205 + Raspberry Pi 4B + GNURADIO

[Marcus D. Leech]

On 11/07/2020 07:43 PM, Jens Hoffmann wrote:

Hi,

it's my intention to use an Ettus B205mini connected to a Raspberry Pi 
4 B (latest model with 8GB RAM) with GNURADIO running on it.


During the first try with the current RASPBIAN OS the complete 
installation seems to be successful but the USRP sink block didn't 
found the B205mini although the uhd_find_device (and related commands) 
shows the correct/necessary output.
After some tinkering, I have decided to use UBUNTU 20.04 (Raspberry 
image) instead of RASPBIAN. But now other problems occur (the USB port 
doesn't detect the connected USRP).


Is anybody in this group with a successful installation of the bundle 
Ettus Research B2xx + Raspberry Pi + GNURADIO and willing to share 
details about it?


Thank you!

Jens / DL1WW

P.S. Related content on the Ettus Knowledge Board is a little bit 
outdated or incomplete.

What does:

lsusb

Show when the device is plugged in?

Is there a usrp rules file in /etc/udev/rules.d?   (Or wherever Ubuntu 
20.04 keeps things).

gr 3.8, uhd4.0 and rfnoc

[Dario Pennisi]

Hi,
I've been trying to create and use a rfnoc block for n310 within gnuradio 3.8 
and uhd4.0. I first tried with pybombs but this doesn't not seem to work very 
well and there is no default recipe that works. I then moved to manual install 
from source and got something up using the maint-3.8 and uhd-4.0 branches 
however none of the rfnoc blocks in uhd 4.0 seem to be usable directly in 
gnuradio companion as the yaml files in uhd are not compatible with the yaml 
block files required by grc.

I then moved to master branch of both repositories and this installs with 
gnuradio, some yaml files for some of the blocks in uhd, so I tired compiling a 
fpga with fft block as instructed in the tutorial but the fft would not produce 
output data.

Finally I tried compiling the gain example block out of tree and installed its 
control block both with maint 3.8 branch (that uses swig) and master branches 
(that uses pybind11) but in both cases the block doesn't get recognized when i 
issue uhd_usrp_probe and it gets listed as block#0 regardless of Ldconfig.
I get it listed in grc after I created a second yaml file compatible with grc 
but of course running a graph will fail as it doesn't find the block control 
class, likely because in the installation process I don't see python bindings 
being generated for it, regardless of the binding creation mechanism.

So my questions are:
1) is there any way to use rfnoc in grc as of today that doesn't need manual 
creation of the block.yaml files?
2) why the fft block using the block.yaml definition from gr-uhd doesn't seem 
to work?
3) how do I make oot blocks recognized by probe and grc?

Thanks,


Dario Pennisi