Re: [Discuss-gnuradio] gnuradio and Hamlib

[Matt Ettus]

Just to clarify a little....

GNURadio is a framework, not really a particular application.  GNUradio is not
just about ham radio done in software.

My goal was to avoid reinventing the wheel (and to avoid writing GUI code...). 
What I was hoping to create was a way for an application to use both GNURadio
and Hamlib.  Hamlib would allow the reuse of user interface frontends, like
GRig.  GNURadio would perform the radio stuff.

The main difficulty, as I see it, is that both environments want to control the
main loop.

Stephane Fillod <address@hidden> said:
> Preliminary note: for me, everything that comes from gnuradio tar ball is
> "gnuradio". I don't know enough about it to distinguish between libs and
> stuff yet.

Stuff in the src/gnu/examples directory are basic apps which demonstrate
gnuradio capabilities. The rest is basically library.  Try to stay in the gnu
hierarchy.

> * question: what is your expection about gnuradio in hamlib?
>   IOW what do you want to do (goal to achieve)?
>   This will help in the design.

I'd like to be able to [easily] have my gnuradio-based app receive commands
from, and return status to a hamlib-based frontend program, like GRig.  Basic
stuff like change frequency, volume, mode, etc.

> * Can you show me sample code for init (with no GUI support)
>   is gnu/examples/fm_demod2_no_gui.cc a good start  ?

That is a good example of a program with no gui, but it requires hardware you
don't have.  The best code to try without special hardware would be audio_scope,
chirp_fft, and mixer.  All of those have gui code, though.

>   Something I can test myself would be great (FI source: file or sound
>   card).
>   All we need is objects initialization, source select: acquisition card or
>   sound card, set_freq/change_freq, set_mode_FM.
>   that's enough to start with.

I can try to make a simple example program.  The easiest would be something
llike the mixer program, without the gui.  A simple demo would be to have hamlib
change the frequency instead of the gui.

> Note about gnu/examples/fm_demod2_no_gui.cc: the second FM demodulation may
> appear as a SUB band controller?

Not sure of the question here.  The program can demodulate 2 different FM
stations at the same time.

>
> * Am I wrong if I assume the output of gnuradio under Hamlib will always be
>   a sound card?
>   Or do we have to be output agnostic (and let gnuradio manage that)?

I wouldn't worry about the output.  Sometimes output will be audio, sometimes
data, sometimes IF samples, etc.

> * as far as I understand, gnuradio is only a toolbox/framework. I mean,
>   there's no defined API to select say, FM mode.
>   You have to do it by yourself. So I guess this has to be done in the
>   gnuradio backend unless some third party library already exists?

Right.  GNURadio is just a framework and library for designing signal processing
applications.  Making a radio, in the conventional sense, out of it is only one
possible application.

> * Hamlib backend would be obviously limititative because of API, and no
>   access to fine-tune parameters (rig_set_conf may help though).
>   SDR will only be seen as regular radio (advantage: re-use existing apps)

That's all I'm really looking for -- setting frequencies, volumes, gains, modes,
etc.

> * Would it be possible to hide the different FI sources to Hamlib ?
>   I mean Is there an abstraction layer in gnuradio that hides these
>   details, or does the application code has to know about the source?
>   IOW, do you have to recompile gnuradio/app if you change source?

Not sure of the question.

> * questions: is gnuradio pthread-safe (I've seen -D_REENTRANT, what about
>   the code itself)? does gnuradio use pthread by itself in constructors?
>   It looks like yes (VrMultiTask), but it is working fine?

some of it is thread-safe.  It should all be, eventually.

> * Implementation hints 2:
>   - gnuradio will be the backend name.
>   - each different VrSource will be a "rig" model on their own, belonging to
> this backend.

This is not really what I was thinking.  I was thinking more along the lines of
I write a program which may use any number of sources, sinks, and other blocks. 
In the main loop, between iterations, I can call methods on those blocks to
change parameters, like frequency (see src/gnu/lib/gr/GrFreqXlatingFIRfilter.h
for example).  Somehow, the control from the hamlib program needs to cause a
call to these methods.

>     So far, can you help me list the available VrSource's?
> MC4020+microtune_eval_board
>     Is there already libaudiofile support (reading from file)?  Input from
> sound card?

The VrSource's are irrelevant to this.

> * Have you heard already about soundmodem?
>   This is a software modem by Thomas Sailor for use on AX.25 packet networks.
>   It can make use of MMX, sound input/output: OSS/Free under Linux,
>   /dev/audio under Solaris and DirectSound under Windows
>   http://www.baycom.org/~tom/ham/soundmodem/

Seen it. Very cool, but not nearly as big a scope as what we're doing.

> * note: is it possible to put your doxygen generated documentation on the web?

That would be a good idea.

> * cheap advice (easier to give than to do :)
>   get away from asm code: use some SIMD library (like libSIMD
>   http://libsimd.sf.net )

libSIMD is not at the point of usefulness yet -- not even close.  We have
implemented general C++ code for all functions.  MMX/SSE/3DNOW are only used in
specializations.  We're able to get a tap per cyle

Matt