Re: [USRP-users] RFNoC Fosphor error

2020-11-04 Thread Robert Wilson via USRP-users
My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is 6144
bytes. I’ve changed MTU to the max with no change in gnuRadio response. Is
the 6144 bytes not enough?

On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum 
wrote:

> 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


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

2020-11-04 Thread David Evans via USRP-users
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 
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 rate

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

2020-11-04 Thread Marcus D Leech via USRP-users
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 
>  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 
>>>  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 cau

[USRP-users] REMINDER: GR Amateur Radio video meeting

2020-11-04 Thread Barry Duggan via USRP-users
For those interested in using GNU Radio in amateur radio applications, 
we have set up an On-line video meeting


- I will present a program on Frequency Shift Keying, with a live 
On-the-Air demonstration of radioteletype

- It will be on **Saturday 7 November 16:00 UTC**
- see the details at https://wiki.gnuradio.org/index.php/User:Duggabe

- We have a Ham Radio chat room on Matrix
- server: https://chat.gnuradio.org
- or via the Homeserver in a matrix app: gnuradio.matrix.ungleich.cloud
- room: #HamRadio:gnuradio.org

73,
---
Barry Duggan KV4FV
https://github.com/duggabe

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


Re: [USRP-users] RFNoC Fosphor error

2020-11-04 Thread Jonathon Pendlum via USRP-users
Hi Robert,

Try using the maximum MTU size supported. Also, try reducing the FFT size
and SPP to 512.

Jonathon

On Wed, Nov 4, 2020 at 8:45 AM Robert Wilson 
wrote:

> My Ethernet Controller is a Qualcomm Atheros AR8151 it’s max MTU is 6144
> bytes. I’ve changed MTU to the max with no change in gnuRadio response. Is
> the 6144 bytes not enough?
>
> On Tue, Nov 3, 2020 at 9:32 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> 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


[USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-04 Thread Ben Magistro via USRP-users
Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any
issues with libfftw?

Using the image on an E310, adding a single OOT module (gr-ais) and trying
to run an app distributed with it, the app segfaults.  To further
troubleshoot, I added gdb and it comes back with the following.  I have a
separate development host that has gnuradio 3.8 setup using pybombs and do
not experience this issue there.

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3

To compile, I've needed to override PYTHON_EXECUTABLE as it points to a
non-existent path in /home/oe-builder in
/usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to
define LD_EXPORT_PATH pointing to /usr/local/lib/.

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


Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

2020-11-04 Thread Marcus D Leech via USRP-users
Do other apps that use FFTs exhibit segfaults. 

Sent from my iPhone

> On Nov 4, 2020, at 11:25 PM, Ben Magistro via USRP-users 
>  wrote:
> 
> 
> Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have you had any issues 
> with libfftw?
> 
> Using the image on an E310, adding a single OOT module (gr-ais) and trying to 
> run an app distributed with it, the app segfaults.  To further troubleshoot, 
> I added gdb and it comes back with the following.  I have a separate 
> development host that has gnuradio 3.8 setup using pybombs and do not 
> experience this issue there.
> 
> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
> 
> To compile, I've needed to override PYTHON_EXECUTABLE as it points to a 
> non-existent path in /home/oe-builder in 
> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake.  To run I also needed to define 
> LD_EXPORT_PATH pointing to /usr/local/lib/.
> 
> Thanks in advance.
> ___
> 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