Re: [Discuss-gnuradio] Tunnel.py exception

[David Barton]

I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets.

 

The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration lower bandwidth tests until I find a way to fix the problem.

 

Has anyone else had this problem with tunnel.py?

Thanks,

Dave

---

From: Tom Rondeau <address@hidden>
To: David Barton <address@hidden>
Cc: address@hidden
Sent: Thu, April 21, 2011 10:22:39 AM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

On Wed, Apr 20, 2011 at 9:25 AM, David Barton <address@hidden> wrote:

I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out:

Rx: ok = True  len(payload) =   82
Tx: len(payload) =   82
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 525, in __bootstrap_inner
    self.run()
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py", line 162, in run
    ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1()))
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py", line 183, in unmake_packet
    payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset)
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py", line 95, in dewhiten
    return whiten(s, o)        # self inverse
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py", line 91, in whiten
    z = sa ^ random_mask_vec8[o:len(sa)+o]
ValueError: shape mismatch: objects cannot be broadcast to a single shape


After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded.

Anyone have any clue what could be causing this issue?

Thanks,
Dave

I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen.

We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem.

Tom