Last two data Blocks are always missing

Hello Everyone,

If you run following code on your machine (I am using gnradio3.1.1 and
this
code is also available in this version with a name ‘fsk_loopback.py’
although it is removed in gnuradio3.1.2) then you will see that it will
transfer a file send.txt (Please create file named as “send.txt” in your
current folder) to another file “rcv.txt” (It will create that file by
itself).

But the problem is it will never transfer the complete file but some
data at
the end is always missing and the amount of data missing depends on
“payload_size = ?” at line 38 in the following:

    payload_size = 64             # bytes

If the file is larger than 64 bytes let say 64 x 10 bytes then last two
blocks will be lost, and first 8 blocks will be received (You can run
the
code given at the end without and USRP hardware, because it only tests
the
GNURadio and dont need any hardware).

In short>

1-If the file is larger than the payload_size then last two blocks of
data
(2 x payload_size) are not received.

2-If the file is smaller than the payload_size then data is not
transferred
at all.

For your convinience I have also attached send.txt and python code file
which you can directly download and run on your PC.

Can some one give me some clue why this data is lost???

#--------------------Here is the code but it is also
attached----------------------
#!/usr/bin/env python

from gnuradio import gr, eng_notation

from gnuradio import usrp

from gnuradio import audio
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import math

from gnuradio.wxgui import stdgui, fftsink
import wx

