# About sample lost

**URL:** <https://www.ruby-forum.com/t/about-sample-lost/245458>\
**Category:** GNU Radio\
**Created:** [June 4, 2013, 9:26am UTC](https://www.ruby-forum.com/t/about-sample-lost/245458 "2013-06-04T09:26:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [June 4, 2013, 9:26am UTC](https://www.ruby-forum.com/t/about-sample-lost/245458/1 "2013-06-04T09:26:44Z")

</div>

Dear list,  
Now I meet a problem about counting all the input samples. I hope I can  
get some assistant from here. The problems are as follows,  
In one of my blocks, I want to count all the consumed input samples to  
get  
the timestamp of the received packet. I have used GPS to synchronize two  
usrps and therefore for the same packet the two usrp should consume the  
same amount of samples in this block from the beginning of the stream.  
At  
the very beginning, it works fine but after it works for a while the  
timestamp in one usrp will lost 8192 samples (8192 samples less than the  
other one). I have checked it is the same as the maximum output buffer  
of  
one block.

I want to ask if it is possible that because the block can not process  
the  
sample as fast as the output from the previous block, one buffer of  
samples  
are lost. BTW I did not find any indicator of overflow from uhd when I  
run  
the code.

Any suggestions would be appreciated.

Best regards

Zan

---

<div class="post-metadata">

**Author:** ![Zan\_Li](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/47e85d/32.png) [@Zan\_Li](https://www.ruby-forum.com/u/Zan_Li)\
**Post date:** [June 4, 2013, 5:38pm UTC](https://www.ruby-forum.com/t/about-sample-lost/245458/2 "2013-06-04T17:38:43Z")

</div>

On 06/04/2013 03:25 AM, Zan Li wrote:

> one block.
> 
> I want to ask if it is possible that because the block can not process the  
> sample as fast as the output from the previous block, one buffer of samples  
> are lost. BTW I did not find any indicator of overflow from uhd when I run  
> the code.
> 
> Any suggestions would be appreciated.

Any thoughts on my previous reply?  
[http://www.mail-archive.com/removed\_email\_address@domain.invalid/msg42356.html](http://www.mail-archive.com/removed_email_address@domain.invalid/msg42356.html)

Also, there is an API to get the number of samples consumed. In your  
work function, you can all this-\>items\_consumed(input\_port\_index). Just  
in case you didnt know, so you do not have to do a manual count, the  
scheduler will do this for you.

Also, what do you mean by “timestamp in one usrp will lost 8192  
samples”? The timestamps are typically tagged on the first sample and  
only resent when there is device overflow. So I am curious how you are  
determining lost samples. Are you correlating on a shared pulse  
transmitted into both USRPs?

-josh