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 <[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 <http://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
