Transmitting a binary 'ones and zeroes' file for Bit Error A

GNU Radio
1

Hello Everyone

I am currently working on binary file transmission from one system to
another, but couldnt figure a way out yet.

Using tx_voice.py when I send a binary file with just an arbitrary
stream of ones and zeroes, data is read and transmitted as packets well.
But unfortunately, on receival side on the retrieval of data, it isnt
written back into the file in the binary format as originally but a
combinations of bits are clubbed and expressed by incomprehensible
hashes and stars. So the data cant be deciphered.

I tried using the GMSK modulation scheme. But the binary data chunks are
filtered out during transmission only…probably due to the gaussian
filter. Please check me out if I am wrong.

Could anyone suggest a way for a ones and zeroes file to be transmitted?
My final aim is to find the ‘Bit error rate’ of transmission form one
node to another.

Also is there any way of comparing two binary files? I mean how should
one approach the bit error analysis keeping correlation in mind etc?

Thanking you all
Rashi Dixit

2

rashi dixit wrote:

hashes and stars. So the data cant be deciphered.
one approach the bit error analysis keeping correlation in mind etc?

Thanking you all
Rashi Dixit

Rashi,

I’m not sue why you are using tx_voice.py for this. It seems to make
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital
examples directory. This will modulate the bits with GMSK by default.
Keep in mind, though, that you want to modulate the data before
transmitting it over the air.

The GNU Radio file sink/source write and read files as binary data, so
the files will look like hashes and stars when viewed with a text
editor. You can use gnuradio-core/src/utils/read_*_binary.m in
Matlab/Octave to read these files.

However, I’m not sure you want to just compare the output file to the
input file unless you also keep track of a packet number. If the header
is missed or corrupted in the current implementation, the packet is
completely dropped, which would completely screw up your calculations
unless you can tell that a full packet has been lossed. Then, you have
to decide how you want to handle the BER calculation due to one lost
packet.

Tom

3

Hey Tom

Thanks for the tip to use benchmark files for the same.On going through
them made me realize they are just as identical to tx_voice.py,
rx_voice.py !

And just as you had said, it would be necessary to keep track of the
packets but I havent yet been able to figure out a way to overcome the
lost packet situation.

The bottleneck is that if I could attach header (external preamble)from
my side to the data then the sequence could be tracked. On trying to
attach external data I dug through the code of pkt.py and
packet_utils.py in
usr/local/lib/python2.4/site-packages/gnuradio/blksmpl and attached a
string to ‘payload’ from my side.

Many-a-times receiver rejects the incoming packet saying:

terminate called after throwing an instance of ‘std::runtime_error’
what(): msg length is not a multiple of d_itemsize
Aborted (core dumped)

Could you the suggest a possible way to overcome this error?

Thanks again!
Rashi

Tom R. [email protected] wrote: rashi dixit wrote:

hashes and stars. So the data cant be deciphered.
one approach the bit error analysis keeping correlation in mind etc?

Thanking you all
Rashi Dixit

Rashi,

I’m not sue why you are using tx_voice.py for this. It seems to make
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital
examples directory. This will modulate the bits with GMSK by default.
Keep in mind, though, that you want to modulate the data before
transmitting it over the air.

The GNU Radio file sink/source write and read files as binary data, so
the files will look like hashes and stars when viewed with a text
editor. You can use gnuradio-core/src/utils/read_*_binary.m in
Matlab/Octave to read these files.

However, I’m not sure you want to just compare the output file to the
input file unless you also keep track of a packet number. If the header
is missed or corrupted in the current implementation, the packet is
completely dropped, which would completely screw up your calculations
unless you can tell that a full packet has been lossed. Then, you have
to decide how you want to handle the BER calculation due to one lost
packet.

Tom

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

Send free SMS to your Friends on Mobile from your Yahoo! Messenger.
Download Now! Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos

4

Hey Tom

Thanks for the tip to use benchmark files for the same.On going through
them made me realize they are just as identical to tx_voice.py,
rx_voice.py !

And just as you had said, it would be necessary to keep track of the
packets but I havent yet been able to figure out a way to overcome the
lost packet situation.

The bottleneck is that if I could attach header (external preamble)from
my side to the data then the sequence could be tracked. On trying to
attach external data I dug through the code of pkt.py and
packet_utils.py in
usr/local/lib/python2.4/site-packages/gnuradio/blksmpl and attached a
string to ‘payload’ from my side.

Many-a-times receiver rejects the incoming packet saying:

terminate called after throwing an instance of ‘std::runtime_error’
what(): msg length is not a multiple of d_itemsize
Aborted (core dumped)

Could you the suggest a possible way to overcome this error?

Thanks again!
Rashi

Tom R. [email protected] wrote: rashi dixit wrote:

hashes and stars. So the data cant be deciphered.
one approach the bit error analysis keeping correlation in mind etc?

Thanking you all
Rashi Dixit

Rashi,

I’m not sue why you are using tx_voice.py for this. It seems to make
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital
examples directory. This will modulate the bits with GMSK by default.
Keep in mind, though, that you want to modulate the data before
transmitting it over the air.

The GNU Radio file sink/source write and read files as binary data, so
the files will look like hashes and stars when viewed with a text
editor. You can use gnuradio-core/src/utils/read_*_binary.m in
Matlab/Octave to read these files.

However, I’m not sure you want to just compare the output file to the
input file unless you also keep track of a packet number. If the header
is missed or corrupted in the current implementation, the packet is
completely dropped, which would completely screw up your calculations
unless you can tell that a full packet has been lossed. Then, you have
to decide how you want to handle the BER calculation due to one lost
packet.

Tom