Re: [Discuss-gnuradio] Hamlib and microtune eval board

[Eric Blossom]

On Wed, Nov 13, 2002 at 11:51:15PM +0100, Stephane Fillod wrote:
> 
> Hi there,

Hi!

> 
> I try to see clearly how Hamlib could interact with GNUradio.
> So far, I see 2 ways:
> 
> 1. GNUradio uses Hamlib to change the frequency of the tuner generating
>   the IF. IOW, make a "hamlib backend" out of the microtune_eval_board
>   class.
> 
> 2. Hamlib implements a real SDR (using gnuradio lib)
> 
> At first, when Matt contacted me, I only thought of 2. But we can have
> 1. for gnuradio applications (eg. fm_demod2.cc), and also 1.+2. for Hamlib 
> applications like grig.
> 
> So I have some questions to implement 1.:
> * What is the parallel port pinout of the microtune eval board? Is there
>   any protocol documentation ? As I understand, this is
>   bit-banged I2C. 

I'll dig it out and send it in a separate message.  The board has a
pretty screwy interface, and is expensive also (about $500 US).  The
choice of pin out is definitely not convenient for /dev/lp access.
Personally, I think a better idea is to turn a new board that includes
a revised pin out, on board generation of the -5V required for the
coax driver, and on board additional I2C trimdacs to control the RF
and IF AGC.

It also may make more sense to wait until the hardware hackers finish
the USB 2 peripheral, and then build a daughter board that glues just
the 4937 module to the USB 2 board.

>  Is it possible to use Linux kernel i2c-dev support?

I think that the kernel i2c-dev talks to the i2c bus on the
motherboard.  If that is the case, it's no good for us.


> If not, I would prefer using the ppdev than direct inb/outb which
>   requires root privileges (on x86 for ioperm).

Me too, but the pin out is such that you can't wiggle the lines you
need with user mode access.  I may have missed something.  Take a look
at the docs I'm sending and see if you can't find a way to make it
work without root privs.

> * talking about class microtune_4937 (src/gnu/lib/grio/microtune_4937.h):
>   - IMHO, set_RF_freq should only return when PLL is locked.
>     Is the pll_locked_p method really needed?

Blocking isn't always the right answer.  Other processing may want to
continue while the PLL settles.  It's open for discussion.  I don't
think that in our current implementation we even look at the locked bit.

>   - get_output_freq: this is the center frequency of the IF, right ?
>     I'm a bit worried, because if I replace the the microtune_eval_board
>     class and its set_RF_freq by rig_set_freq(), Hamlib has no such
>     information about output_freq.

The information seems to be required, because without it, how does the
rest of the software radio know where to look for the signal?  Does
rig_set_freq assume that the signal is converted to baseband?

If you look at fm_demod2.cc, you'll see why we need the info, and how
we use it.

>  With the same receiver, some people 
>     would tap the AF with a sound card, some other may steal the rig 
>     internal IF using an acquisition board, etc.  Do you see what I mean?

Yep, but in either case, the people need to know where the center of
the IF ends up over in software land.  When I say tune the rig to X,
and I'm sampling at Y samples/sec, where is X in the digital domain?
It gets a little more complicated if you consider band pass sampling.
A different abstraction may work better.  This is just what I came up
with.  If you've got another idea that accounts for all the behavior,
please feel free to let me know.

> For the moment, I plan to add support in Hamlib for the
> microtune_eval_bord. This way, a simple C program will be able to
> rig_set_freq() to set the frequency. Note, I don't have the hardware so
> I'll ask one of you to test it.

OK.

> Then, I'd like to go next with a real case I can test myself. Do you think
> it's possible with a sound card (44KHz sampling in mono, so 22KHz real
> bandwidth) to make the src/gnu/examples/nbfm.cc example to work?
> The "IF" source would come from the AF of a regular transceiver (no idea 
> of its bandwidth, I hope more than 3KHz). Do you think it's achievable?

I think it's going to depend on the design of your transceiver.
On some, the conversion to AF and FM demod are implemented in the same
IC, so the signal you're looking for may not be available.  A look at
the schematic or a little poking around ought to answer the question.

Eric