from:"David via USRP\-users"

[USRP-users] One-Sample offsets with external ref/pps

2020-12-18 Thread Haberleitner, David via USRP-users

Hi all,


when using 3 X310 USRPs (TwinRX, UHD 3.15 LTS) synchronized via the CDA-2990 
Octoclock (10MHz Ref and PPS distributed with length-matched cables), we are 
observing deviations of up to two samples (e.g. one board late, one early) 
between the individual devices.

We are seeing these offsets in the measured RF signals, but to have a minimal 
example to show the effect, I've included an example where the timing offsets 
can be observed using the GPIO pins. The screenshots show the GPIO signals 
attached to the ATR-Receive signals. With every run we get different offsets 
between the boards and sometimes all boards are in sync.


Is this a known issue?


Thanks,

David
//
// Copyright 2011 Ettus Research LLC
// Copyright 2018 Ettus Research, a National Instruments Company
//
// SPDX-License-Identifier: GPL-3.0-or-later
//

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

// set up our masks, defining the pin numbers
#define RX_GPIO_MASK   (1 << 0)

int UHD_SAFE_MAIN(int argc, char* argv[])
{
// variables to be set by po
std::string args = "type=x300,addr0=192.168.11.2,addr1=192.168.12.2,addr2=192.168.13.2";
std::string subdev = "A:0 A:1 B:0 B:1";
std::string channel_list = "0,1,2,3,4,5,6,7,8,9,10,11";
double seconds_in_future = 5;
size_t total_num_samps = 100;
double rate = 100e6;

// 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);


size_t devices = usrp->get_num_mboards();
usrp->set_rx_subdev_spec(subdev); // sets across all mboards

// 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;


usrp->set_clock_source("external");
usrp->set_time_source("external");
usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
// wait for pps sync pulse
std::this_thread::sleep_for(std::chrono::seconds(1));
// Checks that all time registers are approximately close but not
// exact, given that the RTT may varying for a control packet
// transaction.
std::cout << (usrp->get_time_synchronized() ? "PPS synchronized."
		  : "PPS: NO SYNC!")
	  << std::endl;

// setup ATR RX GPIO for offset measurement on all boards
for (size_t i = 0; i < devices; i++) {
	usrp->set_gpio_attr("FP0", "CTRL", RX_GPIO_MASK, RX_GPIO_MASK, i);
	usrp->set_gpio_attr("FP0", "DDR", RX_GPIO_MASK, RX_GPIO_MASK, i);
	usrp->set_gpio_attr("FP0", "ATR_0X", 0, RX_GPIO_MASK, i);
	usrp->set_gpio_attr("FP0", "ATR_RX", 1, RX_GPIO_MASK, i);
	usrp->set_gpio_attr("FP0", "ATR_TX", 0, RX_GPIO_MASK, i);
	usrp->set_gpio_attr("FP0", "ATR_XX", 0, RX_GPIO_MASK, i);
}

// detect which channels to use
std::vector channel_strings;
std::vector channel_nums;
boost::split(channel_strings, channel_list, boost::is_any_of("\"',"));
for (size_t ch = 0; ch < channel_strings.size(); ch++) {
size_t chan = std::stoi(channel_strings[ch]);
if (chan >= usrp->get_rx_num_channels()) {
throw std::runtime_error("Invalid channel(s) specified.");
} else
channel_nums.push_back(std::stoi(channel_strings[ch]));
}

// create a receive streamer
// linearly map channels (index0 = channel0, index1 = channel1, ...)
uhd::stream_args_t stream_args("fc32"); // complex floats
stream_args.channels = channel_nums;
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

// setup streaming
std::cout << std::endl;
std::cout << boost::format("Begin streaming %u samples, %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);
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>> buffs(
usrp->get_rx_num_channels(), std::vector>(samps_per_buff));

// create a vector of pointers to point to each of the channel buffers
std::vector*> buff_ptrs;
for (size_t i = 0; i < buffs.size(); i++)
buff_ptrs.push_back([i].front());

// the first call to recv() will block this many seconds before receiving
double timeout = seconds_in_future + 0.1; //

[USRP-users] N320: XQ image issue using sfp0 as time_source

2019-12-10 Thread Truan David via USRP-users

Hi!

We are using multiples N320 (UHD 3.14) and we want to synchronize our setup 
using the White Rabbit protocol and using the N320 as the WR Slave and the 
Master being an OPNT Switch.

We have to be able to stream the IQ over the QSFP+ port (seen as sfp0) and use 
the SFP0 as the WR input so we have the XQ image loaded.

However, when setting sfp0 as the time_source, I get an error saying I need the 
WX image. I checked the "MPM/periph_manager/n3xx" python code and saw it only 
checks for the WX (line 692 of the 3.14 UHD on github). Is this normal?

If not, can I patch it by adding the XQ string to the "sfp_time_source_images", 
pack it and only replace the MPM package or should I totally rebuild UHD and 
flash my SD?


Thank you in advance for your answer!


David Truan

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

2019-10-11 Thread Truan David via USRP-users

Hi Nate,

Sorry it was a mistake from my part, we indeed have the XQ loaded. The QSFP+ 
port is working, and we can transmit data through it.


BR


David Truan


De : Nate Temple 
Envoyé : jeudi, 10 octobre 2019 17:12:15
À : Truan David
Cc : usrp-users@lists.ettus.com
Objet : Re: [USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

Hi David,

Can you try loading the XQ FPGA image onto the N320? When using the XG image, 
only the onboard SFP 0,1 adapters are used. When using the XQ image, two lanes 
of the QSFP will be used (0,1). A table showing what protocols / ports per FPGA 
image can be found here [0].

[0] - https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rh_sfp_protocols

Regards,
Nate Temple

On Wed, Oct 9, 2019 at 7:33 AM Truan David via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi everyone,

We are currently trying to connect the N320 (configured with the XG image) to 
one of our server using the QSFP+ interface through a switch (FS 
S5900-24S4T2Q). The server is equipped with 40Gbps QSFP+ interface and the 
connexion works when connecting directly by QSFP+ without the switch in between.

However when connecting it to the switch (to a 40Gbps QSFP+ port) it doesn't 
even detect the connexion (port led light off on the switch) and we cannot 
reach the N320 from the server.

Do you have an idea what could cause the issue?


Thank you in advance!


David Truan

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

2019-10-09 Thread Truan David via USRP-users

Hi everyone,

We are currently trying to connect the N320 (configured with the XG image) to 
one of our server using the QSFP+ interface through a switch (FS 
S5900-24S4T2Q). The server is equipped with 40Gbps QSFP+ interface and the 
connexion works when connecting directly by QSFP+ without the switch in between.

However when connecting it to the switch (to a 40Gbps QSFP+ port) it doesn't 
even detect the connexion (port led light off on the switch) and we cannot 
reach the N320 from the server.

Do you have an idea what could cause the issue?


Thank you in advance!


David Truan

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N320: set_rx_bw() does not change the actual BW

2019-09-06 Thread Truan David via USRP-users

Hi,

We received our N320 and started doing some basic RX tests on it and everything 
seems ok. We were able to get an emitted chirp and display it using GQRX.

However, when calling the set_rx_bandwidth() UHD function and then reading the 
actual RX bandwidth, it always read back 250MHz. Using rx_samples_to_file 
example and with a --bw=1e6 parameter, I obtain the output:



Setting RX Bandwidth: 1.00 MHz...

Actual RX Bandwidth: 250.00 MHz...



Is this normal or a bug? If it is a bug, does this have an impact on the 
acquisition, if yes what is this impact?

We tested both the HG and the XQ FPGA bitstreams and we use UHD 3.14.0.0 on 
both the N320 and the host, obtaining the same behavior in all cases.


Thank you in advance for your answer!

David T.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] [E310] Fastlock profiles usage with UHD API

2019-02-26 Thread Truan David via USRP-users

Hi everyone!
We recently bought an E310 to try some very wide band acquisition (from 1GHz to 
5GHz) in the fastest way possible. I read about fastlock profiles and was able 
to do some early tests by adding the SPI sptr to the UHD tree and retrieving in 
the code:


uhd::spi_iface::sptr spi = 
usrp->get_device()->get_tree()->access("/mboards/0/spi").get();

I re-implemented the AD9361 fastlock functions found on the AD9361 Linux 
driver(save, recall, ...) and I think "my" fastlock API is now ready.
My idea (taken from 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017634.html)
 is to do a calibration run in which I spot the tunings taking too long, saving 
their profile using fastlock (may need more than 8 profiles). However, I am not 
sure about the usage of the fastlock recall while using UHD:
-Should I still use the "usrp->set_rx_freq" between the fastlock recall or do I 
only need to recall at the sensible freq and do nothing otherwise?
-Should I wait for the "lo_locked" sensor if I use the recall?
-And another question: does anyone ported the AD9361 to the Xlilinx-Linux used 
by the E310?

I am using UHD 3.9.2 patched with the SPI hook.

Thank you a lot for your answers!

David


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UBX-40 fails to ID on N210

2018-07-10 Thread Myers, David via USRP-users

Hello all,

I recently purchased 4 N210s and installed 4 new UXB-40 daughter cards.
When I run uhd_usrp_probe on each of the 4 N210s it fails to identify and 
returns an unknown ID and name.

I've run the probe from two different machines (Ubuntu 16.04 and Xubuntu 16.04).
I've run the probe with UHD 3.9,  3.10,  and  3.11 (uhd installed from Ubuntu 
package manager, "maint" source code, and "master" source code respectively)
I've run the uhd_images_downloader and rerun the uhd_image_loader on each board.
I've taking two other N210s, successfully identified their respective SXB and 
WBX cards with uhd_usrp_probe, replaced those cards with UBX-40s, and then 
failed to ID the newly installed cards.
I've replicated the issue on Mboard: N210r4 and Mboard: N210.

Below is the one outputs from uhd_usrp_probe:

linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.HEAD-197-g053111dc

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
  _
/
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: 00:80:2f:18:6e:3e
|   |   ip-addr: 192.168.10.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: 313E047
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo, gpsdo
|   |   Clock sources: internal, external, mimo, gpsdo
|   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
mimo_locked, ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: Unknown (0x007c)
|   |   |   Serial: 313C17A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: Unknown (0x007c) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: Unknown (0x007b)
|   |   |   Serial: 313C17A
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: Unknown (0x007b) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None

With thanks,

David Myers
Georgia Tech Research Institute
david.my...@gtri.gatech.edu


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

2017-09-09 Thread David via USRP-users


Thx for the info.

Do you think there would be any mileage in using the GPU for that, it 
should vectorise quite well?


I' know nothing about the GPU, only done some simple Cuda stuff, maybe 
theres OpenCL support?



On 08/09/17 16:51, mle...@ripnet.com wrote:


I've run a simple interferometer application with a B210 on an XU4, 
with two channels at 15Msps.


On 2017-09-08 11:23, David wrote:


Thanks Marcus,

so doing ...

benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6

no overruns (got a couple with 256).

I'm just trying to get a feel of what is possible with this processor,

Cheers
Dave


On 08/09/17 15:58, mle...@ripnet.com wrote:


I've found that altering num_recv_frames in the device args to be 
helpful on XU4--try 128 or 256


On 2017-09-08 10:34, David via USRP-users wrote:


Just tried out a USB3 powered hub, to power the b200.

The XU4 wouldn't boot powered from the hub (2A max), but powered 
from it's own supply (4A) and the B200mini powered from the hub all 
seems OK, no device errors, fscks on reboot, etc. :-) :-)


