I had a similar problem way back and found collided packets (corrupted packets
with ok=False). I started digging and found that my gr_probe_mag_sqrd_X was not
returning a high enough magnitude for the carrier sense to be tripped. This
also had to do with an issue I was having getting the xcvr2450 to tune to the
right tx/rx frequencies...
I suggest printing out the result of the magnitude squared to see if this is
the case as well for you guys.
Regards,
Jason T.
________________________________
From: Alex Zhang <cingular.a...@gmail.com>
To: j...@ettus.com
Cc: Tom Rondeau <trondeau1...@gmail.com>; gnuradio mailing list
<discuss-gnuradio@gnu.org>
Sent: Monday, June 18, 2012 9:07 PM
Subject: [Discuss-gnuradio] tunnel.py destination host unreachable -
Temporarily solution, due to too fast reply!
Hello Josh,
I have seen many guys complaining the tunnel.py failed in PING by the
"destination host unreachable", for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static ARP
table to work round this problem, but today I did some investigating and test,
and now I believe the too fast ARP reply from the destination causes that the
transmitter can not receive this reply or receive it with corrupted packets.
For example, if the usrp A send the ARP request at time T, then usrp B send
back the ARP reply at time T+delta. If the delta is too small, then A will
definitely fails to receive it.
The temp solution is as below (tunnel.py in csma_mac.main_loop), just add a
small delay for B to send back the ARP reply. This solution works well.
... ... @@ -185,7 +185,10 @@ def main_loop(self):
185 185 if not payload:
186 186 self.tb.send_pkt(eof=True)
187 187 break
188 -
188 +
189 + time.sleep(0.009) # delay 9ms before sending out the reply
190 + t2 = self.tb.source.u.get_time_now().get_real_secs()
191 + print 'reply at time ', t
189 192 if self.verbose:
190 193 print "Tx: len(payload) = %4d" % (len(payload),)
The root cause for this problem, I guess, should be that the duplex switching
time bwteen the TX and RX at USRP is not small enough. More details should be
about the duplex mechanism of the SBX daughter board. I hope there are some
other way to solve this problem. For example, I tried to specify the TX and RX
at different antennas (TX/RX for transmitter, RX2 for receiver) of the SBX,
but unfortunately it seems impossible.
Looking forward to your further comments.
Thanks,
Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.
---------- Forwarded message ----------
From: Alex Zhang <cingular.a...@gmail.com>
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou <idea...@gmail.com>
Cc: j...@ettus.com, gnuradio mailing list <discuss-gnuradio@gnu.org>
Weixian,
Here is a temp solution, not sure it works or not:
In the csma_mac.main_loop() of your tunnel.py, add a time_sleep(fixed_delay)
right after the payload is read from the OS. You can set fixed_delay as 0.01 to
0.1 and test the result.
And also, please set the CSMA threshold carefully to avoid possible collision.
Alex
On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou <idea...@gmail.com> wrote:
The following is the messages of the transmitter after I ping. The packages of
len(payload)=42 failed CRC check, but other packages succeed.
>URx: ok = True len(payload) = 101
>Tx: len(payload) = 90
>Tx: len(payload) = 54
>UTx: len(payload) = 220
>UTx: len(payload) = 326
>URx: ok = False len(payload) = 326
>Tx: len(payload) = 81
>UTx: len(payload) = 326
>UTx: len(payload) = 326
>UTx: len(payload) = 302
>URx: ok = False len(payload) = 302
>Tx: len(payload) = 78
>UTx: len(payload) = 220
>URx: ok = False len(payload) = 220
>Tx: len(payload) = 81
>UTx: len(payload) = 302
>URx: ok = False len(payload) = 302
>Tx: len(payload) = 70
>UTx: len(payload) = 110
>UTx: len(payload) = 240
>URx: ok = False len(payload) = 240
>Tx: len(payload) = 404
>Tx: len(payload) = 201
>UTx: len(payload) = 101
>UTx: len(payload) = 404
>Tx: len(payload) = 201
>Tx: len(payload) = 54
>UTx: len(payload) = 404
>Tx: len(payload) = 201
>Tx: len(payload) = 114
>UTx: len(payload) = 380
>Tx: len(payload) = 189
>Rx: ok = False len(payload) = 380
>UTx: len(payload) = 240
>UTx: len(payload) = 101
>UTx: len(payload) = 318
>UTx: len(payload) = 81
>UTx: len(payload) = 380
>Tx: len(payload) = 189
>Rx: ok = False len(payload) = 380
>URx: ok = False len(payload) = 189
>Tx: len(payload) = 302
>UTx: len(payload) = 90
>UTx: len(payload) = 350
>UTx: len(payload) = 101
>UTx: len(payload) = 380
>Tx: len(payload) = 189
>Rx: ok = False len(payload) = 380
>UTx: len(payload) = 70
>UTx: len(payload) = 81
>UTx: len(payload) = 101
>UTx: len(payload) = 70
>UTx: len(payload) = 42
>UTx: len(payload) = 42
>UTx: len(payload) = 42
>URx: ok = True len(payload) = 81
>Tx: len(payload) = 42
>UTx: len(payload) = 42
>URx: ok = True len(payload) = 101
>Tx: len(payload) = 42
>UTx: len(payload) = 81
>UTx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 101
>UTx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>UTx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>UTx: len(payload) = 42
>UTx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>UTx: len(payload) = 42
>UTx: len(payload) = 42
>UTx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 42
>URx: ok = False len(payload) = 42
>Tx: len(payload) = 81
>UTx: len(payload) = 101
>URx: ok = True len(payload) = 81
>Rx: ok = True len(payload) = 101
>
>
>
>
>On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou <idea...@gmail.com> wrote:
>
>Hi Alex,
>>After tried many times I found that the transmitter actually received
>>packages of len(payload)=42 from the receiver, but the the packages failed
>>CRC check (ok=false). I think some parameters need to be tuned, maybe bitrate?
>>
>>
>>
>>On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou <idea...@gmail.com> wrote:
>>
>>Hi Alex,
>>>I tried it. The problem is the same. The transmitter only showed tx message
>>>of len(payload) = 42, and the receiver showed both tx/rx messages of
>>>len(payload) = 42.
>>>
>>>
>>>
>>>On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang <cingular.a...@gmail.com> wrote:
>>>
>>>Weixian,
>>>>
>>>>
>>>>Could you please try the ping command like this (if you are working on
>>>>linux):
>>>>
>>>>
>>>>sudo ping 192.168.200.2 -i 0.01
>>>>
>>>>
>>>>-i 0.01 means the time interval between pings is 0.01 second. And tell me
>>>>what happened.
>>>>You can try different time intervals.
>>>>
>>>>
>>>>
>>>>On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang <cingular.a...@gmail.com> wrote:
>>>>
>>>>I did the test by myself, and the most of the time ARP queries failed.... I
>>>>met this problem when I do the OFDM link test, but that is because the
>>>>physical layer is not robust. But for this narrow band (GMSK) modulation, I
>>>>am not sure what the problem is.
>>>>>
>>>>>
>>>>>May Josh knows... :)
>>>>>
>>>>>
>>>>>
>>>>>On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang <cingular.a...@gmail.com>
>>>>>wrote:
>>>>>
>>>>>Something like discarded.
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou <idea...@gmail.com> wrote:
>>>>>>
>>>>>>What do you mean by "it may be consumed"?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang <cingular.a...@gmail.com>
>>>>>>>wrote:
>>>>>>>
>>>>>>>Did you see RX False at the receiver for the ARP reply? If that is not
>>>>>>>seen, it could be due to some reason causing the ARP reply is not sent
>>>>>>>out at all. Although you see the log for the TX packet in the CSMA
>>>>>>>mainloop, but it may be consumed before or when it goes to the
>>>>>>>transmitting path...
>>>>>>>>
>>>>>>>>
>>>>>>>>On Fri, Jun 15, 2012 at 10:49 AM, Weixian Zhou <idea...@gmail.com>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>>Yes, the ARP is replied. But another machine did not received and
>>>>>>>>showed "Destination Host Unreachable".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>On Fri, Jun 15, 2012 at 11:19 AM, Alex Zhang <cingular.a...@gmail.com>
>>>>>>>>>wrote:
>>>>>>>>>
>>>>>>>>>Do you check the ARP reply is sent out or not?
>>>>>>>>>>I am not sure if there are some flow control issues for the
>>>>>>>>>>networking.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>On Fri, Jun 15, 2012 at 10:02 AM, Weixian Zhou <idea...@gmail.com>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>>Thanks for responses. The problem that confused me is that when I
>>>>>>>>>>>on machine A:
>>>>>>>>>>>sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r 0.5M
>>>>>>>>>>>then
>>>>>>>>>>>sudo ifconfig gr0 192.168.200.1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>on machine B:
>>>>>>>>>>>sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r 0.5M
>>>>>>>>>>>then
>>>>>>>>>>>sudo ifconfig gr0 192.168.200.2
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I can see packages tx/rx succeed on both machines. But the ping
>>>>>>>>>>>failed and one machine did not rx. Why is that?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>On Thu, Jun 14, 2012 at 4:38 PM, Alex Zhang
>>>>>>>>>>><cingular.a...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>Most likely you did not set the freq and gain properly. Unstable
>>>>>>>>>>>physical layer communications cause the ARP routing failure.
>>>>>>>>>>>>Please use different frequencies for tx and rx.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou <idea...@gmail.com>
>>>>>>>>>>>>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>I was testing with tunnel.py and following the instructions in
>>>>>>>>>>>>README located in gnuradio/gr-digital/examples/narrwoband.
>>>>>>>>>>>>>I found that when I inputifconfig gr0 192.168.200.1 on machine A,
>>>>>>>>>>>>>and inputifconfig gr0 192.168.200.2 on machine B at the same time,
>>>>>>>>>>>>>both machines showed Tx and Rx packages.
>>>>>>>>>>>>>But when Iping 192.168.200.2 from machine A ( or ping
>>>>>>>>>>>>>192.168.200.1 from machine B respectively), one window of machine
>>>>>>>>>>>>>A only showed Tx packages and another window showed "Destination
>>>>>>>>>>>>>Host Unreachable". Machine B showed both Rx/Tx packages.
>>>>>>>>>>>>>It means that machine B can successfully received packages from
>>>>>>>>>>>>>machine A but A failed to receive replied packages from machine B.
>>>>>>>>>>>>>It confused me that the packages tx/rx were succeed before the
>>>>>>>>>>>>>ping. Anyone has idea?
>>>>>>>>>>>>>--
>>>>>>>>>>>>>
>>>>>>>>>>>>>Regards,Weixian Zhou
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>>Discuss-gnuradio mailing list
>>>>>>>>>>>>>Discuss-gnuradio@gnu.org
>>>>>>>>>>>>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>--
>>>>>>>>>>>>
>>>>>>>>>>>>Alex,
>>>>>>>>>>>>Dreams can come true – just believe.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>--
>>>>>>>>>>>
>>>>>>>>>>>Regards,Weixian Zhou
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>
>>>>>>>>>>Alex,
>>>>>>>>>>Dreams can come true – just believe.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>--
>>>>>>>>>
>>>>>>>>>Regards,Weixian Zhou
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>--
>>>>>>>>
>>>>>>>>Alex,
>>>>>>>>Dreams can come true – just believe.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>--
>>>>>>>
>>>>>>>Regards,Weixian Zhou
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>
>>>>>>Alex,
>>>>>>Dreams can come true – just believe.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>
>>>>>Alex,
>>>>>Dreams can come true – just believe.
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>
>>>>Alex,
>>>>Dreams can come true – just believe.
>>>>
>>>
>>>
>>>
>>>--
>>>
>>>Regards,Weixian Zhou
>>>
>>>
>>>
>>
>>
>>
>>--
>>
>>Regards,Weixian Zhou
>>
>>
>>
>
>
>
>--
>
>Regards,Weixian Zhou
>
>
>
--
Alex,
Dreams can come true – just believe.
--
Alex,
Dreams can come true – just believe.
_______________________________________________
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
