Re: [Discuss-gnuradio] Unexpected issue with file source and USRP source

[Tom Rondeau]

On Sun, Dec 15, 2013 at 10:58 PM, Maria Stevens
<address@hidden> wrote:
> On Fri, Dec 13, 2013 at 3:58 PM, Maria Stevens <address@hidden>
> wrote:
>>
>>
>>> > So, Only case 1 is working for me. I am not using any custom
>>> > gnuradio-block in
>>> > my receiver. Major blocks in my demodulator chain consists of FIR
>>> > filters,
>>> > gr_pfb_clock_sync_ccf and packet decoder along with some adders
>>> > subtractors
>>> > etc. what is the difference caused by the same demodulator chain when
>>> > reading
>>> > data directly from usrp source and from file source? is it because some
>>> > of the
>>> > demodulator chain blocks are causing back pressure due to taking too
>>> > much time
>>> > in processing but when run in real time it causes data loss during
>>> > exchange of
>>> > samples between blocks.? I am confused if in real time the
>>>
>>> > gr_pfb_clock_sync_ccf block or any other major block stucks in
>>> > processing
>>> > during which samples are lost due to new incoming samples.
>>>
>>> Are you observing overflows? If so, have you tried reducing the
>>> bandwidth and see if that helps?
>>
>>
>> Thanks for your reply. I am not observing any overflows. I am using 500k
>> sample rate. My system specs are 6GB RAM core i7 ubuntu 12.04.
>>
>> What could be the issue ?
>>
>> Regards.
>> M.S.
>
>
> Any comments on this issue? Anything that i can try to cater this issue?
>
> Regards
> MS

I would agree with Martin. It sounds like you're dropping samples form
the USRP, so it's strange to hear you say you aren't seeing and
overflow indications.

The only thing else I can think of is that there's a sample rate
mismatch somewhere in the chain. And from your original email, I'm
assuming that you don't have a throttle in your flowgraph when using
the USRP?

If you can publish the simplest form of a transmit and receive
flowgraph we could look at or use to test, that might help understand
this better.

Tom