[Top][All Lists]

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

Re: [Discuss-gnuradio] UHD Error

From: Kapil Borle
Subject: Re: [Discuss-gnuradio] UHD Error
Date: Fri, 23 Aug 2013 23:21:28 -0400

Hi Marcus,

Adding an entry for the USRP in the arp table indeed solves the problem. But there is some discrepancy. As far as I know, I can add the entry using:
1. ping 
2. arp -i eth1 -s {HWADDR}
3. uhd_find_devices

If I use the 1st method, I run into the same problem, while the later two methods work. I have no clue why ping shouldn't work. 

Anyways, thanks for the help.


On Fri, Aug 23, 2013 at 9:20 PM, Marcus D. Leech <address@hidden> wrote:
On 08/23/2013 09:03 PM, Kapil Borle wrote:

I am trying to run benchmark_rx.py and the first time I execute it after booting up the PC, I encounter the error pasted at the end of this message. The error goes away when I try to run benchmark_rx again, but comes back again after rebooting and executing bechmark_rx. 
Some information about the PC
~$ uname -a
Linux ubuntu 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.3 LTS
Release: 12.04
Codename: precise

~$ gnuradio-config-info -v


Error Message:

~$ /usr/local/share/gnuradio/examples/digital/narrowband/benchmark_rx.py -m dbpsk -r 500000 -f 0.6e9 -a addr= --spec=A:0 -A TX/RX --rx-gain=20 -v -S 2
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-0-gf3a16983

Using Volk machine: avx_64_mmx

bits per symbol:     1
RRC roll-off factor: 0.35
FLL bandwidth:       6.28e-02
Timing bandwidth:    6.28e-02
Phase bandwidth:     6.28e-02
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 756 bytes

UHD Error:
    Control packet attempt 0, sequence number 1:
    RuntimeError: no control response, possible packet loss

UHD Error:
    Control packet attempt 1, sequence number 2:
    RuntimeError: no control response, possible packet loss

UHD Error:
    Control packet attempt 2, sequence number 3:
    RuntimeError: no control response, possible packet loss
Traceback (most recent call last):
  File "/usr/local/share/gnuradio/examples/digital/narrowband/benchmark_rx.py", line 141, in <module>
  File "/usr/local/share/gnuradio/examples/digital/narrowband/benchmark_rx.py", line 130, in main
    tb = my_top_block(demods[options.modulation], rx_callback, options)
  File "/usr/local/share/gnuradio/examples/digital/narrowband/benchmark_rx.py", line 57, in __init__
  File "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py", line 190, in __init__
    freq, gain, spec, antenna)
  File "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py", line 52, in __init__
    self.u = uhd.usrp_source(device_addr=args, stream_args=uhd.stream_args('fc32'))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 121, in constructor_interceptor
    return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 1699, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: link dead: timeout waiting for control packet ACK


This may just be an ARP issue.  When you first boot, there's no ARP cache entry for the USRP, so ARP has to run, and it may be that your IP stack is
  configured to drop packets that arrive at the interface during ARP negotiation, rather than holding them.   Just a guess.

With TCP, this isn't as big an issue, because TCP has a retry mechanism.  For UDP protocols (which UHD uses) this could be an issue.

Discuss-gnuradio mailing list

reply via email to

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