[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Prototype Hardware for gnuradio

From: John Gilmore
Subject: Re: [Discuss-gnuradio] Prototype Hardware for gnuradio
Date: Tue, 04 Nov 2008 11:22:33 -0800

> nexsdr_source_c() block patterned after usrp_source_c().
> Converted version of usrp_wfm_rcv.py.
> Converted version of usrp_nbfm_rcv.py.

Congratulations on building your own high function SDR hardware!

Just a brief remark on the software.  It's great that you were able
to get it running quickly via replacing "usrp" with "nexsdr" in
various places, but that really shouldn't be necessary.
The "fm radio" high level GUI and signal processing code should
not know or care what low-level radio interface is in use.

> The WBFM application required removal of the subdevice code,
> modification of the tuning code (removed the residual tuning), and
> adjustment of the gain.

The prevalence of the USRP1 led us to be lazy about how GNU Radio
applications are structured.  High-level code like usrp_wfm_rvc.py
have the name and details of the low-level radio interface ("usrp",
subdevice names like usrp_dbid.TV_RX_REV_3, etc) wired into them.  Now
that we have USRP1, USRP2, HPSDR, and your new SDRtrack, this is
becoming more than inconvenient.

All the low level drivers implement the same interface class -- the
rest of the code just needs to know which one to call, dynamically.
The high level GNU Radio software should be altered to receive from
"standard radio input" and transmit to "standard radio output", so
that every application doesn't need to be tweaked just to change the
device used.  The standard radio input would be set in a tiny config
file (probably just a Python source file, unless the all-in-C++
faction wants to provide a parser), kept in your $HOME directory.

Then all the filenames wouldn't start with "usrp", wouldn't need
to import the "usrp" class, etc.  They'd import a class like "radio",
the radio class would open the $HOME/.gnuradiorc file, and
it would import the USRP, USRP2, or whatever other module the
user had selected (manually, or in a small config GUI).

This is how audio works, it's how video works, it's how disk drives
are interfaced.  You don't run sata_mount for your 1.5TB disk drive,
pata_mount for your old 80 GB drive, and usb_mount for your flash
keychain; you just call "mount" and it figures it out.  Modularity is
your friend.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]