[USRP-users] N210 + UBX Power Calibration

[Ernest Fardin via USRP-users]

Hi,

I'm trying to calibrate the receive power on a USRP N210 with a UBX
daughterboard. Using UHD 4.0, I can get uhd_power_cal.py to run by adding
an N210Calibrator class to usrp_calibrator.py. N210Calibrator overloads the
USRPCalibratorBase class.

class N210Calibrator(USRPCalibratorBase):
"""
N210/UBX Calibration
"""
mboard_ids = ('N210r4',)
default_rate = 2.5e6
min_freq = 50e6
max_freq = 50e6
tune_settling_time = .5

When the calibration completes, the store() method in usrp_calibrator
attempts to write the calibration table to the UBX with

database.write_cal_data(
cal_key,
cal_serial,
cal_data.serialize())

The chan_info string returned by the N210 is:

{'mboard_id': 'N210r4', 'mboard_name': '', 'mboard_serial': '318EFF3',
'rx_antenna': 'TX/RX', 'rx_id': 'UBX-40 v2 (0x007c)', 'rx_serial':
'318D55F', 'rx_subdev_name': 'UBX RX', 'rx_subdev_spec': 'A:0'}

What values to use for cal_key and cal_serial?

Thanks in advance!

Ernest
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Rx Packet Drop in N321 USRP

[zhou via USRP-users]

 Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, there is 
no Tx packet loss but Rx.

On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
 wrote:  
 
  On 2021-09-06 6:59 p.m., zhou wrote:
  
 
 Hi Marcus, 
  Could you please help on this? I find some confusing information on MTU 
configuration in different ettus web pages: 
https://files.ettus.com/manual/page_transport.html :  MTU=8000 for 10GigE
  https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks : MTU=9000 
for 10GigE
  
  Which one is correct? :  
  Thanks.  They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.
 
 The caveat is that BOTH SIDES of the connection have to "agree" on the MTU, 
and some host controllers
   will happily accept a large MTU, but be unable to actually support it, 
although that situation is NOT one
   that I have seen in 10GiGe controllers--they inherently want to support 
"jumbo frames".
 
 
 
  
  
  On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
 wrote:  
  
 Hi,   
  I have a problem with the N321 USRP. I find packet dropped in USRP but not in 
host. In host, I am running Ubuntu 18.04. 
  
 Below is the ifconfig result in N321:
 
root@ni-n3xx-320CAAB:~# ifconfig
 
eth0  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BA
 
  inet addr:192.168.10.165  Bcast:192.168.255.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
  RX packets:618374 errors:0 dropped:11485 overruns:0 frame:0
 
  TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:39776733 (37.9 MiB)  TX bytes:14546432 (13.8 MiB)
 
  Interrupt:27 Base address:0xb000
 
 
 
int0  Link encap:Ethernet  HWaddr AE:CD:BA:E1:CF:96
 
  inet addr:169.254.0.1  Bcast:169.254.0.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:456 errors:0 dropped:0 overruns:0 frame:0
 
  TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:37392 (36.5 KiB)  TX bytes:2770 (2.7 KiB)
 
 
 
lo    Link encap:Local Loopback
 
  inet addr:127.0.0.1  Mask:255.0.0.0
 
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
 
  RX packets:89 errors:0 dropped:0 overruns:0 frame:0
 
  TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:7480 (7.3 KiB)  TX bytes:7480 (7.3 KiB)
 
 
 
sfp0  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BB
 
  inet addr:192.168.12.2  Bcast:192.168.12.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:6239 errors:0 dropped:804 overruns:0 frame:0
 
  TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:18466697 (17.6 MiB)  TX bytes:18417536 (17.5 MiB)
 
 
 
sfp1  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BC
 
  inet addr:192.168.13.2  Bcast:192.168.13.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:24868 errors:0 dropped:796 overruns:0 frame:0
 
  TX packets:24613 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:20486915 (19.5 MiB)  TX bytes:19611643 (18.7 MiB)
 
 
 
Below is ifconfig result in host:
 
user@USRP-SERVER:~$ ifconfig
 
eno1:flags=4163  mtu 1500
 
    inet 192.168.10.143  netmask 255.255.255.0  broadcast 192.168.255.255
 
    inet6 fe80::b27b:25ff:fe1d:9e4e  prefixlen 64  scopeid 0x20
 
   ether b0:7b:25:1d:9e:4e  txqueuelen 1000  (Ethernet)
 
    RX packets 5604  bytes 416435 (416.4 KB)
 
    RX errors 0  dropped 0  overruns 0  frame 0
 
    TX packets 404  bytes 68556 (68.5 KB)
 
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
    device interrupt 16  memory 0xd210-d212
 
 
 
