Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
From: Tuan (Johnny) Ta ta.tu...@gmail.com To: Marcus D. Leech mle...@ripnet.com; david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Monday, October 31, 2011 6:01 PM Subject: Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech mle...@ripnet.com wrote: On 20/10/2011 10:25 AM, David Barton wrote: I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
[Discuss-gnuradio] (no subject)
Marcus, How do I know if I am running in full duplex for tunnel.py? Is there a command line argument for that? I think I am running half duplex only since only using the 1 antenna port. If I am running half duplex then I am unsure why I would be having reflected packets. Thanks, Dave Message: 25 Date: Thu, 20 Oct 2011 11:24:04 -0400 From: Marcus D. Leech mle...@ripnet.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue Message-ID: 4ea03d14.3080...@ripnet.com Content-Type: text/plain; charset=iso-8859-1; Format=flowed On 20/10/2011 10:25 AM, David Barton wrote: I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321 [ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855 [ 63.84 ] Backing off for 0.001 sec [ 63.84 ] Backing off for 0.002 sec [ 63.85 ] Backing off for 0.004 sec [ 63.85 ] Backing off for 0.008 sec [ 63.86 ] Backing off for 0.016 sec [ 63.87 ] Backing off for 0.032 sec [ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321 [ 63.89 ] Rx
[Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321 [ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855 [ 63.84 ] Backing off for 0.001 sec [ 63.84 ] Backing off for 0.002 sec [ 63.85 ] Backing off for 0.004 sec [ 63.85 ] Backing off for 0.008 sec [ 63.86 ] Backing off for 0.016 sec [ 63.87 ] Backing off for 0.032 sec [ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321 [ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448 [ 63.9 ] Backing off for 0.064 sec [ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855 Does anyone have any idea why this could be occurring? I thought maybe it would be a physical reflection but dont understand why ping packets would not be reflected in that case. Thanks, Dave___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
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 (=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
Re: [Discuss-gnuradio] Tunnel.py exception
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 From: Thomas Hauer t...@thomashauer.at To: William Cox wc...@ncsu.edu; David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Wed, April 27, 2011 8:39:26 AM Subject: AW: [Discuss-gnuradio] Tunnel.py exception Hello William, Hello David, i had this problem too. I changed my tunnel.py to understand mac better into a simple program which sends a packet and when the receiver gets the packet the receiver sends an acknowledge back. After a short time period the exception was thrown. I found out that the gnu which is the receiver cannot handle the speed of the sender – gnu so the exception was raised. I inserted some time.sleep()’s in the sender and the exception was gone. Kind Regards Von:discuss-gnuradio-bounces+th=thomashauer...@gnu.org [mailto:discuss-gnuradio-bounces+th=thomashauer...@gnu.org] Im Auftrag von William Cox Gesendet: Donnerstag, 21. April 2011 16:40 An: David Barton Cc: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] Tunnel.py exception I've recently been using tunnel.py for 1/2 hr tests with no problems. I'm using the basic_tx/rx boards with a low frequency (5 MHz) and 1 Mbit datarate. On Thu, Apr 21, 2011 at 10:31 AM, David Barton david.barto...@yahoo.com wrote: I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave From:Tom Rondeau trondeau1...@gmail.com To: David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Thu, April 21, 2011 10:22:39 AM Subject: Re: [Discuss-gnuradio] Tunnel.py exception On Wed, Apr 20, 2011 at 9:25 AM, David Barton david.barto...@yahoo.com wrote: I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out: Rx: ok = True len(payload) = 82 Tx: len(payload) = 82 Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib64/python2.6/threading.py, line 525, in __bootstrap_inner self.run() File /usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py, line 162, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o) # self inverse File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded. Anyone have any clue what could be causing this issue? Thanks, Dave I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen. We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
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 (=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
Re: [Discuss-gnuradio] Tunnel.py exception
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 (=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
Re: [Discuss-gnuradio] Tunnel.py exception
Andrew, I tried making the change you suggested but it results in NameError: global name 'string_len' is not defined. Any idea? Thanks, Dave Message: 11 Date: Thu, 21 Apr 2011 16:26:56 -0400 From: Feng Andrew Ge gefengflo...@gmail.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Tunnel.py exception Message-ID: 4db09310.4020...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dave, To bypass this problem, change the pkt.py file. In the end, after msg = self.rcvd_pktq.delete_head() add if (string_len 18) (string_len 4096) : ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) Andrew On 04/21/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Thu, 21 Apr 2011 07:31:33 -0700 (PDT) From: David Bartondavid.barto...@yahoo.com To: Tom Rondeautrondeau1...@gmail.com Cc:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Tunnel.py exception Message-ID:72896.27694...@web120212.mail.ne1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration?lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave From: Tom Rondeau trondeau1...@gmail.com To: David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Thu, April 21, 2011 10:22:39 AM Subject: Re: [Discuss-gnuradio] Tunnel.py exception On Wed, Apr 20, 2011 at 9:25 AM, David Barton david.barto...@yahoo.com wrote: I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out: Rx: ok = True len(payload) = 82 Tx: len(payload) = 82 Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib64/python2.6/threading.py, line 525, in __bootstrap_inner self.run() File /usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py, line 162, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o) # self inverse File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded. Anyone have any clue what could be causing this issue? Thanks, Dave I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen. We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tunnel.py MAC address
When I run tunnel.py and configure the grX interface IP address I noticed using ifconfig that a seemingly random MAC address is assigned to the gr interface. Does ayone know if there is any logic to how the address is created? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tunnel.py hanging after some time
Hi, I am having trouble with the tunnel.py in the digital foler appear to stop working after a while when using lower bitrates (around 0.5 MB/s) . When I first set up the newtork I am able to ping other nodes with no problem. After some time (sometimes less than half an hour) the pings are no longer sucessful. I checked and the gr interface remains up and correctly configured with the ip address. When I ping out any host I can see the transmission on a spectrum analyzer so I know the transmit path is still functioning. Higher bit rates seem to work for much longer periods of time. Has anyone else had similar issues with these bit rates? If so has anyone figured out the cause of the lost connectivity? I am using USRP2s with WBX cards and using 400 MHz carrier frequency. No other application traffic is being sent over the network. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wireshark issue
Hi, I am relatively new to GNU Radio. I set up a simple experiment of connecting a file source directly to the usrp sink and monitoring the traffic on the ethernet port using wireshark. The source file simply contains the letters abc. When I ran the flowgraph in GRC it did seem to initiate traffic on the ethernet interface to the USRP but I could not find the string abc in any ethernet frame. I thought that since there is no modulation or any other manipulation of the source data in the flowgraph before the usrp that I would be able to find this data string in the ethernet frame. Is there anything the USRP sink block could be doing on the host side that would alter the data before it gets sent out over ethernet interface to the USRP? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple digital data transmitter
Hi, I have set up the following simple digital data transmitter: File source -à throttle -à packet encoder --- DBPSK modulator -à USRP2 File size sample rate samples/sym - 2 samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
Thanks Eric. So the packet encoder samples /symbol does not affect the bit rate but just needs to match the dpsk samples/ symbol rate? Dave From: Eric Blossom e...@comsec.com To: David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Wed, May 12, 2010 2:02:42 PM Subject: Re: [Discuss-gnuradio] Simple digital data transmitter On Wed, May 12, 2010 at 09:06:13AM -0700, David Barton wrote: Hi, I have set up the following simple digital data transmitter: File source -à throttle -à packet encoder --- DBPSK modulator -à USRP2 File size sample rate samples/sym - 2 samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave Remove the throttle, it's not needed. Your baseband sample rate is 100M/32 - 3.125MS/s You're using 2 samples/symbol, thus your symbol rate is 3.125MS/s / 2 - 1.5625Msymbols/s And since you're using DBPSK, you're getting 1 bit/symbol, thus your raw over-the-air bit rate is 1.5625Mbit/s Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DPSK Modulator and Demodulator
From: Jason Uher jasonu...@gmail.com To: discuss-gnuradio@gnu.org; david.barto...@yahoo.com Sent: Thu, April 22, 2010 7:51:41 AM Subject: Re: [Discuss-gnuradio] DPSK Modulator and Demodulator Thanks Jason. I have not delved into the code of the dbpsk demodulator GRC block yet so I am unsure. I was hoping someone with experience using this GRC block could answer quicker. I believe the block has a root raised cosine filter in it so it would make sense that it would have zeros to start but I am not sure why I get 13 bytes of output data back from 2 bytes of input data. Thanks, Dave Hi, I am having trouble the the DBPSK mod and demod blocks. My flow graph is: file source - DBPSKmod - DBPSKdemod - file sink If anyone knows why the output file of the whole graph would be 13 bytes or if I am missing something please let me know. Thanks, Dave On Wed, Apr 21, 2010 at 9:46 PM, marcin_w mwie9...@uni.sydney.edu.au wrote: My mistake, i didn't realise you were using the available DBPSK block. The Packed to Unpacked block is already part of this Modulator, so disregard my comment. Does the bpsk block you're using have some form of timing correction in it? More than likely the data is being run through some sort of filter (either explicitly or effectively) and the zeros at the beginning are a warm up from the padding. If you'd like the output to be 'nice' from a mathematical point of view you will have to deconstruct the mod/demod blocks a little bit and remove the timing correction stages and make sure that your simulated channel does not introduce any timing corrections. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 FPGA documentation
Hi, Is there any documentation or source code available for signal processing done in the USRP2 FPGA? I have seen lots of block diagrams, etc. for USRP but been unable to find anythign similar for usrp 1. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DPSK Modulator and Demodulator
Hi, I am having trouble the the DBPSK mod and demod blocks. My flow graph is: file source - DBPSKmod - DBPSKdemod - file sink The file source is a 2 byte text file set to not repeat The default parameters were used for the DBPSKmod and demod blocks (including 2 Samples/Symbol) When I run the graph the output text file becomes 13 bytes long and they are almost all zeros. I am not sure how it gets to be that length. I tried connecting the ouput of the DBPSKmod directly to the file sink and the file size was 256 bytes. This matched my expectations based on: 2bytes input file * 8bits/byte * 1Symbol/bit * 2 complex samples/Symbol* 8bytes /complex sample = 256 byte output file. If anyone knows why the output file of the whole graph would be 13 bytes or if I am missing something please let me know. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFT block's use of sampling rate
Hi, In GRC I hooked up a signal source with a 100kHz sampling rate directly to a FFT sink. I accidentally listed the FFT sampling frequency as 200kHz. I noticed that it did not complain and all it did was shift the actual signal source frequency by a factor of 2. So my guess would be that the FFT block is not actually using the sampling rate parameter in the FFT calculations except to just scale the frequency axis. Is that accurate? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Low Pass filter and DPSK params
Hi, I have questions about the parameters in the DBPSK and Low Pass Filter blocks in GRC. Low Pass Filter block: 1) If I set the lowpass filter block to interpolate by a factor of 10 should the sampling rate parameter by set to the input sampling rate or the output sampling rate since they will obviously differ by a factor of 10? 2) If I set the lowpass filter block to interpolate by a factor of 10 is the filtering operation performed before interpolation or after interpolation? (Can the filter get rid of the spectral copies centered at multiples of the input sample rate that are created during interpolation or do I need another lowpass filter afterwards to remove these spectral copies?) DBPSK block: 1) What exactly is the Samples / Symbol parameter mean? I am trying to figure out what the relationship is between the input sample rate (bytes per second) to the output sample rate in (complex samples per second). 2) Since the input is bytes is each bit of the byte converted to a separate symbol meaning get 8 symbols for each imput sample(each byte)? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
