Re: [Discuss-gnuradio] Need to resolve error: "Unpack requires a string argument of length 3"

[Tom Rondeau]

On Sat, Aug 13, 2011 at 7:13 PM, Nazmul Islam
<address@hidden> 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