So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).

Using uhd_fft at 10MHz rate results in just a few overruns over 
several minutes, it's marginal...


Now I can move on to do some real stuff...

Kind regards,
Dave


On 04/09/17 18:21, David wrote:

So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some 
data may be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more 
than one issue here?


Sorry for the commentary/verboseness, but I've been at this for a 
while now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of 
the common issues with the XU4 that I've seen reported is that 
the USB3 ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use 
an external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does 
it result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with 
a B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> 
wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having 
a serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 
4.9.28-38, and latest GIT clone of UHD (as of two weeks ago). 
Two uSD cards I had are now totally trashed. I'm on my last 
card. They seem to get totally trashed after I run uhd-fft a few 
times.


The main symptom is that if the B200mini is connected and I 
reboot, an fsck is done every time, and also has the effect of 
continually rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts 
up UHD (uhd-usrp.rules) I am also able to reboot with no issues. 
So a driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@li

Re: [USRP-users] UHD dropping samples running on Debian 9

2017-09-08 Thread David via USRP-users


USRP N2xx or X3xx are network devices?


On 08/09/17 16:07, mle...@ripnet.com wrote:


USRP devices that are attached via USB don't use the networking stack, 
so tweaking network-stack kernel parameters is irrelevant.


Since the USB devices use LibUSB, which is entirely user-space, the 
transport parameters here should be investigated:


