Hi Josh, Thanks for your quick reply! We are actually using rx_samples_to_file as a first attempt at benchmarking the systems data transfer speed. We give a proper crtl+c whenever we terminate the program, but the problem persists. We tried rx_timed_samples per your recommendation and found that the port and USRP terminated properly. The program doesn't seem to be modified from previous releases, so my first blind guess is that there could be an issue with the interface on one side of our network card (Intel 82576 Gigabit controller).
Due to the simplicity of our data collection scheme, we will probably modify rx_samples_to_file to respond to an external trigger. So if we could get the example working properly that would be a great starting point. Do you have any more ideas? Thanks again, Ryan On Tue, May 29, 2012 at 11:09 PM, Josh Blum <j...@ettus.com> wrote: > > > On 05/29/2012 05:36 PM, Ryan Wolfarth wrote: > > Hi list, > > > > We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to > collect > > RF data for GPS related experiments. The server works great and we seem > to > > be able to write 20 Msps from each device simultaneously to a RAID array > > with no overflows. However, after each collection program is terminated, > > the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on. We > > tested this with a single device with the same result. Does anybody know > > the cause of this and if we should be worried? We're running UHD 3.4.2 > > (downloaded 2 days ago). All N210s were updated with the firmware/image > > downloaded from the same version and compiled from source using GNU ZPU > > Tools and Xilinx ISE 13.1 respectively. The server is running 64-bit > > Ubuntu 12.04. Any help is appreciated! > > > > http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds > > I would only really be worried about C which means the device is still > sending samples out of the ethernet port. This can happen if the > streaming isnt properly shutoff like ctrl+c or destructors not being > called. > > Additionally, (if it is still streaming) the USRP isnt getting an ICMP > destination unreachable from the host when the socket on the host > closes. Its possible that due to your network setup that this packet > doesnt get generated and/or delivered. > > If it is the deconstructor issue, sometimes its useful in gr python apps > to set the top block object to None to help python garbage collect it. > > tb.stop() > tb = None > > I would also see if things shutoff as expected when your run one of the > included examples such as rx_timed_samples > > Hope that helps! > -josh > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
