Trying out the tunnel.py example, we are transmitting a ping request
between two USRP2s. The receiving USRP should respond immediately with a
ping reply what the outpout is also saying.
At all, this ping reply is not send. We can bypass this by deploying a
time.sleep(0.05) at the RX-USRP before sending the ping reply
(txpath.send_pkt(payload)). Thus, the transmission is left behind for
50ms which is not very convenient.
Is it because the hardware components have to settle and the tx/rx
switching takes some time? Or might there be some configuration
settings? A colleague of mine is supposing something about different
transmitting mode like streaming and sending just bursts?
Thanks a lot in advance, I really appreciate your help!
Florian -
Please don’t e-mail the same question to the list in multiple threads -
it
actually makes it more difficult for people to help you in a coherent
manner.
Switching between RX and TX on the XCVR daughterboard should have very
minimal overhead - certainly not 6 ms. As soon as it sees the first TX
packet, it should automatically switch.
It is possible that tunnel.py is not properly closing the TX stream, and
thus confusing the USRP. Your colleague might be on to something - have
you looked through the tunnel.py source to see how it is handling the TX
packets?
Cheers,
Ben
On Fri, Feb 3, 2012 at 4:28 AM, Florian Schlembach <
Please don’t e-mail the same question to the list in multiple threads -
it actually makes it more difficult for people to help you in a
coherent
manner.
Sorry, I thought about to specify that a little bit more to make it
findable more easily afterwards.
It is possible that tunnel.py is not properly closing the TX stream,
and
thus confusing the USRP. Your colleague might be on to something -
have
you looked through the tunnel.py source to see how it is handling the
TX
packets?
Yes, we have already looked into it and were trying to point that out
how to setup a “burst mode” in the source files in /gr-digital/lib/.
Ultimately, we have not yet been successful.
I found something on the mailinglist that there might also be
SEND_MODE_ONE_PACKET function beside the SEND_MODE_FULL_BUFF but
actually it affects nothing as I replace it in the gr_uhd_usrp_sink.cc
(after recompling etc.).
In another thread it was mentioned that the transmitting buffer is not
transmitted until it is full which is being done until the timeout time
is elapsed.
Does anybody have an idea how the waiting time could be skipped or this
ONE_PACKET mode could be set up correctly?