https://files.ettus.com/manual/page_transport.html#transport_usb_params

But if problems are occurring at low sample rates, it may be that your 
USB subsystem just isn't up to the task.


On 2017-09-08 11:02, David wrote:


could you explain why please?


On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote:


This is presumably a network-attached USRP (N2xx or X3xx)? 
Otherwise, network parameters are irrelevant.


On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:

Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a
NUC6i7KYK), installed Debian 9 on it and tested Gnuradio on it.
At first we installed via apt-get. We saw some drops in the
gnuradio-companion and had issue with setting the real-time
priority, so we removed it from the system and installed it
again with pybombs.
However, no difference. Today tested it again with UHD provided
benchmark example (for easy reference). Saw occasional drops
with Sps from 1e6 to 10e6. Thought it might be a network driver
issue, updated the Intel network driver with the latest(?)
e1000e driver. Still no difference.
Any ideas, can we fix this somehow?
Thank you
Meelis
Additional information is in the file attached, but most
important system parameters:
#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet
Connection (2) I219-LM (rev 31)
filename:  
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200;
UHD_3.11.0.git-181-g8f9f4184]

___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

2017-09-08 Thread David via USRP-users


Thanks Marcus,

so doing ...

benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6

no overruns (got a couple with 256).

I'm just trying to get a feel of what is possible with this processor,

