Re: [Discuss-gnuradio] Last two data Blocks are always missing

[Brian Padalino]

On Tue, Aug 12, 2008 at 7:33 AM, kaleem ahmad <address@hidden> wrote:
>
> 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???????????

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