Hi Matt,
Quoting Matt Ettus <ma...@et...>:
> Hi. I'm a developer on GNURadio (
> http://www.gnu.org/software/gnuradio/gnuradio.html ), which is a free software
> defined radio project. I'd like to use hamlib (and grig with it) for the user
> interface to one of the radios I've designed with GNURadio.
Geeez, I can't believe it. Couple of months ago, when I saw gnuradio
poping up on gnu.org, I thought, these guys will need a User Interface,
and Hamlib would fit very well with their approach.
At that time I was busy, I didn't even bother to send you a mail to let you know
about Hamlib. That's why I'm very pleased you too got the idea.
Excellent, I like it.
And IMHO, SDR is really an exciting area of innovation for ham's,
with a bright future yet to invent.
> Since there is no serial connection, I was hoping to use a network
connection.
> After going through the code, all I see is an RPC backend. Is there a
straight
> IP connection available, or is that my only choice?
Hamlib is not dedicated to serial connections. For example, it supports some
Winradio receiver ISA cards. Software radio will do as well!
>
> If I read correctly, rpc.rigd creates a daemon which talks to one of the
regular
> backends. This is how I picture it --
>
>
> frontend (i.e. GRig) --> hamlib RPC backend ---INTERNET
>
> and on another machine
>
> INTERNET---> rpc.rigd ---> hamlib radio-specific backend
>
> Is this correct?
Yes, this is absolutely correct.
> Is rpc.rigd the best place to look for info on writing
> an RPC driver?
Well, yes, rpc.rigd is the best place to look for info on writing
an *RPC* driver.
However, if I understand your need correctly, then there's no reason to bother
with RPC at all. RPC is just an indirect (remote) procedure calling machanism.
You have to understand where the Hamlib's layers are. The RPC "backend" is a
pseudo backend, a kind of trick that adds remote access to any real backend
as a bonus.
All you need to do for gnuradio, is to create a new backend (let's call
it "gnuradio"), and provide set_freq/get_freq, set_mode/get_mode methods
and so on. In the set_freq method for example, just call the appropriate
function of gnuradio and link the backend plugin against your library.
I guess gnuradio is a little more complex to run, like you need to have the
control over a main loop to do the DSP stuff. But this can be worked out.
Practically, you may end up with running gnuradio from rpc.rigd,
to make it persistant and simplify threads, but the gnuradio *backend*
won't have to know about RPC.
Sorry I won't be able to play with gnuradio because I don't have a computer
with PCI slots (laptop), but I'll give a look at the source code anyway
so we can speak the same language, and help you writting the gnuradio backend.
It's going to be fun!
Cheers,
Stephane - F8CFE
|