Cheers
Dave



On 08/09/17 15:58, mle...@ripnet.com wrote:


I've found that altering num_recv_frames in the device args to be 
helpful on XU4--try 128 or 256


On 2017-09-08 10:34, David via USRP-users wrote:


Just tried out a USB3 powered hub, to power the b200.

The XU4 wouldn't boot powered from the hub (2A max), but powered from 
it's own supply (4A) and the B200mini powered from the hub all seems 
OK, no device errors, fscks on reboot, etc. :-) :-)


So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).

Using uhd_fft at 10MHz rate results in just a few overruns over 
several minutes, it's marginal...


Now I can move on to do some real stuff...

Kind regards,
Dave


On 04/09/17 18:21, David wrote:

So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some data 
may be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more 
than one issue here?


Sorry for the commentary/verboseness, but I've been at this for a 
while now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of 
the common issues with the XU4 that I've seen reported is that the 
USB3 ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use 
an external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does 
it result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with a 
B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> 
wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 
4.9.28-38, and latest GIT clone of UHD (as of two weeks ago). Two 
uSD cards I had are now totally trashed. I'm on my last card. They 
seem to get totally trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I 
reboot, an fsck is done every time, and also has the effect of 
continually rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts up 
UHD (uhd-usrp.rules) I am also able to reboot with no issues. So a 
driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD dropping samples running on Debian 9

2017-09-08 Thread David via USRP-users


could you explain why please?


On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote:


This is presumably a network-attached USRP (N2xx or X3xx)? Otherwise, 
network parameters are irrelevant.


On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:


Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), 
installed Debian 9 on it and tested Gnuradio on it. At first we 
installed via apt-get. We saw some drops in the gnuradio-companion 
and had issue with setting the real-time priority, so we removed it 
from the system and installed it again with pybombs.
However, no difference. Today tested it again with UHD provided 
benchmark example (for easy reference).  Saw occasional drops with 
Sps from 1e6 to 10e6. Thought it might be a network driver issue, 
updated the Intel network driver with the latest(?) e1000e driver. 
Still no difference.

Any ideas, can we fix this somehow?
Thank you
Meelis
Additional information is in the file attached, but most important 
system parameters:

