On 09/15/2012 01:33 AM, Josh Blum wrote: > The TX GPIO setting kicks in when packets sent into the USB. You can > override the GPIO setting though with the dboard iface (all swigged up > into python as well) > http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html My revised FPGA design always advertises that it has space in the transmitter buffer, that the buffer never underflows, and that it is never empty. This should force the ATR mechanism to keep the transmitter on, since there is always data to transmit. The signal that the master_control.v block uses to determine whether or not there is data to transmit, tx_empty, is a constant 1'b0. If I read the logic right, this should satisfy the ATR. I am hesitant to use the GPIO interface without a good example of what I'm trying to do, since I've read that the GPIO controls can burn up the USRP.
The culprit responsible for turning the transmitter off periodically is in uhd/host/lib/usrp/usrp1/io_impl.cpp line 275, which shuts off the transmitter if nothing has been sent to the USRP recently. I can get around this by sending a stream of 1s to the USRP, which are unceremoniously and deliberately discarded by the FPGA. Debug logs show that the host is instructing the transmitter to enable (i.e., via usrp_tx_enable(true) in fx2_ctrl.cpp). As expected, the daughterboard transmitter now turns on. The USRP only transmits a pure sinusoidal carrier at the transmitter's center frequency, however. It should be transmitting chirps, and either the chirp generator isn't working or the signal is not making it to the daughterboard. This exact same FPGA image works perfectly with libusrp. I'm not sure what has changed with the interface. As far as I know, for the USRP1 the standard UHD FPGA image is identical to the libusrp FPGA image. I'll write some debugging functionality for my FPGA image and let you know what I find. Colin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
