On Tue, 24 Jul 2007, Brian Padalino wrote:
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
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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
