Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...

[Matt Ettus]

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