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.
Feng Andrew Ge <address@hidden>
David Barton <address@hidden>
Fri, April 29, 2011 10:35:52 AM
Re: [Discuss-gnuradio] Tunnel.py
In the patch I told you, please change 4096 to 4095,
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
Therefore, the cause is corruption under low SNR or
interference. The missing part is error correction
By applying the above patch, you can bypass this
python code problem.
Posted by David Barton (Guest)
on 2011-04-29 15:26
I tried the previously suggested patch that checked
the str_len of the
before unmaking the packet but errors still occurred.
I noticed that
printing the size fo packet out the errors occur when
the str_len is
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
mistaking the message length. Anyone have any ideas?
What do you mean that the receiver couldnt handle the
the sleeps put in?