On 07/04/2023 08:26, Jason Matusiak wrote:
I have been trying to work on a gnuradio block to fill in the dropped samples in a USRP stream.  While testing things out, I came across something odd.  I am using an X310 as my test device and am changing the sample rate.  I was at 100Msps, let it run for some time, and then changed it to 10Msps; sometimes this works, sometimes I need to change a few times to get dropped samples.  Sometimes, if I look, the time between the last tag and the tag when I changed the sample rate was 37.4225 seconds (for example).  If I count the number of samples between those two tags, I get 374232036 samples.  That is more samples than should have happened in that time at 100Msps.

I am guessing that tweaking sample rates does something weird to the sample buffers and probably means that my sample packing approach will only work with lost samples caused by freq changes or other driver slowdowns.

Does anyone have any insight to what might be going on here?  I know that it is wasted cycles for most people, but it would be nice if the USRP/UHD would report the number of lost samples when it retags at the beginning of good samples.
The command stream is entirely asynchronous to the sample stream. So when you change sample rates, AFAIR, you don't
  know which samples correspond to the sample-rate change.

The underlying UHD API has timestamps on every frame of samples from the hardware.  But the GR interface   only issues a new timestamp tag when something requiring a new tag is required--like overrun.

I don't think the case of rate-change+overrun was a use case that was particularly explicitly addressed in the GR interface
  into UHD.

Another issue is that if you're changing *master clock* in the middle, that's not supported on X310, and the master-clock   rate can only be specified reliably when you create the session, not in the middle of streaming.


_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to