Re: [Discuss-gnuradio] Non Graphical Use of gnuradio Tools

[CEL]

Hi Martin,

arguing that this is unrelated to osmocom, but relevant to GNU Radio:
I'm CC'ing the discuss-gnuradio mailing list [1]; I'll recommend
following up there (and taking osmocom-sdr out of CC: when doing that),
unless someone else sees an argument for keeping this discussion here.

So, GNU Radio as a framework doesn't set any constraints on what the
scheduler and blocks do to stdout; especially, the default logger
writes to stdout, so, no matter how you do it, putting the output onto
stdout doesn't work out; it's a shared resource across all components
in GNU Radio.

> Unix and to a lesser degree, DOS handled input and output
> logic elegantly with <, >, | and even tee when one sends output
> to multiple files and unix just turned 50 this Summer so it's
> doing something right.

Yes, but you can only have graphs that are paths this way. GNU Radio
allows for arbitrary cycle-free graphs. So, this only solves a small
subset. It's a mature solution, but for a much smaller problem space,
i.e. not generally applicable to GNU Radio. You put this very nicely!
You're saying:

> … kind of text-based way to string those python GNU
> modules together

and that's the whole point: Unix shell piping can create *strings* of
processing steps. GNU Radio can do more than that – thus, we never
implemented something different. 

> Is there any kind of text-based way to string those python GNU
> modules together to cause them to work as they do when
> connected using GRC?

I'd argue that GNU Radio's python interface allows you to execute

top_block.connect(source_block, processing_block1, processing_block2,
sink_block)
top_block.run()

so, that's a pretty text-based approach :)

Don't forget that it essentially doesn't matter to your OS whether you
run a bash script or a python script – and in this case, python has the
tools that bash is lacking to create complex flow graphs.

So, what to recommend?

First of all, you don't *have* to use GRC to create your flow graphs.
Many of us do, because it gives you kind of a graphical representation
of the Python program that GRC generates and thus is kind of self-
documenting, but really, just write Python :) You'll find that you can
read the flow graph programs that GRC generates pretty well, and base
your programs on that.

No matter how you set up your GNU Radio flow graph, it's a very valid
use case to want something like

python flowgraph.py | grep "alert" > warnings.txt

you can actually do that by

/bin/bash
TEMPDIR=$(mktemp -d)
mkfifo "${TEMPDIR}/fifo"
python flowgraph.py --filename "${TEMPDIR}/fifo" &
grep "alert" < "${TEMPDIR}/fifo" > warnings.txt

The magic happens in your flowgraph, where you'd add a "Parameter"
block to add your "--filename" option, and use that option for the
file name in a file sink :) 

Hope that helps,
Marcus

[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Sun, 2018-08-19 at 13:47 -0500, Martin McCormick wrote:
> If there is a better mailing list for the following question, I will
> gladly take
> it there.
> 
>       I want to use as much of the gnu radio project as
> practical but the graphical way to string various modules
> together isn't terribly useful for computer users who happen to
> be blind.
> 
>       Unix and to a lesser degree, DOS handled input and output
> logic elegantly with <, >, | and even tee when one sends output
> to multiple files and unix just turned 50 this Summer so it's
> doing something right.
> 
>       Is there any kind of text-based way to string those python GNU
> modules together to cause them to work as they do when
> connected using GRC?
> 
>       This could very well be a dumb question as I have only
> scratched at python a few years ago and what I am talking
> about may be similar to a Makefile which is what you use to refer
> to a bunch of C modules that might be in a program.
> 
>       Anyway, I sure hope there is something else out there
> that accomplishes the same job.
> 
>       I have played with the Realtek, RTL2838UHIDIR and it does
> surprisingly well on analog signals so it's time to string some
> of those modules together and try some digital decoding.
> 
> Thanks for any and all constructive suggestions.
> 
> Martin McCormick WB5AGZ

smime.p7s
Description: S/MIME cryptographic signature