#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection 
(2) I219-LM (rev 31)
filename:   
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184]


___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD dropping samples running on Debian 9

2017-09-08 Thread David via USRP-users


network buffer size?

Should be...

# sysctl net.core.rmem_max
net.core.rmem_max = 5000


On 08/09/17 15:25, Meelis Nõmm via USRP-users wrote:

Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), 
installed Debian 9 on it and tested Gnuradio on it. At first we 
installed via apt-get. We saw some drops in the gnuradio-companion and 
had issue with setting the real-time priority, so we removed it from 
the system and installed it again with pybombs.
However, no difference. Today tested it again with UHD provided 
benchmark example (for easy reference).  Saw occasional drops with Sps 
from 1e6 to 10e6. Thought it might be a network driver issue, updated 
the Intel network driver with the latest(?) e1000e driver. Still no 
difference.


Any ideas, can we fix this somehow?
Thank you
Meelis

Additional information is in the file attached, but most important 
system parameters:

#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) 
I219-LM (rev 31)
filename:   
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184]



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

2017-09-08 Thread David via USRP-users


Just tried out a USB3 powered hub, to power the b200.

The XU4 wouldn't boot powered from the hub (2A max), but powered from 
it's own supply (4A) and the B200mini powered from the hub all seems OK, 
no device errors, fscks on reboot, etc. :-) :-)


So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).

Using uhd_fft at 10MHz rate results in just a few overruns over several 
minutes, it's marginal...


Now I can move on to do some real stuff...

Kind regards,
Dave


On 04/09/17 18:21, David wrote:

So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some data 
may be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more 
than one issue here?


Sorry for the commentary/verboseness, but I've been at this for a 
while now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of the 
common issues with the XU4 that I've seen reported is that the USB3 
ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an 
external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does it 
result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with a 
B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
<usrp-users@lists.ettus.com> wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, 
and latest GIT clone of UHD (as of two weeks ago). Two uSD cards I 
had are now totally trashed. I'm on my last card. They seem to get 
totally trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I reboot, 
an fsck is done every time, and also has the effect of continually 
rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts up 
UHD (uhd-usrp.rules) I am also able to reboot with no issues. So a 
driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com







___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

2017-09-04 Thread David via USRP-users


So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may 
be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more than 
one issue here?


Sorry for the commentary/verboseness, but I've been at this for a while 
now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the issue may be 
power draw on the USB interface during boot. One of the common issues with the 
XU4 that I've seen reported is that the USB3 ports do not provide USB3 spec 
power levels.

Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an external 
power adapter to feed power to the USRP.

Another test you could try -- Try using the USB2 on the XU4. Does it result in 
the same boot up problems?

I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini and 
have not seen any issue such as this.

Regards,
Nate Temple





On Sep 2, 2017, at 1:44 AM, David via USRP-users <usrp-users@lists.ettus.com> 
wrote:

Hi All,

I'm trying to get XU4 and B200mini to work together, but having a serious 
issue: the SD card gets trashed!

I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and latest 
GIT clone of UHD (as of two weeks ago). Two uSD cards I had are now totally 
trashed. I'm on my last card. They seem to get totally trashed after I run 
uhd-fft a few times.

The main symptom is that if the B200mini is connected and I reboot, an fsck is 
done every time, and also has the effect of continually rebooting, and 
continually corrupting the card.

Unplug the B200mini and all is fine (after a couple of fscks). I managed to 
work out that if I remove the udev rule that starts up UHD (uhd-usrp.rules) I 
am also able to reboot with no issues. So a driver issue?

Without the udev rule I get the following, which I'm assuming is normal?:

