discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maria Stevens
Subject: [Discuss-gnuradio] Unexpected issue with file source and USRP source
Date: Thu, 12 Dec 2013 15:54:29 +0500

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]