On 24/02/2023 11:06, Rob Kossler wrote:
Hi Peter,
Each recv() call returns metadata with a timestamp. You can verify
each receive has advanced exactly the right amount of time
corresponding to 16k samples. If this verifies, you haven't dropped
anything. The metadata also includes the Overflow indication. To be
honest, I have no idea why you aren't seeing the "O" right away.
Rob
There are some notes on the transport here:
https://files.ettus.com/manual/page_transport.html#transport_usb
I've used "num_recv_frames" in the past to help with occasional overruns
at higher rates. These parameters, from
what I understand, are used to configure the session way down at the
bottom of libusb, and, near as I can tell,
on Linux, the resources implied by them are shared among all
processes using the libusb subsystem.
UHD by default sets "num_recv_frames" to 32, and the max value for this
appears to be very system dependent,
and also dependent on who else is using the kernel "raw" USB subsystem.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
