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

Reply via email to