Re: [Hamlib-developer] Re: gnuradio and Hamlib

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

Hi Matt!

On Wed, Jul 03, 2002, Matt Ettus wrote:
> > 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.

Problem of vocabulary. When I say FI, I mean a tap, a sampled source. What
is the best word anyway?
About the microtune and MC4020, I'll need some specs, like the bandwidth
of the FI (around 5MHz?) and the frequency range of the tuner.

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

Okay, so we have a dilemma about the main loop. Either GRig, Hamlib, or
gnuradio will have to suffer a (little) modification. Explicit main loop
for GRig and Hamlib or -DTHREAD for gnuradio.
A temporary solution would be to put the main loop in a modified
rpc.rigd daemon. We'll see.


Allright Matt, I have good news for you. I have just checked in an initial
gnuradio backend. It does not MC4020 yet, but there're should be enough
for you to see if I'm on the right track.

From a fresh checkout, add the --with-gnuradio to autogen.sh (after
doing chmod +x on the script). For the build to work, you'll have to put
libgnuradio.a in the gnuradio subdirectory (sorry, libgnuradio.la is
still not suitable for use, I'll explain you why in a future mail),
and have gnuradio-0.3 in the same parent directory as your hamlib
checkout. Having gnuradio installed in /usr/include and /usr/lib should
work also. And of course, libfftw must be already installed too :)

Let me know if you encounter any build problem.
I've provided a simple gnuradio/testgr program to be hack. Right now, it
should display a GUI with a scope, but dies with segfault:

  (fillods@charybde:gnuradio)$ ./testgr
  could not load logo file '/dev/null'
  testgr:hello, I am your main() !
  rig:rig_init called
  rig: loading backend gnuradio
  gnuradio: _init called
  rig_register (2001)
  gr_init called
  rig:rig_open called
  gr_open called
  VrNullSink cachedSize = 131072
  VrNullSink.setup[0x80869e0] 131072 freq 5e+06 (0.026214 sec)
  GrFFTSink cachedSize = 65536
  GrFFTSink.setup[0x8087cc0] 65536 freq 5e+06 (0.013107 sec)
  VrSource.setup[0x8086950] 500000 freq 5e+06 (0.100000 sec)
  Warning: could not allocate more than 33554432 bytes for shared memory
  buffer.
  VrSource output bufferSize = 4194304 (0.838861 sec)
  gr_get_vfo called: VFOA
  Erreur de segmentation

If I comment out line 84 in testgr.cc priv->m->process(), then I get the
GUI, and set_my_freq is called correctly. I must have messed up
something in the source and sink wiring.
Matt, can you have a look and tell me what I've done wrong?
BTW, the "Warning: could not allocate more than 33554432 bytes ...."
looks suspicious.

As a final note, yes, for now, this backend does nothing useful. Source
and sink are fake. And some data structures have to be better tought
(esp. the gnuradio_priv_data).
This first release is only to devise the glue between Hamlib and gnuradio.


> 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

Hey, that's great!
If only I were still in AZ, I would have loved to attend!


Cheers,
Stephane


P.S. and see you in the contest "Rallye des points hauts" (kind of field 
     day on 2m and up) for those in Europe!