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: Debugging Overflow Out of Sequence Errors
(Perelman Nathan (Nathan) via USRP-users)
2. Re: USRP X300, PCIe, Windows, PCIe extender card
(Serge Malo via USRP-users)
3. Re: Debugging Overflow Out of Sequence Errors
(Michael West via USRP-users)
4. New N200 functioning improperly (Dan Sego via USRP-users)
5. Re: New N200 functioning improperly
(Marcus D. Leech via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 May 2014 16:56:33 -0400
From: "Perelman Nathan \(Nathan\) via USRP-users"
<[email protected]>
To: "Gareth Crispin" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID:
<3862c5643b15b6468269546753eb2a920a2fb...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
Thanks, I already tried building the most recent driver from Intel from
source though and it did not make a difference.
-Nathan
From: [email protected] [mailto:[email protected]] On Behalf Of
Gareth Crispin
Sent: Friday, May 16, 2014 4:53 PM
To: Perelman Nathan (Nathan)
Cc: Ian Buckley; [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
It looks like that card has a kernel driver bug in Centos 6:
http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-825
74l-ethernet-controller-causing-network-blipping/
Might be worth following the article above and installing the e1000
driver from elrepo to see if it helps..
Kind regards,
Gareth
On 15 May 2014, at 17:44, Perelman Nathan (Nathan) via USRP-users
<[email protected]> wrote:
Thanks for the suggetions.
I have not confirmed that it is just single packets being dropped.
Lost packets sometimes correlate with counter increases in the
kernel/driver, and sometimes do not. When they do, the dropped count
from ifconfig and the rx_no_buffer_count and rx_missed_errors fields
from ethtool -S increase. Usually it reports around 1000 dropped
packets.
I did increase the kernel buffer space to 300M.
I have not changed the default MTU.
The chip on my NIC is a 82574L. Do you know what specific changes should
be made to get it to not drop packets? Alternatively, is there a 1x
PCI-E gigabit NIC you would recommend?
I tried the following things:
Upgrading to the most recent driver (3.0.4-NAPI)
Disabling flow control with ethtool -A
Increasing the rx ring buffers to max with ethtool -G
Setting these kernel options (found through Google, not really sure
exactly how some of these are supposed to help): pcie_aspm=off
e1000e.IntMode=1,1 e1000e.InterruptThrottleRate=10000,10000 acpi=off
After all that, I'm still seeing packets being dropped when running
benchmark_rate:
./a.out --rx_cpu=sc16 --mode mimo --args
addr0=192.168.11.2,addr1=192.168.11.3 --rx_rate 12500000 --channels 0,1
--duration 7200
linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-3); Boost_104100;
UHD_003.007.001-0-unknown
Creating the usrp device with: addr0=192.168.11.2,addr1=192.168.11.3...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Multi USRP:
Device: USRP2 / N-Series Device
Mboard 0: N210r4
Mboard 1: N210r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: SBXv3 RX
RX Channel: 1
RX DSP: 0
RX Dboard: A
RX Subdev: SBXv3 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: SBXv3 TX
TX Channel: 1
TX DSP: 0
TX Dboard: A
TX Subdev: SBXv3 TX
Testing receive rate 12.500000 Msps on 2 channels
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
DDDDReceiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
DDD
Benchmark rate summary:
Num received samples: 179990917524
Num dropped samples: 3918948
Num overflows detected: 0
Num transmitted samples: 0
Num sequence errors: 0
Num underflows detected: 0
Done!
A similar test for the other 2 USRPs on the other Ethernet port reports
zero dropped samples. Any ideas for other things to try or should I just
invest in a different NIC?
Thanks.
-Nathan
From: Ian Buckley [mailto:[email protected]
<mailto:[email protected]> ]
Sent: Friday, May 9, 2014 8:25 PM
To: Perelman Nathan (Nathan)
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
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
<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] <mailto:[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] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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/20140516/d1ba372c/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 16 May 2014 21:10:54 +0000
From: Serge Malo via USRP-users <[email protected]>
To: Ben Hilburn <[email protected]>, "[email protected]"
<[email protected]>
Cc: St?phane Hamel <[email protected]>
Subject: Re: [USRP-users] USRP X300, PCIe, Windows, PCIe extender card
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all,
Good news today: I have been able to use the X300 with the OSS-HIB38-X8-DUAL
card.
I had to do this with a different PC (Core i7-920, with a NVidia M/B with 2
PCIe 16x slots, normally used for SLI).
I?m still unable to use the X300 in the first computer I have tried: it is a
computer based on a COM-Express module from Advantech (SOM-5892FG, Core
i7-3612). I suppose there is some kind of limitation that prevents the X300 to
be enumerated correctly. Still, I find it strange that I was able to use a NI
RAID 8265 via OSS-HIB38 with that computer.
Now, performance-wise, I still have issues with the X300.
I have almost the same performances between the PXIe-8135 controller and the
core i7-920 computer.
I have tried both ?usrp_x300_fpga_HGS.bit? and ?usrp_x300_fpga_HGS.lvbitx?
images, but I got the same results:
Benchmark_rate ?rx_rate 200000000: overflows
Benchmark_rate ?rx_rate 100000000: PASS
Benchmark_rate ?rx_rate 120000000 --args master_clock_rate=120e6: overflows
Benchmark_rate ?rx_rate 60000000 --args master_clock_rate=120e6: PASS
Is there any performance known issues on Windows 7, with UHD 3.7.1?
Thanks again for your help!
Have a good week-end,
Serge
Serge Malo, ing
Principal Ing?nieur logiciel
Senior Software engineer
T (514) 842-7577 x648 | [email protected]<mailto:[email protected]>
From: Ben Hilburn [mailto:[email protected]]
Sent: May-15-14 4:28 PM
To: Serge Malo
Cc: Matt Ettus; Ashish Chaudhari; Michael West; Balint Seeber; Jose Loera
Subject: Re: [USRP-users] USRP X300, PCIe, Windows, PCIe extender card
Hi Serge -
There has been a lot of back-and-forth, and you have provided a lot of great
detail. I think I'm a bit lost, now, though, and it sounds like you may
actually have a couple of different issues. I'd like to clarify a few things
and make sure I understand what you are seeing:
1. It sounds like you have several PCIe adapter cards that you have tried.
The OneStop Systems OSS-HIB38 works when used through a NI 8265 RAID device,
but not otherwise. Do you have any adapters that work as expected?
2. In all cases, you are unable to achieve 200 MSps without overflows. Is
that true?
Thanks, Serge. We will do everything we can to get you up and running!
Cheers,
Ben
On Thu, May 15, 2014 at 9:02 AM, Serge Malo via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
For Dual-Host Switch Mode (Mode 0), only the lower port works for the NI 8265
RAID. But none for the X300.
I have tried the OSS-HIB38-x8-DUAL (Mode 2), called ?Expressnet secondary?.
In that mode, the NI 8265 RAID is recognized and functional in Windows on both
ports. But again, none for the X300.
I have tried the 2 other modes of the OSS-HIB38-x8-DUAL (Mode 1: Target, Mode
3: Triple Host). The 8265 is not recognized in those modes.
The X300 shows up in the Windows Device Manager as a ?PCI Data Acquisition and
Signal Processing Controller?, with a yellow triangle and an exclamation mark.
It says that the Drivers are not installed (Code 28). Obviously, I tried many
times to install NIRIO1310f1 driver and the ?niusrprio-stable_Win64? low-level
driver, but it won?t change the status of this device in the Windows Device
Manager.
Yes, I?m booting the computer when the X300 is already powered on and plugged
in. Whenever I changed the connection or the OSS card mode, I have shut down
the PC, made the change, and re-powered up the PC.
In the Windows Device Manager, the Location of the X300 is ?PCI Slot 73 (PCI
bus 5, device 0, function 0)?. I?m wondering if this can point you to a PCIe
enumeration problem.
Thanks again!
Serge
Serge Malo, ing
Principal Ing?nieur logiciel
Senior Software engineer
T (514) 842-7577 x648<tel:%28514%29%20842-7577%20x648> |
[email protected]<mailto:[email protected]>
From: Matt Ettus [mailto:[email protected]<mailto:[email protected]>]
Sent: May-15-14 9:33 AM
To: Serge Malo
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP X300, PCIe, Windows, PCIe extender card
I'm not familiar with dual host mode. Can you try it in regular host mode?
Possibly on both ports? Also, does it show up in the device manager, but not
work, or does it look like the device isn't even connected at all? Are you
booting with the USRP already powered on and plugged in? And are you rebooting
every time you unplug, replug or power down?
I'll look into getting one of these cards to test with if this doesn't help.
Thanks,
Matt
On Thu, May 15, 2014 at 3:25 PM, Serge Malo
<[email protected]<mailto:[email protected]>> wrote:
The HIB38-x8-DUAL board is set in mode 0: ?Dual Host Switch?.
I?m using the lower port.
I?m using a OSS-PCIe-CBL-x8/x4-2M cable
Using this configuration, I was able to use a NI 8265 RAID.
Thanks,
Serge
Serge Malo, ing
Principal Ing?nieur logiciel
Senior Software engineer
T (514) 842-7577 x648<tel:%28514%29%20842-7577%20x648> |
[email protected]<mailto:[email protected]>
From: Matt Ettus [mailto:[email protected]<mailto:[email protected]>]
Sent: May-15-14 9:15 AM
To: Serge Malo
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP X300, PCIe, Windows, PCIe extender card
Do you have the board set for host mode? Which port are you using? Do you
have standard x8 to x4 cables?
Matt
On Thu, May 15, 2014 at 2:45 PM, Serge Malo
<[email protected]<mailto:[email protected]>> wrote:
HI Matt,
It?s the OSS-PCIe-HIB38-x8-DUAL
http://www.onestopsystems.com/pcie_hib38_x8.php
Regards,
Serge
Serge Malo, ing
Principal Ing?nieur logiciel
Senior Software engineer
T (514) 842-7577 x648<tel:%28514%29%20842-7577%20x648> |
[email protected]<mailto:[email protected]>
From: Matt Ettus [mailto:[email protected]<mailto:[email protected]>]
Sent: May-15-14 8:42 AM
To: Serge Malo
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP X300, PCIe, Windows, PCIe extender card
Serge,
Which HIB38 card are you using? It looks like there are multiple versions.
Matt
On Thu, May 15, 2014 at 2:29 PM, Serge Malo via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I?m using Windows 7, x64, UHD 3.7.1.
Using FPGA image usrp_x300_fpga_HGS.bit
I have been able to connect my X300 with a NI PXIe controller (8133), in a PXIe
chassis (1075), with a PXIe adapter (NI PXIe-8262).
However, I can?t get the benchmark_rate to receive samples at the rate of
200MS/s without buffer overflows (100MS/s seems ok).
In the end, I prefer a setup in a ?regular PC? with a PCIe Adapter card.
The problem is that I don?t have the recommended PCIe card NI PCIe-8371 card.
I have tried the OneStop Systems OSS-HIB38 card, but I can?t get Windows to
recognize the X300 with this card. However, I was able to use this OneStop
OSS-HIB38 card with a NI 8265 RAID without problem.
I also tried the ?MXI-Express BIOS Compatibility Software?, but it won?t detect
any compatible devices.
Any ideas of what I could try?
Where can I find more information about the ?MXI-Express Mode 1 operation?? I?d
like to find out if the OSS HIB38 card is supporting this Mode.
Regards,
Serge
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20140516/1aaffa50/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 16 May 2014 14:46:58 -0700
From: Michael West via USRP-users <[email protected]>
To: "Perelman Nathan (Nathan)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID:
<CAM4xKrqxrtEEOu3BWq=4gsbo-8+ldue-hat5k_b7u-3poin...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Nathan,
It seems you have already isolated the problem to the NIC, so it might be
worth investing in a new one. If 'ifconfig' or 'ethtool -S' show errors or
dropped packets on the NIC, that will confirm that the NIC (or cable) is
suspect. You can also swap the ports to which the N210s are connected and
see if the problem stays with the NIC or follows the device.
Best regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Fri, May 16, 2014 at 1:56 PM, Perelman Nathan (Nathan) via USRP-users <
[email protected]> wrote:
> Thanks, I already tried building the most recent driver from Intel from
> source though and it did not make a difference.
>
> -Nathan
>
>
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf Of
> *Gareth
> Crispin
> *Sent:* Friday, May 16, 2014 4:53 PM
> *To:* Perelman Nathan (Nathan)
> *Cc:* Ian Buckley; [email protected]
>
> *Subject:* Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>
>
>
> It looks like that card has a kernel driver bug in Centos 6:
>
>
> http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-82574l-ethernet-controller-causing-network-blipping/
>
>
>
> Might be worth following the article above and installing the e1000 driver
> from elrepo to see if it helps..
>
>
>
> Kind regards,
>
> Gareth
>
>
>
>
>
> On 15 May 2014, at 17:44, Perelman Nathan (Nathan) via USRP-users <
> [email protected]> wrote:
>
>
>
> Thanks for the suggetions.
>
> I have not confirmed that it is just single packets being dropped.
>
> Lost packets sometimes correlate with counter increases in the
> kernel/driver, and sometimes do not. When they do, the dropped count from
> ifconfig and the rx_no_buffer_count and rx_missed_errors fields from
> ethtool -S increase. Usually it reports around 1000 dropped packets.
>
> I did increase the kernel buffer space to 300M.
>
> I have not changed the default MTU.
>
> The chip on my NIC is a 82574L. Do you know what specific changes should
> be made to get it to not drop packets? Alternatively, is there a 1x PCI-E
> gigabit NIC you would recommend?
>
>
>
> I tried the following things:
>
> Upgrading to the most recent driver (3.0.4-NAPI)
>
> Disabling flow control with ethtool -A
>
> Increasing the rx ring buffers to max with ethtool -G
>
> Setting these kernel options (found through Google, not really sure
> exactly how some of these are supposed to help): pcie_aspm=off
> e1000e.IntMode=1,1 e1000e.InterruptThrottleRate=10000,10000 acpi=off
>
>
>
> After all that, I?m still seeing packets being dropped when running
> benchmark_rate:
>
> ./a.out --rx_cpu=sc16 --mode mimo --args
> addr0=192.168.11.2,addr1=192.168.11.3 --rx_rate 12500000 --channels 0,1
> --duration 7200
>
> linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-3); Boost_104100;
> UHD_003.007.001-0-unknown
>
>
>
>
>
> Creating the usrp device with: addr0=192.168.11.2,addr1=192.168.11.3...
>
> -- Opening a USRP2/N-Series device...
>
> -- Current recv frame size: 1472 bytes
>
> -- Current send frame size: 1472 bytes
>
> Using Device: Multi USRP:
>
> Device: USRP2 / N-Series Device
>
> Mboard 0: N210r4
>
> Mboard 1: N210r4
>
> RX Channel: 0
>
> RX DSP: 0
>
> RX Dboard: A
>
> RX Subdev: SBXv3 RX
>
> RX Channel: 1
>
> RX DSP: 0
>
> RX Dboard: A
>
> RX Subdev: SBXv3 RX
>
> TX Channel: 0
>
> TX DSP: 0
>
> TX Dboard: A
>
> TX Subdev: SBXv3 TX
>
> TX Channel: 1
>
> TX DSP: 0
>
> TX Dboard: A
>
> TX Subdev: SBXv3 TX
>
>
>
> Testing receive rate 12.500000 Msps on 2 channels
>
> Receiver error: ERROR_CODE_TIMEOUT
>
> Unexpected error on recv, continuing...
>
> DDDDReceiver error: ERROR_CODE_TIMEOUT
>
> Unexpected error on recv, continuing...
>
> DDD
>
> Benchmark rate summary:
>
> Num received samples: 179990917524
>
> Num dropped samples: 3918948
>
> Num overflows detected: 0
>
> Num transmitted samples: 0
>
> Num sequence errors: 0
>
> Num underflows detected: 0
>
>
>
>
>
> Done!
>
>
>
>
> A similar test for the other 2 USRPs on the other Ethernet port reports
> zero dropped samples. Any ideas for other things to try or should I just
> invest in a different NIC?
>
> Thanks.
>
> -Nathan
>
>
>
> *From:* Ian Buckley [mailto:[email protected] <[email protected]>]
> *Sent:* Friday, May 9, 2014 8:25 PM
> *To:* Perelman Nathan (Nathan)
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>
>
>
> 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
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20140516/11d1a413/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 17 May 2014 08:43:00 -0700
From: Dan Sego via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] New N200 functioning improperly
Message-ID:
<calgevjtnmff_t-__msmffjeyzw0t3khfalrsq6eu2hknqds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Good morning to the community,
I have just received my second N200/WBX and after careful assembly,
including electrostatic prevention, the device is producing meaningless
results when observing signals with known spectral properties. The control
code is MSVS C++ that was successfully used with the number 1 unit (a
digital TV signal, I have decomposed the schematics of both devices and
using manufacturer data sheets to determine that maximum signal level was
over 20 dB below the lowest maximum component power rating in the receive
cascade). The code is a hard-wired variant of rx_samples_to_file.
I'm running UHD_003_005 release. I am able to find the device and examine
properties using usrp_find_devices and uhd_usrp_probe and subdev_spec_test
return no problems. I have also run the rx I/Q cal for the new unit.
Any suggestions before I begin warranty actions with the vendor?
cheers
Dan Sego
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140517/7205681f/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 17 May 2014 11:48:35 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] New N200 functioning improperly
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/17/2014 11:43 AM, Dan Sego via USRP-users wrote:
> Good morning to the community,
> I have just received my second N200/WBX and after careful assembly,
> including electrostatic prevention, the device is producing
> meaningless results when observing signals with known spectral
> properties. The control code is MSVS C++ that was successfully used
> with the number 1 unit (a digital TV signal, I have decomposed the
> schematics of both devices and using manufacturer data sheets to
> determine that maximum signal level was over 20 dB below the
> lowest maximum component power rating in the receive cascade). The
> code is a hard-wired variant of rx_samples_to_file.
> I'm running UHD_003_005 release. I am able to find the device and
> examine properties using usrp_find_devices and uhd_usrp_probe and
> subdev_spec_test return no problems. I have also run the rx I/Q cal
> for the new unit.
> Any suggestions before I begin warranty actions with the vendor?
> cheers
> Dan Sego
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Please tell me what:
uhd_usrp_probe
returns
(As in copy/paste the entire output)
--
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/20140517/22260ffb/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 16
******************************************
