On Sat, Aug 13, 2011 at 7:13 PM, Nazmul Islam
mnis...@winlab.rutgers.edu wrote:
Hello,
This is Nazmul, a PhD student of Rutgers University. I am using a modified
form of 'benchmark_Tx.py' and 'benchmark_Rx.py' for my research. I am
transmitting a random binary sequence and calculating the bit error rate at
the receiver (BER). Basically, I am generating a long binary sequence,
grouping them into different packets and then transmitting the packets using
'benchmark_Tx' program. I receive the packets using 'benchmark_Rx.py' and
then find the BER. The program works at high transmitter amplitude, i.e.,
when channels are good. However, when I start lowering the transmitter
amplitude, i.e. create bad channels, at some point, I get the following
error:
Exception in thread Thread-1:
Traceback (most recent call last):
File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner
self.run()
File /usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/pkt.py,
line 164, in run
self.callback(ok, payload)
File ./rec_randombingen.py, line 97, in rx_callback
(ide,pktno,) = struct.unpack('!cH', payload[0:3])
error: unpack requires a string argument of length 3
After showing this error, the whole programs. Let's assume that I am
transmitting 100 packets. If this error occurs at 20-th packet, the
benchmark_rx does not receive the next 80 packets. This really hampers the
calculation of packet loss probability and bit error rate.
I guess, for very bad channels, noise is acting as erasure, i.e., some part
of the packet header is getting erased. Ideally, I would like the program to
assume this packet to be 'lost' and move on to receiving the remaining
packets. It is OK with me if I lose a packet due to this type of error but
how can I make sure that the whole program does not stop due to this error?
Your feedback will be very appreciated.
Thanks,
Nazmul
Nazmul,
There are certain cases where the frames are received with errors that
are just such a way that passes the checks and are delivered to the
callback function. My guess is that it occurs when the received packet
length is received as 0. When the unpack action happens with no
payload, it throws an error.
One way to work around this is to put in an extra check for the packet
size, if this is indeed the problem. You can also put a try/except
block around the code to catch when those errors happen.
In my previous experience, these issues happened rarely, but it sounds
like you are having a bigger problem with it. Could be that I was
running in a higher SNR environment, so that these errors were more
rare.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
