[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
>