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

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

Quoting Stephane Fillod <f4...@fr...>:

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

I see.  It looks like you want the hamlib plugin to be the actual radio.  I
guess that's reasonable.

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

Great.  

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

I checked out from cvs, but configure is missing.  I tried ./autogen.sh, but I get:

[matt@localhost hamlib]$ ./autogen.sh 
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
/usr/bin/m4: configure.in: No such file or directory
kylix/Makefile.am:1: invalid variable `dist_sharedstate_DATA'
autoconf: configure.in: No such file or directory
./autogen.sh: ./configure: No such file or directory




On 2 totally unrelated notes...   

1> It's been about 10 years since I did any RPC stuff...  How is security
handled?  I wouldn't want to put a rig or rotator on the net only to have it hacked.

2> Has there been any thought/work on alternate pathways for audio/signals?  I
guess I mean that while with my FT-1000 I might want all audio to go through the
standard speaker/mike,  what happens if I want to pass rig audio through the PC
soundcard for processing?  Or what if I wanted to send the audio from my remote
rig over ethernet back to the point where I am operating grig over rpc?

Matt