On Sun, Nov 1, 2009 at 6:13 PM, Alexander Chemeris <[email protected]> wrote: > > Could any of GnuRadio developers remove this assert? > > usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int, > double): Assertion `dac_rate () == 128000000' failed. > > It's no longer valid when you reclock your USRP and just makes > it impossible to use libusrp in this case. >
Sounds reasonable to me. > I'm now trying to make GnuRadio usable with OpenBTS without > patching of GnuRadio and this is show-stopper for me now. > > PS Whom should I contact with more re-clocking related fixes? > To date no Python examples seem to work with re-clocked USRP > without patching. I'm seeking for a way to make them working > without too much changes. Probably USRP FPGA frequency can > be set from environment variable? Is there any nicer way to do this? > Most gnuradio development occurs with git, so the easiest way to get changes accepted upstream is by generating patches against the master branch at: http://gnuradio.org/git/gnuradio.git master Patches or pull requests from a published repository clone can be submitted to the patch-gnuradio mailing list. I currently work with both openbts and gnuradio, so I can assist with host side re-clocking or git issues. I'm still getting setup on the hardware side, but as a start for testing I created an openbts branch in my repo at: git://github.com/ttsou/gnuradio-ttsou.git openbts Viewable at: http://github.com/ttsou/gnuradio-ttsou/tree/openbts For your last question, using the mid-level interfaces in usrp_basic may be more appropriate for your needs. Thomas _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