class fsk_tx_graph (stdgui.gui_flow_graph):
def init(self, frame, panel, vbox, argv):
stdgui.gui_flow_graph.init (self, frame, panel, vbox, argv)

    parser = OptionParser (option_class=eng_option)
    parser.add_option ("-c", "--cordic-freq", type="eng_float",

default=29.32e6,
help=“set Tx cordic frequency to FREQ”,
metavar=“FREQ”)
parser.add_option ("-f", “–filename”, type=“string”,
default=“send.txt”,
help=“read data from FILENAME”)
parser.add_option ("-R", “–repeat”, action=“store_true”,
default=False)
parser.add_option ("-r", “–data-rate”, type=“eng_float”,
default=100e3)
(options, args) = parser.parse_args ()

    print "cordic_freq = %s" % (eng_notation.num_to_str

(options.cordic_freq))

    # 

    data_rate = options.data_rate
    self.sw_interp = 8
    self.usrp_interp = 128e6 / self.sw_interp / data_rate
    self.fs = 128e6 / self.usrp_interp

    max_deviation = data_rate / 4
    payload_size = 64             # bytes

    print "data_rate = ", data_rate
    print "sw_interp = ", self.sw_interp
    print "usrp_interp = ", self.usrp_interp
    print "fs = ", self.fs

    # transmitter pipeline

    src = gr.file_source (gr.sizeof_char, "send.txt", 

options.repeat)

    framer = gr.simple_framer (payload_size)

    bytes_to_syms = gr.bytes_to_syms ()


    interp_taps =  gr.firdes.low_pass (self.sw_interp,      # gain
                                       self.fs,             # 

sampling
rate
data_rate / 2 * 1.2, # cutoff
data_rate/2 * 0.4, # trans
width
gr.firdes.WIN_HANN)

    print "len = ", len (interp_taps)

    interp = gr.interp_fir_filter_fff (self.sw_interp, interp_taps)

    k = 2 * math.pi * max_deviation / self.fs
    fmmod = gr.frequency_modulator_fc (k)

    gain = gr.multiply_const_cc (2000)

    self.connect (src, framer)
    self.connect (framer, bytes_to_syms)
    self.connect (bytes_to_syms, interp)
    self.connect (interp, fmmod)
    self.connect (fmmod, gain)
    tx_tail = gain                  # end of tx pipeline


    if 0:
        post_interp = fftsink.fft_sink_f (self, panel, title="Post

Interp", fft_size=512, sample_rate=self.fs)
self.connect (interp, post_interp)
vbox.Add (post_interp.win, 1, wx.EXPAND)

    if 0:
        post_mod = fftsink.fft_sink_c (self, panel, title="Post

Modulation", fft_size=512, sample_rate=self.fs)
self.connect (fmmod, post_mod)
vbox.Add (post_mod.win, 1, wx.EXPAND)

    # receiver pipeline

    self.samples_per_symbol = 8
    self.usrp_decim = 64e6 / self.samples_per_symbol / data_rate
    assert (self.fs == data_rate * self.samples_per_symbol)

    demod_gain = 1
    filter_taps =  gr.firdes.low_pass (1,                   # gain
                                       self.fs,             # 

sampling
rate
data_rate / 2 * 1.1, # cutoff
data_rate, # trans
width
gr.firdes.WIN_HANN)

    print "len = ", len (filter_taps)

    filter = gr.fir_filter_ccf (1, filter_taps)

    # k = 2 * math.pi * max_deviation / self.fs
    fmdemod = gr.quadrature_demod_cf (demod_gain)

    corr = gr.simple_correlator (payload_size)

    filesink = gr.file_sink (gr.sizeof_char, "rcv.txt")

    self.connect (tx_tail, filter)
    self.connect (filter, fmdemod)
    self.connect (fmdemod,corr)
    self.connect (corr,filesink)

    if 0:
        fft_input = fftsink.fft_sink_c (self, panel, "Input", 512,

self.fs)
self.connect (tx_tail, fft_input)
vbox.Add (fft_input.win, 1, wx.EXPAND)

def main ():
app = stdgui.stdapp (fsk_tx_graph, “FSK Loopback”)
app.MainLoop ()

if name == ‘main’:
main ()
http://www.nabble.com/file/p18942634/send.txt send.txt
http://www.nabble.com/file/p18942634/fsk_loopback.py fsk_loopback.py


View this message in context:
http://www.nabble.com/Last-two-data-Blocks-are-always-missing-tp18942634p18942634.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Tue, Aug 12, 2008 at 7:33 AM, kaleem ahmad [email protected]
wrote:

But the problem is it will never transfer the complete file but some data at
In short>
Can some one give me some clue why this data is lost???
Just taking a stab in the dark here, but in your program there are a
couple of low pass filters. There is a finite group delay with those
filters. Do you know the length of your filters?

How large have you made your payload size? I have a feeling that if
you make your payload size relatively large, then you won’t see the
last few blocks missing, but instead a piece of the last block.

To alleviate, you may want to flush the filters out with all 0’s for
at least the length of 1/2 the taps, but it might be better to clear
the whole thing just so if you decide to start a new burst, the filter
doesn’t have anything left over to cause some weird transients at the
beginning of the burst.

Hope that helps.

Brian

Dear Brian,

I have tried with different payload sizes and the maximum value I tried
was
1024 bytes. But in all cases I never received last Block (Sorry in my
first
post I mistakenly wrote last two blocks, it is actually the last block
only).

The length of transmit side filter is 125 and that of received side is
25.

Can you please explain how can I flush or clear the filters as you said:

“To alleviate, you may want to flush the filters out with all 0’s for
at least the length of 1/2 the taps, but it might be better to clear
the whole thing just so if you decide to start a new burst, the filter
doesn’t have anything left over to cause some weird transients at the
beginning of the burst.”

Please give me a clue with little code if possible.

Thanks

Brian P. wrote:

transfer a file send.txt (Please create file named as “send.txt” in your
If the file is larger than 64 bytes let say 64 x 10 bytes then last two

couple of low pass filters. There is a finite group delay with those
beginning of the burst.


View this message in context:
http://www.nabble.com/Last-two-data-Blocks-are-always-missing-tp18942634p18946885.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Dear Brian,

Thanks for your suggestion, it solved my problem as I am padding 0’s
equal
to one block size at the end.

But now I have to bear an overhead of one block size all the time, In my
application all the time I have to send one block of data. So it means
that
for every packet I have to add an extra packet.

Best Regards

Brian P. wrote:

post I mistakenly wrote last two blocks, it is actually the last block
doesn’t have anything left over to cause some weird transients at the
fixes your problems.

Brian


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://www.nabble.com/Last-two-data-Blocks-are-always-missing-tp18942634p18947787.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Tue, Aug 12, 2008 at 11:39 AM, kaleem ahmad [email protected]
wrote:

Can you please explain how can I flush or clear the filters as you said:

“To alleviate, you may want to flush the filters out with all 0’s for
at least the length of 1/2 the taps, but it might be better to clear
the whole thing just so if you decide to start a new burst, the filter
doesn’t have anything left over to cause some weird transients at the
beginning of the burst.”

Please give me a clue with little code if possible.

I really have no idea how to do it in code in GNU Radio. The easiest
thing to do is just transmit an extra block of data and ignore it at
the receiver. The smart thing to do is to zero the input to the
filter and run it for the total length of the filter taps.

Good luck writing the code for it. I’m interested to know if this
fixes your problems.

Brian

On Tue, Aug 12, 2008 at 12:23 PM, kaleem ahmad [email protected]
wrote:

Dear Brian,

Thanks for your suggestion, it solved my problem as I am padding 0’s equal
to one block size at the end.

But now I have to bear an overhead of one block size all the time, In my
application all the time I have to send one block of data. So it means that
for every packet I have to add an extra packet.

You may try to not fill it with full packets, but only partial ones?
Play with the different sizes. It sounds like the problem really is
just the group delay of the filter.

Brian

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