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 192.168.10.2
2. arp -i eth1 -s 192.168.10.2 {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.
Kapil
On Fri, Aug 23, 2013 at 9:20 PM, Marcus D. Leech <[email protected]> wrote:
> On 08/23/2013 09:03 PM, Kapil Borle wrote:
>
> Hi,
>
> 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
> v3.7.0-104-g6bf21a5a
>
> Thanks,
> Kapil
>
>
> *Error Message:*
>
> ~$ /usr/local/share/gnuradio/examples/digital/narrowband/benchmark_rx.py
> -m dbpsk -r 500000 -f 0.6e9 -a addr=192.168.10.2 --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
>
> Demodulator:
> 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>
> main()
> 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__
> options.verbose)
> 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
>
>
> Thanks,
> Kapil
>
> 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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
