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
On Wed, May 30, 2012 at 11:35 AM, Darren Long <darren.l...@mac.com> wrote:
> 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
