How do I properly disable/enable the WBX receiver with UHD?

I am testing the program on a USRP1 w/ WBX dboard and UHD. My
is to disable to receiver while I am transmitting, and then re-enable it
once I’m done. I looked at db_wbx_common.cpp and found the enabler
functions. Each of these programs a few GPIO bits. Using that as a guide
was able to disable the receiver, but after I re-enabled it I didn’t get
more packets.


db_iface.set_gpio_out(UNIT_RX, RX_POWER_DOWN, RX_POWER_UP |


db_iface.set_gpio_out(UNIT_RX, RX_POWER_UP, RX_POWER_UP | RX_POWER_DOWN)

UNIT_RX, RX_POWER_DOWN, and RX_POWER_UP are set correctly as in the
reference code. I verified that the bits were being set correctly by
checking get_gpio_out() before and after I called set_gpio_out(). I’d
to do this in Python if possible.

Now, I know this may not be the correct method of doing this, so I ask

Using a USRP1 w/ WBX dboard and UHD, what is the proper way to disable
then re-enable) the receiver?

Thanks for looking!


Using a USRP1 w/ WBX dboard and UHD, what is the proper way to disable (and
then re-enable) the receiver?

I usually don’t think to disable the receiver. Running the transmitter
on demand and always running the receiver is a fine model of use.

Perhaps you could shutoff your demodulator when you transmit? Or reject
the echo’d packets in a mac layer?


On 03/06/2011 12:17 PM, Josh B. wrote:

Also, doing this is not going to be daughterboard-agnostic–not all
daughterboards can have their RX analog chain disabled this way, as
far as I know, and also, does the RX chain “forget” its previous
programming across such a power-down/disable operation? If it does,
then you have the added latency of re-configuring the analog hardware
back to where it was before you shut it down.

A better approach is to simply “ignore” whatever you’re receiving while
transmitting–either by using a valve, or a x0 multiplier somehwere
in the RX chain, which will effectively cause the demodulator to not
see any useful signal.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs