On Thu, Jan 31, 2008 at 01:50:32PM +1300, Richard Clarke wrote:
> Hi All,
>
> summary: If I try and receive and transmit data from and to the USRP
> simultaneously at the same data rate (no matter what it is, even as low as
> 2MB/s each way) I always get usrp underruns.
Which operating system and distribution are you using?
> Questions
> *******
> 1) Do others see the same thing?
Haven't tried.
> 2) Is this because any buffering that's going at the PC end is insufficient
> to smooth out any slight differences in actual receive and transmit data
> rates, leading to the occasional starving of the USRP's usb receive
> buffers?
You're running the two daughterboards (the rx and tx) on a single
USRP, right? In that case, the input and output rates will be locked
to the same clock.
If you're running under Linux, I'd try specifying the fusb buffering
parameters in the usrp.source_c and usrp.sink_c constructors.
Use identical values on the source and sink. E.g.,
fusb_block_size = 4096 # must be a multiple of 512
fusb_nblocks = 4
src = usrp.source_c(0, decim,
fusb_block_size=fusb_block_size,
fusb_nblocks=fusb_nblocks)
...
dst = usrp.sink_c(0, interp,
fusb_block_size=fsub_block_size, fusb_nblocks=fusb_nblocks)
and I'd enable realtime scheduling (you'll need to be root or holding
CAP_SYS_NICE):
# Attempt to enable realtime scheduling
r = gr.enable_realtime_scheduling()
if r == gr.RT_OK:
realtime = True
else:
realtime = False
print "Note: failed to enable realtime scheduling"
for the simplest test case, just connect the sink and source
together and see how that works. No mod or demod, "cat < IF-in > IF-out"
fg.connect(src, dst)
> 3) If I configure my application to receive samples from the usrp at a
> lower rate than I retransmit them (using the rational resampler to
> interpolate) this significantly reduces any under run's reported. Is this
> the generally used method to get around this particular issue?
No. You want the input and output rates exactly the same.
> 4) Is it possible to configure the USRP to directly pass samples from the
> receive to the transmit, bypassing the PC altogether? Could be useful to me
> as a basic RF passband to complex baseband, cutting out PC latencies.
This is possible, but to my knowledge no one has written the verilog
to do it.
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
