Stefan Bruens wrote:
Found the bug, at least the first:
db_flexrf.cc:
-------
flexrf_base_tx::flexrf_base_tx(usrp_basic *usrp, int which, int _power_on)
: flexrf_base(usrp, which, _power_on)
{
/*
@param usrp: instance of usrp.sink_c
@param which: 0 or 1 corresponding to side TX_A or TX_B respectively.
*/
d_usrp = (usrp_basic_tx*)usrp;
d_tx = true;
int d_spi_enable; // <-- shadows class member!
if(which == 0) {
d_spi_enable = SPI_ENABLE_TX_A;
}
else {
d_spi_enable = SPI_ENABLE_TX_B;
}
------
At least, the board is able to tune to the right frequency, and I was able to
send a few times.
Unfortunately, after running a few other (python) examples, it stopped
working, so I think, the python code modifies some registers and the c++ code
is not able to set this registers to working values.
Disconnecting power from the USRPs did not help - any hints?
Stefan
Stefan,
Thanks, that was indeed a bug. It has been fixed in my branch as of r9682.
This is also the first time that I've had the equipment in my new place
to test the transmitters, so, frankly, I'm impressed that this is the
only bug so far.
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