[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

2017-09-04 Thread David via USRP-users

Unfortunately, for me, things are not as they seem...
So after using the B200mini on USB2, just now, I've just done a reboot 
(paranoia setting in), and it's now stuck continuously rebooting, doing 
an fsck rebooting, etc...

One one pass...

   2fsck 1.42.13 (17-May-2015)
   rootfs was not cleanly unmounted, check forced.
   Pass 1: Checking inodes, blocks, and sizes
   Pass 2: Checking directory structure
   [9.412622] random: crng init done===  \
   82.8%
   rootfs: |=   |
   87.4%

On Another:

Pass 2: Checking directory structure
[9.876457] random: crng init done=\ 
86.6%

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 
blocks

fsck exited with status code 1
done.
[   10.858006] EXT4-fs (mmcblk1p2): mounted filesystem without 
journal. Opts: (null)

done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

I've just unplug the b200mini, and it is still continuing to reboot and 
check the fs, that's new, maybe more than one issue here?
I stop the reboot by hitting enter twice at the boot prompt (keeping my 
finger on Enter!).

I power-cycle and it still reboots.
I suspect the flag that sets the rootfs as un-cleanly umounted is set 
and won't re-set, as the fsck never appears to complete, the fsck seems 
to get as far as 86% then a reboot occurs.

So I've now unplugged the SD card (assuming it's safe to do so at the 
boot prompt) and plugged it into my main PC. Not recognised!

fdisk -l shows nothing.
Plug it back into the XU4 and ...

   Exynos5422 # boot
   there are pending interrupts 0x0001
   [ERROR] response timeout error : 0104 cmd 17
   ** Can't read partition table on 0:0 **
   there are pending interrupts 0x0104
   [ERROR] response timeout error : 0104 cmd 17

   ** Unable to use mmc 0:1 for fatload **
   there are pending interrupts 0x0104
   [ERROR] response timeout error : 0104 cmd 17
   ** Can't read partition table on 0:0 **
   ** Bad partition 1 **
   ext4load - load binary file from a Ext4 filesystem

   Usage:
   ext4load  <dev[:part]> [addr] [filename] [bytes]
  - load binary file 'filename' from 'dev' on 'interface'
 to address 'addr' from ext4 filesystem
   there are pending interrupts 0x0104
   [ERROR] response timeout error : 0104 cmd 17
   ** Can't read partition table on 0:0 **
   ** Bad partition 2 **
   ext4load - load binary file from a Ext4 filesystem

   Usage:
   ext4load  <dev[:part]> [addr] [filename] [bytes]
  - load binary file 'filename' from 'dev' on 'interface'
 to address 'addr' from ext4 filesystem
>>> Load Boot Script from mmc 0:1 <<<
   reading boot.scr

   ** Unable to read "boot.scr" from mmc 0:1 **
>>> Load Boot Script from mmc 0:2 <<<

   ** Unable to use mmc 0:2 for fatload **
>>> Run Default Bootcmd <<<
   reading kernel..device 0 Start 1263, Count 16384
   MMC read: dev # 0, block # 1263, count 16384 ... 16384 blocks read: OK
   completed
   reading RFS..device 0 Start 17647, Count 2048
   MMC read: dev # 0, block # 17647, count 2048 ... 2048 blocks read: OK
   completed
   Bad Linux ARM zImage magic!

Now power cycling the XU4... and it's continually rebooting as before... 
put the sd-card back into my main PC and it's not seen. Eh?

As you guys have had this working, it would be great to know what OS, 
Kernel version, you used?

I'll get the Y-cable and better PSU, and (hopefully) re-flash the image 
onto the sd-card, although I cant do that at the moment as it's no 
longer being recognised, another * new sd-card? :-(, deep 
breath...calm...

Maybe after a reboot the card will be seen with Ubuntu, maybe Windows.. 
Haven't got time now...

Regards,
Dave

On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the issue may be 
power draw on the USB interface during boot. One of the common issues with the 
XU4 that I've seen reported is that the USB3 ports do not provide USB3 spec 
power levels.

Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an external 
power adapter to feed power to the USRP.

Another test you could try -- Try using the USB2 on the XU4. Does it result in 
the same boot up problems?

I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini and 
have not seen any issue such as this.

Regards,
Nate Temple

On Sep 2, 2017, at 1:44 AM, David via USRP-users <usrp-users@lists.ettus.com> 
wrote:

Hi All,

Re: [USRP-users] B200mini & XU4 problem

2017-09-04 Thread David via USRP-users


Thanks All,

So on USB2 I get the following:

   odroid@odroid:~$ uhd_fft -f 935e6 -s 1e6
   linux; GNU C++ version 5.4.0 20160609; Boost_105800;
   UHD_003.010.002.000-0-gbd6e21dc

   -- Detected Device: B200mini
   -- Operating over USB 2.
   -- Initialize CODEC control...
   -- Initialize Radio control...
   -- Performing register loopback test... pass
   -- Performing CODEC loopback test... pass
   -- Setting master clock rate selection to 'automatic'.
   -- Asking for clock rate 16.00 MHz...
   -- Actually got clock rate 16.00 MHz.
   -- Performing timer loopback test... pass
   -- Asking for clock rate 32.00 MHz...
   -- Actually got clock rate 32.00 MHz.
   -- Performing timer loopback test... pass

   UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
EnvironmentError: IOError: usb rx8 transfer status:
   LIBUSB_TRANSFER_NO_DEVICE
   terminate called after throwing an instance of 'uhd::usb_error'
  what():  RuntimeError: USBError -4: usb tx4 submit failed:
   LIBUSB_ERROR_NO_DEVICE
   Aborted


and the GUI appears for a fraction of a second. However, running the 
following causes no errors:


   odroid@odroid:~$ uhd_rx_cfile -r 1e6 -f 935e6 blob.raw
   linux; GNU C++ version 5.4.0 20160609; Boost_105800;
   UHD_003.010.002.000-0-gbd6e21dc

   -- Detected Device: B200mini
   -- Operating over USB 2.
   -- Initialize CODEC control...
   -- Initialize Radio control...
   -- Performing register loopback test... pass
   -- Performing CODEC loopback test... pass
   -- Setting master clock rate selection to 'automatic'.
   -- Asking for clock rate 16.00 MHz...
   -- Actually got clock rate 16.00 MHz.
   -- Performing timer loopback test... pass
   -- Asking for clock rate 32.00 MHz...
   -- Actually got clock rate 32.00 MHz.
   -- Performing timer loopback test... pass
   [UHD_RX] Defaulting to mid-point gains:
   [UHD_RX] Channel 0 gain: 38.0 dB
   ^Codroid@odroid:~$
   odroid@odroid:~$
   odroid@odroid:~$ ls -ltr
   total 31212
   drwxrwxr-x  8 odroid odroid 4096 Aug 20 14:17 uhd
   drwxrwxr-x 33 odroid odroid 4096 Aug 25 15:59 gnuradio
   -rw-rw-r--  1 odroid odroid 31951808 Sep  4 16:05 blob.raw

I'll get the Y-cable Nate suggested, probably a beefier PSU too, and go 
from there...


Thanks All,
Dave


On 03/09/17 22:45, Nate Temple wrote:

Hi Dave,

What is the error when uhd_fft fails over the USB2 port?

The routing is different between the USB2 and USB3 ports on the XU4. The USB3 
ports are routed through a USB3 hub (GL3521) and also have a RTL8153 1GbE 
ethernet controller on the #1 channel. They also provide their own bus power 
through the NCP380HM switch. I don't know where the issue is at with the XU4 
power via the USB3 ports, but any of these could be the culprit. I know Odroid 
will recommend a powered hub for USB3 devices that don't have an external power 
option. The schematics will show all the details:

https://dn.odroid.com/5422/ODROID-XU4/Schematics/

Regards,
Nate Temple


On Sep 3, 2017, at 5:46 AM, David via USRP-users <usrp-users@lists.ettus.com> 
wrote:

Hey all,
Thanks for the replies, didn't realise it would work on USB2... so I...
- plugged into USB2 port
- no boot up problems with the udev rule enabled
- get similar device read errors, until the device is unplugged & plugged back 
in
- then uhd_usrp_probe works, no corruption of the fs :-)
- takes much longer to load fw!
- can't run uhd_fft however (...LIBUSB_ERROR_NO_DEVICE...)

So using USB2 port seems OK, but need to unplug, plug in the device after each 
reboot, can do a
uhd_usrp_probe with no issues, and reboot OK, but uhd_fft fails (is that 
expected?).

Why the difference between USB2 and USB3, thought the power (500mA) was the 
same?

