[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Transmitting a binary 'ones and zeroes' file for
Re: [Discuss-gnuradio] Transmitting a binary 'ones and zeroes' file for Bit Error Analysis
Fri, 29 Jun 2007 09:13:59 +0100
Thunderbird 126.96.36.199 (Windows/20070604)
rashi dixit wrote:
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
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