On Mon, Nov 13, 2006 at 10:19:22PM -0800, Thomas Schmid wrote:
>
> No, I do not log the received data into a file. I record the wave
> forms on the oscilloscope and do a post processing on them in octave.
>
> >> First of all, I don't understand why we have such a high delay.
> >> Shouldn't it be more in the hundreds of /mu s instead of in the ms
> >> range?
> >
> >Yes, at the high input rates.
> >
> >> Second, why is the delay shorter for decimation 64, and again
> >> larger for a decimation of 256?
> >
> >Underruns and/or incorrect examination of the incoming data?
>
> I think now, after considering your response, that this might be the
> problem. I will check both things tomorrow and do the measurements
> again. Hopefully I will find smaller delays.
>
> >Also, the received data (and transmitted data too) is "quad buffered"
> >in the FX2, so there's a maximum of 4 512-byte buffers between you and
> >the data on the receive path. This could be reduced without much
> >trouble to "double buffered". But I don't think this is really the
> >problem.
> >
> >With the quad buffered case and decim = 8, the most data that could be
> >buffered in the FX2 is 4*512 = 2048 --> 2048/32e6 = 64 us worth.
> >
> >Right now I'm looking at how the received data buffering is done in
> >the usrp and gr-usrp code. Looks like there may be a
> >problem/opportunity in the usrp1_source_base.cc.
> >
> >I'll get back to you with more info in a bit...
>
> Thank you very much. I am looking forward to your response.
>
> Thomas
Thomas,
I've made a change to usrp1_source_base.cc that might help.
You can either pick it up from my developer branch:
$ svn co http://gnuradio.org/svn/gnuradio/branches/developers/eb/rx-latency
or apply the attached patch.
Please let me know if it helps. I think it will, once the overruns
are take care of. If it does work, I'll merge it into the trunk.
Eric
Index: gr-usrp/src/usrp1_source_base.cc
===================================================================
--- gr-usrp/src/usrp1_source_base.cc (revision 3982)
+++ gr-usrp/src/usrp1_source_base.cc (working copy)
@@ -29,7 +29,6 @@
#include <usrp_standard.h>
#include <assert.h>
-static const int OUTPUT_MULTIPLE_BYTES = 4 * 1024;
usrp1_source_base::usrp1_source_base (const std::string &name,
gr_io_signature_sptr output_signature,
@@ -58,9 +57,9 @@
throw std::runtime_error ("can't open usrp1");
// All calls to d_usrp->read must be multiples of 512 bytes.
- // We jack this up to 4k to reduce overhead.
+ // We set this to match the fusb block size
- set_output_multiple (OUTPUT_MULTIPLE_BYTES /
output_signature->sizeof_stream_item (0));
+ set_output_multiple (d_usrp->block_size() /
output_signature->sizeof_stream_item(0));
}
usrp1_source_base::~usrp1_source_base ()
@@ -91,13 +90,19 @@
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
- static const int BUFSIZE = 4 * OUTPUT_MULTIPLE_BYTES;
+ static const int BUFSIZE = 64 * 1024;
unsigned char buf[BUFSIZE];
int output_index = 0;
int output_items_produced;
int bytes_read;
bool overrun;
+ // To minimize rx latency, never return more than 1 fusb block_size worth of
samples.
+ // FIXME: A better fix would be to return the maximum we could without
blocking,
+ // but the current interface doesn't allow us to do that.
+
+ noutput_items = std::max(output_multiple(), noutput_items);
+
while (output_index < noutput_items){
int nbytes = ninput_bytes_reqd_for_noutput_items (noutput_items -
output_index);
nbytes = std::min (nbytes, BUFSIZE);
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
