# Tips for improving file transfer data loss

**URL:** <https://www.ruby-forum.com/t/tips-for-improving-file-transfer-data-loss/240332>\
**Category:** GNU Radio\
**Created:** [April 8, 2014, 7:43pm UTC](https://www.ruby-forum.com/t/tips-for-improving-file-transfer-data-loss/240332 "2014-04-08T19:43:46Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [April 8, 2014, 7:43pm UTC](https://www.ruby-forum.com/t/tips-for-improving-file-transfer-data-loss/240332/1 "2014-04-08T19:43:46Z")

</div>

I’m looking for some tips on how to improve file transfer using two  
USRP’s.  
I understand the method I’m using might be fairly crude, but I’m just  
starting out.

Problem is I’m dropping a lot of data out of the file (receiving missing  
parts of a string and such). This gets really bad when one of the USRP’s  
is  
moving.

File Source \> Packet Encoder \> GMSK Mod \> USRPB100 Sink

USRP B100 Source \> Xlating FIR Filter (LP 100khz) \> GMSK Demod \> Packet  
Decoder \> File Sink.

I want to try and add some FEC, however, the only FEC blocks that ship  
with  
GNURadio say “This package is for continuous data, not packetized”. Any  
FEC  
tips would be nice.

Is there anything wrong/bad with this flow graph for sending files? Or  
perhaps a better solution? I understand there could be a heap of  
problems  
not relating to GNURadio, but I’m sending the files in the middle of a  
very  
large (\>1mile square) open field , with good line of sight.

Cheers,

Ken

---

<div class="post-metadata">

**Author:** ![kena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/e9bcb4/32.png) [@kena](https://www.ruby-forum.com/u/kena)\
**Post date:** [April 9, 2014, 3:26pm UTC](https://www.ruby-forum.com/t/tips-for-improving-file-transfer-data-loss/240332/2 "2014-04-09T15:26:40Z")

</div>

On Tue, Apr 8, 2014 at 1:42 PM, Ken A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> USRP B100 Source \> Xlating FIR Filter (LP 100khz) \> GMSK Demod \> Packet
> 
> Cheers,
> 
> Ken

Ken,

There’s lots that can go wrong between the transmitter and receiver. As  
you’ve already identified, there’s no FEC here, so nothing to fix an  
error.  
Even a single bit error in a packet will cause you to lose that packet  
because of the CRC check.

At our latest hackfest, we worked (among other things) on two things:  
our  
new FEC system and gr-mac. The FEC API system will allow you to apply  
FECs  
to packetized data, and gr-mac has ARQ. See the notes from the event for  
where things are:

[http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1403-2](http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1403-2)

Tom