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 20dBattenuator between them. The
settings I am using on both sides for tunnel.pyare:
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 ofthe 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.
When I use VLC to stream a video from computer A to computer B over
beginning originates from computer A. If the packet originated from
[ 63.63 ] Backing off for 0.008 sec
[ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448
[ 63.76 ] Backing off for 0.032 sec
[ 63.79 ] Backing off for 0.008 sec
[ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855
[ 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
There’s generally only about 45dB of isolation available between TX and
RX, so if you’re running in full-duplex, your receiver will see its
own transmissions.
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.
What do you mean my zero-stuffing the TX frames? And how would it help
with
the turn-around time of the XCVR2450 daughterboard? Do you mean I should
transmit a zero-filled packet before any real packet, so that the
receiving
side (A in my scenario) has time to switch back to receiving before the
real packet arrives?
What do you mean my zero-stuffing the TX frames? And how would it help
with the turn-around time of the XCVR2450 daughterboard? Do you mean I
should transmit a zero-filled packet before any real packet, so that
the receiving side (A in my scenario) has time to switch back to
receiving before the real packet arrives?
The transmit side assumes that the combination of RX-to-TX and TX-to-RX
transition experienced by both sides is non-zero. So, you get
the transmit side to simply send some idle 0s, and then the actual
start-of-frame data, etc. What happens in these situations in my
experience
is that the start-of-frame gets missed during the switchover
interval. So if the transmit side sends zeros (or, really, anything
other than
the start-of-frame sequence) for a “little while” after commencing a
transmit burst, you’re less likely to run into TX-to-RX transition
issues.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Thanks for the explanation. I managed to get the system working by
introducing a delay before every packet transmission. I know it’s a hack
but that’s the quickest method I can think of. The minimum delay that I
can
get it to work is 11ms. It seems quite large. Is this reasonable for the
turn-around time (from TX to RX) of the XCVR2450?
Thanks for the explanation. I managed to get the system working by
introducing a delay before every packet transmission. I know it’s a
hack but that’s the quickest method I can think of. The minimum delay
that I can get it to work is 11ms. It seems quite large. Is this
reasonable for the turn-around time (from TX to RX) of the XCVR2450?
Johnny
That sounds like the right order-of-magnitude, yes.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
broadcasts an ARP packet to find the MAC address of B’s IP. B gets the
Thank you,
Johnny
We used to have this problem “back in the day” with packet-radio, using
analog FM transceivers–they were often notoriously sluggish
in turning around the TX/RX logic.
You might try zero-stuffing the TX frames–that’s basically what we did
back in the day. Although the XCVR2450 short turn around fairly
quickly, it’s not infinitely quick.
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 [email protected]
wrote:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.