Hi Marcus and the folks at Ettus,
I am an extremely satisfied and happy user of your USRP’s. We plan on
buying a lot more USRP’s for our company since it is an outstanding cost
effective platform for testing and measurements.
However if I have to offer some criticism (and I assure you that this is
the only complaint that I have amidst all the good things i have to
say), it is about the threadbare documentation available on getting
started with doing applications - whether that be for GRC, or python
programming for the USRP. I had to google the web for some examples and
this is how I learnt. There has to be a much easier way to getting
started. The folks at Ettus attribute too much intelligence to the
average user if this how they expect people to learn; it is actually a
disservice to Ettus as a company to make it so hard to start using your
products.
Hope what i have said above does not in any way detract from the overall
considerably positive feedback that i would like to convey.
Best regards,
-Vijay
— On Wed, 4/27/11, Marcus D. Leech [email protected] wrote:
From: Marcus D. Leech [email protected]
Subject: Re: [Discuss-gnuradio] GNU Radio conditional operation
To: [email protected]
Date: Wednesday, April 27, 2011, 12:40 PM
On 27/04/2011 12:27 PM, Songsong G. wrote:
Thank you for your answer.
I have one more question,
In that directory, there are lots of python script,
Unfortunately, I’m not good at that language
and I have just learned GNU Radio with GRC
Is that what I wanted now available in GRC?
Generally, custom processing blocks, which is what you’ll likely be
having to do, are written in C++.
In Gnu Radio, the Python is used as a kind of “glue” that sets up and
“manages” flow-graphs, but the
underlying signal-processing elements, and buffer and task scheduling
is generally handled in C code.
The vast majority of those blocks have mappings into Python (via Swig)
to allow the Python
``management` structure to manage them.
GRC emits Python code, using the underlying Gnu Radio conventions and
mechanisms to form a flow-graph.
Blocks you write yourself can be manifested
(via Swig) into Python,
and then manifested
via XML into
GRC.
The XML that GRC uses exists as a way of describing the surface
of a
processing block, and also as a way of
describing the Python code that must be emitted in order to plug the
block into the overall flow-graph.