[USRP-users] Raspberry Pi 4 sampling Rate

2020-11-03 Thread Alvaro Pendas Recondo via USRP-users 
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.44] 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.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 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.00 MHz...
[INFO] [B200] Actually got clock rate 40.00 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUO[00:00:12.078147] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
O[00:00:12.092404] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UO[00:00:12.108355] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
U[OU00:00:12.123737] Timestamp after overrun
recovery ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
OU[00:00:12.132437] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUOU[00:00:12.142422] Timestamp after overrun recovery
ahead of error timestamp! Unable to calculate number of dropped
samples.(Delta: -3170 ticks)
UUO[00:00:12.155257] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUUO[00:00:12.168528] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UUU[O00:00:12.178400] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
U[00:00:12.193251] Timestamp after overrun recovery ahead of error
timestamp! Unable to calculate number of dropped samples.(Delta: -3170
ticks)
OUO[00:00:12.204356] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
O[00:00:12.224770] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
UO[00:00:12.235145] Timestamp after overrun recovery ahead
of error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
U[O00:00:12.247517] Timestamp after overrun recovery ahead of
error timestamp! Unable to calculate number of dropped samples.(Delta:
-3170 ticks)
[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] Receive

Re: [USRP-users] Raspberry Pi 4 sampling Rate

2020-11-03 Thread Marcus D. Leech via USRP-users 

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 
. 




