I have been running it for a few days and have no issues now. The tunnel seems
to continue working for days.
Thanks for your help!
Dave
________________________________
From: Feng Andrew Ge <gefengflo...@gmail.com>
To: David Barton <david.barto...@yahoo.com>
Cc: discuss-gnuradio@gnu.org
Sent: Fri, April 29, 2011 4:02:06 PM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception
From my experience, the patch does the trigger.
if (string_len> 18)& (string_len< 4095) :
Andrew
On 04/29/2011 04:00 PM, David Barton wrote:
Ok. Would the case I described also cause the same shape exception killing the
receive chain. Because anytime it fails on me it always is with 4095 which I
cant figure out why.
>
>Thanks,
>Dave
>
>
>
>
________________________________
From: Feng Andrew Ge <gefengflo...@gmail.com>
>To: David Barton <david.barto...@yahoo.com>
>Cc: discuss-gnuradio@gnu.org
>Sent: Fri, April 29, 2011 2:57:28 PM
>Subject: Re: [Discuss-gnuradio] Tunnel.py exception
>
>Dave, yes, what you described is more likely to happen. That will corrupt
>your
>received data.
>
>
>What I described is a special case (with less probability) explaining why you
>got a payload with a length of 4095 bytes.
>
>
>Andrew
>
>On 04/29/2011 01:52 PM, David Barton wrote:
>Thank you for the explanation. I will try this and let you know.
>>
>>I had one question though. It seems odd to me that the interference will
>>always
>>cause the header to be corrupted to all ones for both sets of 2 bytes .
>>Wouldnt
>>it be more likely to have sent 80 bytes payload and have lets say 1 bit
>>corrupted ineach (like both change to 81 instead of 80 ) which would cause a
>>error I would think. Since I always see 4095 length as error it seems weird
>>that
>>so many bits are corrupted and all corrputed to be all 1's. I just want to
>>make
>>sure I understand the root cause of the issue.
>>
>>Thanks,
>>Dave
>>
>>
>>
>>
________________________________
From: Feng Andrew Ge <gefengflo...@gmail.com>
>>To: discuss-gnuradio@gnu.org; David Barton <david.barto...@yahoo.com>
>>Sent: Fri, April 29, 2011 10:35:52 AM
>>Subject: Re: [Discuss-gnuradio] Tunnel.py exception
>>
>>Dave,
>>
>>In the patch I told you, please change 4096 to 4095, that is,
>>
>>if (string_len> 18)& (string_len< 4095) :
>>
>>Here is how this happened:
>>
>>When you send a packet in GNU Radio, there is a header right ahead the
>>payload
>>(plus CRC bits).
>>The header has 4 bytes which consist of two same 2-byte information. In each
>>2-byte, the 12 least significant bits represent the length
>>of your payload plus CRC; the 4 most significant bits represent whitening
>>offset
>>information.
>>
>>When you receive the packet, the two lengths contained in each of the 2-byte
>>in
>>the header are compared. If they are the same, say, both x, the receiver
>>will get the next x bytes information; otherwise, the receiver assumes that
>>the
>>packet is corrupted.
>>
>>
>>Currently GNU Radio doesn't have any error correction code. Therefore, the
>>header can be corrupted under low SNR or interference.
>>Even with corruption or interference, in probability, sometimes you will
>>still
>>see the two length information in the header are the same.
>>
>>
>>In your case (of course it happened to me before, otherwise I won't know),
>>you
>>see 4095 of string_len, it means that the 12 least significant bits
>>in each of the 2 bytes (in the header) are all 1's, that is " 1111 1111 1111
>>"
>>(=4095). However, the contained payload---not matter what it is---is
>>actually
>>wrong.
>>
>>Therefore, the cause is corruption under low SNR or interference. The missing
>>part is error correction code.
>>
>>By applying the above patch, you can bypass this python code problem.
>>
>>Andrew
>>
>>
>>Posted by David Barton (Guest)
>>on 2011-04-29 15:26
>>
>>I tried the previously suggested patch that checked the str_len of the
>>message
>>before unmaking the packet but errors still occurred. I noticed that
>>when
>>printing the size fo packet out the errors occur when the str_len is
>>exactly
>>equal to 4095. There is no reason it should be that length as I am only
>>periodically sending short ping packets. I have yet to figure out why it
>>is
>>mistaking the message length. Anyone have any ideas?
>>
>>Thomas,
>>
>>What do you mean that the receiver couldnt handle the sender speed?
>>Where were
>>the sleeps put in?
>>
>>Thanks,
>>Dave
>>
>>
>>
>>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
