Re: [USRP-users] B200mini & XU4 problem

[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 
> 
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


___
USRP-users mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] B200mini & XU4 problem

[Marcus D. Leech via USRP-users]

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  
> 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___
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

[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 
> 
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


___
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

[Marcus D. Leech via USRP-users]

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  
> 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___
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

[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 
 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

[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  
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

[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   [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   [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  
wrote:

Hi All,

I'm trying to get XU4 and B200mini to work together, but having a serious 
issue: the 

Re: [USRP-users] B200mini & XU4 problem

[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  
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,
Nate Temple





On 

Re: [USRP-users] B200mini & XU4 problem

[Ralph A. Schmid, dk5ras via USRP-users]

In such cases I tend to hard-wire the 5V pin of the USB connector, and the
issues usually are gone - when the external power supply is strong enough.
The USB port may originally be connected to the internal power distribution
of the PCB and cause hick-ups from high power drain...

Ralph.

> -Original Message-
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
> Nate Temple via USRP-users
> Sent: Saturday, September 2, 2017 11:03 PM
> To: David
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] B200mini & XU4 problem
> 
> 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  us...@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


___
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

[Nate Temple via USRP-users]

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  
> 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,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
 On Sep 2, 2017, at 1:44 AM, David via USRP-users 
  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
>> 
> 
> 
> 

Re: [USRP-users] B200mini & XU4 problem

[Marcus D. Leech via USRP-users]

On 09/03/2017 08:46 AM, David via USRP-users 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


https://archlinuxarm.org/platforms/armv7/samsung/odroid-xu4

___
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

[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 
 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

Re: [USRP-users] B200mini & XU4 problem

[Marcus D. Leech via USRP-users]

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

Re: [USRP-users] B200mini & XU4 problem

[Nate Temple via USRP-users]

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