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!
Thank you,
Ryan
On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
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
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
Problem solved! rx_samples_to_file doesn’t include a stream_cmd_stop!
Here’s our fix:
Add the following after line 93 (outfile.close()):
if(!num_requested_samples){
uhd::stream_cmd_t
stream_cmd_stop(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
usrp->issue_stream_cmd(stream_cmd_stop);
}
This seems to do the trick. The C debug light is off as is the Ethernet
link activity light!
-Ryan
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 05/30/2012 08:52 AM, Ryan Wolfarth wrote:
This seems to do the trick. The C debug light is off as is the Ethernet
link activity light!
Ah, that makes sense. Thanks for the patch.
I wonder a little bit what happens with this supposed ICMP packet I
mentioned. But its just kind of a handy nicety, so I wouldn’t worry
about it.
-Josh