On 07/23/2018 10:04 PM, RizThon wrote:
Hi Marcus,

It's a B210. So you confirm this is strange, and is probably a problem on the Soapy part?

I can try to write the same straight in UHD to see what I get.

Thanks.
Yes an overrun should result in an overrun indication, and a timestamp that is a "jump", but always in the positive direction.



On Tue, Jul 24, 2018 at 10:00 AM Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:

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


_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to