GNU Radio Companion v3.6.4-43-g6e5dfe1a
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-37-g21311276
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.
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
However, when I remove the file sink and directly connect the USRP with
same demodulator chain, I observe frequent packet loss.
USRP Source --> Demodulator Chain
CASE 3 :
In this case I connected file sink and demodulator so that demodulator
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
compare results. Again I observed frequent packet loss.
USRP Source --> File sorce (def.bin)
–> Demodulator Chain
after executing flowgraph4.grc , i execute flowgraph5.grc, post
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
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?
it because some of the demodulator chain blocks are causing back
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
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
Any help would be appreciated.