[Hamlib-developer] Re: gnuradio and Hamlib

[Stephane F. <f4...@fr...>]

On Mon, Jul 01, 2002, Matt Ettus wrote:
> The main difficulty, as I see it, is that both environments want to control the
> main loop.

Well, not really. Hamlib can be seen as a utility library. It does not 
need to control the main loop. However, the user application linked
against Hamlib may want to control it, e.g. grig or any GUI.
That's why it would be nice if the gnuradio backend would not require 
to grab the main loop.
And this is possible, provided gnuradio library is compiled with -DTHREAD.

 
> > * 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.

Alright, seems pretty feasible. Since you're going to be first "user",
what is your FI source ? Is it the MC4020+microtune_eval_board ?

I understand that you will most probably not use only this source, 
and the backend will serve as a lab rat, but Hamlib needs at least 
to release some working skeleton. So which ever is fine. Then we'll 
be able to clone this "model" (i.e. source) to other models
within the backend.  
If this terminology sounds obscure to you, don't worry, as soon as code 
will show up, this will make sense.

> > * 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.

I've ran them, nice. The code is pretty simple, and I can see what's the
essential part. I should be able to make a initial draft out of it.

Note: there's missing some checking against fftw existence in configure.in

> > 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.

In high-end rigs, there can be two indepedant receivers, a MAIN controler 
and a SUB band controler. Hamlib has support for such rigs.
So the question is not really a question. gnuradio will fit nicely, 
cool :^)


> > * 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.

okay, however this will have to be setup in Hamlib through some kind of
interface. And that's what I try to think forward.
Anyway, I see already how (set_conf).


> > * 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.

Okay, I'll try to put it another way.
Imagine you have everything in binary form, the user application, the Hamlib
(frontend + backend), the gnuradio library. Now, someone develops
some code to support a new FI source. Does gnuradio has an abstraction
interface (at binary level) to support this new FI by just dropping the new 
"lib" with recompiling everything.

Actually, Hamlib is able to do this.

If you're still not sure about the question, don't worry. I'll find the
answer sooner or later by reading the code :)

Note: seeing  eb->set_RF_freq and carrier->setFrequency does not look
	promising :(

> > * 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.

Good.
IMHO, we should use -DTHREAD for gnuradio, this would simply remove the
need to call m->process(), no more main loop, and everyone is happy.


> > * 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.

Hmm. Please correct me if I'm wrong. IOW, you're not gonna use Grig right 
out-of-the-box. Your idea/need is to take Grig as a base, and hack it
specifically for gnuradio extension, in such a way that may not work
with a stock GRig. Right?
(I'm a bit exagerating, but this is to better understand what interfaces
will be needed in the backend).


-- 
Stephane