enp1s0f0:flags=4163  mtu 9000
 
    inet 192.168.12.1  netmask 255.255.255.0  broadcast 192.168.12.255
 
    inet6 fe80::faf2:1eff:fe42:dddc  prefixlen 64  scopeid 0x20
 
    ether f8:f2:1e:42:dd:dc  txqueuelen 1000  (Ethernet)
 
    RX packets 294  bytes 35184 (35.1 KB)
 
    RX errors 0  dropped 0  overruns 0  frame 0
 
    TX packets 395  bytes 37148 (37.1 KB)
 
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
 
 
enp1s0f1:flags=4163  mtu 9000
 
    inet 192.168.13.1  netmask 255.255.255.0  broadcast 192.168.13.255
 
    inet6 fe80::faf2:1eff:fe42:  prefixlen 64  scopeid 0x20
 
    ether f8:f2:1e:42:dd:dd  txqueuelen 1000  (Ethernet)
 
    RX packets 9  bytes 2228 (2.2 KB)
 
    RX errors 0  dropped 0  overruns 0  frame 0
 
    TX packets 72  

[USRP-users] Set Network Buffer in N321 USRP Permanently

[zhou via USRP-users]

 Hi Marcus,
 
  Thanks for your comments on my other USRP questions. I have another issue 
with N321 USRP.Following the tuning tips in 
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks , I have set 
wmem_max, wmem_default, rmem_max, rmem_default to 33554432 in host (Ubuntu):
   sudo sysctl -w net.core.wmem_max=33554432
   sudo sysctl -w net.core.rmem_max=33554432
   sudo sysctl -w net.core.wmem_default=33554432
   sudo sysctl -w net.core.rmem_default=33554432I have made the configuration 
permanent by adding these lines in /etc/sysctl.conf, such that they won't get 
lost after host reboot. 
I want to do the same in N321 but couldn't because there is no sysctl.conf in 
it. I can still configure these parameters from terminal, but it won't survive 
a reboot.The Linux in N321 is tiny. How can I make the configuration 
permanently in it?
Any comment from the community will be appreciated.
Thanks,Hongwei

   ___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Set Network Buffer in N321 USRP Permanently

[Marcus D. Leech]

On 2021-09-07 8:12 a.m., zhou wrote:

Hi Marcus,

Thanks for your comments on my other USRP questions. I have another 
issue with N321 USRP.
Following the tuning tips in 
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks 
 , 
I have set wmem_max, wmem_default, rmem_max, rmem_default to 33554432 
in host (Ubuntu):

sudo sysctl -w net.core.wmem_max=33554432
sudo sysctl -w net.core.rmem_max=33554432
sudo sysctl -w net.core.wmem_default=33554432
sudo sysctl -w net.core.rmem_default=33554432
I have made the configuration permanent by adding these lines in 
*/etc/sysctl.conf, *such that they won't get lost after host reboot.


I want to do the same in N321 but couldn't because there is no 
sysctl.conf in it. I can still configure these parameters from 
terminal, but it won't survive a reboot.
The Linux in N321 is tiny. How can I make the configuration 
permanently in it?


Any comment from the community will be appreciated.

Thanks,
Hongwei


I don't have an N321 myself, but you will probably find that there's an 
/etc/sysctl.conf.d directory, and you can create a sysctl.conf file there.


But unless you're using the N321 like it's an ordinary host, talking to 
an *external* USRP, you shouldn't need to adjust these parameters.


When you're streaming samples into/out-of the N321, they don't go 
through the CPU portion of the Zynq at all, so these parameters aren't 
relevant.



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Rx Packet Drop in N321 USRP

[Marcus D. Leech]

On 2021-09-07 7:54 a.m., zhou wrote:
Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, 
there is no Tx packet loss but Rx.
Well, the *usual* reason is cabling issues.  But a secondary reason 
would be overload--the drivers run out of buffers to place packets
  for the user/application layer.  That shouldn't be the case here, 
unless you're doing a LOT of ordinary Linux CPU  network traffic over

  those interfaces.





On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
 wrote:



On 2021-09-06 6:59 p.m., zhou wrote:
Hi Marcus,

Could you please help on this?
I find some confusing information on MTU configuration in different 
ettus web pages:
https://files.ettus.com/manual/page_transport.html 
 : MTU=8000 for 10GigE
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks 
 : 
MTU=9000 for 10GigE


Which one is correct? :

Thanks.
They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.


The caveat is that BOTH SIDES of the connection have to "agree" on the 
MTU, and some host controllers
  will happily accept a large MTU, but be unable to actually support 
it, although that situation is NOT one
  that I have seen in 10GiGe controllers--they inherently want to 
support "jumbo frames".







On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
  wrote:



Hi,

I have a problem with the N321 USRP. I find packet dropped in USRP 
but not in host. In host, I am running Ubuntu 18.04.


*_Below is the ifconfig result in N321:_*

root@ni-n3xx-320CAAB:~# ifconfig

*eth0* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BA

inet addr:192.168.10.165 Bcast:192.168.255.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*1500*  Metric:1

RX packets:618374 errors:0 *dropped:11485*overruns:0 frame:0

TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:39776733 (37.9 MiB)  TX bytes:14546432 (13.8 MiB)

Interrupt:27 Base address:0xb000

int0 Link encap:Ethernet  HWaddr AE:CD:BA:E1:CF:96

inet addr:169.254.0.1 Bcast:169.254.0.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:9000  Metric:1

RX packets:456 errors:0 dropped:0 overruns:0 frame:0

