On Tuesday 16 September 2008 05:05:37 Tom Rondeau wrote:
> 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
> onl
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 T
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.
*/
Hi,
I tried setting TX frequency using the c++ db branch. Setting the RX frequency
works fine, setting the TX frequency using the python code works as well.
The problem, as far as I could pin it down, is the missing lock. Result from
io_read is: 0xff5b.
Regards,
Stefan
--
Stefan Brüns / B
