discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FPGA Modifications for a Continuous Carrier?


From: Michael P Buettner
Subject: Re: [Discuss-gnuradio] FPGA Modifications for a Continuous Carrier?
Date: Tue, 31 Jul 2007 13:57:13 -0700 (PDT)


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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]