On 06/03/2013 01:10 PM, ÀîÔÞ wrote:
> 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.
> 

You shouldnt see any overflow within the scheduler, which is full
backpressured, but perhaps from the USRP... However, 8192 (fc32 samps)
corresponds to a default memory chunk size for buffers in the gnuradio
scheduler, and not an MTU size packet from the USRP.

Can you think of a reason in your code that this might happen? Because
8192 sounds like an entire work function call worth of samples
unaccounted for, not an overflow.

-josh

> Any suggestions would be appreciated.
> 
> Best regards
> 
> Zan
> 
> 
> 
> _______________________________________________ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to