On 05/10/2010 04:54 PM, Ian Holland wrote:
Hi All
I am coming across problems when using USRP2s with certain decimation
factors, and these problems are somewhat counterintuitive.
For instance, either using our own code while simply waiting for samples
to cross a threshold (so very little computation), I find that I am
getting SSS, indicating out-of-sequence packets.
This was for a decimation factor of 20. However, when I tried a
decimation factor of 10, which should have increased both the Ethernet
and the computational requirements, I no longer observed out-of-sequence
packets.
I tried the same sort of thing with usrp2_fft.py, trying decimations of
10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets
within about 10 – 20 seconds, but with decimation factor 10 I saw no
out-of-sequence packets even after a few minutes.
Can anybody suggest what might be going on here?
I don't know what exactly is happening here, as I have not seen this
behavior, but I just want to clarify a little terminology. The S you
are seeing indicates sequence number errors. While getting packets out
of sequence would give this error, that isn't that is happening. The
sequence number errors really indicate that you are dropping packets
because you can't keep up.
Typically, if you can't keep up at a slow decimation, going to a faster
one would make things worse, not better. The only thing I can think of
to explain what you are seeing is that you might be doing a lot more
processing at the lower rate. For example, at the lower sample rate,
you might be making your filter transition bands very narrow, resulting
in very long filters.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
