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

[Ian Holland]

Hi Matt and Marcus.

I understand it is indicating dropped packets, hence causing later ones
to show up out-of-sequence. Re the processing, this occurs even with the
usrp2_fft.py script as well. I don't think that does more processing for
higher values of decimation factor, though please correct me if I am
wrong here. Also, I am not doing any special filtering with my code,
simply capturing raw complex samples, and comparing their magnitude to a
threshold. Of course, once the threshold is crossed I do more
computations, but these S's appear even while I am still listening. On
the other hand, when I reduce the decimation factor, then I don't have
this problem until I do my other processing, which then leads to lost
packets due to excessive computational load. As such, I haven't found a
value of decimation factor that I can use.

Cheers

Ian.
 


-----Original Message-----
From: Matt Ettus [mailto:address@hidden 
Sent: Tuesday, 11 May 2010 9:46 AM
To: Ian Holland
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...

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