Re: [Discuss-gnuradio] some progress and some questions

[Matt Ettus]

Quoting Joseph DiVerdi <address@hidden>:

> I am pleased to report some good progress in setting up and using gnuradio
> which has, in turn, spawned a few questions. In no particular order:

Great!

> aumix and aumix-X11 are pretty snappy and useful programs for controlling
> sound cards under ncurses and X windows environments, respectively. I've used
> them to "tame" my sound card so it behaves sensibly (mostly). Source is
> readily available so inclusion of initialization and control code into
> home-rolled applications is an option.

Yes, I'd like to get that code somehow into GNU Radio.  It would make things
much more convenient.  In the mean time, I think you can save a setup file from
the mixer once you have it as you like, and then send that file back to it, so
you don't have to do it manually every time.

> The "home-rolled" VLF complex frequency translator (CFT) is doing its job
> very nicely. FWIW, it translates a 20-60kHz (balanced) input into a complex
> pair of (balanced) signals 0-20kHz (although the sound card is single-ended).
> The LO generator is a crystal controlled, TTL walking ring counter with final
> resynchronizer providing four phases of 40kHz which deliver accurate,
> balanced, quadrature drive to the mixers. The LO generator can operate up to
> 40MHz without modification. Higher LOs are available with this scheme using
> different logic families. The mixers are commutating mixers based on CMOS
> 4PST switches (fully balanced, of course). These mixers are limited to
> operation to only a few MHz but other mixers are suitable for higher
> frequencies. A single pole of low pass filtering at 25kHz on each channel
> limits the signals emitted from the XFT and delivered to the sound card.

Sounds like a very nice clean design.  Perhaps a posted schematic on Wiki would
help others in the same situation.

> I've stuck with the straight forward scheme of using the examples directory
> as my working directory and modifying Makefile.am when new programs are
> added. It works well and is stable.

Good, although I must again suggest you try using Python.  It will make your
life much easier.  Right now not all blocks are wrapped into Python, and there
really isn't a good fft or oscope block yet, but once those are there, I can't
see a reason not to use python.

> It looks like
> some of the functionality that I need is not available, e.g., FT processing
> without an attached display (GrFFTSink without the display),

Very true.  This should be coming soon, especially now that we are looking to do
the displays in Python, and to deprecate the use of Qt in favor of Wxwindows.

> real<->polar
> representation conversion,

That should [partially] be there.  You can use GrReal, GrImag, and GrMagnitude. 
GrPhase is not there yet, but should be simple, and a block to create complex
numbers is not there yet.  Also, take a look at GrArbFunc.  I find it very
useful, but there are no examples of its use.  Let me know if you have problems
with it.

> frequency domain "scope" display.

Not sure what you mean here.  Not GrFFTSink?

> Alternately, I
> just haven't yet found them yet. I will try my hand at writing some modules
> and offering them to the repository.

That would be great.  I can offer suggestions and help if you need it.

> Is there a "road map" noting the characteristics of the various families,
> e.g., Gr vs. Vr, gr_, qa_, atsc_, etc.?

Gr stands for GNU Radio, and all the new blocks we create fall in that category.

Vr blocks are originally from the old pSpectra/Spectrumware code.  Any ones that
you see used in the examples directory should be fine, but many of those not
used (even those not in a "needs-work" directory may not work anymore due to
api changes.  Point these out if you need to use one.

qa_ files are for QA or quality assurance.  The idea is that you would write a
corresponding qa file to perform unit testing on each regular file to automate
the testing process.  There aren't always qa_ files for each other file that
there should be.  I haven't been good about keeping up with this.

gr_ files are more library functions, but are not gnuradio blocks.  Very often,
these are simply wrapped in a corresponding Gr file (see the GrConvertSF and
gr_convert_SF files for example).  The atsc_ files are similar, except they are
mostly specific to ATSC (HDTV), and might need some changes to make them more
generally useful.

Matt