Hello folks. I am currently looking at using the USRP for interaction
with RFID tags. The crux of the problem is that I need to transmit a
continuous carrier wave to power the tag, but I also need very low
latency with respect to receiving a tag signal and responding to that
signal (< 500us. Not going to happen, but the closer the better).
Currently, I am transmitting the carrier from the host which eats up
half of my USB bandwidth and keeps the TX buffers full, both of which
are killing my latency.
My question is, would it be possible to modify the FPGA so that the
default behavior is to transmit the carrier until it receives buffers
for transmit? This should reduce the latency by using the USB half
duplex, keeping the TX buffers empty which allows for burst transmits,
and also by freeing up some computes which are now burned sending out
“1’s”.
To further complicate the problem, I’ve very little experience
working with FPGAs and verilog. So, a caveat to the above question is
that this not only needs to be possible, it needs to be relatively
straight forward as well.
Any advice as to the feasibility of this endeavor would be greatly
appreciated. If it seems reasonable, pointers as to what would be
involved, where I would need to look, etc. would also be helpful.
Thanks.
Michael Buettner
On 7/24/07, Michael P Buettner [email protected] wrote:
Hello folks. I am currently looking at using the USRP for interaction with RFID tags. The crux of the problem is that I need to transmit a continuous carrier wave to power the tag, but I also need very low latency with respect to receiving a tag signal and responding to that signal (< 500us. Not going to happen, but the closer the better). Currently, I am transmitting the carrier from the host which eats up half of my USB bandwidth and keeps the TX buffers full, both of which are killing my latency.
My question is, would it be possible to modify the FPGA so that the default behavior is to transmit the carrier until it receives buffers for transmit? This should reduce the latency by using the USB half duplex, keeping the TX buffers empty which allows for burst transmits, and also by freeing up some computes which are now burned sending out “1’s”.
The tx_buffer can help you out here:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/tx_buffer.v
You can see how at line 72 there is a case statement and if the TX
FIFO is empty, the values are set to be zero. I am not 100% sure, but
I believe if you change these values to be non-zero you will get a
carrier to come out.
Moreover, once the TX FIFOs are filled with something, that data will
then automatically switch over for you.
The only thing I’d be worried about is the master control register
which controls whether or not the TX strobes are enabled. You can see
this here:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/master_control.v
Follow the ‘enable_tx’ signal around to see what I mean.
You may want to dig into Verilog simulation a bit if you have the
time. There are testbenches that are written and in the repository
that allow you to see what the changes you make will have on the code.
I hope this helps.
Brian
On Tue, 24 Jul 2007, Brian P. wrote:
this here:
Brian
Thanks Brian, that was just what I was looking for. I’ve now enough
to dig into anyway, and we’ll see what happens.
Are there any current testbenches? The only testbench I can find is
full_chip which is defunct.
Thanks again.
michael
On 7/24/07, Michael P Buettner [email protected] wrote:
Thanks Brian, that was just what I was looking for. I’ve now enough to dig into anyway, and we’ll see what happens.
Are there any current testbenches? The only testbench I can find is full_chip which is defunct.
Whoops - I guess there isn’t an up to date testbench. Maybe that
should go on a todo list somewhere.
Brian
On Tue, 24 Jul 2007, Brian P. wrote:
FIFO is empty, the values are set to be zero. I am not 100% sure, but
Follow the ‘enable_tx’ signal around to see what I mean.
You may want to dig into Verilog simulation a bit if you have the
time. There are testbenches that are written and in the repository
that allow you to see what the changes you make will have on the code.
I hope this helps.
Brian
I have had some success modifying the FPGA to send a continuous carrier.
A carrier is sent until data is received, at which point the data is
transmitted correctly. Basically, the transmit behavior I wanted is
there. Unfortunately, I now see continuous overruns when using my FPGA
code. The simplest example has a message_source transmitting to the USRP
(a message is sent every second or so) and the USRP is receiving into a
file_sink. I have looked at a number of examples that have no overruns
using the normal .rbf file, and when I swap in my .rbf the continuous
overruns invariably result. It appears that no data is arriving at the
host, and the received samples are stopped completely somewhere.
Does anyone have any insight as to why this would be happening? The
only change I have made is that I now send something non-zero when the
tx fifo is empty. I would expect the transmit and receive chain to be
relatively separate. Particularly as I am using two daughterboards on
one USRP, one is transmitting and one is receiving.
Any insights or advice? Thanks.
Michael
Discuss-gnuradio Info Page
I seem to have jumped the gun a bit. I have the overrun problem
whenever I build the bit file.
Using the “std_2rxhb_2tx.rbf” file distributed with GSR, all is well.
When I build my own .rbf using Quartus II 7.1 Web Edition, I have the
underrun problem. I am using a fresh SVN check out, and in the
config.vh file for usrp_std the “common_config_2rxhb_2tx.vh” line is
uncommented.
Has anyone else had this problem? When building from usrp_std.v
should I expect to get the same .rbf as “std_2rxhb_2tx.rbf”? Maybe I am
missing something…
Any help would be appreciate.
michael