TX packets:15 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:37392 (36.5 KiB)  TX bytes:2770 (2.7 KiB)

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING  MTU:65536 Metric:1

RX packets:89 errors:0 dropped:0 overruns:0 frame:0

TX packets:89 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:7480 (7.3 KiB)  TX bytes:7480 (7.3 KiB)

*sfp0* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BB

inet addr:192.168.12.2 Bcast:192.168.12.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*9000*  Metric:1

RX packets:6239 errors:0 *dropped:804 *overruns:0 frame:0

TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:18466697 (17.6 MiB)  TX bytes:18417536 (17.5 MiB)

*sfp1* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BC

inet addr:192.168.13.2 Bcast:192.168.13.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*9000*  Metric:1

RX packets:24868 errors:0 *dropped:796*overruns:0 frame:0

TX packets:24613 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:20486915 (19.5 MiB)  TX bytes:19611643 (18.7 MiB)

_*Below is ifconfig result in host:*_

user@USRP-SERVER:~$ ifconfig

*eno1*: flags=4163  mtu *1500*

inet 192.168.10.143  netmask 255.255.255.0  broadcast 192.168.255.255

inet6 fe80::b27b:25ff:fe1d:9e4e prefixlen 64  scopeid 0x20

   ether b0:7b:25:1d:9e:4e  txqueuelen 1000  (Ethernet)

RX packets 5604  bytes 416435 (416.4 KB)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 404  bytes 68556 (68.5 KB)

TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

device interrupt 16  memory 0xd210-d212

*enp1s0f0*: flags=4163  mtu *9000*

inet 192.168.12.1  netmask 255.255.255.0  broadcast 192.168.12.255

inet6 fe80::faf2:1eff:fe42:dddc prefixlen 64  scopeid 0x20

ether f8:f2:1e:42:dd:dc txqueuelen 1000  (Ethernet)

RX packets 294  bytes 35184 (35.1 KB)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 395  bytes 37148 (37.1 KB)

TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

*enp1s0f1*: flags=4163  mtu *9000*

inet 192.168.13.1  netmask 255.255.255.0  broadcast 192.168.13.255

inet6 fe80::faf2:1eff:fe42: prefixlen 64  scopeid 0x20

ether f8:f2:1e:42:dd:dd txqueuelen 1000  (Ethernet)

RX packets 9  bytes 2228 (2.2 KB)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 72  bytes 7983 (7.9 KB)

TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

lo: flags=73  mtu 65536

inet 127.0.0.1  netmask 255

[USRP-users] Re: Rx Packet Drop in N321 USRP

[Marcus D. Leech]

On 2021-09-07 7:54 a.m., zhou wrote:
Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, 
there is no Tx packet loss but Rx.

Hmmm, so, just found this:

   Beginning with kernel 2.6.37, it has been changed the meaning of
   dropped packet count. Before, dropped packets was most likely due to
   an error. Now, the rx_dropped counter shows statistics for dropped
   frames because of:

 * Softnet backlog full
 * Bad / Unintended VLAN tags
 * Unknown / Unregistered protocols
 * IPv6 frames when the server is not configured for IPv6

   [...]

   If the rx_dropped counter stops incrementing while tcpdump is
   running; then it is more than likely showing drops because of the
   reasons listed earlier.



   IN other words, mostly harmless. At some point, the semantics of
   "dropped packets" changed, and I didn't even notice.





On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
 wrote:



On 2021-09-06 6:59 p.m., zhou wrote:
Hi Marcus,

Could you please help on this?
I find some confusing information on MTU configuration in different 
ettus web pages:
https://files.ettus.com/manual/page_transport.html 
 : MTU=8000 for 10GigE
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks 
 : 
MTU=9000 for 10GigE


Which one is correct? :

Thanks.
They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.


The caveat is that BOTH SIDES of the connection have to "agree" on the 
MTU, and some host controllers
  will happily accept a large MTU, but be unable to actually support 
it, although that situation is NOT one
  that I have seen in 10GiGe controllers--they inherently want to 
support "jumbo frames".







On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
  wrote:



Hi,

I have a problem with the N321 USRP. I find packet dropped in USRP 
but not in host. In host, I am running Ubuntu 18.04.


*_Below is the ifconfig result in N321:_*

root@ni-n3xx-320CAAB:~# ifconfig

*eth0* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BA

inet addr:192.168.10.165 Bcast:192.168.255.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*1500*  Metric:1

RX packets:618374 errors:0 *dropped:11485*overruns:0 frame:0

TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:39776733 (37.9 MiB)  TX bytes:14546432 (13.8 MiB)

Interrupt:27 Base address:0xb000

int0 Link encap:Ethernet  HWaddr AE:CD:BA:E1:CF:96

inet addr:169.254.0.1 Bcast:169.254.0.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:9000  Metric:1

RX packets:456 errors:0 dropped:0 overruns:0 frame:0

TX packets:15 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:37392 (36.5 KiB)  TX bytes:2770 (2.7 KiB)

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING  MTU:65536 Metric:1

RX packets:89 errors:0 dropped:0 overruns:0 frame:0

