Unexpected issue with file source and USRP source

GNU Radio Companion v3.6.4-43-g6e5dfe1a
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-37-g21311276
USRP N210

Hello All !

I am observing following 3 cases for same transmitter. I ran each case
multiple times and reach to conclusion that only CASE 1 is working fine.

CASE 1:

First i execute flowgraph1.grc in which there is
USRP Source --> File Sink (abc.bin)

After writing file i execute another flowgraph2.grc that reads the
previously saved file ‘abc.bin’ as show below
File Source (abc.bin) --> throttle --> Demodulator chain

In this case, I am able to receive and decode all the sent packets
correctly.

CASE 2:

However, when I remove the file sink and directly connect the USRP with
the
same demodulator chain, I observe frequent packet loss.

flowgraph3.grc
USRP Source --> Demodulator Chain

CASE 3 :

In this case I connected file sink and demodulator so that demodulator
can
demodulate the incoming samples and at the same time USRP writes the
samples to a file ‘def.bin’. This file is to be used for post processing
to
compare results. Again I observed frequent packet loss.

flowgraph4.grc
USRP Source --> File sorce (def.bin)
–> Demodulator Chain

after executing flowgraph4.grc , i execute flowgraph5.grc, post
processing
of file ‘def.bin’
File Source(def.bin) --> throttle --> Demodulator chain
I observed same packet loss.

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.

Any help would be appreciated.

Regards.

M.S.

On Thu, Dec 12, 2013 at 03:54:29PM +0500, Maria Stevens 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?

MB

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs