Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Phase Offset between USRP-B210 Channels
(Marcus D. Leech via USRP-users)
2. Re: Help diagnosing SDR software lockups when using B200?
(Robert J. McIntyre via USRP-users)
3. FW: B210 USB error after longer rx stream duration
(Sabathy Mischa via USRP-users)
4. Re: FW: B210 USB error after longer rx stream duration
(Marcus D. Leech via USRP-users)
5. Re: FW: B210 USB error after longer rx stream duration
(Sabathy Mischa via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Sun, 04 May 2014 12:31:10 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Phase Offset between USRP-B210 Channels
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/04/2014 05:11 AM, Sivan Toledo via USRP-users wrote:
> Stefan, make sure that you can the calibration procedure on the USRP.
> I have no idea if this is what is affecting your experiment, but you
> should do it before you start digging deeper.
>
> Sivan
>
Have you confirmed that your splitter is 0deg across all the frequencies
you care about? Not all of them are.
I did the same experiment when the B210 first came out, with a Marconi
test set as the signal source, and saw uniform zero-degree (more or less)
phase offset between channels across a number of different
frequencies. I then switched splitters, and it was all over the place.
>
> On Fri, May 2, 2014 at 9:30 AM, Stefan Ereth via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi all,
> I'm saving IQ-Samples from both Channels of an USRP B210 for
> Direction of Arrival Estimation with Music. My source Code is
> based on the rx_multi_samples.cpp example. For tests I connected a
> sine-generator with a splitter to both channels. With a pulse sine
> a verified that the measured data is time aligned. (picture
> abs_pulse_sine in appendix) But the problem is, that there is a
> phase offset between the two channels of more than 180 degree.
> (picture real_sine and phase_diff) This offset varies by retuning.
>
> I don't understand where this phase offset come from, because the
> LO of both channels is in the same Chip and should be phase
> aligned. Is this a known problem of the B210? Or is there an error
> in my source code?
>
> Regards,
> Stefan Ereth
>
> //
> // Copyright 2011 Ettus Research LLC
> //
> // This program is free software: you can redistribute it and/or
> modify
> // it under the terms of the GNU General Public License as
> published by
> // the Free Software Foundation, either version 3 of the License, or
> // (at your option) any later version.
> //
> // This program is distributed in the hope that it will be useful,
> // but WITHOUT ANY WARRANTY; without even the implied warranty of
> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> // GNU General Public License for more details.
> //
> // You should have received a copy of the GNU General Public License
> // along with this program. If not, see
> <http://www.gnu.org/licenses/>.
> //
> #define use_short
> #include <uhd/utils/thread_priority.hpp>
> #include <uhd/utils/safe_main.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <boost/program_options.hpp>
> #include <boost/format.hpp>
> #include <boost/thread.hpp>
> #include <boost/lexical_cast.hpp>
> #include <boost/algorithm/string.hpp>
> #include <iostream>
> #include <fstream>
> #include <complex>
>
> namespace po = boost::program_options;
>
> int UHD_SAFE_MAIN(int argc, char *argv[]){
> uhd::set_thread_priority_safe();
>
> //variables to be set by po
> std::string args, sync, subdev, channel_list,file,file0,file1;
> double seconds_in_future, freq;
> size_t total_num_samps;
> double rate,gain,tx_gain;
> std::ofstream outfile,outfile2;
>
> //setup the program options
> po::options_description desc("Allowed options");
> desc.add_options()
> ("help", "help message")
> ("args", po::value<std::string>(&args)->default_value(""),
> "single uhd device address args")
> ("file",
> po::value<std::string>(&file)->default_value("measure0-1"), "name
> of the file to write binary samples to")
> ("secs",
> po::value<double>(&seconds_in_future)->default_value(1.0), "number
> of seconds in the future to receive")
> ("nsamps",
> po::value<size_t>(&total_num_samps)->default_value(10000), "total
> number of samples to receive")
> ("rate", po::value<double>(&rate)->default_value(8e6),
> "rate of incoming samples")
> ("sync",
> po::value<std::string>(&sync)->default_value("b210"),
> "synchronization method: now, pps, mimo")
> ("freq", po::value<double>(&freq)->default_value(800e6),
> "RF center frequency in Hz")
> ("gain", po::value<double>(&gain), "gain for the RF chain")
> ("tx-gain", po::value<double>(&tx_gain), "gain for the TX
> in calibration Mode")
> ("subdev", po::value<std::string>(&subdev), "subdev spec
> (homogeneous across motherboards)")
> ("v", "specify to enable inner-loop verbose")
> ("calc","specify to enable transmitting and recording of
> calibration data")
> ("channels",
> po::value<std::string>(&channel_list)->default_value("0"), "which
> channel(s) to use (specify \"0\", \"1\", \"0,1\", etc)")
> ;
> po::variables_map vm;
> po::store(po::parse_command_line(argc, argv, desc), vm);
> po::notify(vm);
>
> //print the help message
> if (vm.count("help")){
> std::cout << boost::format("UHD RX Multi Samples %s") %
> desc << std::endl;
> std::cout <<
> " This is a demonstration of how to receive aligned
> data from multiple channels.\n"
> " This example can receive from multiple DSPs, multiple
> motherboards, or both.\n"
> " The MIMO cable or PPS can be used to synchronize the
> configuration. See --sync\n"
> "\n"
> " Specify --subdev to select multiple channels per
> motherboard.\n"
> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a
> Basic RX.\n"
> "\n"
> " Specify --args to select multiple motherboards in a
> configuration.\n"
> " Ex: --args=\"addr0=192.168.10.2,
> addr1=192.168.10.3\"\n"
> << std::endl;
> return ~0;
> }
>
> bool verbose = vm.count("v") == 1;
> bool calibration = vm.count("calc") == 1;
>
>
>
> /**************** RX Init
> *************************************************/
> //create a usrp device
> std::cout << std::endl;
> std::cout << boost::format("Creating the usrp device with:
> %s...") % args << std::endl;
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(args);
>
> usrp->set_master_clock_rate(30e6); //less then 30.72e6
> //M?glichkeit 1: Variable Clock-Rate
> //always select the subdevice first, the channel mapping
> affects the other settings
> if (vm.count("subdev")){
> uhd::usrp::subdev_spec_t subdevClass = subdev;
> std::cout << subdevClass.to_pp_string() << std::endl;
> usrp->set_rx_subdev_spec(subdevClass); //sets across all
> mboards
> }
>
> std::cout << boost::format("Using Device: %s") %
> usrp->get_pp_string() << std::endl;
>
> //set the rx sample rate (sets across all channels)
> std::cout << boost::format("Setting RX Rate: %f Msps... ") %
> (rate/1e6) << std::endl;
> usrp->set_rx_rate(rate);
> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>
> //set center Frequency
> std::cout << boost::format("Setting RX Freq: %f MHz...") %
> (freq/1e6) << std::endl;
> uhd::tune_request_t tune_request(freq);
> for(size_t i=0;i<usrp->get_rx_num_channels();i++)
> usrp->set_rx_freq(tune_request,i);
> std::cout << boost::format("Actual RX Freq: %f MHz...") %
> (usrp->get_rx_freq(1)/1e6) << std::endl << std::endl;
>
> //set the rf gain
> if (vm.count("gain")){
> for(size_t i=0;i<usrp->get_rx_num_channels();i++){
> std::cout << boost::format("Setting RX Gain for
> Channel %d: %f dB...") % i % gain << std::endl;
> usrp->set_rx_gain(gain,i);
> std::cout << boost::format("Actual RX Gain: %f dB...")
> % usrp->get_rx_gain() << std::endl << std::endl;
> }
> }
>
> //open files to write
> if(calibration) file+=".calc"; //Kalibrierdaten mit Endung .calc
> else file+=".dat"; //Messdaten mit Endung.dat
> file0 = file;
> file1 = file;
> file0 += "0";
> file1 += "1";
>
> outfile.open(file0.c_str(), std::ofstream::binary);
> if(usrp->get_rx_num_channels()>1){
> outfile2.open(file1.c_str(),std::ofstream::binary);
> }
>
>
>
> /**************** Recieve Start
> ******************************************/
> //create a receive streamer
> //linearly map channels (index0 = channel0, index1 = channel1,
> ...)
> uhd::stream_args_t stream_args("sc16"); //complex short
>
> //stream_args.channels = channel_nums;
> for (size_t i = 0; i < usrp->get_rx_num_channels(); i++)
> stream_args.channels.push_back(i);
> uhd::rx_streamer::sptr rx_stream =
> usrp->get_rx_stream(stream_args);
>
> //setup streaming
> std::cout << std::endl;
> std::cout << boost::format(
> "Begin receiving of %u samples. Start in %f seconds in the
> future..."
> ) % total_num_samps % seconds_in_future << std::endl;
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
> stream_cmd.num_samps = total_num_samps;
> stream_cmd.stream_now = false;
> stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future) +
> usrp->get_time_now();
> rx_stream->issue_stream_cmd(stream_cmd); //tells all channels
> to stream
>
> //meta-data will be filled in by recv()
> uhd::rx_metadata_t md;
>
> //allocate buffers to receive with samples (one buffer per
> channel)
> const size_t samps_per_buff = rx_stream->get_max_num_samps();
> std::vector<std::vector<std::complex<short> > > buffs(
> usrp->get_rx_num_channels(),
> std::vector<std::complex<short> >(samps_per_buff)
> );
>
> //create a vector of pointers to point to each of the channel
> buffers
> std::vector<std::complex<short> *> buff_ptrs;
> for (size_t i = 0; i < buffs.size(); i++)
> buff_ptrs.push_back(&buffs[i].front());
>
> //the first call to recv() will block this many seconds before
> receiving
> double timeout = seconds_in_future + 1; //timeout (delay
> before receive + padding)
>
> size_t num_acc_samps = 0; //number of accumulated samples
> while(num_acc_samps < total_num_samps){
> //receive a single packet
> size_t num_rx_samps = rx_stream->recv(
> buff_ptrs, samps_per_buff, md, timeout
> );
>
> //use a small timeout for subsequent packets
> timeout = 0.1;
>
> //handle the error code
> if (md.error_code ==
> uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) break;
> if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
> throw std::runtime_error(str(boost::format(
> "Receiver error %s"
> ) % md.strerror()));
> }
>
> if(verbose) std::cout << boost::format(
> "Received packet: %u samples, %u full secs, %f frac secs"
> ) % num_rx_samps % md.time_spec.get_full_secs() %
> md.time_spec.get_frac_secs() << std::endl;
>
> //Schreiben der gelesenen Werte in die Dateien
> if(outfile.is_open())
> outfile.write((const char
> *)&buffs[0].front(),num_rx_samps*sizeof(buffs[0].front()));
> if(outfile2.is_open())
> outfile2.write((const char
> *)&buffs[1].front(),num_rx_samps*sizeof(buffs[1][0]));
>
> num_acc_samps += num_rx_samps;
> }
>
> if (num_acc_samps < total_num_samps) std::cerr << "Receive
> timeout before all samples received..." << std::endl;
> /**************************** Recieve End
> *******************************************************/
> if(outfile.is_open())
> outfile.close();
> if(outfile2.is_open())
> outfile2.close();
>
> //finished
> std::cout << std::endl << "Done! Mine" << std::endl << std::endl;
>
> return EXIT_SUCCESS;
> }
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140504/b886539e/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 4 May 2014 11:23:39 -0700
From: "Robert J. McIntyre via USRP-users" <[email protected]>
To: 'Marcus M?ller' <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Thanks, Marcus. Specified the type=b200, and it?s still not being recognized,
giving the same results as below, but with a ?type: b200? notation.
My B200 is listed in device manager (on Win7) as a ?WestBridge? device, which
is how it seems to be listed until firmware is loaded, at which point it
becomes an Ettus B200.
Thanks for your continued help.
--Robert
From: Marcus M?ller [mailto:[email protected]]
Sent: Sunday, May 04, 2014 2:11 AM
To: Robert J. McIntyre
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert,
for the benchmark utility, specifying
<executable> --args type=b200
should explicitely specify you're looking for USB3 devices. If that doesn't
help, make sure your USRP is found by the system at first.
Greetings,
Marcus
On Sun, May 4, 2014 at 12:15 AM, Robert J. McIntyre via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
I?ve downloaded the latest drivers off the VIA website (which are newer than
the cards? manufacturers? drivers), as well as the manufacturers? drivers. A
variety of USB devices will work with that card, and the Device Manager shows
the B200 as a ?WestBridge? device attached to the controller, and the power
light on the B200 is on.
When trying to run the benchmark utility (or start SDR Sharp via ExtIO), I get:
Creating the usrp device with: ...
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
Plugging the B200 into the onboard (Intel) controller makes it work as expected.
This exact thing happens with both different VIA cards. I?ve reinstalled the
drivers for the cards, as well as UHD. If I put the Renesas controller back
in, it will work fine from it.
Thanks!
Robert
From: USRP-users [mailto:[email protected]
<mailto:[email protected]> ] On Behalf Of Marcus D. Leech via
USRP-users
Sent: Saturday, May 03, 2014 2:49 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
On 05/03/2014 05:37 PM, Robert J. McIntyre via USRP-users wrote:
Thanks, Marcus. It definitely seems to be related to sample rate: I dropped
down to 2 Msps, and then 4 Msps, and was able to use it fine. Jumping to 8,
however, caused almost immediate issues.
I switched to the Intel controller, and it seems to be more stable, even having
gone as long as 15-20 minutes at 16Msps without issue, but strangely I tend to
have better benchmark results with the renesas one. So, one gives better
long-term uptime, the other gives less overruns/dropped samples on the
benchmarks. :| I?ve tried two different VIA controllers (built on VL801 and
VL805), but neither one would actually load the firmware to the B200, despite
other devices working fine.
I do understand the UHD/ExtIO interaction, but I suppose that there could be an
issue with the ExtIO code calling into UHD, but since the symptoms happen with
or without ExtIO, it points to something further down the stack. :)
Any tips on getting the VIA controllers to work? I?d like to at least be able
to benchmark one. :)
Thanks!!!!!
Robert
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, May 03, 2014 2:14 PM
To: Robert J. McIntyre
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert,
this is strange indeed, although there are several reports of things working
out very badly with renesas controllers, so try and stick with the Intel one;
Ettus actively does not recommend using any Renesas control, since they have
problems implementing the USB3.0 standard.
Access is always done using UHD (ExtIO is just an interface for which Balint
wrote an UHD wrapper), just to clear up on that.
You could try one of the binaries from the examples supplied with uhd, for
example rx_samples_to_udp,or _to_file and see if it runs without a GUI on top
for the desired amount of time (warning: 15 minutes of 8Msam/s will be around
29 GB, so make sure you're not filling up your SSD inadvertently).
All the best,
Marcus
On Sat, May 3, 2014 at 10:49 PM, Robert J. McIntyre via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hoping that someone can help me, and I can help the group with diagnosing
very frequent "lockups" of SDR software when using the B200.
My system is (roughly):
B200
USB 3 via a Renesas controller (though the same thing happens with an Intel
controller, and another Renesas controller on my laptop)
UHD 003.007.001
Core i7 with 16GB RAM
Regardless of whether I use SDR Sharp, or SDR Console, about every 5-10
minutes of using the SDR as a receiver (clicking around within the
bandwidth, etc.), both software will "lock up", in that they'll continue to
run the waterfall, but there won't be any data displayed. If I stop/restart
the radio (via the SDR software radio selection options) it will almost
always come back to life, for 5-10 minutes, and then die again.
I've set the sample rate to 8Msps, and get zero dropped/lost/overruns using
benchmark_rate.exe.
I'd love to help investigate this, but am looking for some help in where to
start. Based on the fact that it affects multiple programs, which use
different access methods (UHD vs. ExtIO), it seems like it's not the
individual software packages, but rather either my system in general, or
somewhere from UHD down through the firmware/FPGA image.
Thoughts?
Thanks!
Robert
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Make sure your Windows drivers for these controllers are up-to-date.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140504/077fc119/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 5 May 2014 14:38:03 +0000
From: Sabathy Mischa via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: B210 USB error after longer rx stream
duration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Sorry I forgot to make CC to list, please see below.
Mischa
From: Sabathy Mischa
Sent: Montag, 5. Mai 2014 16:06
To: 'Marcus M?ller'
Subject: RE: [USRP-users] B210 USB error after longer rx stream duration
Hi Marcus ,
This is indeed very strange. For sure the device didn't got disconnected
physically.
I additionally set up a Debian testing environment with libusb 1.0.18-2 to see
whether the bug remains or not with a newer libusb version.
Unfortunately it occurred again.
Has somebody an idea how to fix this?
It is easy to reproduce the bug, just take a USRP Source block and connect it
to a null sink and let it stream data for some hours/days.
BR
Mischa
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Mittwoch, 23. April 2014 13:13
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 USB error after longer rx stream duration
Hi Mischa,
this is very strange:
On 04/23/2014 01:01 PM, Sabathy Mischa via USRP-users wrote:
RuntimeError: usb rx6 transfer status: 5
the libusb source code tells me that status 5 is LIBUSB_TRANSFER_NO_DEVICE,
( http://libusb.sourceforge.net/api-1.0/libusb_8h_source.html l. 1106ff)
which basically means the device got disconnected.
Greetings,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140505/d21f9dd6/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 05 May 2014 10:40:38 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FW: B210 USB error after longer rx stream
duration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 05/05/2014 10:38 AM, Sabathy Mischa via USRP-users wrote:
>
> Sorry I forgot to make CC to list, please see below.
>
> Mischa
>
> *From:*Sabathy Mischa
> *Sent:* Montag, 5. Mai 2014 16:06
> *To:* 'Marcus M?ller'
> *Subject:* RE: [USRP-users] B210 USB error after longer rx stream duration
>
> Hi Marcus ,
>
> This is indeed very strange. For sure the device didn't got
> disconnected physically.
>
> I additionally set up a Debian testing environment with libusb
> 1.0.18-2 to see whether the bug remains or not with a newer libusb
> version.
>
> Unfortunately it occurred again.
>
> Has somebody an idea how to fix this?
> It is easy to reproduce the bug, just take a USRP Source block and
> connect it to a null sink and let it stream data for some hours/days.
>
> BR
>
> Mischa
>
>
Are you using the external power supply or relying on USB power?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140505/c04f18af/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 5 May 2014 15:38:37 +0000
From: Sabathy Mischa via USRP-users <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FW: B210 USB error after longer rx stream
duration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I stream at 15.36 MSPS with USB 3.0 connectivity and the supplied USB 3.0 cable.
From: Marcus D. Leech [mailto:[email protected]]
Sent: Montag, 5. Mai 2014 17:01
To: Sabathy Mischa
Subject: Re: [USRP-users] FW: B210 USB error after longer rx stream duration
On 05/05/2014 10:49 AM, Sabathy Mischa wrote:
I tried both, with and without external power. The error occurs with both
configurations.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Montag, 5. Mai 2014 16:41
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] FW: B210 USB error after longer rx stream duration
On 05/05/2014 10:38 AM, Sabathy Mischa via USRP-users wrote:
Sorry I forgot to make CC to list, please see below.
Mischa
From: Sabathy Mischa
Sent: Montag, 5. Mai 2014 16:06
To: 'Marcus M?ller'
Subject: RE: [USRP-users] B210 USB error after longer rx stream duration
Hi Marcus ,
This is indeed very strange. For sure the device didn't got disconnected
physically.
I additionally set up a Debian testing environment with libusb 1.0.18-2 to see
whether the bug remains or not with a newer libusb version.
Unfortunately it occurred again.
Has somebody an idea how to fix this?
It is easy to reproduce the bug, just take a USRP Source block and connect it
to a null sink and let it stream data for some hours/days.
BR
Mischa
Are you using the external power supply or relying on USB power?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
OK, so what rates are you streaming at? USB-2.0 or USB-3.0? Are you using the
as-supplied cable?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140505/bb7ded34/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 45, Issue 5
*****************************************