TX packets:89 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:7480 (7.3 KiB)  TX bytes:7480 (7.3 KiB)

*sfp0* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BB

inet addr:192.168.12.2 Bcast:192.168.12.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*9000*  Metric:1

RX packets:6239 errors:0 *dropped:804 *overruns:0 frame:0

TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:18466697 (17.6 MiB)  TX bytes:18417536 (17.5 MiB)

*sfp1* Link encap:Ethernet  HWaddr 00:80:2F:32:36:BC

inet addr:192.168.13.2 Bcast:192.168.13.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:*9000*  Metric:1

RX packets:24868 errors:0 *dropped:796*overruns:0 frame:0

TX packets:24613 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:20486915 (19.5 MiB)  TX bytes:19611643 (18.7 MiB)

_*Below is ifconfig result in host:*_

user@USRP-SERVER:~$ ifconfig

*eno1*: flags=4163  mtu *1500*

inet 192.168.10.143  netmask 255.255.255.0  broadcast 192.168.255.255

inet6 fe80::b27b:25ff:fe1d:9e4e prefixlen 64  scopeid 0x20

   ether b0:7b:25:1d:9e:4e  txqueuelen 1000  (Ethernet)

RX packets 5604  bytes 416435 (416.4 KB)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 404  bytes 68556 (68.5 KB)

TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

device interrupt 16  memory 0xd210-d212

*enp1s0f0*: flags=4163  mtu *9000*

inet 192.168.12.1  netmask 255.255.255.0  broadcast 192.168.12.255

inet6 fe80::faf2:1eff:fe42:dddc prefixlen 64  scopeid 0x20

ether f8:f2:1e:42:dd:dc txqueuelen 1000  (Ethernet)

RX packets 294  bytes 35184 (35.1 KB)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 395  bytes 37148 (37.1 KB)

TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

*enp1s0f1*: flags=4

[USRP-users] Re: Rx Packet Drop in N321 USRP

[zhou via USRP-users]

 Thanks a lot, Marcus.The kernel version I am using in host is 5.4.0-81, but 
there is no packet drop. It is still strange that packet drop happened in USRP. 
In my test, sometimes there are U errors. I am wondering if there is 
something wrong with network buffer.

On Tuesday, 7 September 2021, 14:39:54 BST, Marcus D. Leech 
 wrote:  
 
  On 2021-09-07 7:54 a.m., zhou wrote:
  
 
 Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, there is 
no Tx packet loss but Rx.  Hmmm, so, just found this:
 
 
 
Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet 
count. Before, dropped packets was most likely due to an error. Now, the 
rx_dropped counter shows statistics for dropped frames because of:

   - Softnet backlog full
   - Bad / Unintended VLAN tags
   - Unknown / Unregistered protocols
   - IPv6 frames when the server is not configured for IPv6
 
[...]
 
If the rx_dropped counter stops incrementing while tcpdump is running; then it 
is more than likely showing drops because of the reasons listed earlier.
 

 
 

 
 
IN other words, mostly harmless. At some point, the semantics of "dropped 
packets" changed, and I didn't even notice.

  

 
 

 
 
 
  
  On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
 wrote:  
  
 On 2021-09-06 6:59 p.m., zhou wrote:
  
 
Hi Marcus, 
  Could you please help on this? I find some confusing information on MTU 
configuration in different ettus web pages: 
https://files.ettus.com/manual/page_transport.html :  MTU=8000 for 10GigE
  https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks : MTU=9000 
for 10GigE
  
  Which one is correct? :  
  Thanks.  They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.
 
 The caveat is that BOTH SIDES of the connection have to "agree" on the MTU, 
and some host controllers
   will happily accept a large MTU, but be unable to actually support it, 
although that situation is NOT one
   that I have seen in 10GiGe controllers--they inherently want to support 
"jumbo frames". 
 
 
 
  
  
  On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
 wrote:  
  
 Hi,   
  I have a problem with the N321 USRP. I find packet dropped in USRP but not in 
host. In host, I am running Ubuntu 18.04. 
  
 Below is the ifconfig result in N321:
 
root@ni-n3xx-320CAAB:~# ifconfig
 
eth0  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BA
 
  inet addr:192.168.10.165  Bcast:192.168.255.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
  RX packets:618374 errors:0 dropped:11485 overruns:0 frame:0
 
  TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:39776733 (37.9 MiB)  TX bytes:14546432 (13.8 MiB)
 
  Interrupt:27 Base address:0xb000
 
 
 
int0  Link encap:Ethernet  HWaddr AE:CD:BA:E1:CF:96
 
  inet addr:169.254.0.1  Bcast:169.254.0.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:456 errors:0 dropped:0 overruns:0 frame:0
 
  TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:37392 (36.5 KiB)  TX bytes:2770 (2.7 KiB)
 
 
 
lo    Link encap:Local Loopback
 
  inet addr:127.0.0.1  Mask:255.0.0.0
 
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
 
  RX packets:89 errors:0 dropped:0 overruns:0 frame:0
 
  TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:7480 (7.3 KiB)  TX bytes:7480 (7.3 KiB)
 
 
 
