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" <mmueller@gnuradio.org>:

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