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:m...@ettus.com] Sent: Tuesday, 11 May 2010 9:46 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio