Forum: GNU Radio USRP DBID Mods for New Daughterboard?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-04-01 22:13
(Received via mailing list)
Suppose I wanted to create a new daughterboard for the USRP; then what
is entailed on the host software side to allow GNU Radio robust access
to using this daughterboard?  At this time, this is a thought
experiment: I've been asked the question, done a little research, and
don't have a good / clear answer yet.

I'm trying to figure out if there's a robust way to incorporate the
necessary info into the dbid without integrating my board's info into
the GNU Radio trunk.  What I'd ideally be able to do is create some
classes that inherit from db_base, then add those to an internally-
kept database so that when I instantiate the usrp it can find the
correct info for my daughtercard.  The usrp instantiation would be
exactly as it currently is, e.g., I could just use one of GNU Radio's
USRP examples; the GNU Radio / daughtercard combination would "just
work" for those who have my special dbid code.

Looking through usrp_basic.cc, I find the method "init_db" -- which
seems to be the key -- which in turn calls "instantiate_dbs".  This
function is found in db_boards.cc, and does not allow for any dbid
outside those provided by the usrp_dbid.dat file (which is used to
generate the usrp_dbid.[h,cc,py] files).  For my theoretical
daughterboard, the "instantiate_dbs" function will return a
std::vector of an sptr to a basic_rx or basic_tx -- which obviously
won't work correctly with the new daughtercard.

The only way I can determine, using the current GNU Radio trunk, is to
create a new class that inherits from usrp_standard_rx and _tx, which
overloads the "init_db" method to provide a different means for
determining the dbid info .. by calling some function other than
"instantiate_dbs" or maybe more robustly creating the daughterboard
sptr.  This seems like a lot of work, since it requires a whole new
SWIG interface and Python function call ... and, I can't just "reuse"
the current ways. This doesn't meet the way I'd ideally like to have
this system work, but it's the only way I can figure out on short
notice.

Thoughts?  Suggestions?  TIA! - MLD
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-04-01 22:29
(Received via mailing list)
On Wed, Apr 01, 2009 at 04:12:35PM -0400, Michael Dickens wrote:
> Suppose I wanted to create a new daughterboard for the USRP; then what
> is entailed on the host software side to allow GNU Radio robust access
> to using this daughterboard?  At this time, this is a thought
> experiment: I've been asked the question, done a little research, and
> don't have a good / clear answer yet.

Michael,

I think the easiest way would be to add a free function to db_boards.h
that allowed you to register additional (dbid, factory) pairs to an
internal data base searched by instantiate_dbs.  You'd have to
register your new daugherboard(s) before instantiating usrp_standard_*

Maybe something like:

struct db_factory {
  virtual db_base *operator()(usrp_basic_sptr usrp, which_side) = 0;
}

void db_register_dbid(int dbid, db_factory f);


Eric
This topic is locked and can not be replied to.