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