I've been wondering about power, esp. since reading the odroid forums, I think, 
as you say Nate, a powered hub, or Y adaptor (I didn't know about that) is the 
next step...

Marcus, is there a location for the Arch image please? I saw a previous post 
from you about using b2x0's with XU4... :-)

Many Thanks,
Dave

On 02/09/17 23:30, Marcus D. Leech via USRP-users wrote:

On 09/02/2017 05:02 PM, Nate Temple via USRP-users wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the issue may be 
power draw on the USB interface during boot. One of the common issues with the 
XU4 that I've seen reported is that the USB3 ports do not provide USB3 spec 
power levels.

Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an external 
power adapter to feed power to the USRP.

Another test you could try -- Try using the USB2 on the XU4. Does it result in 
the same boot up problems?

I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini and 
have not seen any issue such as this.

Regards,
N

Re: [USRP-users] B200mini & XU4 problem

2017-09-03 Thread David via USRP-users


Hey all,
Thanks for the replies, didn't realise it would work on USB2... so I...
- plugged into USB2 port
- no boot up problems with the udev rule enabled
- get similar device read errors, until the device is unplugged & 
plugged back in

- then uhd_usrp_probe works, no corruption of the fs :-)
- takes much longer to load fw!
- can't run uhd_fft however (...LIBUSB_ERROR_NO_DEVICE...)

So using USB2 port seems OK, but need to unplug, plug in the device 
after each reboot, can do a
uhd_usrp_probe with no issues, and reboot OK, but uhd_fft fails (is that 
expected?).


Why the difference between USB2 and USB3, thought the power (500mA) was 
the same?


I've been wondering about power, esp. since reading the odroid forums, I 
think, as you say Nate, a powered hub, or Y adaptor (I didn't know about 
that) is the next step...


Marcus, is there a location for the Arch image please? I saw a previous 
post from you about using b2x0's with XU4... :-)


Many Thanks,
Dave

On 02/09/17 23:30, Marcus D. Leech via USRP-users wrote:

On 09/02/2017 05:02 PM, Nate Temple via USRP-users wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of the 
common issues with the XU4 that I've seen reported is that the USB3 
ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an 
external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does it 
result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with a 
B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
<usrp-users@lists.ettus.com> wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, 
and latest GIT clone of UHD (as of two weeks ago). Two uSD cards I 
had are now totally trashed. I'm on my last card. They seem to get 
totally trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I reboot, 
an fsck is done every time, and also has the effect of continually 
rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts up 
UHD (uhd-usrp.rules) I am also able to reboot with no issues. So a 
driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


I run a *PAIR* of b205-minis on an Odroid XU4, but I use an external, 
powered, USB-3.0 hub.   I don't recall ever having a filesystem 
trashing problem, but

  I use an Arch image.

Modulo kernel bugs, there's no way for UHD applications or hardware to 
"trash your filesystem".  So, if this is an issue, then the issue is 
with the
  underlying OS+drivers implementation.  None of the UHD code runs in 
kernel space, and runs as an ordinary user.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] B200mini & XU4 problem

2017-09-02 Thread David via USRP-users


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and 
latest GIT clone of UHD (as of two weeks ago). Two uSD cards I had are 
now totally trashed. I'm on my last card. They seem to get totally 
trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I reboot, an 
fsck is done every time, and also has the effect of continually 
rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I managed 
to work out that if I remove the udev rule that starts up UHD 
(uhd-usrp.rules) I am also able to reboot with no issues. So a driver issue?


Without the udev rule I get the following, which I'm assuming is normal?:

[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] One-Sample offsets with external ref/pps

[USRP-users] N320: XQ image issue using sfp0 as time_source

Re: [USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

[USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

[USRP-users] N320: set_rx_bw() does not change the actual BW

[USRP-users] [E310] Fastlock profiles usage with UHD API

[USRP-users] UBX-40 fails to ID on N210

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] UHD dropping samples running on Debian 9

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] UHD dropping samples running on Debian 9

Re: [USRP-users] UHD dropping samples running on Debian 9

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] B200mini & XU4 problem

Re: [USRP-users] B200mini & XU4 problem

[USRP-users] B200mini & XU4 problem

18 matches

Site Navigation

Mail list logo

Footer information