discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] About sample lost


From: Josh Blum
Subject: Re: [Discuss-gnuradio] About sample lost
Date: Mon, 03 Jun 2013 14:02:48 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5


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 address@hidden 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]