usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRaspberry Pi 4 sampling Rate
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I connect it
to a Raspberry Pi 4 (which has two USB 3 ports) and I run the example
benchmark_rate with the same sampling rate I get the output that I copy
below. It seems that even if it is also operating over USB 3, this
connection cannot meet the expected performance anymore. If I reduce the
sampling rate (down to 12 MS approx) everything works fine. Any ideas about
what might be causing this problem?
By the way, I already followed all the instructions explained at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
.
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (overflows (O)
MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (underruns (U)
MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery ahead of error
timestamp! Unable to calculate number of dropped samples.(Delta: -3170
ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote:
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I
connect it to a Raspberry Pi 4 (which has two USB 3 ports) and I run
the example benchmark_rate with the same sampling rate I get the
output that I copy below. It seems that even if it is also operating
over USB 3, this connection cannot meet the expected performance
anymore. If I reduce the sampling rate (down to 12 MS approx)
everything works fine. Any ideas about what might be causing this problem?
By the way, I already followed all the instructions explained at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits.
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (overflows
(O) MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (underruns
(U) MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
Well, the main reason is that your typical laptop compute environment,
based on x86 processor technology, is going to be more powerful
than the ARM on a Raspberry Pi4.
Now, you may be able to improve things slightly by adjusting the USB
transport parameters, as described here:
https://files.ettus.com/manual/page_transport.html#transport_usb
But once you actually start "doing stuff" on the Raspberry Pi, you'll
find that it can't process as many samples per second as on an x86
system--whether a laptop or desktop machine. There's a reason that a
Raspberry Pi is $50, and a typical low-end laptop is 10 times that.
I have only succeeded in running a B210 on a Raspberry Pi at lower data
rates (closer to 12MS) so your experience is consistent with mine.
On Tue, 3 Nov 2020 at 17:20, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote:
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I
connect it to a Raspberry Pi 4 (which has two USB 3 ports) and I run
the example benchmark_rate with the same sampling rate I get the
output that I copy below. It seems that even if it is also operating
over USB 3, this connection cannot meet the expected performance
anymore. If I reduce the sampling rate (down to 12 MS approx)
everything works fine. Any ideas about what might be causing this
problem?
By the way, I already followed all the instructions explained at
<
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (overflows
(O) MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (underruns
(U) MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
Well, the main reason is that your typical laptop compute environment,
based on x86 processor technology, is going to be more powerful
than the ARM on a Raspberry Pi4.
Now, you may be able to improve things slightly by adjusting the USB
transport parameters, as described here:
https://files.ettus.com/manual/page_transport.html#transport_usb
But once you actually start "doing stuff" on the Raspberry Pi, you'll
find that it can't process as many samples per second as on an x86
system--whether a laptop or desktop machine. There's a reason that a
Raspberry Pi is $50, and a typical low-end laptop is 10 times that.
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 11/03/2020 02:19 PM, Luke Stutters wrote:
I have only succeeded in running a B210 on a Raspberry Pi at lower
data rates (closer to 12MS) so your experience is consistent with mine.
In certain very-simple DSP flows, I've achieved 14Msps on an Odroid
XU4--which is spec-similar to the Rpi4 B.
CPU/Memory/IO performance really matters. Just because the system has a
USB3 interface does NOT mean that it can
sustain high rates. Even just moving samples through your system,
without doing anything to them (as in the benchmark_rate
example) requires code-paths that are at least several hundred
instructions long. Multi-core doesn't necessarily help much with
this because there's no performant way to effectively parallelize the
simple process of pulling samples off of USB and getting them
into the user layer. The SMP aspects of most modern systems only
really start to "shine" when you have a DSP work-flow with
lots of steps that can each benefit from running in their own
thread. But you still have a rate-limiting step of getting the samples
out of the device and into the work-flow. In that portion, system
details matter A LOT.
On Tue, 3 Nov 2020 at 17:20, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote:
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I
connect it to a Raspberry Pi 4 (which has two USB 3 ports) and I
run
the example benchmark_rate with the same sampling rate I get the
output that I copy below. It seems that even if it is also
operating
over USB 3, this connection cannot meet the expected performance
anymore. If I reduce the sampling rate (down to 12 MS approx)
everything works fine. Any ideas about what might be causing
this problem?
By the way, I already followed all the instructions explained at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
<https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits>
<https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits>.
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (overflows
(O) MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (underruns
(U) MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery
ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after
overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery
ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery
ahead of
error timestamp! Unable to calculate number of dropped
samples.(Delta:
-3170 ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun
recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun
recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery
ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
Well, the main reason is that your typical laptop compute
environment,
based on x86 processor technology, is going to be more powerful
than the ARM on a Raspberry Pi4.
Now, you *may* be able to improve things slightly by adjusting the
USB
transport parameters, as described here:
https://files.ettus.com/manual/page_transport.html#transport_usb
But once you actually start "doing stuff" on the Raspberry Pi, you'll
find that it can't process as many samples per second as on an x86
system--whether a laptop or desktop machine. There's a reason
that a
Raspberry Pi is $50, and a typical low-end laptop is 10 times that.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I too was able to sustain around 12Msps on an XU4+B200mini, and was also
able to get OpenBTS to work.
Marcus, hope it's OK to ask, but did you use a USB3 hub? When I tried it
the XU4 was unable to supply enough current, causing the SDcard to get
corrupted (I had a lot of fun with this!), the solution to this
apparently known issue was to use a hub.
Cheers,
Dave
On 03/11/2020 20:33, Marcus D. Leech via USRP-users wrote:
On 11/03/2020 02:19 PM, Luke Stutters wrote:
I have only succeeded in running a B210 on a Raspberry Pi at lower
data rates (closer to 12MS) so your experience is consistent with mine.
In certain very-simple DSP flows, I've achieved 14Msps on an Odroid
XU4--which is spec-similar to the Rpi4 B.
CPU/Memory/IO performance really matters. Just because the system has
a USB3 interface does NOT mean that it can
sustain high rates. Even just moving samples through your system,
without doing anything to them (as in the benchmark_rate
example) requires code-paths that are at least several hundred
instructions long. Multi-core doesn't necessarily help much with
this because there's no performant way to effectively parallelize
the simple process of pulling samples off of USB and getting them
into the user layer. The SMP aspects of most modern systems only
really start to "shine" when you have a DSP work-flow with
lots of steps that can each benefit from running in their own
thread. But you still have a rate-limiting step of getting the samples
out of the device and into the work-flow. In that portion, system
details matter A LOT.
On Tue, 3 Nov 2020 at 17:20, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote:
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I
connect it to a Raspberry Pi 4 (which has two USB 3 ports) and
I run
the example benchmark_rate with the same sampling rate I get the
output that I copy below. It seems that even if it is also
operating
over USB 3, this connection cannot meet the expected performance
anymore. If I reduce the sampling rate (down to 12 MS approx)
everything works fine. Any ideas about what might be causing
this problem?
By the way, I already followed all the instructions explained at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
<https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits>
<https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
<https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits>>.
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection
(overflows
(O) MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection
(underruns
(U) MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1
channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun
recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after
overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery
ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery
ahead of
error timestamp! Unable to calculate number of dropped
samples.(Delta:
-3170 ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun
recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun
recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun
recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun
recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
Well, the main reason is that your typical laptop compute
environment,
based on x86 processor technology, is going to be more powerful
than the ARM on a Raspberry Pi4.
Now, you *may* be able to improve things slightly by adjusting
the USB
transport parameters, as described here:
https://files.ettus.com/manual/page_transport.html#transport_usb
<https://files.ettus.com/manual/page_transport.html#transport_usb>
But once you actually start "doing stuff" on the Raspberry Pi,
you'll
find that it can't process as many samples per second as on an x86
system--whether a laptop or desktop machine. There's a reason
that a
Raspberry Pi is $50, and a typical low-end laptop is 10 times that.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<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
I used the external power input on the B210.
Sent from my iPhone
On Nov 4, 2020, at 12:13 PM, David Evans via USRP-users usrp-users@lists.ettus.com wrote:
I too was able to sustain around 12Msps on an XU4+B200mini, and was also able to get OpenBTS to work.
Marcus, hope it's OK to ask, but did you use a USB3 hub? When I tried it the XU4 was unable to supply enough current, causing the SDcard to get corrupted (I had a lot of fun with this!), the solution to this apparently known issue was to use a hub.
Cheers,
Dave
On 03/11/2020 20:33, Marcus D. Leech via USRP-users wrote:
On 11/03/2020 02:19 PM, Luke Stutters wrote:
I have only succeeded in running a B210 on a Raspberry Pi at lower data rates (closer to 12MS) so your experience is consistent with mine.
In certain very-simple DSP flows, I've achieved 14Msps on an Odroid XU4--which is spec-similar to the Rpi4 B.
CPU/Memory/IO performance really matters. Just because the system has a USB3 interface does NOT mean that it can
sustain high rates. Even just moving samples through your system, without doing anything to them (as in the benchmark_rate
example) requires code-paths that are at least several hundred instructions long. Multi-core doesn't necessarily help much with
this because there's no performant way to effectively parallelize the simple process of pulling samples off of USB and getting them
into the user layer. The SMP aspects of most modern systems only really start to "shine" when you have a DSP work-flow with
lots of steps that can each benefit from running in their own thread. But you still have a rate-limiting step of getting the samples
out of the device and into the work-flow. In that portion, system details matter A LOT.
On Tue, 3 Nov 2020 at 17:20, Marcus D. Leech via USRP-users usrp-users@lists.ettus.com wrote:
On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote:
Hello,
I am using a USRP B200mini with a sampling rate of 40MS that works
perfectly fine connected to a laptop with USB 3. However, when I
connect it to a Raspberry Pi 4 (which has two USB 3 ports) and I run
the example benchmark_rate with the same sampling rate I get the
output that I copy below. It seems that even if it is also operating
over USB 3, this connection cannot meet the expected performance
anymore. If I reduce the sampling rate (down to 12 MS approx)
everything works fine. Any ideas about what might be causing this problem?
By the way, I already followed all the instructions explained at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits.
./benchmark_rate --rx_rate 40e6 --tx_rate 40e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex...
[00:00:00.000044] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image:
/usr/local/share/uhd/images/usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200mini
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
[00:00:11.448560] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (overflows
(O) MSps).
This can cause 22.7428.
[00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1
channels) exceeds the maximum capacity of the connection (underruns
(U) MSps).
This can cause 22.7428.
[00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of
dropped samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error:
ERROR_CODE_TIMEOUT, continuing...
[00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing...
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_NO_DEVICE[
00:00:13.083166] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status:
LIBUSB_TRANSFER_NO_DEVICE
Well, the main reason is that your typical laptop compute environment,
based on x86 processor technology, is going to be more powerful
than the ARM on a Raspberry Pi4.
Now, you may be able to improve things slightly by adjusting the USB
transport parameters, as described here:
https://files.ettus.com/manual/page_transport.html#transport_usb
But once you actually start "doing stuff" on the Raspberry Pi, you'll
find that it can't process as many samples per second as on an x86
system--whether a laptop or desktop machine. There's a reason that a
Raspberry Pi is $50, and a typical low-end laptop is 10 times that.
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