I've noticed that when stopping a GRC sketch and starting another, I get unknown stream ID reports from my B100, requiring a restart of the USRP to recover. This used to happen a while back, but was fixed. Perhaps the fix has been broken or the issue is similar.
Darren Sent from my iPhone On 30 May 2012, at 16:23, Ryan Wolfarth <wolfa...@muohio.edu> wrote: > 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
