I am trying to update some legacy (gnuradio 3.2 with libusrp) python
code to run on the latest git release (master, Mon Sep 10 08:42:14 2012
-0700). I am using a custom FPGA image for the USRP1. The FPGA image
implements additional functionality that is controlled via the FPGA user
registers, such as usrp.FR_USER_0. Previously, I could access these
registers in Python with the
u._write_fpga_reg(address, value)
function, where u is an instantiated libusrp sink, but I can’t find an
equivalent function for USRP-UHD. The closest I can find is
usrp.set_user_register(address, value), but this generates an exception:
RuntimeError: LookupError: Path not found in tree: /mboards/0/user/regs
Is there a new Python function for writing to FPGA registers? I’ve seen
references to peek32 and poke32, but I haven’t found if/where they are
exposed in Python. Do I need to do something to make USRP-UHD aware of
my custom registers? Does the FPGA image itself need to be changed for
UHD compatibility?
function, where u is an instantiated libusrp sink, but I can’t find
an equivalent function for USRP-UHD. The closest I can find is
usrp.set_user_register(address, value), but this generates an
exception:
RuntimeError: LookupError: Path not found in tree:
/mboards/0/user/regs
This sounds like a pretty strait forward thing to add. Can you
checkout this branch: usrp1_set_user_reg and try to call
set_user_register again?
The set_user_register() function now returns without error. I cannot
confirm that the function works, however, as my program as a whole does
not work. In my program, the transmitted signal is generated entirely in
the FPGA, and USB input is neither accepted nor required. The old
libusrp code used a usrp_sink solely to control the daughterboard and
the FPGA registers—very similar to the discontinued gr-radar-mono code.
With the UHD version, I can’t get the transmitter to turn on, regardless
of input. If I connect the usrp_sink to a vector source of 1s, the
transmitter turns on, but not for very long. Is there some way to force
the transmitter to be on? I am using the RFX series daughtercards. The
transmitter should be the only thing attempting to use this particular
daughtercard. I’d appreciate any suggestions you may have, but I’ll keep
poking at it.
My project itself is an FMCW chirp radar front-end for the USRP. If I
can get it brought up-to-date, and secure the permission of my sponsor,
I will release it as open source to the gnuradio community.
It might be worth adding the constants usrp.FR_USER_0 and the like back
in somewhere.
With the UHD version, I can’t get the transmitter to turn on,
regardless of input. If I connect the usrp_sink to a vector source
of 1s, the transmitter turns on, but not for very long. Is there
some way to force the transmitter to be on? I am using the RFX
series daughtercards. The transmitter should be the only thing
attempting to use this particular daughtercard. I’d appreciate any
suggestions you may have, but I’ll keep poking at it.
My project itself is an FMCW chirp radar front-end for the USRP. If
I can get it brought up-to-date, and secure the permission of my
sponsor, I will release it as open source to the gnuradio
community.
Thanks for your help, everything works now! The set_user_register()
function appears to work perfectly with my USRP1. I’m going to submit my
design to our sponsor for approval. If they approve, I will make it
available for download in a few weeks once I finish cleaning up the
code.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.