[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Tunnel.py exception

From: Feng Andrew Ge
Subject: Re: [Discuss-gnuradio] Tunnel.py exception
Date: Fri, 29 Apr 2011 10:35:52 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8


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.


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 sender speed?
Where were
the sleeps put in?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]