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 <[email protected]> To: David Barton <[email protected]> Cc: [email protected] 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 <[email protected]> >To: [email protected]; David Barton <[email protected]> >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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