./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.44] 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.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 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.00 MHz...
[INFO] [B200] Actually got clock rate 40.00 MHz.
[WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
[WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
[00:00:11.891995] Tx timeouts: 1
UUUO[00:00:12.078147] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
O[00:00:12.092404] Timestamp after overrun 
recovery ahead of error timestamp! Unable to calculate number of 
dropped samples.(Delta: -3170 ticks)
UO[00:00:12.108355] Timestamp after overrun recovery ahead 
of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
U[OU00:00:12.123737] Timestamp after overrun 
recovery ahead of error timestamp! Unable to calculate number of 
dropped samples.(Delta: -3170 ticks)
OU[00:00:12.132437] Timestamp after overrun 
recovery ahead of error timestamp! Unable to calculate number of 
dropped samples.(Delta: -3170 ticks)
UUOU[00:00:12.142422] Timestamp after overrun 
recovery ahead of error timestamp! Unable to calculate number of 
dropped samples.(Delta: -3170 ticks)
UUO[00:00:12.155257] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
UUUO[00:00:12.168528] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
UUU[O00:00:12.178400] Timestamp after overrun recovery ahead 
of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
U[00:00:12.193251] Timestamp after overrun recovery ahead of 
error timestamp! Unable to calculate number of dropped samples.(Delta: 
-3170 ticks)
OUO[00:00:12.204356] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
O[00:00:12.224770] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
UO[00:00:12.235145] Timestamp after overrun recovery 
ahead of error timestamp! Unable to calculate number of dropped 
samples.(Delta: -3170 ticks)
U[O00:00:12.247517] Timestamp after overrun recovery ahead 
of error timestamp! Unable to

Re: [USRP-users] Raspberry Pi 4 sampling Rate

2020-11-03 Thread Luke Stutters via USRP-users 
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
> >
> 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.44] 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.00 MHz...
> > [INFO] [B200] Actually got clock rate 16.00 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.00 MHz...
> > [INFO] [B200] Actually got clock rate 40.00 MHz.
> > [WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
> > [WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
> > [00:00:11.891995] Tx timeouts: 1
> > UUUO[00:00:12.078147] Timestamp after overrun recovery
> > ahead of error timestamp! Unable to calculate number of dropped
> > samples.(Delta: -3170 ticks)
> > O[00:00:12.092404] Timestamp after overrun
> > recovery ahead of error timestamp! Unable to calculate number of
> > dropped samples.(Delta: -3170 ticks)
> > UO[00:00:12.108355] Timestamp after overrun recovery ahead
> > of error timestamp! Unable to calculate number of dropped
> > samples.(Delta: -3170 ticks)
> > U[OU00:00:12.123737] Timestamp after overrun
> > recovery ahead of error timestamp! Unable to calculate number of
> > dropped samples.(Delta: -3170 ticks)
> > OU[00:00:12.132437] Timestamp after overrun
> > recovery ahead of error timestamp! Unable to calculate number of
> > dropped samples.(Delta: -3170 ticks)
> > UUOU[00:00:12.142422] Timestamp after overrun
> > recovery ahead of error timestamp! Unable to calculate number of
> > dropped samples.(Delta: -3170 ticks)
> > UUO[00:00:12.155257] Timestamp after overrun recovery
> > ahead of error timestamp! Unable to calculate number of dropped
> > samples.(Delta: -3170 ticks)
> > UUUO[00:00:12.168528] Timestamp after overrun recovery
> > ahead of error timestamp! Unable to calculate number of dropped
> > samples.(Delta: -3170 ticks)
> > UUU[O00:00:12.178400] Timestamp after overrun recovery ahead
> > of error timestamp! Unable to calculate number of dropped
> > samples.(Delta: -3170 ticks)
> > U[00:00:12.193251] Timestamp after overrun recovery ahead of
> > error timestamp! Unable to calculate number of dropped samples.(Delta:
> > -3170 ticks)
> > OUO[00:00

Re: [USRP-users] N320 inverted spectrum when tuned below 450 MHz

2020-11-03 Thread Jason Roehm via USRP-users 


On 10/14/20 2:41 PM, Marcus D. Leech via USRP-users wrote:

On 10/14/2020 01:28 PM, Jason Roehm via USRP-users wrote:
I have an N320 that I'm trying out for the first time. I'm using UHD 
4.0.0, and I loaded the corresponding root filesystem data for that 
release to the N320. I find that when the receiver is tuned to 
frequencies below 450 MHz, the spectrum is inverted. When you tune to 
450 MHz or above, the spectrum is upright as expected. See the 
attached screenshots for example spectral plots.


There are several ATSC signals visible in the spectrum. I simply used 
an indoor antenna, so there is a lot of multipath on the signals 
causing their spectra to be very non-flat, but the telltale sign of 
spectral inversion here is where the pilot tone is appearing on each 
one. In the first plot, tuned to 440 MHz, they appear on the right of 
each signal; this is not where they should be. When you tune to 450 
MHz, the location of the signals flip to the right half of the plot, 
and the pilot tone is on the left, where they belong.


Is this a known issue?

Thank you.

Jason
I'm discussing this with R&D right now.  It's *conceivable*, because 
there's an extra mixer stage in the below-450-mhz pathway, and that
  mixer stage uses "high side" LO injection, which would produce an 
inverted spectrum, but the FPGA would "know" this and invert it back...



Marcus,

Did you ever get any resolution on this issue?

Jason


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

Re: [USRP-users] N320 inverted spectrum when tuned below 450 MHz

2020-11-03 Thread Marcus D. Leech via USRP-users 

On 11/03/2020 02:54 PM, Jason Roehm via USRP-users wrote:


On 10/14/20 2:41 PM, Marcus D. Leech via USRP-users wrote:

On 10/14/2020 01:28 PM, Jason Roehm via USRP-users wrote:
I have an N320 that I'm trying out for the first time. I'm using UHD 
4.0.0, and I loaded the corresponding root filesystem data for that 
release to the N320. I find that when the receiver is tuned to 
frequencies below 450 MHz, the spectrum is inverted. When you tune 
to 450 MHz or above, the spectrum is upright as expected. See the 
attached screenshots for example spectral plots.


There are several ATSC signals visible in the spectrum. I simply 
used an indoor antenna, so there is a lot of multipath on the 
signals causing their spectra to be very non-flat, but the telltale 
sign of spectral inversion here is where the pilot tone is appearing 
on each one. In the first plot, tuned to 440 MHz, they appear on the 
right of each signal; this is not where they should be. When you 
tune to 450 MHz, the location of the signals flip to the right half 
of the plot, and the pilot tone is on the left, where they belong.


Is this a known issue?

Thank you.

Jason
I'm discussing this with R&D right now.  It's *conceivable*, because 
there's an extra mixer stage in the below-450-mhz pathway, and that
  mixer stage uses "high side" LO injection, which would produce an 
inverted spectrum, but the FPGA would "know" this and invert it back...



Marcus,

Did you ever get any resolution on this issue?

Jason


I've raised the issue with R&D, but not heard back.  I'm hampered by not 
having an N320 in my own lab to test this.


Presumably, the issue you see is version independent?




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

Re: [USRP-users] Raspberry Pi 4 sampling Rate

2020-11-03 Thread Marcus D. Leech via USRP-users 

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



>

.

>
>
>
> ./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.44] 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.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 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.00 MHz...
> [INFO] [B200] Actually got clock rate 40.00 MHz.
> [WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
> [WARNING] [MULTI_USRP] The total sum of rates (40.00 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.00 Msps on 1 channels
> [00:00:11.891995] Tx timeouts: 1
> UUUO[00:00:12.078147] Timestamp after overrun recovery
> ahead of error timestamp! Unable to calculate number of dropped
> samples.(Delta: -3170 ticks)
> O[00:00:12.092404] Timestamp after overrun
> recovery ahead of error timestamp! Unable to calculate number of
> dropped samples.(Delta: -3170 ticks)
>

Re: [USRP-users] RFNoC Fosphor error

2020-11-03 Thread Jonathon Pendlum via USRP-users 
Hi Ben,

Try setting your NIC's MTU to 9000.

Jonathon

On Mon, Nov 2, 2020 at 6:55 AM Robert Wilson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> OS: Linux Ubuntu 20.04.1 LTS
> GRC: 3.8
> UHD: 4.0
> USRP:X310 (HG)
>
> I have been looking at RFNoC only for a few weeks. I have followed the
> RFNoC Workshop 4 tutorial and successfully built my own custom gain block
> as well as implemented and FFT from existing blocks using the "Getting
> Started with RFNoC" document online.
>
> I am now attempting to get Fosphor up and running on my X310 to further
> understand bitstream generation from YAML files. At one point I believe
> there was an example bitstream that had the correct Fosphor configuration I
> don't see it in the build of UHD I have.
>
> I've attached my .yml file and a copy of my GRC flow graph.
> Below is the error message I'm receiving.
>
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_4.0.0.0-1-gcf570707
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [GPS] No GPSDO found
> [INFO] [X300] Radio 1x clock: 200 MHz
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
> 0xfd7d809a, 0x
> [WARNING] [0/Radio#0] Setting RX IQ Balance is not possible on this device.
> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph...
> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
> gr::log :DEBUG: rfnoc_rx_streamer1 - Committing graph...
> gr::log :DEBUG: rfnoc_rx_streamer1 - Sending start stream command...
> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command...
>
> >>> Done (return code -11)
>
> More resources of this type of development would be welcome as well.
>
> Many Thanks,
> Ben Wilson
>
>
> ___
> 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