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
"ÀîÔÞ" <lizan19861219@yahoo.cn> (Guest)
on 2013-06-03 19:12
Josh Blum (Guest)
on 2013-06-03 20:05
On 06/03/2013 01:10 PM, wrote: > > 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
Zan L. (zan_l)
on 2013-06-04 15:29
Hi Josh, Thanks a lot for your reply. I have checked the code but did not find any bugs to miss one buffer of samples. What I am doing is read the overall samples which are consumed at the beginning of general_work function as follows: uint64_t nread = this->nitems_read(0); and then add the sample number in this round of general_work function call. However, I always miss several 8192s of samples. Are there some situations that the an entire work function call worth of samples are unaccounted for? Best regards Zan
Zan L. (zan_l)
on 2013-06-04 17:09
Josh Blum wrote in post #1111166: > On 06/03/2013 01:10 PM, wrote: >> >> 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 Hi Josh, Thanks a lot for your reply. I have checked the code but did not find any bugs to miss one buffer of samples. What I am doing is read the overall samples which are consumed at the beginning of general_work function as follows: uint64_t nread = this->nitems_read(0); and then add the sample number in this round of general_work function call. However, I always miss several 8192s of samples. Are there some situations that the an entire work function call worth of samples are unaccounted for? Best regards Zan
Zan L. (zan_l)
on 2013-06-05 15:26
Hi, The problems have been solved. It is because in the consume_each function, some times, even if there is no enough input item, it still consume more items and this cause the return value of this->nitems_read(0) is actually larger than the actual consumed items. Best regards Zan
Enable email notification
Enable multi-page view