[Top][All Lists]

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

[Discuss-gnuradio] USRP DBID Mods for New Daughterboard?

From: Michael Dickens
Subject: [Discuss-gnuradio] USRP DBID Mods for New Daughterboard?
Date: Wed, 1 Apr 2009 16:12:35 -0400

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

reply via email to

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