[Hamlib-developer] Re: gnuradio and Hamlib

[Matt E. <ma...@et...>]

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

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

This is way more complex than you think.  Several Master's and PhD theses were
written on the scheduling and threading in GNURadio's progenitor,
Spectra/pspectra.  It was designed to be multithreaded, but certain operations
are single-threaded only, like the scheduler.  Only actual processing is
multithreaded.  Additionally, many of the processing blocks must run in order on
the data (like IIR filters), but not all (FIR filters do not suffer from this). 
At this point, the threading is disabled so there is one less thing to worry
about.

I guess the main point is that gnuradio is many things, to many people :)  We
don't want to change gnuradio internals to be able to use hamlib in one
gnuradio-based app.  Conversely, I wouldn't want you to change hamlib's
internals to support gnuradio.

> > 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'm not sure what FI stands for, but yes, I have the microtune and MC4020 combo.
 That would be a great demo.

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

ok.  And yes, it does sound obscure to me :)

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

Thanks.  i'll check into that.

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

[I'm assuming FI means some sort of IO device, like the MC4020 here...]  That's
a tough one.  I'm more of a DSP and comms guy, so I don't know the intricacies
of shared libraries, linking, plugins, etc.  I'm pretty sure it hasn't been done
yet, but I don't know how hard it would be.  There's not much motivation,
though, since the source code is free.

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

My intention was that GRig could be used unmodified.  I'd like the user not to
be able to tell whether they are using a ft-1000 or gnuradio-based SDR.


Thanks again,
Matt

P.S.  If anyone is interested, I will be giving a talk and demos for gnuradio at
TAPR's DCC this year.  See http://www.tapr.org