Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Has anybody use B210 with the Beaglebone-Black?
(Julian Oliver)
2. USRP2 - No UHD Devices Found (Roland Awusie)
3. Re: USRP2 - No UHD Devices Found (Tom Tsou)
4. Re: USRP2 - No UHD Devices Found (Roland Awusie)
5. Re: USRP2 - No UHD Devices Found (Roland Awusie)
6. Re: Has anybody use B210 with the Beaglebone-Black?
(Julian Oliver)
7. Re: Has anybody use B210 with the Beaglebone-Black? (Tom Tsou)
8. Re: Has anybody use B210 with the Beaglebone-Black?
(Julian Oliver)
9. Re: USRP B2xx Transport Control for low-bandwidth signals
(Jacob Gilbert)
10. Re: BPSK using GRC (AK)
11. Re: USRP B2xx Transport Control for low-bandwidth signals
(Jacob Gilbert)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 Jun 2014 18:06:11 +0200
From: Julian Oliver <[email protected]>
To: 442777816 <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Has anybody use B210 with the
Beaglebone-Black?
Message-ID: <20140613160611.GD12398@rimu>
Content-Type: text/plain; charset="us-ascii"
..on Fri, Jan 17, 2014 at 07:03:02PM +0800, 442777816 wrote:
> Hi,everybody
>
> Now I wanna use the BBB as the host of the B210 board. But I met some problem
> when I was doing with UHD. Has anyone do the similiar things like me? What is
> the operating system you use in your BBB?
I've just compiled the latest uhd directly on a Rev A5C BeagleBone Black running
Debian Wheezy and am finding that 'uhd_usrp_probe' doesn't see my B200*:
root@arm:~# uhd_usrp_probe
linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.007.001-72-g383061d8
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
Strangely 'usb-devices' lists the device, albeit with blank/zero'd Vendor and
Product IDs (second entry):
root@arm:~# usb-devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=03.08
S: Manufacturer=Linux 3.8.13-bone56 musb-hcd
S: Product=MUSB HDRC host driver
S: SerialNumber=musb-hdrc.1.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev=00.00
S: Manufacturer=Ettus Research LLC
S: Product=USRP B200
S: SerialNumber=ECR04Z3B2
C: #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=2mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=03.08
S: Manufacturer=Linux 3.8.13-bone56 musb-hcd
S: Product=MUSB HDRC host driver
S: SerialNumber=musb-hdrc.0.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
lsusb:
root@arm:~# lsusb
Bus 001 Device 014: ID 0000:0000
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Worth mentioning that the BeagleBone Black's USB bus power is insufficient for
the kernel to see the B200 at all, so I'm running it on 6V DC. Even so, I need
to toggle the following files in /sys before I can see it in dmesg output:
echo 0 > /sys/bus/usb/devices/usb1/authorized
sleep 1
echo 1 > /sys/bus/usb/devices/usb1/authorized
sleep 1
echo on > /sys/bus/usb/devices/usb1/power/control
I'm still digging and will report back with my results.
* I realise referencing a B200 rather than B210 makes this post slightly off
topic.
Cheers,
--
Julian Oliver
http://julianoliver.com
http://criticalengineering.org
PGP key: https://julianoliver.com/key.asc
Beware the auto-complete life.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/a28ae9a8/attachment-0001.asc>
------------------------------
Message: 2
Date: Fri, 13 Jun 2014 10:22:07 -0600
From: Roland Awusie <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP2 - No UHD Devices Found
Message-ID:
<cagdf4g5wmu3hxdksjz3r4hgoocwuqqiwv-tnlcdib6yr10q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I running into "No UHD Devices Found" issues on my usrp2 with wbx
daughterboard. I recently used "/*usrp2_card_burner_gui.py*" program to
update the firmware and fpga images unto the SD card. My network and IP
addres setup working OK as below.
But when I ran "uhd_find_devices" on the terminal, I got No UHD Devices
Found" error.
[rawusie@localhost /]$ *ping 192.168.10.3*
PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
64 bytes from 192.168.10.3: icmp_seq=1 ttl=32 time=1.12 ms
64 bytes from 192.168.10.3: icmp_seq=2 ttl=32 time=1.09 ms
64 bytes from 192.168.10.3: icmp_seq=3 ttl=32 time=1.09 ms
64 bytes from 192.168.10.3: icmp_seq=4 ttl=32 time=1.15 ms
64 bytes from 192.168.10.3: icmp_seq=5 ttl=32 time=1.11 ms
64 bytes from 192.168.10.3: icmp_seq=6 ttl=32 time=1.11 ms
^C
--- 192.168.10.3 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 1.091/1.116/1.152/0.038 ms
[rawusie@localhost /]$
[rawusie@localhost /]$
[rawusie@localhost /]$ *uhd_find_devices*
linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
UHD_003.007.001-72-g383061d8
*No UHD Devices Found*
[rawusie@localhost /]$
[rawusie@localhost /]$
Please,Can someone help me to overcome this problem?
Thank you,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/5a9f5267/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 13 Jun 2014 13:50:37 -0400
From: Tom Tsou <[email protected]>
To: Roland Awusie <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 - No UHD Devices Found
Message-ID:
<CAATyM+aU0xAGA_pySEFSbVN4Gh40=ewe2bvle2zdjcxd2jb...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 13, 2014 at 12:22 PM, Roland Awusie via USRP-users
<[email protected]> wrote:
> [rawusie@localhost /]$ ping 192.168.10.3
> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
> 64 bytes from 192.168.10.3: icmp_seq=1 ttl=32 time=1.12 ms
> 64 bytes from 192.168.10.3: icmp_seq=2 ttl=32 time=1.09 ms
> 64 bytes from 192.168.10.3: icmp_seq=3 ttl=32 time=1.09 ms
> 64 bytes from 192.168.10.3: icmp_seq=4 ttl=32 time=1.15 ms
> 64 bytes from 192.168.10.3: icmp_seq=5 ttl=32 time=1.11 ms
> 64 bytes from 192.168.10.3: icmp_seq=6 ttl=32 time=1.11 ms
> ^C
> --- 192.168.10.3 ping statistics ---
> 6 packets transmitted, 6 received, 0% packet loss, time 5006ms
> rtt min/avg/max/mdev = 1.091/1.116/1.152/0.038 ms
> [rawusie@localhost /]$
> [rawusie@localhost /]$
> [rawusie@localhost /]$ uhd_find_devices
> linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
> UHD_003.007.001-72-g383061d8
>
> No UHD Devices Found
What happens when you run the following?
uhd_usrp_probe --args="addr=192.168.10.3"
-TT
------------------------------
Message: 4
Date: Fri, 13 Jun 2014 12:02:02 -0600
From: Roland Awusie <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 - No UHD Devices Found
Message-ID:
<cagdf4g4c3gx8mt+tfalofgz+xtt15+wwojstvvbpuvt1rla...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tom,
I got the following output. These results as pointed out by Marcus implies
the USRP2 is working. Just need to clean up these warnings.
linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
UHD_003.007.001-72-g383061d8
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
______________________________
_______________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: USRP2 r4
| | hardware: 1024
| | mac-addr: 00:50:c2:85:3b:5a
| | ip-addr: 192.168.10.3
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: 2906
| | FW Version: 12.4
| | FPGA Version: 10.1
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: 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: WBX, WBX + Simple GDB (0x0053)
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: WBXv2 RX+GDB
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 68.750 to 2200.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ltc2284
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -250.000 to 250.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: WBX (0x0052)
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: WBXv2 TX+GDB
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 68.750 to 2200.000 Mhz
| | | | Gain range PGA0: 0.0 to 25.0 step 0.1 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
Thank you,
Roland
On Fri, Jun 13, 2014 at 11:50 AM, Tom Tsou <[email protected]> wrote:
> On Fri, Jun 13, 2014 at 12:22 PM, Roland Awusie via USRP-users
> <[email protected]> wrote:
> > [rawusie@localhost /]$ ping 192.168.10.3
> > PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
> > 64 bytes from 192.168.10.3: icmp_seq=1 ttl=32 time=1.12 ms
> > 64 bytes from 192.168.10.3: icmp_seq=2 ttl=32 time=1.09 ms
> > 64 bytes from 192.168.10.3: icmp_seq=3 ttl=32 time=1.09 ms
> > 64 bytes from 192.168.10.3: icmp_seq=4 ttl=32 time=1.15 ms
> > 64 bytes from 192.168.10.3: icmp_seq=5 ttl=32 time=1.11 ms
> > 64 bytes from 192.168.10.3: icmp_seq=6 ttl=32 time=1.11 ms
> > ^C
> > --- 192.168.10.3 ping statistics ---
> > 6 packets transmitted, 6 received, 0% packet loss, time 5006ms
> > rtt min/avg/max/mdev = 1.091/1.116/1.152/0.038 ms
> > [rawusie@localhost /]$
> > [rawusie@localhost /]$
> > [rawusie@localhost /]$ uhd_find_devices
> > linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
> > UHD_003.007.001-72-g383061d8
> >
> > No UHD Devices Found
>
> What happens when you run the following?
>
> uhd_usrp_probe --args="addr=192.168.10.3"
>
> -TT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/bdad01dd/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 13 Jun 2014 13:25:59 -0600
From: Roland Awusie <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 - No UHD Devices Found
Message-ID:
<cagdf4g67p3xitamh7kzu0rcxdpc1ivvudswaaw89dzzucb5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, after clearing these warnings, the out look much better:
[root@localhost /]# uhd_usrp_probe --args "addr=192.168.10.3"
linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
UHD_003.007.001-72-g383061d8
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: USRP2 r4
| | hardware: 1024
| | mac-addr: 00:50:c2:85:3b:5a
| | ip-addr: 192.168.10.3
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: 2906
| | FW Version: 12.4
| | FPGA Version: 10.1
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: 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: WBX, WBX + Simple GDB (0x0053)
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: WBXv2 RX+GDB
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 68.750 to 2200.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ltc2284
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -250.000 to 250.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: WBX (0x0052)
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: WBXv2 TX+GDB
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 68.750 to 2200.000 Mhz
| | | | Gain range PGA0: 0.0 to 25.0 step 0.1 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
Thank you all for your help.
Roland
On Fri, Jun 13, 2014 at 12:02 PM, Roland Awusie <[email protected]>
wrote:
> Hi Tom,
>
> I got the following output. These results as pointed out by Marcus implies
> the USRP2 is working. Just need to clean up these warnings.
>
>
> linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
> UHD_003.007.001-72-g383061d8
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> ______________________________
> _______________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: USRP2 r4
> | | hardware: 1024
> | | mac-addr: 00:50:c2:85:3b:5a
> | | ip-addr: 192.168.10.3
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: 2906
> | | FW Version: 12.4
> | | FPGA Version: 10.1
> | |
> | | Time sources: none, external, _external_, mimo
> | | Clock sources: internal, external, mimo
> | | Sensors: 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: WBX, WBX + Simple GDB (0x0053)
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: WBXv2 RX+GDB
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 68.750 to 2200.000 Mhz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ltc2284
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -250.000 to 250.000 Mhz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | ID: WBX (0x0052)
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: WBXv2 TX+GDB
> | | | | Antennas: TX/RX, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 68.750 to 2200.000 Mhz
> | | | | Gain range PGA0: 0.0 to 25.0 step 0.1 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9777
> | | | | Gain Elements: None
>
> Thank you,
> Roland
>
>
> On Fri, Jun 13, 2014 at 11:50 AM, Tom Tsou <[email protected]> wrote:
>
>> On Fri, Jun 13, 2014 at 12:22 PM, Roland Awusie via USRP-users
>> <[email protected]> wrote:
>> > [rawusie@localhost /]$ ping 192.168.10.3
>> > PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
>> > 64 bytes from 192.168.10.3: icmp_seq=1 ttl=32 time=1.12 ms
>> > 64 bytes from 192.168.10.3: icmp_seq=2 ttl=32 time=1.09 ms
>> > 64 bytes from 192.168.10.3: icmp_seq=3 ttl=32 time=1.09 ms
>> > 64 bytes from 192.168.10.3: icmp_seq=4 ttl=32 time=1.15 ms
>> > 64 bytes from 192.168.10.3: icmp_seq=5 ttl=32 time=1.11 ms
>> > 64 bytes from 192.168.10.3: icmp_seq=6 ttl=32 time=1.11 ms
>> > ^C
>> > --- 192.168.10.3 ping statistics ---
>> > 6 packets transmitted, 6 received, 0% packet loss, time 5006ms
>> > rtt min/avg/max/mdev = 1.091/1.116/1.152/0.038 ms
>> > [rawusie@localhost /]$
>> > [rawusie@localhost /]$
>> > [rawusie@localhost /]$ uhd_find_devices
>> > linux; GNU C++ version 4.8.2 20131212 (Red Hat 4.8.2-7); Boost_105400;
>> > UHD_003.007.001-72-g383061d8
>> >
>> > No UHD Devices Found
>>
>> What happens when you run the following?
>>
>> uhd_usrp_probe --args="addr=192.168.10.3"
>>
>> -TT
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/992200ff/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 13 Jun 2014 22:13:26 +0200
From: Julian Oliver <[email protected]>
To: 442777816 <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Has anybody use B210 with the
Beaglebone-Black?
Message-ID: <20140613201326.GE12398@rimu>
Content-Type: text/plain; charset="us-ascii"
So, some progress:
I switched from a lower quality 3000mA to a higher qyality 500mA 5V supply to
power my BeagleBone Black (Rev A5C) and now have a responsive UHD.
It's not all roses however. On boot the board doesn't see the B200 at all.
Nothing in dmesg. Unplugging and re-plugging does nothing.
I then performed some overrides in /sys:
echo 0 > /sys/bus/usb/devices/usb1/authorized
sleep 1
echo 1 > /sys/bus/usb/devices/usb1/authorized
sleep 1
echo on > /sys/bus/usb/devices/usb1/power/control
At this point the B200 popped up in dmesg output, with idVendor=2500,
idProduct=0020, albeit as "Westbridge":
[ 147.858566] usb usb1: unregistering interface 1-0:1.0
[ 147.860629] musb-hdrc musb-hdrc.1.auto: shutdown urb de073140 ep1in-intr
[ 147.864987] usb usb1: usb_disable_device nuking non-ep0 URBs
[ 148.881689] usb usb1: configuration #1 chosen from 1 choice
[ 148.881817] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 148.888241] hub 1-0:1.0: usb_probe_interface
[ 148.888293] hub 1-0:1.0: usb_probe_interface - got id
[ 148.888349] hub 1-0:1.0: USB hub found
[ 148.888434] hub 1-0:1.0: 1 port detected
[ 148.888465] hub 1-0:1.0: standalone hub
[ 148.888493] hub 1-0:1.0: individual port power switching
[ 148.888522] hub 1-0:1.0: no over-current protection
[ 148.888549] hub 1-0:1.0: Single TT
[ 148.888581] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
[ 148.888611] hub 1-0:1.0: power on to power good time: 10ms
[ 148.888675] hub 1-0:1.0: local power source is good
[ 148.888862] hub 1-0:1.0: enabling power on all ports
[ 148.889298] usb usb1: authorized to connect
[ 148.989770] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 148.989901] hub 1-0:1.0: hub_suspend
[ 148.989970] usb usb1: bus auto-suspend, wakeup 1
[ 149.918197] usb usb1: usb auto-resume
[ 149.918258] hub 1-0:1.0: hub_resume
[ 149.918437] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 211.102595] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 211.102736] hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
[ 211.210353] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status
0x101
[ 211.315833] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[ 211.435385] usb 1-1: default language 0x0409
[ 211.435668] usb 1-1: udev 2, busnum 1, minor = 1
[ 211.435707] usb 1-1: New USB device found, idVendor=2500, idProduct=0020
[ 211.435743] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 211.435775] usb 1-1: Product: WestBridge
[ 211.435805] usb 1-1: Manufacturer: Cypress
[ 211.435835] usb 1-1: SerialNumber: 0000000004BE
[ 211.437133] usb 1-1: usb_probe_device
[ 211.437178] usb 1-1: configuration #1 chosen from 1 choice
[ 211.437342] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 211.439177] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 211.439268] hub 1-0:1.0: port 1 enable change, status 00000503
I then ran uhd_usrp_probe and it all looks quite good:
linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.007.001-72-g383061d8
-- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... done
-- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200_fpga.bin... done
-- Operating over USB 2.
-- Detecting internal GPSDO.... No GPSDO found
-- not found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32 MHz
-- Actually got clock rate 32 MHz
-- Performing timer loopback test... pass
_____________________________________________________
/
| Device: B-Series Device
| _____________________________________________________
| /
| | Mboard: B200
| | revision: 4
| | product: 1
| | serial: ECR04Z3B2
| | FW Version: 4.0
| | FPGA Version: 3.0
| |
| | Time sources: none, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -16.000 to 16.000 Mhz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: FE-RX2
| | | | Antennas: TX/RX, RX2
| | | | Sensors:
| | | | Freq range: 50.000 to 6000.000 Mhz
| | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: B200 RX dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -16.000 to 16.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: FE-TX2
| | | | Antennas: TX/RX
| | | | Sensors:
| | | | Freq range: 50.000 to 6000.000 Mhz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: B200 TX dual DAC
| | | | Gain Elements: None
OpenBTS (which I'm ultimately trying to run on the BBB under Debian with the
B200) consistently fails after a short time however, but that's a story for
another thread.
Nonetheless, the moment it does I see this in the output:
[ 542.599223] musb-hdrc musb-hdrc.1.auto: shutdown urb de58ff40 ep6in-bulk
[ 542.599256] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c740 ep6in-bulk
[ 542.599276] musb-hdrc musb-hdrc.1.auto: shutdown urb df7a8bc0 ep6in-bulk
[ 542.599295] musb-hdrc musb-hdrc.1.auto: shutdown urb df45cec0 ep6in-bulk
[ 542.599313] musb-hdrc musb-hdrc.1.auto: shutdown urb de58fcc0 ep6in-bulk
[ 542.599332] musb-hdrc musb-hdrc.1.auto: shutdown urb df45cbc0 ep6in-bulk
[ 542.599350] musb-hdrc musb-hdrc.1.auto: shutdown urb df45cf40 ep6in-bulk
[ 542.599368] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c840 ep6in-bulk
[ 542.599386] musb-hdrc musb-hdrc.1.auto: shutdown urb df7a8540 ep6in-bulk
[ 542.599405] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c440 ep6in-bulk
[ 542.599422] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c1c0 ep6in-bulk
[ 566.223011] musb-hdrc musb-hdrc.1.auto: shutdown urb de659e40 ep6in-bulk
[ 566.223042] musb-hdrc musb-hdrc.1.auto: shutdown urb df7a8b40 ep6in-bulk
[ 566.223062] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c5c0 ep6in-bulk
[ 566.223081] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c140 ep6in-bulk
[ 566.223099] musb-hdrc musb-hdrc.1.auto: shutdown urb df45ce40 ep6in-bulk
[ 566.223117] musb-hdrc musb-hdrc.1.auto: shutdown urb df7a8c40 ep6in-bulk
[ 566.223135] musb-hdrc musb-hdrc.1.auto: shutdown urb df45cec0 ep6in-bulk
[ 566.223154] musb-hdrc musb-hdrc.1.auto: shutdown urb df45c3c0 ep6in-bulk
[ 566.223172] musb-hdrc musb-hdrc.1.auto: shutdown urb df7a8ec0 ep6in-bulk
Cheers,
--
Julian Oliver
http://julianoliver.com
http://criticalengineering.org
PGP key: https://julianoliver.com/key.asc
Beware the auto-complete life.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/83c2b351/attachment-0001.asc>
------------------------------
Message: 7
Date: Fri, 13 Jun 2014 16:26:39 -0400
From: Tom Tsou <[email protected]>
To: Julian Oliver <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Has anybody use B210 with the
Beaglebone-Black?
Message-ID:
<CAATyM+b4KmU5C1jiTmao6WJ_orL87DVrSP+Ln3PvCxF93J=5...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 13, 2014 at 4:13 PM, Julian Oliver via USRP-users
<[email protected]> wrote:
> OpenBTS (which I'm ultimately trying to run on the BBB under Debian with the
> B200) consistently fails after a short time however, but that's a story for
> another thread.
I can't comment on the other issues right now as my BBB is in a
cardboard box. But, for running OpenBTS on ARM, make sure you are
using the OsmoTRX transceiver.
http://openbsc.osmocom.org/trac/wiki/OsmoTRX
Notably, see the sections on ARM platforms with NEON and running
OsmoTRX with OpenBTS.
Also, do you have other devices (keyboard, mouse, etc.) hanging off the USB bus?
-TT
------------------------------
Message: 8
Date: Fri, 13 Jun 2014 22:40:13 +0200
From: Julian Oliver <[email protected]>
To: Tom Tsou <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Has anybody use B210 with the
Beaglebone-Black?
Message-ID: <20140613204013.GF12398@rimu>
Content-Type: text/plain; charset="us-ascii"
..on Fri, Jun 13, 2014 at 04:26:39PM -0400, Tom Tsou wrote:
> On Fri, Jun 13, 2014 at 4:13 PM, Julian Oliver via USRP-users
> <[email protected]> wrote:
> > OpenBTS (which I'm ultimately trying to run on the BBB under Debian with the
> > B200) consistently fails after a short time however, but that's a story for
> > another thread.
>
> I can't comment on the other issues right now as my BBB is in a
> cardboard box. But, for running OpenBTS on ARM, make sure you are
> using the OsmoTRX transceiver.
>
> http://openbsc.osmocom.org/trac/wiki/OsmoTRX
>
> Notably, see the sections on ARM platforms with NEON and running
> OsmoTRX with OpenBTS.
Very interesting, thanks! I'm a fan of OsmoCOM's work but didn't think to look
there to see if they had a transceiver solution suitable for ARM/NEON targets
like the BBB.
> Also, do you have other devices (keyboard, mouse, etc.) hanging off the USB
> bus?
No. I'm ssh'ing into the device over wired Ethernet.
Cheers,
--
Julian Oliver
http://julianoliver.com
http://criticalengineering.org
PGP key: https://julianoliver.com/key.asc
Beware the auto-complete life.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/47b2d30d/attachment-0001.asc>
------------------------------
Message: 9
Date: Fri, 13 Jun 2014 20:54:01 -0400
From: Jacob Gilbert <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP B2xx Transport Control for
low-bandwidth signals
Message-ID:
<cac52akby7wqe8s7h+hob9c+koxqup2ijqvyov2tqtc4rfxx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I see the issue regardless of the application. I was able to resolve the
issue entirely by inserting a delay block (delaying 4k samples at 32kS/s)
in the signal processing chain to act as a buffer. Default transport
control parameters.
I wouldn't raise this at all here, but I found it very odd that it worked
flawlessly with the B100.
Jacob
On Jun 12, 2014 9:03 AM, "Marcus D. Leech via USRP-users" <
[email protected]> wrote:
>
> On 06/06/2014 09:33 AM, Jacob Gilbert via USRP-users wrote:
>>
>> Hello,
>>
>> I am experiencing frequent underflows with the B210 and ran into a few
questions regarding UHD USB flow control.
>>
>> I am using a rate limited source (Audio Source) and generating a
low-bandwidth signal (256kS/s) and sending to the USRP. I notice a large
number of underflows (and LED flickering) on the B210 using this
configuration. If I interpolate and use a larger sample rate (1024kS/s) the
problem is greatly reduced. At 4096kS/s it is effectively gone. This
unfortunately doesn?t work well for what I need (the host cannot keep up
with this rate over USB and the necessary filtering to produce a suitably
clean interpolated signal) so I am hoping you can give me some help here.
>>
>> As another data point the application works fine at 256kS/s on the B100
on a non-disadvantaged platform but exhibits the same behavior using the
B210.
>>
>> Based on the UHD Transport Application Notes Ettus page, it looks like
there are 4 parameters that can be tweaked to modify behavior of the USB
transport mechanism. These do not appear to have much of an impact, if any
but I don?t quite understand which set I should modify for transmit
applications. I also noticed on the Ettus page regarding latency, there is
a note that the B100 has a ?flush timer? that also impacts the USB latency.
>>
>> 1. If I am attempting to transmit low bandwidth signals, which
parameters should be changed?
>>
>> 2. Does the flush timer note impact the B2xx and can this be set from
the gr-uhd interface (and if so, how)?
>>
>> 3. Am I overlooking something?
>>
>>
>> Thanks for the help,
>>
>> Jacob
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Jacob:
>
> I've engaged the R&D team to see if there's a quick win here. Clearly,
this should "just work".
>
> Does this problem occur regardless of what application you're using? If
you just use tx_waveforms, for example, at the low sample rate, do
> you get underruns?
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/629522b0/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 12 Jun 2014 06:13:33 +0000 (UTC)
From: AK <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] BPSK using GRC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Mike Jameson <mike@...> writes:
>
>
> Hi again, you are also not gray coding on tx but you are on rx.? FYI, a
further tweak for efficiency is to disable 'Pad for USRP' which is no longer
required for UHD implementations and was only applicable to USB USRP devices
anyhow.Mike
>
>
> --Mike Jameson M0MIK BScRadio Communications Technology SpecialistEmail:
[email protected]
>
> Web: http://scanoo.com
>
> On 30 March 2013 11:09, Mike Jameson <mike <at> scanoo.com> wrote:
>
> Hi, differential encoding is disabled on tx side but enabled on rx side.
Hope that fixes things.Mike
**Hi ZaInzAiN Jj !! Could you post the .txt file that you used for the
modulation? I'm trying to do the same problem but there's some error because
I dont have the appropriate file. Thankyou very much :)**
------------------------------
Message: 11
Date: Sat, 14 Jun 2014 09:06:28 -0400
From: Jacob Gilbert <[email protected]>
To: Balint Seeber <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B2xx Transport Control for
low-bandwidth signals
Message-ID:
<cac52akafyq025w+ydl5dcczfwywd0va_hyybd8tdf3oqcrj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I do think this is contributing, and last week I did check that providing a
slightly greater source rate than the sink will resolve the issue (for
short TX durations). That being said, I think something else is going on
here. This setup works fine with a rubidium locked B100; there is the
occasional overflow or underflow due to the two clock issue, but overall
very stable. With the B200 it is not even close; very noticeable
transmission outage on the B200, TX LED flickering maybe 3-4 times per
second.
The B2xx is sold as a B100 replacement, and I was surprised it had issues
here. It's been great other than this though.
Jacob
On Thu, Jun 12, 2014 at 12:48 PM, Balint Seeber <[email protected]>
wrote:
> Hi Jacob,
>
> You might be experiencing the 'two clock' problem, since your audio source
> and the B210 are driven by different crystals (I have seen this before
> myself).
>
> To test this, please have a look at Lab 5 here:
> http://files.ettus.com/tutorials/labs/ (I resample to 1.1 x the USRP
> sample rate of 250ksps).
>
> There are more notes on this here:
> http://files.ettus.com/tutorials/labs/html/img88.html (or the PDF in the
> directory linked above).
>
> Let us know what happens when you make that change!
>
> Kind regards,
> Balint
>
>
> On Fri, Jun 6, 2014 at 6:33 AM, Jacob Gilbert via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> I am experiencing frequent underflows with the B210 and ran into a few
>> questions regarding UHD USB flow control.
>>
>> I am using a rate limited source (Audio Source) and generating a
>> low-bandwidth signal (256kS/s) and sending to the USRP. I notice a large
>> number of underflows (and LED flickering) on the B210 using this
>> configuration. If I interpolate and use a larger sample rate (1024kS/s) the
>> problem is greatly reduced. At 4096kS/s it is effectively gone. This
>> unfortunately doesn?t work well for what I need (the host cannot keep up
>> with this rate over USB and the necessary filtering to produce a suitably
>> clean interpolated signal) so I am hoping you can give me some help here.
>>
>> As another data point the application works fine at 256kS/s on the B100
>> on a non-disadvantaged platform but exhibits the same behavior using the
>> B210.
>>
>> Based on the UHD Transport Application Notes Ettus page, it looks like
>> there are 4 parameters that can be tweaked to modify behavior of the USB
>> transport mechanism. These do not appear to have much of an impact, if any
>> but I don?t quite understand which set I should modify for transmit
>> applications. I also noticed on the Ettus page regarding latency, there is
>> a note that the B100 has a ?flush timer? that also impacts the USB latency.
>>
>> 1. If I am attempting to transmit low bandwidth signals, which parameters
>> should be changed?
>>
>> 2. Does the flush timer note impact the B2xx and can this be set from the
>> gr-uhd interface (and if so, how)?
>>
>> 3. Am I overlooking something?
>>
>>
>> Thanks for the help,
>>
>> Jacob
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140614/c8e4a759/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 46, Issue 14
******************************************