sfp0  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BB
 
  inet addr:192.168.12.2  Bcast:192.168.12.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:6239 errors:0 dropped:804 overruns:0 frame:0
 
  TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:18466697 (17.6 MiB)  TX bytes:18417536 (17.5 MiB)
 
 
 
sfp1  Link encap:Ethernet  HWaddr 00:80:2F:32:36:BC
 
  inet addr:192.168.13.2  Bcast:192.168.13.255  Mask:255.255.255.0
 
  UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
 
  RX packets:24868 errors:0 dropped:796 overruns:0 frame:0
 
  TX packets:24613 errors:0 dropped:0 overruns:0 carrier:0
 
  collisions:0 txqueuelen:1000
 
  RX bytes:20486915 (19.5 MiB)  TX bytes:19611643 (18.7 MiB)
 
 
 
Below is ifconfig result in host:
 
user@USRP-SERVER:~$ ifconfig
 
eno1:flags=4163  mtu 1500
 
    inet 192.168.10.143  netmask 255.255.255.0  broadcast 192.168.255.255
 
    inet6 fe80::b27b:25ff:fe1d:9e4e  prefixlen 64  scopeid 0x20
 
   ether b0:7b:25:1d:9e:4e  txqueuelen 

[USRP-users] Re: Set Network Buffer in N321 USRP Permanently

[zhou via USRP-users]

 
Thanks for your suggestion, Marcus. 

On Tuesday, 7 September 2021, 14:21:19 BST, Marcus D. Leech 
 wrote:  
 
  On 2021-09-07 8:12 a.m., zhou wrote:
  
 
 Hi Marcus,

  Thanks for your comments on my other USRP questions. I have another issue 
with N321 USRP. Following the tuning tips in 
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks , I have set 
wmem_max, wmem_default, rmem_max, rmem_default to 33554432 in host (Ubuntu):
   sudo sysctl -w net.core.wmem_max=33554432
   sudo sysctl -w net.core.rmem_max=33554432
   sudo sysctl -w net.core.wmem_default=33554432
   sudo sysctl -w net.core.rmem_default=33554432   I have made the 
configuration permanent by adding these lines in /etc/sysctl.conf, such that 
they won't get lost after host reboot.  
  I want to do the same in N321 but couldn't because there is no sysctl.conf in 
it. I can still configure these parameters from terminal, but it won't survive 
a reboot. The Linux in N321 is tiny. How can I make the configuration 
permanently in it? 
  Any comment from the community will be appreciated. 
  Thanks, Hongwei  
 
  I don't have an N321 myself, but you will probably find that there's an 
/etc/sysctl.conf.d directory, and you can create a sysctl.conf file there.
 
 But unless you're using the N321 like it's an ordinary host, talking to an 
*external* USRP, you shouldn't need to adjust these parameters.
 
 When you're streaming samples into/out-of the N321, they don't go through the 
CPU portion of the Zynq at all, so these parameters aren't relevant.


 
   ___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Struggling to build kernel and userspace for x400

[tywonemi]

Dear USRP maintainers,

As my master's thesis I've set out to port the GNU Radio RFNoC to the  
RFSoC 2x2 development board for purposes of academic research of  
optical communications, and I have some issues. If it's more practical  
for you, feel free to forward me to written resources I may have missed.
First some context: The motivation for this is rapid development and  
measurement on a digitizer-like platform without RF frontends. Since  
USRP x410 has the same SoC on board, the easiest way for me to do this  
will be to use as much of the existing open source work done by  
forking the USRP design. However, I'm getting stuck on building yocto  
due to a symbol duplicate in gdbm build within the oe-core package.
There seem to be several steps involved in this port/fork - stubbing  
the RF frontend controls and removing support in the UHD host drivers,  
adapting the board constraints, possibly reducing some buffer sizes  
due to lower available PL RAM, but right now I am trying to verify if  
I'll be able to get access to all the sources and tools required to  
make the processing subsystem pipe or filter samples between the hard  
logic gigabit ethernet controller and the programmable logic with the  
RFNoC crossbar, and to perform the RFNoC control operations. This is  
because the RFSoC 2x2 lacks an SFP-like interface for higher bandwidth  
data packet streaming. It's only mentioned in one line in the x410  
manual:
Like other USRPs, it is addressable through a 1 GbE RJ45 connector,  
which allows full access to the embedded Linux system, as well as data  
streaming at low rates.
I'd like to build Linux for the USRP to see what sources it pulls and  
to verify and maybe modify the datapath from the gigabit controller  
through the driver to the PL. However, I have trouble getting it to  
build.

I'm running Arch Linux with GCC 11.1, kas 2.5 (directly, no docker image).
On meta-ettus repository, tag v4.1.0.2-rc3, running  
`./contrib/kas_build_imgs_package.sh x4xx` fails the oe-core step:


| /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld:  
./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of  
`parseopt_program_args'; gdbmtool.o:(.data.rel.local+0x260): first  
defined here
| /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld:  
./libgdbmapp.a(parseopt.o):(.bss+0x10): multiple definition of  
`parseopt_program_doc'; gdbmtool.o:(.data.rel.local+0x268): first  
defined here


