Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: UHD error on first connection (Marcus Leech)
2. Re: UHD error on first connection (Miklos Maroti)
3. Re: UHD error on first connection (Miklos Maroti)
4. Re: Transport Application Notes for Mac OS X
(Perelman Nathan (Nathan))
5. ??: Running USPR B210 got an error (chun-hong_zha...@agilent.com)
6. Re: ??: Running USPR B210 got an error (Marcus D. Leech)
7. GPSDO N210 time problem (bob wole)
8. Building monoloithic static UHD library (Alexander Buckley)
9. Re: GPSDO N210 time problem (Marcus D. Leech)
10. Re: GPSDO N210 time problem (Sivan Toledo)
11. Re: GPSDO N210 time problem (Nowlan, Sean)
12. Manual UDP Output to USRP N200 (Joseph Payton)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Dec 2013 17:24:05 +0000 (UTC)
From: Marcus Leech <mle...@ripnet.com>
To: mmar...@math.u-szeged.hu
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD error on first connection
Message-ID: <915734774.28007.1386005045349.JavaMail.mail@webmail01>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131202/906f7e69/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 2 Dec 2013 22:03:29 +0100
From: Miklos Maroti <mmar...@math.u-szeged.hu>
To: Marcus Leech <mle...@ripnet.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD error on first connection
Message-ID:
<CAEUdg=DG3x=y2naXKkSFTs=nwqjjdkhsfqa3kaoubonsxaa...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Marcus,
On Mon, Dec 2, 2013 at 6:24 PM, Marcus Leech <mle...@ripnet.com> wrote:
> You might look here for hints on configuring your ARP parameters:
>
> http://www.linuxforu.com/2009/08/linux-network-stack-administration-a-developers-approach/
I have tried to play with the ARP parameters, but no effect.
>
> But given that PING works, and other things don't, I wonder if you have a
> firewall issue? What happens if you
> turn off your hosts firewall temporarily?
I do not have firewall, or at least I have tried to turn it off with
sudo ufw disable. No effect, same problem.
> Are you directly connected to your USRP2, or through a switch or router?
I think it is directly connected, but I do not have physical access to
the machine(s). It is at the orbit-lab at Rutgers. Here is their
description of such a node:
PUSpeed: 3401MHz
HDSize: 55GiB (60GB)
HDSerialNumber:ED1234A000011291
LastInventory: 14:11:51 10/31/13
MEM: 8GiB
CPUType: Intel Corp. Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz 6.10.7
IF NAME: eth0
IF MAC: 68:05:ca:0d:2a:6e
DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection [8086:10D3]
DEV ID: 8086:10D3
IF NAME: eth1
IF MAC: 00:03:1d:0a:98:d7
DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection [8086:10D3]
DEV ID: 8086:10D3
IF NAME: eth2
IF MAC: 00:03:1d:0a:98:d8
DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection [8086:10D3]
DEV ID: 8086:10D3
IF NAME: wlan0
IF MAC: 00:15:6d:84:fb:7a
DEV TYPE: Atheros Communications Inc. [168C]AR928X Wireless Network
Adapter (PCI-Express) [168C:2A]
DEV ID: 168C:002A
DEV TYPE: USRP2 / N-Series Device
DEV ID: FFFE:0003
UHD VERSION: UHD_003.005.000-0-unknown
SERIAL: 1231
DEV TYPE: SBX
DEV ID: FFFE:0007
> on Dec 02, 2013, Miklos Maroti <mmar...@math.u-szeged.hu> wrote:
>
> Hi Marcus,
>
> On Mon, Dec 2, 2013 at 5:04 PM, Marcus Leech <mle...@ripnet.com> wrote:
>> I wonder if your IP stack is configured to discard-during-ARP, rather than
>> hold-during-ARP ? That might explain this issue.
>
> I do not know. How can I check how it is configured?
>
>> Try pinging the device before doing the uhd_usrp_probe -- this will be
>> instructive as to what might be going on .
>
> Ping works perfectly and does not help at all. Even after the ping the
> first uhd_usrp_probe fails, the second works.
>
> One more thing, if I quickly try to do an uhd_usrp_probe right after
> the second, then that can also fail, but I do not have the error
> message at hand. I will try to get that and post it here.
Ok, after issuing the first uhd_usrp_probe command the next
uhd_usrp_probe or uhd_find_devices will not find the device right
away, only after a 1 sec delay. If I use a ping after the first faild
uhd_usrp_probe, then the ping takes a long time:
root@node1-1:~# uhd_find_devices; ping -c1 192.168.10.2;
uhd_usrp_probe; ping -c1 192.168.10.2
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.002-0-unknown
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name:
serial: 1231
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_req=1 ttl=32 time=1.12 ms
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.128/1.128/1.128/0.000 ms
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.002-0-unknown
-- 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
Error: RuntimeError: link dead: timeout waiting for control packet ACK
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_req=1 ttl=32 time=753 ms
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 753.226/753.226/753.226/0.000 ms
Miklos
------------------------------
Message: 3
Date: Mon, 2 Dec 2013 22:36:19 +0100
From: Miklos Maroti <mmar...@math.u-szeged.hu>
To: Marcus Leech <mle...@ripnet.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD error on first connection
Message-ID:
<CAEUdg=agsrhe2ss7az0_o4by8ixa2yaomsdwwtdrkuub+dh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Guys,
It seems that I have found a solution, but it is not clear what the
problem was and why has it disappeared. Standard 64-bit ubuntu 12.04
with 3.5 kernel does not work, however upgrading just the kernel to
3.8 (but still using 12.04, the kernel is backported from 13.04)
fixed the problem. So people should be aware.
Miklos
On Mon, Dec 2, 2013 at 10:03 PM, Miklos Maroti <mmar...@math.u-szeged.hu> wrote:
> Hi Marcus,
>
> On Mon, Dec 2, 2013 at 6:24 PM, Marcus Leech <mle...@ripnet.com> wrote:
>> You might look here for hints on configuring your ARP parameters:
>>
>> http://www.linuxforu.com/2009/08/linux-network-stack-administration-a-developers-approach/
>
> I have tried to play with the ARP parameters, but no effect.
>
>>
>> But given that PING works, and other things don't, I wonder if you have a
>> firewall issue? What happens if you
>> turn off your hosts firewall temporarily?
>
> I do not have firewall, or at least I have tried to turn it off with
> sudo ufw disable. No effect, same problem.
>
>> Are you directly connected to your USRP2, or through a switch or router?
>
> I think it is directly connected, but I do not have physical access to
> the machine(s). It is at the orbit-lab at Rutgers. Here is their
> description of such a node:
>
> PUSpeed: 3401MHz
> HDSize: 55GiB (60GB)
> HDSerialNumber:ED1234A000011291
> LastInventory: 14:11:51 10/31/13
> MEM: 8GiB
> CPUType: Intel Corp. Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz 6.10.7
> IF NAME: eth0
> IF MAC: 68:05:ca:0d:2a:6e
> DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection
> [8086:10D3]
> DEV ID: 8086:10D3
> IF NAME: eth1
> IF MAC: 00:03:1d:0a:98:d7
> DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection
> [8086:10D3]
> DEV ID: 8086:10D3
> IF NAME: eth2
> IF MAC: 00:03:1d:0a:98:d8
> DEV TYPE: Intel Corporation [8086]82574L Gigabit Network Connection
> [8086:10D3]
> DEV ID: 8086:10D3
> IF NAME: wlan0
> IF MAC: 00:15:6d:84:fb:7a
> DEV TYPE: Atheros Communications Inc. [168C]AR928X Wireless Network
> Adapter (PCI-Express) [168C:2A]
> DEV ID: 168C:002A
> DEV TYPE: USRP2 / N-Series Device
> DEV ID: FFFE:0003
> UHD VERSION: UHD_003.005.000-0-unknown
> SERIAL: 1231
> DEV TYPE: SBX
> DEV ID: FFFE:0007
>
>> on Dec 02, 2013, Miklos Maroti <mmar...@math.u-szeged.hu> wrote:
>>
>> Hi Marcus,
>>
>> On Mon, Dec 2, 2013 at 5:04 PM, Marcus Leech <mle...@ripnet.com> wrote:
>>> I wonder if your IP stack is configured to discard-during-ARP, rather than
>>> hold-during-ARP ? That might explain this issue.
>>
>> I do not know. How can I check how it is configured?
>>
>>> Try pinging the device before doing the uhd_usrp_probe -- this will be
>>> instructive as to what might be going on .
>>
>> Ping works perfectly and does not help at all. Even after the ping the
>> first uhd_usrp_probe fails, the second works.
>>
>> One more thing, if I quickly try to do an uhd_usrp_probe right after
>> the second, then that can also fail, but I do not have the error
>> message at hand. I will try to get that and post it here.
>
> Ok, after issuing the first uhd_usrp_probe command the next
> uhd_usrp_probe or uhd_find_devices will not find the device right
> away, only after a 1 sec delay. If I use a ping after the first faild
> uhd_usrp_probe, then the ping takes a long time:
>
> root@node1-1:~# uhd_find_devices; ping -c1 192.168.10.2;
> uhd_usrp_probe; ping -c1 192.168.10.2
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.002-0-unknown
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: usrp2
> addr: 192.168.10.2
> name:
> serial: 1231
>
>
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2: icmp_req=1 ttl=32 time=1.12 ms
>
> --- 192.168.10.2 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 1.128/1.128/1.128/0.000 ms
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.002-0-unknown
>
> -- 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
> Error: RuntimeError: link dead: timeout waiting for control packet ACK
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2: icmp_req=1 ttl=32 time=753 ms
>
> --- 192.168.10.2 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 753.226/753.226/753.226/0.000 ms
>
> Miklos
------------------------------
Message: 4
Date: Mon, 2 Dec 2013 17:54:50 -0500
From: "Perelman Nathan (Nathan)" <nperel...@lgsinnovations.com>
To: "Michael West" <michael.w...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Transport Application Notes for Mac OS X
Message-ID:
<3862c5643b15b6468269546753eb2a92096ba...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
Thanks for the help. It looks like a cause of the difference between OS
X and Linux is this code in usrp2_impl.cpp:
//setup the dsp transport hints (default to a large recv buff)
if (not device_addr.has_key("recv_buff_size")){
#if defined(UHD_PLATFORM_MACOS) || defined(UHD_PLATFORM_BSD)
//limit buffer resize on macos or it will error
device_addr["recv_buff_size"] = "1e6";
#elif defined(UHD_PLATFORM_LINUX) || defined(UHD_PLATFORM_WIN32)
//set to half-a-second of buffering at max rate
device_addr["recv_buff_size"] = "50e6";
#endif
}
As mentioned in the comment, setting a large recv_buff_size on OS X does
error out. Following the instructions at
https://www.myricom.com/software/myri10ge/391-how-can-i-restore-the-sock
et-buffer-sizes-in-macosx-10-6.html , I ran:
nvram boot-args="ncl=524288"
and then rebooted. Then I was able to run
sysctl -w kern.ipc.maxsockbuf=67108864
After that, running with "recv_buff_size=50000000" did result in
successful 2 seconds captures at 25 MHz sampling rate using both
rx_samples_to_file and my test app.
The net.inet.udp.recvspace setting does not seem to be necessary. Maybe
this sets the default size which UHD is changing anyways?
From: Michael West [mailto:michael.w...@ettus.com]
Sent: Wednesday, November 27, 2013 2:46 PM
To: Perelman Nathan (Nathan)
Cc: Ian Buckley; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Transport Application Notes for Mac OS X
Nathan,
I came across this information and thought I would pass it on. To set
the amount of UDP receive space globally in Mac OS X:
sysctl -w net.inet.udp.recvspace=<bytes>
(according to
https://www.myricom.com/software/myri10ge/391-how-can-i-restore-the-sock
et-buffer-sizes-in-macosx-10-6.html)
Regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Tue, Nov 26, 2013 at 4:55 PM, Michael West <michael.w...@ettus.com>
wrote:
Nathan,
Here are a few things to try:
1) Increase the receive side buffer size on the socket. Add the
parameter --args="recv_buff_size=<bytes>", wherre <bytes> is the size of
the buffer. (I would suggest a large value, such as 100 MB.)
2) Use unbuffered I/O on the file. Disable using fcntl(). Be careful,
though. This may require that writes are sector or page aligned for
best performance.
3) Create separate threads for the recv() and file output with a queue
between them that can be used as a buffer.
The fact that the issue only happens on OS X when writing to a file
suggests that it is a problem with the OS X filesystem.
In general, the overflow condition exists when too much time elapses
from one call to recv() and the next. It is hard to tell if there is
just a momentary issue on the OS X filesystem that causes the delay or
an overall problem sustaining the write speed. If you have a single
thread trying to do both I/O operations (recv() and write()), you will
have the longest delays on both ends (since they are both blocking
calls) and you will be more likely to see issues. Splitting them into
two separate threads should resolve any issues caused by the filesystem
having a momentary delay.
Please let us know if any of the suggestions above solve your problem.
Regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Tue, Nov 26, 2013 at 1:26 PM, Perelman Nathan (Nathan)
<nperel...@lgsinnovations.com> wrote:
The following is the rx_samples_to_file command that worked when saving
to a ram disk but fails saving to hard drive:
rx_samples_to_file --rate=25e6 --ref external --nsamps 50000000
--freq=1e9
From: Ian Buckley [mailto:i...@ionconcepts.com]
Sent: Tuesday, November 26, 2013 3:51 PM
To: Perelman Nathan (Nathan)
Cc: Michael West; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Transport Application Notes for Mac OS X
Nathan, What arguments did you use for rx_samples_to_file? I'm curious
to try this out and try to repro.
On Nov 26, 2013, at 12:41 PM, Perelman Nathan (Nathan)
<nperel...@lgsinnovations.com> wrote:
The benchmark_rate example does pass for 25 MHz. And rx_samples_to_file
does work with writing to a RAM disk. However, my test app (which uses a
large buffer and then writes it all at once) fails on the RAM disk, and
both my test app and rx_samples_to_file fail on the hard drive. The same
laptop did work under Linux, so the hardware should be capable of
supporting this. Any optimization suggestions for either receiving or
the hard drive under OS X?
-Nathan
From: Michael West [mailto:michael.w...@ettus.com <http://ettus.com> ]
Sent: Tuesday, November 26, 2013 2:28 PM
To: Perelman Nathan (Nathan)
Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Transport Application Notes for Mac OS X
Hi Nathan,
It may be a case where the filesystem can't write to the file fast
enough. To remove the filesystem from the equation, please try using
the benchmark_rate example ("/usr/local/lib/uhd/examples/benchmark_rate
--rx_rate=25e6"). Let us know how it goes.
Best regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com <http://www.ettus.com>
On Tue, Nov 26, 2013 at 10:29 AM, Perelman Nathan (Nathan)
<nperel...@lgsinnovations.com <mailto:nperel...@lgsinnovations.com> >
wrote:
Looking at http://files.ettus.com/uhd_docs/manual/html/transport.html
<http://files.ettus.com/uhd_docs/manual/html/transport.html> , I see
there are sections describing how to tune Linux and Windows for use with
a N2xx series USRP. Googling around finds many different suggestions for
what settings need to be changed on OS X, so I was wondering if anyone
had specific suggestions for what worked for them?
My goal is to be able to receive samples at 25 MHz under OS X without
overflow, but I'm encountering overflow errors using the
rx_samples_to_file example even with just 6.25 MHz as the sampling rate.
This is with OS X 10.9 on a late 2011 MacBook Pro. The same hardware has
no problems receiving at 25 MHz under Linux. Thanks.
-Nathan Perelman
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131202/9d2fc795/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 3 Dec 2013 02:02:31 +0000
From: <chun-hong_zha...@agilent.com>
To: <mle...@ripnet.com>
Cc: usrp-users@lists.ettus.com
Subject: [USRP-users] ??: Running USPR B210 got an error
Message-ID:
<ecb501a59178574bb5eaf941ca86729f0908d...@wcosexch04.agilent.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
I tried to install the unstable version from the website you gave. However, I
still got error. But it could find the device.
Where I ran uhd_usrp_prove without root right, it gave me error UHD Error: USB
Open failed: insufficient permissions.
Is there any issues?
Thanks.
BR,
Nick
???: Marcus Leech [mailto:mle...@ripnet.com]
????: 2013?12?3? 0:04
???: ZHANG,CHUN-HONG (A-China,ex1)
??: usrp-users@lists.ettus.com
??: Re: [USRP-users] Running USPR B210 got an error
You should probably follow the instructions here for the "Master/unstable"
branch, which contains full support for B210:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
Also, if everything installs properly, there's absolutely no reason to run any
of this stuff as root.
on Dec 01, 2013,
chun-hong_zha...@agilent.com<mailto:chun-hong_zha...@agilent.com> wrote:
Hi all,
I?m a user of USRP B210. Now I tried to install UHD on Ubuntu 12.10 x86_64.
After installing the latest UHD, I run uhd_usrp_probe command and got error.
Then I tried to change different usb port on my PC, including usb 2.0 and usb
3.0 ports. However, each time I just got the same error. Is there anybody can
help me to solve this issue. Thanks in advance.
czhang@usrp-pc:~/Downloads/openBTS$ sudo uhd_usrp_probe
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.005.004-62-stable
-- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...100%Operating
over USB 23.
Error: AssertionError: libusb_claim_interface(this->get(), interface) == 0
in virtual void libusb_device_handle_impl::claim_interface(int)
at
/root/remote_fs_root/workspace/bf4_ubuntu-build/Slaves/Ubuntu-12.10-x86_64/uhd/host/lib/transport/libusb1_base.cpp:203
BR,
chunhong
________________________________
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/f1d736e7/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/f1d736e7/attachment-0001.txt>
------------------------------
Message: 6
Date: Mon, 02 Dec 2013 21:04:46 -0500
From: "Marcus D. Leech" <mle...@ripnet.com>
To: chun-hong_zha...@agilent.com
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] ??: Running USPR B210 got an error
Message-ID: <529d3c3e.9080...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/02/2013 09:02 PM, chun-hong_zha...@agilent.com wrote:
>
> Hi Marcus,
>
> I tried to install the unstable version from the website you gave.
> However, I still got error. But it could find the device.
>
> Where I ran uhd_usrp_prove without root right, it gave me error UHD
> Error: USB Open failed: insufficient permissions.
>
> Is there any issues?
>
> Thanks.
>
> BR,
>
> Nick
>
> *???**:*Marcus Leech [mailto:mle...@ripnet.com]
> *????:* 2013?12?3? 0:04
> *???:* ZHANG,CHUN-HONG (A-China,ex1)
> *??:* usrp-users@lists.ettus.com
> *??:* Re: [USRP-users] Running USPR B210 got an error
>
> You should probably follow the instructions here for the
> "Master/unstable" branch, which contains full support for B210:
>
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
>
> Also, if everything installs properly, there's absolutely no reason to
> run any of this stuff as root.
>
> on Dec 01, 2013, chun-hong_zha...@agilent.com
> <mailto:chun-hong_zha...@agilent.com> wrote:
>
> Hi all,
>
> I?m a user of USRP B210. Now I tried to install UHD on Ubuntu 12.10
> x86_64. After installing the latest UHD, I run uhd_usrp_probe command
> and got error. Then I tried to change different usb port on my PC,
> including usb 2.0 and usb 3.0 ports. However, each time I just got the
> same error. Is there anybody can help me to solve this issue. Thanks
> in advance.
>
> */czhang@usrp-pc:~/Downloads/openBTS$ sudo uhd_usrp_probe/*
>
> */linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.005.004-62-stable/*
>
> *//*
>
> */-- Loading FPGA image:
> /usr/share/uhd/images/usrp_b210_fpga.bin...100%Operating over USB 23./*
>
> */Error: AssertionError: libusb_claim_interface(this->get(),
> interface) == 0/*
>
> */ in virtual void libusb_device_handle_impl::claim_interface(int)/*
>
> */ at
> /root/remote_fs_root/workspace/bf4_ubuntu-build/Slaves/Ubuntu-12.10-x86_64/uhd/host/lib/transport/libusb1_base.cpp:203/*
>
> BR,
>
> chunhong
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Check to make sure that you have a:
/etc/udev/rules.d/10-usrp.rules
File, and that the 2500:0020 device Id is listed in there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131202/10f26722/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 3 Dec 2013 12:46:20 +0500
From: bob wole <bnw...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] GPSDO N210 time problem
Message-ID:
<cagd3ozzo7b0pmnduayy8she-gypfgob2msthob4pb5msghz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am facing an issue using two my N210 kits with GPSDO kits. I installed
GPSDO kits on two separate N210. I wait usually 5 to 10 minutes after
powering up the USRPs so that GPSDO gets lock.
Now when I check the time on USRPs, I run the flowgraph at same instance,
sometimes I don't get the same time. Time difference is very significant. I
am printing epoch time as well as USRP time on of both kits. Output is
shown below:
Output of 1st Kit:
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
GPS lock status: locked
GPS epoch time: 1136074272 seconds
USRP Time is 1136074272.72
Output of 2nd Kit:
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
GPS lock status: locked
GPS epoch time: 1136075215 seconds
USRP Time is 1136075216.49
I really want same time on both devices for my application. What is the
issue here? How could this be fixed?
--
bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/1e526085/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 3 Dec 2013 15:22:30 +0000
From: Alexander Buckley <albuck...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Building monoloithic static UHD library
Message-ID:
<caogz1rvx8m2efxegpyntu1f1ig3lxrsrh-klivqmtk04_cn...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I believe I am having a recursive linking problem while trying to build a
static library.
First let me lay out what I am trying to do, that is, build a wrapper for
the UHD so that I can use it in Labview for linux.
It is my first time linking something this complicated, let me review what
I believe to be true:
Labview requires shared libraries.
I have built a wrapper as a shared library (wrapper.so) that is linked to
libuhd.so but contains simple test functions/objects but without any calls
to uhd. This works as expected in Labview. I am implenting 'extern "C" {}'
to expose function I make to Labview.
As soon as I call anything from inside UHD, Labview fails to load my
library.
I am operating under the belief it is a result of Labview being unhappy
with dynamic linking, as I have I have built a test program to use my
library and it works just fine, producing signals from my hardware.
So what I would like to do then is build a monolithic shared library that
is totally self contained and see if that works. I haven't been successful
so far.
What I have done so far is the following:
1. Attempted to build UHD statically. For starters, I am having trouble
forcing cmake to build libuhd.a. The makefiles in the UHD project are
machine made by cmake and don't resemble too much what I am used to seeing
in hand made MakeFile's so I am using cmake gui.
I have added all the following flags in the gui config that were not there
by deafult that I have read up on: ( I am carpet bombing here as I am not
sure of what goes where)
BUILD_SHARED_LIBS box unchecked (off)
BUILD_STATIC_LIBS on --> ends up being ignored by cmake
CMAKE_CXX_FLAGS -fPIC -Wl,--whole-archive
CMAKE_C_FLAGS -fPIC -Wl,--whole-archive
CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined -Wl,--whole-archive
CMAKE_STATIC_LINKER_FLAGS -Wl,--no-undefined -Wl,--whole-archive
When I do this I still get libuhd.so, not libuhd.a
To make libuhd.a I have used ar with all the cached object files from
compilation:
ar rsc libuhd.a `find . -type f -name '*.o'`
I think this could be a hack though and am not sure of the implications.
So first question, what am I doing wrong here? How to I get the build
process to give me the static libuhd.a, not libuhd.so using cmake?
2. Second issue, I think my problem is recursive.
In my own hand written makefile that builds wrapper.so from compiled
wrapper.o and libuhd.a, I changed my link flag from --shared to --static to
see what would happen.
I get very many linker erros simlar to these:
device_addr.cpp:(.text+0x4357): undefined reference to
`boost::basic_regex<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*,
unsigned int)'
log.cpp:(.text+0x794): undefined reference to
`boost::filesystem3::path::parent_path() const'
log.cpp:(.text+0x7ab): undefined reference to
`boost::filesystem3::path::filename() const'
usr/local/lib/libuhd.a(log.cpp.o): In function `_GLOBAL__sub_I_log.cpp':
log.cpp:(.text.startup+0x11): undefined reference to
`boost::system::generic_category()'
paths.cpp:(.text.startup+0x2d): undefined reference to
`boost::system::system_category()'
/usr/local/lib/libuhd.a(property_tree.cpp.o): In function
`boost::detail::sp_ms_deleter<property_tree_impl::tree_guts_type>::destroy()
[clone .part.80]':
property_tree.cpp:(.text+0x59c): undefined reference to
`pthread_mutex_destroy'
/usr/local/lib/libuhd.a(paths.cpp.o): In function
`get_env_paths(std::string cons
/usr/local/lib/libuhd.a(msg.cpp.o): In function `uhd::msg::_msg::~_msg()':
msg.cpp:(.text+0x2e4c): undefined reference to `pthread_mutex_lock'
msg.cpp:(.text+0x2f69): undefined reference to `pthread_mutex_unlock'
msg.cpp:(.text+0x304a): undefined reference to `pthread_mutex_init'
Basically lots of boost stuff and some pthread. (I am guessing the pthread
is a by-product of the boost thread errors).
So I am guessing libuhd must be built also with static links to boost.
My trouble here is very much repeating itself, do I have to build boost
first as a static library, boost.a and then link it into a static build of
libuhd.a?
Or can I build libuhd.a from boost.so statically with some wonderful flags
I don't know about? (I am exaggerating here as it is not boost.so, it is a
series of boost_this.so and boost_that.so)
In summary then my question in it's simplest form is how to a do I build
a monolithic static uhd library that is not dynamically linked to anything
for semi make literate people. I have been reading a lot about make files
and libraries though what I find is tailored to other problems or
discussing issues there are slightly different than mine and what is
unifying in theory has not quite crystallizing for me beyond what I have
already implemented.
All I have been albe to sort out thus far is that I require static linking
and the link flags:
-fPIC -Wl,--whole-archive -Wl,--no-undefined
though this has not yet yielded the desired outcome.
I have reached the point now where I need to write leters to Santa.
I would really apreciate some suggestion here ... hoping someone else has
tried to do this already.
Some aditional info:
I am using:
unbuntu 12.10
Labview 2013 for linux
UHD 003.005
cmake 2.8.9
and compiling my wrapper with g++
regards,
Alexander Buckley
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/de6956b3/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 03 Dec 2013 10:41:37 -0500
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] GPSDO N210 time problem
Message-ID: <529dfbb1.4060...@ripnet.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/03/2013 02:46 AM, bob wole wrote:
> I am facing an issue using two my N210 kits with GPSDO kits. I
> installed GPSDO kits on two separate N210. I wait usually 5 to 10
> minutes after powering up the USRPs so that GPSDO gets lock.
>
> Now when I check the time on USRPs, I run the flowgraph at same
> instance, sometimes I don't get the same time. Time difference is very
> significant. I am printing epoch time as well as USRP time on of both
> kits. Output is shown below:
>
> Output of 1st Kit:
>
>
> -- Detecting internal GPSDO.... Found a Jackson Labs GPS
> -- found
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> GPS lock status: locked
> GPS epoch time: 1136074272 seconds
> USRP Time is 1136074272.72
>
> Output of 2nd Kit:
>
> -- Detecting internal GPSDO.... Found a Jackson Labs GPS
> -- found
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> GPS lock status: locked
> GPS epoch time: 1136075215 seconds
> USRP Time is 1136075216.49
>
> I really want same time on both devices for my application. What is
> the issue here? How could this be fixed?
>
> --
> bob
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Could you show us how you're acquiring, converting and printing the times?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/9ef1950e/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 3 Dec 2013 16:56:07 +0100
From: Sivan Toledo <stol...@tau.ac.il>
To: bob wole <bnw...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] GPSDO N210 time problem
Message-ID:
<caol_rufztu+rsuhdptxady-xfvyuq5jfr_k8q8bcgsxmzj+...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Bob, these are not GPS times but times from the time the USRPs started up.
GPS times should start with 138, not 113. Here is the correct time from a
few minutes ago:
stoledo@soul ~>date +%s
1386086013
stoledo@soul ~>date
Tue Dec 3 17:53:38 IST 2013
I am not sure why you are getting these unlocked times. You can test
whether the GPS is locked. There is also a UHD function to tell the USRP to
use the external time reference. Maybe it's also affecting the time you see.
Sivan
On Tue, Dec 3, 2013 at 8:46 AM, bob wole <bnw...@gmail.com> wrote:
> I am facing an issue using two my N210 kits with GPSDO kits. I installed
> GPSDO kits on two separate N210. I wait usually 5 to 10 minutes after
> powering up the USRPs so that GPSDO gets lock.
>
> Now when I check the time on USRPs, I run the flowgraph at same instance,
> sometimes I don't get the same time. Time difference is very significant. I
> am printing epoch time as well as USRP time on of both kits. Output is
> shown below:
>
> Output of 1st Kit:
>
>
> -- Detecting internal GPSDO.... Found a Jackson Labs GPS
> -- found
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> GPS lock status: locked
> GPS epoch time: 1136074272 seconds
> USRP Time is 1136074272.72
>
> Output of 2nd Kit:
>
> -- Detecting internal GPSDO.... Found a Jackson Labs GPS
> -- found
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> GPS lock status: locked
> GPS epoch time: 1136075215 seconds
> USRP Time is 1136075216.49
>
> I really want same time on both devices for my application. What is the
> issue here? How could this be fixed?
>
> --
> bob
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/3781b4ea/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 3 Dec 2013 16:18:12 +0000
From: "Nowlan, Sean" <sean.now...@gtri.gatech.edu>
To: Sivan Toledo <stol...@tau.ac.il>, bob wole <bnw...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] GPSDO N210 time problem
Message-ID:
<8eec4551d5844607a2ca25d62725b...@apatlisdmail02.core.gtri.org>
Content-Type: text/plain; charset="us-ascii"
I've found that the Jackson Labs Firefly 1A has an initialized time of 00:0:00
01 JAN 2006 (1136073600 epoch seconds) before GPS lock. It looks like the USRP
latched that time before GPS locked. I'm not sure why the Firefly reports that
GPS is locked when the time is bogus. I don't know if it's bad values being
reported by the Firefly or some issue with parsing in UHD. In my own
applications I've had to guard against these bogus results by checking that
"gps_locked" sensor is true and that the "gps_time" sensor is reasonably
greater than the initialized time of 1136073600.
Sean
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Sivan
Toledo
Sent: Tuesday, December 03, 2013 10:56 AM
To: bob wole
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] GPSDO N210 time problem
Bob, these are not GPS times but times from the time the USRPs started up.
GPS times should start with 138, not 113. Here is the correct time from a few
minutes ago:
stoledo@soul ~>date +%s
1386086013
stoledo@soul ~>date
Tue Dec 3 17:53:38 IST 2013
I am not sure why you are getting these unlocked times. You can test whether
the GPS is locked. There is also a UHD function to tell the USRP to use the
external time reference. Maybe it's also affecting the time you see.
Sivan
On Tue, Dec 3, 2013 at 8:46 AM, bob wole
<bnw...@gmail.com<mailto:bnw...@gmail.com>> wrote:
I am facing an issue using two my N210 kits with GPSDO kits. I installed GPSDO
kits on two separate N210. I wait usually 5 to 10 minutes after powering up the
USRPs so that GPSDO gets lock.
Now when I check the time on USRPs, I run the flowgraph at same instance,
sometimes I don't get the same time. Time difference is very significant. I am
printing epoch time as well as USRP time on of both kits. Output is shown
below:
Output of 1st Kit:
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
GPS lock status: locked
GPS epoch time: 1136074272 seconds
USRP Time is 1136074272.72
Output of 2nd Kit:
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
GPS lock status: locked
GPS epoch time: 1136075215 seconds
USRP Time is 1136075216.49
I really want same time on both devices for my application. What is the issue
here? How could this be fixed?
--
bob
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/491b1852/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 3 Dec 2013 11:30:04 -0500
From: Joseph Payton <joey.pay...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Manual UDP Output to USRP N200
Message-ID:
<cajmawsz2hjrnoaoypdxrzf-mxyn1mwh29njd9oxnnfr9jom...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Is there a way to "manually" (using a socket, via UDP- without receiving
via a streamer) send raw VRT packets to the USRP N200?
If so, do the headers need to VRT headers need to be modified on the way
out or will the they work "as captured"?
(I also imagine that I would need to handle notification of underflow via
handling the socket receive side?)
I know that this is "what the UHD driver does" but I am looking to
implement something very lightweight.
Thanks in advance.
Joey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20131203/16e67dbf/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 40, Issue 3
*****************************************
