-----BEGIN PGP SIGNED MESSAGE-----
Actually, I don’t think this, as it is right now, would be a very good
While GRC files are great for usability, they need to be compatible
with the installed GR version. Many of the “cool” features are work in
progress, so that block names change, blocks disappear, better
solutions etc are written.
Furthermore, the 3.6 to 3.7 translation happened not so long ago, so
that there are lots of GNU Radio programs and .grc files floating
around that don’t work with the recent GR version. GRC has just (like
2 weeks ago) learnt to gracefully work with “missing” blocks, and
there has been a lot of confusion about “broken” grc files… That’s
why I’m a little sceptical when it comes to a directory of standalone
Maybe that’s somehow related to the way I use GRC: It’s really great
for clicking together a flowgraph, but at some point you realize that
you need to do something based on some complex condition; that’s where
you start to write your own blocks or extend your flowgraph with
python logic; .grc files – to me – are mostly intermediate steps
towards a finished solution. If you can pack the generated blocks with
the .grc, that’s fine, you’ll get a great, useful, easy to understand
and explain graphical application; if you only deliver the .grc, the
user won’t have your blocks, and thus, no usable application.
That being said, a directory for “useful” flow graphs would be nice.
They do need however a compatibility table or something of the like.
For the very basic flowgraphs (e.g. osmosdr src->file sink) I think
experimentation is the key to success; for the very cool applications
that you can do with a out-of-the-box GNU Radio installation, there
are lots of examples provided with the GNU Radio source code, always
conveniently stored under examples/ of each module.
gr-digital has a lot of excellent examples of the usage model of GRC I
described above: When you look at the OFDM examples, you’ll find GRC
files containing comprehensive OFDM RX and TX applications. But those
were not clicked together from blocks that were already existing
before – these blocks were written with GRC in mind, using all the
modern, cool GNU Radio features, introducing really versatile PDUs,
fully embracing messages, etc. Any older version of GNU Radio can’t
deal with them – it would simply be lacking the new blocks and tools
that make up these flow graphs.
- From my point of view, having a directory of projects, like CGRAN
means to be, makes a lot of sense. Exchanging .grc files often makes
Having just written that, it seems to me that as a directory we should
probably really be going down the pyBOMBS route – having easy to
install projects in a comprehensive directory containing .grc files.
On 30.03.2014 16:20, Fernando P. wrote:
Also, nowadays many developers write a pybombs recipe when they
mailing list [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----