Is this replicable for you? It happens to me with the x4xx-prerelease  
tag, too. Is there some frozen development setup environment that  
should be used? Is that included in the kas docker? If so, how would I  
invoke kas from docker to use the yaml configs?


Also, I've gone through the "MPM" and "firmware" sections of the UHD  
tree looking for software that would run on the SoC and configure the  
gigabit ethernet and work with it. For example, in x300, this is done  
in firmware/usrp3/x300/x300_init.c but I have not found any  
configuration (any eventual calls to xge_* etc). Am I wrong to assume  
that this code has not been published yet? Is it going to be made open  
source in the future? It really seems like everything else is present,  
but the actual userspace software running on the x400.


Best regards,

Emil J Tywoniak,
Faculty of Electrical Engineering
Czech Technical University in Prague
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Rx Packet Drop in N321 USRP

[Marcus D. Leech]

On 2021-09-07 3:59 p.m., zhou wrote:

Thanks a lot, Marcus.
The kernel version I am using in host is 5.4.0-81, but there is no 
packet drop. It is still strange that packet drop happened in USRP.
In my test, sometimes there are U errors. I am wondering if there 
is something wrong with network buffer.
L means "late packet', which means that the thing that's producing 
packets isn't "keeping up" with the required

  cadence of samples being consumed by the radio.

Do you get this when talking to the N321 from your host, or when using 
the N321 in embedded mode (using the

  Linux OS running on the N321).

How are your N321 and host computer connected?  Are they connected via a 
switch or direct connected?


It's not clear to me how the "RX drops" is triggered for the 
"unsupported protocols" case--whether that's just unsupported
  *ETHERNET* protocols, or any protocol packet for which there isn't a 
service registered on the system--in this case your
  N321.  If it's the latter, then it may just be the case that your 
host PC is sending perhaps broadcast or other packets for
  which there are no services registered on your N321 system to process 
them, so it drops them, and just logs it.  Unless

  your host PC is doing a LOT of this, it's of no consequence.





On Tuesday, 7 September 2021, 14:39:54 BST, Marcus D. Leech 
 wrote:



On 2021-09-07 7:54 a.m., zhou wrote:
Thanks Marcus. What is the reason for Rx packet drop in N321? I have 
configured the same MTU on both ends of the connection. Interestingly, 
there is no Tx packet loss but Rx.

Hmmm, so, just found this:

Beginning with kernel 2.6.37, it has been changed the meaning of
dropped packet count. Before, dropped packets was most likely due
to an error. Now, the rx_dropped counter shows statistics for
dropped frames because of:

  * Softnet backlog full
  * Bad / Unintended VLAN tags
  * Unknown / Unregistered protocols
  * IPv6 frames when the server is not configured for IPv6

[...]

If the rx_dropped counter stops incrementing while tcpdump is
running; then it is more than likely showing drops because of the
reasons listed earlier.



IN other words, mostly harmless. At some point, the semantics of
"dropped packets" changed, and I didn't even notice.






On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech 
  wrote:



On 2021-09-06 6:59 p.m., zhou wrote:
Hi Marcus,

Could you please help on this?
I find some confusing information on MTU configuration in different 
ettus web pages:
https://files.ettus.com/manual/page_transport.html 
 : MTU=8000 for 
10GigE
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks 
 : 
MTU=9000 for 10GigE


Which one is correct? :

Thanks.
They're both valid, in that a larger MTU tends to improve bulk 
performance at high sample rates.


The caveat is that BOTH SIDES of the connection have to "agree" on 
the MTU, and some host controllers
  will happily accept a large MTU, but be unable to actually support 
it, although that situation is NOT one
  that I have seen in 10GiGe controllers--they inherently want to 
support "jumbo frames".







On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users 
  wrote:



Hi,

I have a problem with the N321 USRP. I find packet dropped in USRP 
but not in host. In host, I am running Ubuntu 18.04.


*_Below is the ifconfig result in N321:_*

root@ni-n3xx-320CAAB:~# ifconfig

*eth0* Link encap:Ethernet HWaddr 00:80:2F:32:36:BA

inet addr:192.168.10.165 Bcast:192.168.255.255  Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST  MTU:*1500* Metric:1

RX packets:618374 errors:0 *dropped:11485*overruns:0 frame:0

TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:39776733 (37.9 MiB)  TX bytes:14546432 (13.8 MiB)

Interrupt:27 Base address:0xb000

int0 Link encap:Ethernet HWaddr AE:CD:BA:E1:CF:96

inet addr:169.254.0.1 Bcast:169.254.0.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1

RX packets:456 errors:0 dropped:0 overruns:0 frame:0

TX packets:15 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:37392 (36.5 KiB)  TX bytes:2770 (2.7 KiB)

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:65536  Metric:1

RX packets:89 errors:0 dropped:0 overruns:0 frame:0

TX packets:89 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:7480 (7.3 KiB)  TX bytes:7480 (7.3 KiB)

*sfp0* Link encap:Ethernet HWaddr 00:80:2F:32:36:BB

