Forum: GNU Radio About sample lost

Df7cdd34a301d6acf9db691f95c1243c?d=identicon&s=25 "ÀîÔÞ" <lizan19861219@yahoo.cn> (Guest)
on 2013-06-03 19:12
(Received via mailing list)
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
D7c45fe2b9d1bc4156cebeb19a3a2b63?d=identicon&s=25 Josh Blum (Guest)
on 2013-06-03 20:05
(Received via mailing list)
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
Df7cdd34a301d6acf9db691f95c1243c?d=identicon&s=25 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
Df7cdd34a301d6acf9db691f95c1243c?d=identicon&s=25 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
Df7cdd34a301d6acf9db691f95c1243c?d=identicon&s=25 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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.