Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Device address for USRP (Marcus Leech via USRP-users)
2. Debugging Overflow Out of Sequence Errors
(Perelman Nathan (Nathan) via USRP-users)
3. Re: Debugging Overflow Out of Sequence Errors
(Marcus M?ller via USRP-users)
4. Re: Debugging Overflow Out of Sequence Errors
(Ian Buckley via USRP-users)
5. Re: Device address for USRP (asad umer via USRP-users)
6. Build USRP X310 FPGA code (Luong Tan Phong via USRP-users)
7. USRP B210 error (asad umer via USRP-users)
8. Re: Device address for USRP (Marcus D. Leech via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Fri, 9 May 2014 16:18:36 +0000 (UTC)
From: Marcus Leech via USRP-users <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Device address for USRP
Message-ID: <1585311774.7000.1399652316459.JavaMail.mail@webmail03>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140509/fdf95702/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 9 May 2014 18:37:00 -0400
From: "Perelman Nathan \(Nathan\) via USRP-users"
<[email protected]>
To: <[email protected]>
Subject: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID:
<3862c5643b15b6468269546753eb2a920a22c...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
Any recommendation on debugging overflow out of sequence errors? I can't
seem to sustain captures for longer than about 15 minutes without seeing
a D printed to the output and getting an error, and sometimes get one as
soon as 30 seconds in.
My setup is as follows:
UHD 3.7.1 on CentOS 6 (built from source)
4 USRP N210s with SBX daughtboards, 2 connected directly to my computer
via gigabit Ethernet to individual gigabit Ethernet ports on separate
subnets, the other 2 connected with a MIMO cable to the first 2 USRPs.
The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
reference through a splitter. Time_source and clock_source for those is
set to "external"
The 2 slave USRPs have time_source and clock_source set to mimo.
I'm setting the time using set_time_next_pps() on the 2 master USRPs,
and checking to make sure the time is synced between all 4 USRPs before
starting the capture.
The sample rate for all 4 USRPs is set to 12.5 MHz.
I'm starting the capture as a continuous stream with a start time 0.5
seconds in the future.
3.7.1 firmware image flashed on all USRPs.
One multi_usrp object constructed with all 4 USRPs and
recv_buff_size=150e6.
I'm calling recv() in one thread and then passing the buffers to 4
separate threads for writing to files. The files are on an SSD that is
not having any issues keeping up with the writing.
Thanks.
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140509/21cb5a13/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 10 May 2014 01:42:04 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID:
<cahrjasu03tr26ziyc6uhr3yh_xjjxmxriccouoacht_jcrr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Nathan,
so you're having 2*12.5 MS/s, which equals to 25MS/s, which, each complex
sample being 32b == 8B (wire format) implies an 800Mb/s rate at both of
your 1000Mb/s ports.
Seeing that your operating system seems to start dropping packets (the D
warnings typically are a sign of that) I'd say there is too little headroom
for varying performance of your storage subsystem, and all the different
things that can happen on a PC, while still streaming continously.
You can try to solve that with even more independent Gigabit ports and an
even more powerful workstation, possibly.
Also, the fact that your drives seem to be not the limiting factor can be
somewhat misleading -- even if they can continously write at least as fast
as the samples come in, file systems and general purpose OSes will
interrupt your writing on a lot of occasions. Also, many SSDs offer great
*average* rates, without being able to guarantee a high *minimum* rate...
You should try to identify the bottleneck in your computer. Is it PCIe
speed? Is it the CPU doing computation, storage management, other tasks? Is
it the storage controller? Do the network cards spontaneously drop packets
at high rates?
Hope I have given you some interesting pointers,
Greetings,
Marcus
On Sat, May 10, 2014 at 12:37 AM, Perelman Nathan (Nathan) via USRP-users <
[email protected]> wrote:
> Any recommendation on debugging overflow out of sequence errors? I can?t
> seem to sustain captures for longer than about 15 minutes without seeing a
> D printed to the output and getting an error, and sometimes get one as soon
> as 30 seconds in.
>
>
>
> My setup is as follows:
>
> UHD 3.7.1 on CentOS 6 (built from source)
>
> 4 USRP N210s with SBX daughtboards, 2 connected directly to my computer
> via gigabit Ethernet to individual gigabit Ethernet ports on separate
> subnets, the other 2 connected with a MIMO cable to the first 2 USRPs.
>
> The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
> reference through a splitter. Time_source and clock_source for those is set
> to ?external?
>
> The 2 slave USRPs have time_source and clock_source set to mimo.
>
> I?m setting the time using set_time_next_pps() on the 2 master USRPs, and
> checking to make sure the time is synced between all 4 USRPs before
> starting the capture.
>
> The sample rate for all 4 USRPs is set to 12.5 MHz.
>
> I?m starting the capture as a continuous stream with a start time 0.5
> seconds in the future.
>
> 3.7.1 firmware image flashed on all USRPs.
>
> One multi_usrp object constructed with all 4 USRPs and
> recv_buff_size=150e6.
>
> I?m calling recv() in one thread and then passing the buffers to 4
> separate threads for writing to files. The files are on an SSD that is not
> having any issues keeping up with the writing.
>
>
>
> Thanks.
>
> -Nathan
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20140510/0cfadc67/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 9 May 2014 17:24:49 -0700
From: Ian Buckley via USRP-users <[email protected]>
To: "Perelman Nathan \(Nathan\)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
A few thoughts Nathan.
It sounds like you are just loosing single packets at a time, have you
confirmed this?
Do lost packets correlate with counter increases in the Kernel/Driver?
(ifconfig & ethool -S) or are they silently lost?
Have you followed basic configuration info form here
(http://files.ettus.com/uhd_docs/manual/html/transport.html)? Particularly
stuff that increases available kernel buffer space.
Have you changed the default MTU from 1500 to something larger? This is a cause
of issues in a surprising number of cases.
Have you investigated the errata for the exact model of chip used in you NIC?
In recent years Intel 82574L and 82579LM have both had errata that caused
random packet loss and there are some configuration fixes for these issues.
Has your NIC/Kernel decided to enable 802.3x ethernet flow control? (ethtool
-a). If so disable that. (ethtool -A INTERFACE autoneg off tx off rx off)
-Ian
On May 9, 2014, at 3:37 PM, Perelman Nathan (Nathan) via USRP-users
<[email protected]> wrote:
> Any recommendation on debugging overflow out of sequence errors? I can?t seem
> to sustain captures for longer than about 15 minutes without seeing a D
> printed to the output and getting an error, and sometimes get one as soon as
> 30 seconds in.
>
> My setup is as follows:
> UHD 3.7.1 on CentOS 6 (built from source)
> 4 USRP N210s with SBX daughtboards, 2 connected directly to my computer via
> gigabit Ethernet to individual gigabit Ethernet ports on separate subnets,
> the other 2 connected with a MIMO cable to the first 2 USRPs.
> The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
> reference through a splitter. Time_source and clock_source for those is set
> to ?external?
> The 2 slave USRPs have time_source and clock_source set to mimo.
> I?m setting the time using set_time_next_pps() on the 2 master USRPs, and
> checking to make sure the time is synced between all 4 USRPs before starting
> the capture.
> The sample rate for all 4 USRPs is set to 12.5 MHz.
> I?m starting the capture as a continuous stream with a start time 0.5 seconds
> in the future.
> 3.7.1 firmware image flashed on all USRPs.
> One multi_usrp object constructed with all 4 USRPs and recv_buff_size=150e6.
> I?m calling recv() in one thread and then passing the buffers to 4 separate
> threads for writing to files. The files are on an SSD that is not having any
> issues keeping up with the writing.
>
> Thanks.
> -Nathan
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20140509/0d7ac4d8/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 10 May 2014 12:45:56 +0500
From: asad umer via USRP-users <[email protected]>
To: Marcus Leech <[email protected]>, [email protected]
Subject: Re: [USRP-users] Device address for USRP
Message-ID:
<CAEhLvxQuPrCD5E=cwapmqpnblbm3ckv5ba3-cvgfuud2tjb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
And i need to mention the channels for the antennas?
On Fri, May 9, 2014 at 9:18 PM, Marcus Leech <[email protected]> wrote:
> That will work, it's just telling the UHD code what *class* of USRP to go
> looking for on USB.
>
> on May 09, 2014, *asad umer* <[email protected]> wrote:
>
> its B210
>
>
> On Fri, May 9, 2014 at 8:16 PM, Marcus Leech <[email protected]> wrote:
>
>> I recommend being explicit about which USRP you're talking about, so
>> "type=b200" in the device address.
>>
>>
>> on May 09, 2014, *asad umer via USRP-users* <[email protected]>
>> wrote:
>>
>> If i am using a single USRP B210 for TX and RX,then do i need to
>> mention its address in UHD source or sink block in GRC?
>> Do i need to mention the channels for two antennas also?
>> ------------------------------
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> 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/20140510/b877b2b5/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 10 May 2014 14:54:27 +0700
From: Luong Tan Phong via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Build USRP X310 FPGA code
Message-ID:
<CAA8YXsr4=dwWvbSNTsRM=qopuy2upnrd9fbbm2ecprxs82g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I've builded USRP X310 FPGA code (downloaded on github at Apr-15-2014) with
HGS configure by Xilinx ISE 14.7 on Ubuntu to create usrp_x310_fpga_HGS.bit
file and burn it to USRP X310.
After that, I can't run my application with X310 by error:
*linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.000-123-g87b068ed*
*Using Volk machine: avx_32_mmx_orc*
*-- X300 initialization sequence...*
*-- Determining maximum frame size... 1472 bytes.*
*-- Setup basic communication...*
*-- Loading values from EEPROM...*
*-- Setup RF frontend clocking...*
*-- Radio 1x clock:200*
*-- Detecting internal GPSDO.... Found an internal GPSDO*
*-- Initialize Radio control...*
*-- Performing register loopback test... pass*
*-- Sync DAC's.*
*-- Performing register loopback test... pass*
*-- Sync DAC's.*
*-- Initializing clock and PPS references...*
*Traceback (most recent call last):*
* File "/home/ktd/top_block.py", line 101, in <module>*
* tb = top_block()*
* File "/home/ktd/top_block.py", line 58, in __init__*
* channels=range(1),*
* File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor*
* return old_constructor(*args)*
* File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 1765, in make*
* return _uhd_swig.usrp_source_make(*args)*
*RuntimeError: RuntimeError: The gpsdo PPS was not detected. Please check
the PPS source and try again.*
My application is OK with usrp_x310_fpga_HGS.bit file downloaded from
http://files.ettus.com/binaries/maint_images/archive/uhd-images_003.007.000-70-gfcc85c95.zip
Could you help me to fix it, please?
Best regards,
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140510/71ae018a/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 10 May 2014 14:22:32 +0500
From: asad umer via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210 error
Message-ID:
<caehlvxtb6gtrpeeotorklzzkeya6fop_vmkswj0ozv7jkql...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am using B21o and simply RXing a signal and observing it in FFT sink
block...The parameters set for UHD USRP source block are as shown in the
screenshot...When i execute the flow graph i get the following error:
thread[thread-per-block[0]: <block gr uhd usrp source (24)>]: LookupError:
KeyError: Cannot find an item size:
Can anybody help me ou heret??
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140510/5445adda/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2014-05-10 14:16:40.png
Type: image/png
Size: 146942 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140510/5445adda/attachment-0001.png>
------------------------------
Message: 8
Date: Sat, 10 May 2014 10:51:12 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: asad umer <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Device address for USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/10/2014 03:45 AM, asad umer wrote:
> And i need to mention the channels for the antennas?
>
>
The default will be to use the TX/RX port for the channel you've selected.
> On Fri, May 9, 2014 at 9:18 PM, Marcus Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> That will work, it's just telling the UHD code what *class* of
> USRP to go looking for on USB.
> on May 09, 2014, *asad umer* <[email protected]
> <mailto:[email protected]>> wrote:
>
> its B210
>
>
> On Fri, May 9, 2014 at 8:16 PM, Marcus Leech
> <[email protected] <mailto:[email protected]>> wrote:
>
> I recommend being explicit about which USRP you're talking
> about, so "type=b200" in the device address.
> on May 09, 2014, *asad umer via USRP-users*
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> If i am using a single USRP B210 for TX and RX,then do
> i need to mention its address in UHD source or sink
> block in GRC?
> Do i need to mention the channels for two antennas also?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
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/20140510/7a806af3/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 45, Issue 10
******************************************