inet addr:192.168.12.2 Bcast:192.168.12.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST  MTU:*9000* Metric:1

RX packets:6239 errors:0 *dropped:804 *overruns:0 frame:0

TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0

collisi

[USRP-users] Re: Struggling to build kernel and userspace for x400

[Marcus D. Leech]

On 2021-09-07 4:25 p.m., tywon...@fel.cvut.cz wrote:

Dear USRP maintainers,

As my master's thesis I've set out to port the GNU Radio RFNoC to the 
RFSoC 2x2 development board for purposes of academic research of 
optical communications, and I have some issues. If it's more practical 
for you, feel free to forward me to written resources I may have missed.
First some context: The motivation for this is rapid development and 
measurement on a digitizer-like platform without RF frontends. Since 
USRP x410 has the same SoC on board, the easiest way for me to do this 
will be to use as much of the existing open source work done by 
forking the USRP design. However, I'm getting stuck on building yocto 
due to a symbol duplicate in gdbm build within the oe-core package.
There seem to be several steps involved in this port/fork - stubbing 
the RF frontend controls and removing support in the UHD host drivers, 
adapting the board constraints, possibly reducing some buffer sizes 
due to lower available PL RAM, but right now I am trying to verify if 
I'll be able to get access to all the sources and tools required to 
make the processing subsystem pipe or filter samples between the hard 
logic gigabit ethernet controller and the programmable logic with the 
RFNoC crossbar, and to perform the RFNoC control operations. This is 
because the RFSoC 2x2 lacks an SFP-like interface for higher bandwidth 
data packet streaming. It's only mentioned in one line in the x410 
manual:
Like other USRPs, it is addressable through a 1 GbE RJ45 connector, 
which allows full access to the embedded Linux system, as well as data 
streaming at low rates.
I'd like to build Linux for the USRP to see what sources it pulls and 
to verify and maybe modify the datapath from the gigabit controller 
through the driver to the PL. However, I have trouble getting it to 
build.
I'm running Arch Linux with GCC 11.1, kas 2.5 (directly, no docker 
image).
On meta-ettus repository, tag v4.1.0.2-rc3, running 
`./contrib/kas_build_imgs_package.sh x4xx` fails the oe-core step:


| /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld: 
./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of 
`parseopt_program_args'; gdbmtool.o:(.data.rel.local+0x260): first 
defined here
| /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld: 
./libgdbmapp.a(parseopt.o):(.bss+0x10): multiple definition of 
`parseopt_program_doc'; gdbmtool.o:(.data.rel.local+0x268): first 
defined here


Is this replicable for you? It happens to me with the x4xx-prerelease 
tag, too. Is there some frozen development setup environment that 
should be used? Is that included in the kas docker? If so, how would I 
invoke kas from docker to use the yaml configs?


Also, I've gone through the "MPM" and "firmware" sections of the UHD 
tree looking for software that would run on the SoC and configure the 
gigabit ethernet and work with it. For example, in x300, this is done 
in firmware/usrp3/x300/x300_init.c but I have not found any 
configuration (any eventual calls to xge_* etc). Am I wrong to assume 
that this code has not been published yet? Is it going to be made open 
source in the future? It really seems like everything else is present, 
but the actual userspace software running on the x400.


Best regards,

Emil J Tywoniak,
Faculty of Electrical Engineering
Czech Technical University in Prague

This seems a very ambitious project, and I wish you luck.

The amount of experience "out there" with the X400 series from Ettus at 
this point is very small, so don't be that surprised not to get much in 
the way of help

  from "the community".

In terms of Ettus R&D folks who may be able to help you, they're pretty 
busy working on actual Ettus/NI products, and likely don't have a lot of 
time
 to help folks porting Ettus code to non-Ettus hardware.  Just a 
practicality of time management.


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: setting lenght of fft RFNoC UHD 4

[Marcus D. Leech]

On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters: 
fft_amplitude = uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED 
fft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARD fft_shift = 
uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I do abs and display 
the data. Tell me how to do it better? And do I need to set a 
different type for the array which is passed to the recv function when 
setting Mag ** 2?
YOu're already setting Mag**2, so there's no need to ABS. Typically, 
after that you'll use a 10*log10 function which is then itself scaled by
  the FFT length and a few other factors.  I'd suggest looking at the 
Gnu Radio FFT code to see how it scales the FFT output.  There are
  MANY ways to scale an FFT (and even the MAG**2 output of an FFT)--the 
RFNOC FFT produces a linear-form output, so if you
  want to see it in dB units you have to do that yourself from what I 
understand.  Implementing a 10*log10 in the FPGA would likely
  be prohibitive, and usually you do that after you've done some 
averaging and frame-rate reduction.





ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech >:


On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:

Hello. There is any information on my question. I also noticed
that if you take the data after the FFT, then the sensitivity
drops very much. I see a -30 dBm signal but -60 dBm is no longer
displayed.

How are you scaling and displaying your FFT output?  What options
do you have set on your FFT?  DO you have it using Mag**2, how do
you scale it
  after that?




сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk mailto:adray0...@gmail.com>>:

