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.
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com