[Hamlib-developer] gnuradio and Hamlib

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

Hi Matt and others,


Here are some thoughts thrown altogether about developping 
a gnuradio backend for Hamlib. For those not aware, Hamlib is a radio
control library, that would serve as a useful middle layer to let nice
GUI control gnuradio.

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.


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

* Can you show me sample code for init (with no GUI support)
  is gnu/examples/fm_demod2_no_gui.cc a good start  ?
  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.
Note about gnu/examples/fm_demod2_no_gui.cc: the second FM demodulation may
appear as a SUB band controller?

* 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)?

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

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

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

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

* Implementation hints:
  - compile gnuradio with -DTHREADS
  -  in gnuradio_init, do some object allocation, etc.
  - in gnuradio_open, do the chain&connect and VrMultiTask->start. -DTHREADS
renders ->process method useless
  - in gnuradio_close: VrMultiTask->stop
  -  in gnuradio_cleanup: delete objects ...

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

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

* comment: gnuradio will raise some latency issues. Maybe nothing to do much
  with Hamlib, but just to keep it in mind when we encounter FIFO's, etc. 
  It may raise some design issues.

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

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


There's no hurry. We have time to devise something that works.


Cheers,
Stephane - F8CFE