On 07/23/2018 09:51 PM, RizThon via USRP-users wrote:
Hi all,
I have a question concerning the timestamps while getting an overrun.
I'm sampling at 28MS/s and reading blocks of 1024 samples. So it takes
36571 to 36572ns to sample each block.
I try to read x blocks, calling receive for each block. I get
something like
block 93: correctly read 1024 samples, timestamp as expected
(ie +36571ns compared to block 92)
block 94: only received 364 samples, timestamp still as expected
block 95: overrun, timestamp is bigger than expected (+94286)
block 96: correctly read 1024 samples, but timestamp is lower than
block 95 (-81286)
block 97: correctly read 1024 samples, timestamp as expected
block 98:correctly read 1024 samples, timestamp as expected
block 99:correctly read 1024 samples, but timestamp is bigger than
expected (+2818750)
The exact same pattern repeats itself from time to time
block n: receive fewer than expected samples
block n+1: overrun with timestamp jump
block n+2: get timestamp smaller by always 81285 or 81286
block n+3: ok
block n+4: ok
block n+5: big timestamp jump
Can someone explain what is happening, and what the proper way to
handle overruns is?
I'm using SoapySDR, so I don't know if it's specific to UHD or if
there's some bug in Soapy (I'm not seeing that behaviour with the same
program running a LimeSDR).
Thanks.
What type of USRP is this from?
There aren't too many people on this list who can help debug SOAPYSDR
stuff, so debugging it might require doing a "throw away" purely using
the UHD API, to see if the problem persists there.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