Here is my script. I am trying to read different amounts of
data from DDC and from FFT. Are there any new statements on
my question?


чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
mailto:jonathon.pend...@ettus.com>>:

Great, thanks. Can you also share your latest python script?

Jonathon

On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk
mailto:adray0...@gmail.com>> wrote:

Yes, I can try it but next week. But I still wanted
to do FFT on FPGA. And one more question. Is it
possible to create two streamers and read 256 samples
one at a time and another 8192 for example? I want to
do FFT on one channel and start a stream with DDC for
demodulation on the other. What is possible?


ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum
mailto:jonathon.pend...@ettus.com>>:

Hi Ivan,

Can you try running your script with the SPP set
to 512 and without the FFT block, i.e. Radio ->
Rx Streamer? This may be a general issue with SPP
unrelated to the FFT. I'm getting the same "Bad
CHDR packet" error on a different device with the
FIR filter block, but it goes away when I remove
the block.

Jonathon

On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:

On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote:





Thanks. Still trying to work this out.  In
UHD 4, the interface to the FPGA changed from
a straightforward DMA implementation--done by
ADI for
  their IIO subsystem, to a driver that makes
the FPGA/Radio "look" like a network device
with an MTU of 9000.

With an MTU that large, you should have no
trouble with 512-bin FFTs. But clearly, you are.

The "int0" network interface exists only
while there's a session with the radio, so it
won't show up in "ifconfig" unless there's a
session active,
  and it indeed has an MTU of 9000. So MTU
isn't your problem.  It's something else, and
I'm not sure what at the moment.



пн, 30 авг. 2021 г. в 15:08, Marcus D. Leech
mailto:patchvonbr...@gmail.com>>:

On 2021-08-29 7:17 a.m., Ivan Zahartchuk
wrote:

Thanks a lot. Here is my output with
uhd_usrp_probe and my code:

Could you share with us the output of:

ip link

or ifconfig




сб, 28 авг. 2021 г. в 20:19, Marcus D.
 

[USRP-users] Re: setting lenght of fft RFNoC UHD 4

[Marcus D. Leech]

On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters: 
fft_amplitude = uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED 
fft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARD fft_shift = 
uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I do abs and display 
the data. Tell me how to do it better? And do I need to set a 
different type for the array which is passed to the recv function when 
setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC.   I don't know exactly what 
scaling strategy it uses.


If I wanted to get power estimates out of an RFNOC FFT, I'd have:

FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N   all inside RFNOC, and 
then scale to my hearts content at leisurely rates on the host.





ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech >:


On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:

Hello. There is any information on my question. I also noticed
that if you take the data after the FFT, then the sensitivity
drops very much. I see a -30 dBm signal but -60 dBm is no longer
displayed.

How are you scaling and displaying your FFT output?  What options
do you have set on your FFT?  DO you have it using Mag**2, how do
you scale it
  after that?




сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk mailto:adray0...@gmail.com>>:

Here is my script. I am trying to read different amounts of
data from DDC and from FFT. Are there any new statements on
my question?


чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
mailto:jonathon.pend...@ettus.com>>:

Great, thanks. Can you also share your latest python script?

Jonathon

On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk
mailto:adray0...@gmail.com>> wrote:

Yes, I can try it but next week. But I still wanted
to do FFT on FPGA. And one more question. Is it
possible to create two streamers and read 256 samples
one at a time and another 8192 for example? I want to
do FFT on one channel and start a stream with DDC for
demodulation on the other. What is possible?


ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum
mailto:jonathon.pend...@ettus.com>>:

Hi Ivan,

Can you try running your script with the SPP set
to 512 and without the FFT block, i.e. Radio ->
Rx Streamer? This may be a general issue with SPP
unrelated to the FFT. I'm getting the same "Bad
CHDR packet" error on a different device with the
FIR filter block, but it goes away when I remove
the block.

Jonathon

On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:

On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote:





Thanks. Still trying to work this out.  In
UHD 4, the interface to the FPGA changed from
a straightforward DMA implementation--done by
ADI for
  their IIO subsystem, to a driver that makes
the FPGA/Radio "look" like a network device
with an MTU of 9000.

With an MTU that large, you should have no
trouble with 512-bin FFTs. But clearly, you are.

The "int0" network interface exists only
while there's a session with the radio, so it
won't show up in "ifconfig" unless there's a
session active,
  and it indeed has an MTU of 9000. So MTU
isn't your problem.  It's something else, and
I'm not sure what at the moment.



пн, 30 авг. 2021 г. в 15:08, Marcus D. Leech
mailto:patchvonbr...@gmail.com>>:

On 2021-08-29 7:17 a.m., Ivan Zahartchuk
wrote:

Thanks a lot. Here is my output with
uhd_usrp_probe and my code:

Could you share with us the output of:

ip link

or ifconfig




сб, 28 авг. 2021 г. в 20:19, Marcus D.
Leech mailto:patchvonbr...@gmail.com>>:

On 2021-08-28 10:49 a.m., Ivan
Zahartchuk wrote:

Tell me who I can turn to for help
or how can I solve the problem