On 05/30/2012 08:52 AM, Ryan Wolfarth wrote:
> 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_STO
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
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
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
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 n
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 ter
