OFDM Transmitter & LO Feedthrough
Dear all,
I got a question regarding the implementation of a transmitter using C++ and
UHD. I am working with a N310.
My problem is the following:
I want to implement an OFDM transmitter using C++ and the UHD lib. I already
implemented the TXRX using the GNURadio framework. However, possible sampling
rates seem to be restricted on my machine and that's why I want do the
implementation in C++.
Here, I could already implement the sequence and the IFFT (I used the FFTW3
libs). However, when I stream the data to the N310 and observe the spectrum I
get a very strong carrier the rest of the spectrum looks more or less the way I
expected... This strong carrier does not occur in GNURadio, so hardware should
not be the issue.
Perhaps you could give me an hint what could cause this behaviour and how to do
a workaround.
I read something about LO leakage and tried the tune_request_t but this also
failed...
For the transmission of the sequence to the N310 I used the following code from
the UHD examples...
std::vector> buff(buffer_size, std::complex(0.3,
0.3));
for(i=sequence_length-1;i>0;i--)
{
buff.push_back(std::complex(sequence[i].real(),sequence[i].imag()));
}
std::vector*> buffs(channel_nums.size(), ());
// print pre-test summary
std::cout << boost::format("[%s] Channel sounding at transmit rate %f Msps
on %u channels")
% NOW() % (usrp->get_tx_rate() / 1e6) %
tx_stream->get_num_channels()
<< std::endl;
// Create the metadata, and populate the time spec at the latest possible
moment
uhd::tx_metadata_t md;
md.has_time_spec = true;
md.start_of_burst = true;
md.end_of_burst = false;
md.time_spec = usrp->get_time_now() + uhd::time_spec_t(tx_delay);
while (not burst_timer_elapsed) {
const size_t num_tx_samps_sent_now =
tx_stream->send(buffs, buff.size(), md)
* tx_stream->get_num_channels();
}
Any help would be highly appreciated!
Best regards,
Anton
AW: AW: USRP Errror "USER2: Invalid reason associated with wait request"
Thank you for that info! So I know at least where not to look for the problem :)) BR, Anton Von: Marcus D. Leech Gesendet: Mittwoch, 15. Juni 2022 22:40:17 An: Dobler, Anton; discuss-gnuradio@gnu.org Betreff: Re: AW: USRP Errror "USER2: Invalid reason associated with wait request" On 2022-06-15 16:34, Dobler, Anton wrote: The reason to run the flowgraph in su mode is that I want to use dpdk to ensure a reliable ethernet connection for sfp0/1… at least that’s what is mentioned by ettus in there AN regarding the usage of dpdk… BR, Anton Von: Discuss-gnuradio <mailto:discuss-gnuradio-bounces+anton.dobler=unibw...@gnu.org> im Auftrag von Marcus D. Leech <mailto:patchvonbr...@gmail.com> Gesendet: Mittwoch, 15. Juni 2022 21:54:53 An: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Betreff: Re: USRP Errror "USER2: Invalid reason associated with wait request" On 2022-06-15 15:33, Dobler, Anton wrote: Dear all, I am running GNURadio 3.8.1 with UHD3.15 LTS on an Ubuntu 18.04 machine with 16 cores (Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz) and a 10GigBit Ethernet card (DPDK enabled). The output of the benchmark_rate test is: root@dobler-Precision-7820-Tower:/home/dobler/rfnoc/uhd/host/build/examples# ./benchmark_rate --args "mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1" --rx_rate=125e6 --tx_rate=125e6 [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de EAL: Detected 16 lcore(s) EAL: No free hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b9 net_e1000_em EAL: PCI device :d5:00.0 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: using IOMMU type 1 (Type 1) EAL: Ignore mapping IO port bar(2) EAL: PCI device :d5:00.1 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: Ignore mapping IO port bar(2) PMD: ixgbe_dev_link_status_print(): Port 0: Link Down EAL: Port 0 MAC: 90 e2 ba f1 38 1c PMD: ixgbe_dev_link_status_print(): Port 1: Link Down EAL: Port 1 MAC: 90 e2 ba f1 38 1d EAL: Waiting for links to come up... EAL: Port 0 UP: 1, 1 Mbps EAL: Port 1 UP: 1, 1 Mbps EAL: Init DONE! EAL: Starting I/O threads! USER2: Thread 1 started USER2: Thread 2 started [00:00:00.01] Creating the usrp device with: mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1... [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=169.254.2.13,product=n310,second_addr=1.0.2.2,use_dpdk=1,time_source=external,clock_source=external'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3176E00 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium [00:00:04.381956] Setting device timestamp to 0... [00:00:04.452104] Testing receive rate 125.00 Msps on 1 channels [00:00:04.593488] Testing transmit rate 125.00 Msps on 1 channels [00:00:14.944083] Benchmark complete. Benchmark rate summary: Num received samples: 1292668703 Num dropped samples: 0 Num overruns detected:0 Num transmitted samples: 1250045736 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 0 Num late commands:0 Num timeouts (Tx):0 Num timeouts (Rx):0 This test is done with the
AW: USRP Errror "USER2: Invalid reason associated with wait request"
The reason to run the flowgraph in su mode is that I want to use dpdk to ensure a reliable ethernet connection for sfp0/1… at least that’s what is mentioned by ettus in there AN regarding the usage of dpdk… BR, Anton Von: Discuss-gnuradio im Auftrag von Marcus D. Leech Gesendet: Mittwoch, 15. Juni 2022 21:54:53 An: discuss-gnuradio@gnu.org Betreff: Re: USRP Errror "USER2: Invalid reason associated with wait request" On 2022-06-15 15:33, Dobler, Anton wrote: Dear all, I am running GNURadio 3.8.1 with UHD3.15 LTS on an Ubuntu 18.04 machine with 16 cores (Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz) and a 10GigBit Ethernet card (DPDK enabled). The output of the benchmark_rate test is: root@dobler-Precision-7820-Tower:/home/dobler/rfnoc/uhd/host/build/examples# ./benchmark_rate --args "mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1" --rx_rate=125e6 --tx_rate=125e6 [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de EAL: Detected 16 lcore(s) EAL: No free hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b9 net_e1000_em EAL: PCI device :d5:00.0 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: using IOMMU type 1 (Type 1) EAL: Ignore mapping IO port bar(2) EAL: PCI device :d5:00.1 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: Ignore mapping IO port bar(2) PMD: ixgbe_dev_link_status_print(): Port 0: Link Down EAL: Port 0 MAC: 90 e2 ba f1 38 1c PMD: ixgbe_dev_link_status_print(): Port 1: Link Down EAL: Port 1 MAC: 90 e2 ba f1 38 1d EAL: Waiting for links to come up... EAL: Port 0 UP: 1, 1 Mbps EAL: Port 1 UP: 1, 1 Mbps EAL: Init DONE! EAL: Starting I/O threads! USER2: Thread 1 started USER2: Thread 2 started [00:00:00.01] Creating the usrp device with: mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1... [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=169.254.2.13,product=n310,second_addr=1.0.2.2,use_dpdk=1,time_source=external,clock_source=external'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3176E00 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium [00:00:04.381956] Setting device timestamp to 0... [00:00:04.452104] Testing receive rate 125.00 Msps on 1 channels [00:00:04.593488] Testing transmit rate 125.00 Msps on 1 channels [00:00:14.944083] Benchmark complete. Benchmark rate summary: Num received samples: 1292668703 Num dropped samples: 0 Num overruns detected:0 Num transmitted samples: 1250045736 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 0 Num late commands:0 Num timeouts (Tx):0 Num timeouts (Rx):0 This test is done with the default FPGA image for the N310 with XG. So far everything seems to be good! Now for the application I am running I used the uhd_image_builder to generate a FPGA image with a DDCs and DUCs and moreover I included also a FFT. The flowgraph consists basically of a file source, a fft and a duc (both on the fpga) and the radio (usrp n310) itself. However, when I execute the flow-graph already with privileged rights (chrt -f 99 python3 flowgraph.py) I run into under-runs and moreover I get the following error &q
USRP Errror "USER2: Invalid reason associated with wait request"
Dear all, I am running GNURadio 3.8.1 with UHD3.15 LTS on an Ubuntu 18.04 machine with 16 cores (Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz) and a 10GigBit Ethernet card (DPDK enabled). The output of the benchmark_rate test is: root@dobler-Precision-7820-Tower:/home/dobler/rfnoc/uhd/host/build/examples# ./benchmark_rate --args "mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1" --rx_rate=125e6 --tx_rate=125e6 [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de EAL: Detected 16 lcore(s) EAL: No free hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b9 net_e1000_em EAL: PCI device :d5:00.0 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: using IOMMU type 1 (Type 1) EAL: Ignore mapping IO port bar(2) EAL: PCI device :d5:00.1 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: Ignore mapping IO port bar(2) PMD: ixgbe_dev_link_status_print(): Port 0: Link Down EAL: Port 0 MAC: 90 e2 ba f1 38 1c PMD: ixgbe_dev_link_status_print(): Port 1: Link Down EAL: Port 1 MAC: 90 e2 ba f1 38 1d EAL: Waiting for links to come up... EAL: Port 0 UP: 1, 1 Mbps EAL: Port 1 UP: 1, 1 Mbps EAL: Init DONE! EAL: Starting I/O threads! USER2: Thread 1 started USER2: Thread 2 started [00:00:00.01] Creating the usrp device with: mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1... [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=169.254.2.13,product=n310,second_addr=1.0.2.2,use_dpdk=1,time_source=external,clock_source=external'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3176E00 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium [00:00:04.381956] Setting device timestamp to 0... [00:00:04.452104] Testing receive rate 125.00 Msps on 1 channels [00:00:04.593488] Testing transmit rate 125.00 Msps on 1 channels [00:00:14.944083] Benchmark complete. Benchmark rate summary: Num received samples: 1292668703 Num dropped samples: 0 Num overruns detected:0 Num transmitted samples: 1250045736 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 0 Num late commands:0 Num timeouts (Tx):0 Num timeouts (Rx):0 This test is done with the default FPGA image for the N310 with XG. So far everything seems to be good! Now for the application I am running I used the uhd_image_builder to generate a FPGA image with a DDCs and DUCs and moreover I included also a FFT. The flowgraph consists basically of a file source, a fft and a duc (both on the fpga) and the radio (usrp n310) itself. However, when I execute the flow-graph already with privileged rights (chrt -f 99 python3 flowgraph.py) I run into under-runs and moreover I get the following error "USER2: Invalid reason associated with wait request". When I reduce the sampling rate obviously the under-runs disappear but the second error message still pops up after a time and also the LED on the front panel of the USRP goes off. What do you think is the reason for this? Running the same flow-graph on a different workstation works fine. Could some issue with the network cards be the problem? Any help is appreciated! Best regards, Anton
UHD4.2 & DPDK
Dear community, I try to use DPDK together with UHD4.2 but I get the following error: ./benchmark_rate --args "mgmt_addr=169.254.2.13,addr=1.0.1.2, second_addr=1.0.2.2,use_dpdk=1" --rx_rate=125e6 [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; UHD_4.2.0.0-4-g04d14cd7 [DEBUG] [PREFS] Loaded user config file /root/.config/uhd.conf EAL: Detected 16 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :00:04.0 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.1 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.2 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.3 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.4 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.5 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.6 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:04.7 on NUMA socket 0 EAL: probe driver: 8086:2021 rawdev_ioat EAL: PCI device :00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b9 net_e1000_em EAL: PCI device :d5:00.0 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: using IOMMU type 1 (Type 1) EAL: Ignore mapping IO port bar(2) EAL: PCI device :d5:00.1 on NUMA socket 0 EAL: probe driver: 8086:10fb net_ixgbe EAL: Ignore mapping IO port bar(2) [DEBUG] [MPMD] Discovering MPM devices on port 49600 [ERROR] [DPDK] Could not find route to destination address 1.0.1.2 [ERROR] [X300] X300 Network discovery error RuntimeError: DPDK: Could not find route to destination address 1.0.1.2 [00:00:00.000503] Creating the usrp device with: mgmt_addr=169.254.2.13,addr=1.0.1.2, second_addr=1.0.2.2,use_dpdk=1... [DEBUG] [MPMD] Discovering MPM devices on port 49600 [ERROR] [DPDK] Could not find route to destination address 1.0.1.2 [ERROR] [X300] X300 Network discovery error RuntimeError: DPDK: Could not find route to destination address 1.0.1.2 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,name=ni-n3xx-3176E00,fpga=XG,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1 [DEBUG] [MPMD] Claiming mboard 0 [DEBUG] [MPMD] Device args: `mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,name=ni-n3xx-3176E00,fpga=XG,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1'. RPC address: 169.254.2.13 [DEBUG] [MPMD] MPM reports device info: addr=1.0.1.2,claimed=True,connection=remote,dboard_0_pid=336,dboard_0_serial=31732ED,dboard_1_pid=336,dboard_1_serial=31732F6,description=N300-Series Device,eeprom_version=2,fourth_addr=169.254.2.13,fpga=XG,fpga_version=8.0,fpga_version_hash=8daa80c.clean,fs_version=20220419212711,mender_artifact=v4.2.0.0_n3xx,mpm_sw_version=4.2.0.0-g46a70d85,mpm_version=4.2,name=ni-n3xx-3176E00,pid=16962,product=n310,rev=6,rpc_connection=remote,second_addr=1.0.2.2,serial=3176E00,type=n3xx [DEBUG] [MPMD] Found 8 motherboard sensors. [DEBUG] [MPMD] Initializing mboard 0 [INFO] [MPM.PeriphManager] init() called with device args `fpga=XG,mgmt_addr=169.254.2.13,name=ni-n3xx-3176E00,product=n310,second_addr=1.0.2.2,use_dpdk=1,clock_source=internal,time_source=internal'. [DEBUG] [MPMD::MB_IFACE] Adding clock iface `radio_clk`, frequency: 125 MHz, mutable: Yes [DEBUG] [MPMD::MB_IFACE] Adding clock iface `bus_clk`, frequency: 200 MHz, mutable: No [ERROR] [DPDK] Could not find route to destination address 1.0.1.2 [WARNING] [MPMD::XPORT::UDP] Error during MTU discovery on address 1.0.1.2: RuntimeError: DPDK: Could not find route to destination address 1.0.1.2 [ERROR] [DPDK] Could not find route to destination address 1.0.2.2 [WARNING] [MPMD::XPORT::UDP] Error during MTU discovery on address 1.0.2.2: RuntimeError: DPDK: Could not find route to destination address 1.0.2.2 [ERROR] [MPMD::MB_IFACE] No CHDR connection available! Error: RuntimeError: No CHDR connection available! I use the uhd.conf as follows: [use_dpdk=1] dpdk-mtu=9000 dpdk-driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/dpdk/ dpdk-corelist=0,9,10 dpdk-num-mbufs=4096 dpdk-mbufs-cache-size=315 ;ens2f0 [dpdk-mac=90:e2:ba:f1:38:1c] dpdk-lcore = 9 dpdk-ipv4 = 1.0.2.1/24 ;ens2f1 [dpdk-mac=90:e2:ba:f1:38:1d] dpdk-lcore = 10 dpdk-ipv4 = 1.0.1.1/24? Any help would be highly appreciated! Best regards, Anton
AW: RFNoC image builder problem
Hi Rob, Thank you for your reply. Yes I actually installed all the dependencies. The python path environment variable shows: echo $PYTHONPATH usr/local/lib/python2.7/site-packages:/usr/local/lib/python3/dist-packages: I have checked the locations but obviously the imagbuilder module is not found in those locations, but it is found in ~/rfnoc_devel/uhd/host/python/uhd/imgbuilder. I guess that the image_builder.py is not properly compiled... or is it sufficient to use this python script? I checked the CMake files but there was no link to the imgbuilder folder or the related python files... Could it be that there is no linkage to this script in the Cmake files? Do you use UHD-4.2 and are you able to run rfnoc_image_builder? No I do not specify the FPGA directories... Thank you again for your help! BR, Anton Von: Rob Kossler Gesendet: Donnerstag, 19. Mai 2022 16:21 An: Dobler, Anton Cc: discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com Betreff: Re: RFNoC image builder problem [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hi Anton, Did you install all of the dependencies listed here<https://files.ettus.com/manual/page_build_guide.html#build_dependencies_ubuntu>? The error is a python error in not finding a needed package. It is possible you need to configure PYTHONPATH to point to a UHD folder. Did you specify the FPGA_DIR option to rfnoc_image_builder? Rob On Thu, May 19, 2022 at 9:42 AM Dobler, Anton mailto:anton.dob...@unibw.de>> wrote: Dear community, does anyone have an idea what the problem is about that import error? I checked the files for UHD4.0 (the rfnoc_image_builder runs fine here) but I am not experienced enough to find the problem... Any help would be very appreciated! BR, Anton ____ Von: Dobler, Anton Gesendet: Donnerstag, 12. Mai 2022 17:19 An: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>; usrp-us...@lists.ettus.com<mailto:usrp-us...@lists.ettus.com> Betreff: RFNoC image builder problem Dear community, I am running UHD4.2 on Ubuntu 20.04. When I try to run rfnoc_image_builder, I get the following error: rfnoc_image_builder --help Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 29, in from uhd.imgbuilder import image_builder ImportError: cannot import name 'image_builder' from 'uhd.imgbuilder' (unknown location) What is the issue here? I tried UHD4.1 but got the same issue here... Any help is very appreciated! BR, Anton
AW: RFNoC image builder problem
Dear community, does anyone have an idea what the problem is about that import error? I checked the files for UHD4.0 (the rfnoc_image_builder runs fine here) but I am not experienced enough to find the problem... Any help would be very appreciated! BR, Anton Von: Dobler, Anton Gesendet: Donnerstag, 12. Mai 2022 17:19 An: discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com Betreff: RFNoC image builder problem Dear community, I am running UHD4.2 on Ubuntu 20.04. When I try to run rfnoc_image_builder, I get the following error: rfnoc_image_builder --help Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 29, in from uhd.imgbuilder import image_builder ImportError: cannot import name 'image_builder' from 'uhd.imgbuilder' (unknown location) What is the issue here? I tried UHD4.1 but got the same issue here... Any help is very appreciated! BR, Anton
AW: [Discuss-gnuradio] Impulse response in DVB-T, someboby knows how to
Either you may go for a sequence, for example CAZAC or PN-sequences, that, if you cross-correlate the receive signal with the transmitted, show you the channel impulse response. The cross-correlation can be done in frequency domain using the properties of Fourier transformation. The easier approach if you just want to identify if there are other frequency components in your receive signal is to apply a FFT and have a look at the spectrum. Best regards Von: Discuss-gnuradio im Auftrag von Juan Antonio Gesendet: Samstag, 14. Mai 2022 22:47 An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] Impulse response in DVB-T, someboby knows how to It is too complicated for me right now to understand or measure a gnuradio block. However, I have seen in the oscilloscope the audio output of a continuous pilot and it looks like a sine wave. The question could be: Can the components of that sine wave be separated in the time domain and thus know if there are different waves reaching the receiver? Best Regards
RFNoC image builder problem
Dear community, I am running UHD4.2 on Ubuntu 20.04. When I try to run rfnoc_image_builder, I get the following error: rfnoc_image_builder --help Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 29, in from uhd.imgbuilder import image_builder ImportError: cannot import name 'image_builder' from 'uhd.imgbuilder' (unknown location) What is the issue here? I tried UHD4.1 but got the same issue here... Any help is very appreciated! BR, Anton
AW: RFNoC, UHD4.0
Thank you for that information. Can I safely use one of the default images or is there danger to brick the device if the SHA256 does not match each other? BR, Anton Von: Cédric Hannotier Gesendet: Donnerstag, 12. Mai 2022 10:50 An: Marcus D. Leech Cc: Dobler, Anton; discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com Betreff: Re: RFNoC, UHD4.0 On 11/05/22 15:33, Marcus D. Leech wrote: > On 2022-05-11 15:24, Dobler, Anton wrote: > > I use a n310 and have two 10gigbit for data streaming and one 1gigbit > > for managing the device… the strange thing about it is that the example > > flowgraph with rx radio downconverter and rx streamer works without any > > problems… > > I run the application on the host pc… > > What is that receiver profile error about? > > > > What can I do about the sha256 error? I also think the problem is rather > > due to my setup … > You might try upgrading to newer release of UHD. I would also suggest > continuing this discussion on the usrp-users mailing list, where there's a > bit more RFNOC > activity and expertise. > > I don't know what to suggest about the SHA256 error. Possibly your > installation doesn't have the correct SHA256 tools, or your filesystem is > truncating the files? > The images_downloader application uses the Python package "hashlib". > Perhaps that is failing in some way in your installation? The SHA256 error seems legit. If you compare the hash between the downloaded zip and the manifest, they do not match. Expected hash for "e3xx_e310_sg1_fpga_default" [1]: 89cb6985184d41d42bc5bde87addb5432f51a067175c1ec48568a8c03008cbda sha256sum of downloaded zip [2]: 73cad3cd5271d388de271accd15045daca8d61c850a5cc9459bd38dc0cb6893c [1] https://github.com/EttusResearch/uhd/blob/b38c9d837201482842b00e1af858cbcf51791c17/images/manifest.txt [2] https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg1_fpga_default-g2cba65b.zip > > > > Thank you, > > > > BR > > > > *Von:* Discuss-gnuradio > > im Auftrag von > > Marcus D. Leech > > *Gesendet:* Mittwoch, 11. Mai 2022 20:54:15 > > *An:* discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com > > *Betreff:* Re: RFNoC, UHD4.0 > > On 2022-05-11 14:45, Dobler, Anton wrote: > > > > > > Dear Community, > > > > > > > > > I try to set up a basic flowgraph in GRC consisting out of a null > > > source, a tx streamer and DUC and a TX radio. > > > > > > > > > I use UHD4.0 and GR3.8.2. > > > > > > > > > However, I get the following error message: > > > > > > > > > /RuntimeError: RuntimeError: Error during RPC call to `init'. Error > > > message: RuntimeError: Receiver profile out of range RF bandwidth./ > > > > > > > > > I tried different settings for sample rate, etc. but still I get > > > that error. I attached the used flowgraph. > > > > > > > > > > > > > > > The second question is with regards to the default fpga images. When > > > I download the images I get the following error: > > > > > > > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg1_fpga_default-g2cba65b.zip!/ > > > /01137 kB / 01137 kB (100%) e3xx_e310_sg3_fpga_default-g2cba65b.zip/ > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg3_fpga_default-g2cba65b.zip!/ > > > /10183 kB / 10183 kB (100%) e3xx_e320_fpga_default-g2cba65b.zip/ > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e320_fpga_default-g2cba65b.zip!/ > > > /20729 kB / 20729 kB (100%) n3xx_n310_fpga_default-g2cba65b.zip/ > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n310_fpga_default-g2cba65b.zip!/ > > > /14345 kB / 14345 kB (100%) n3xx_n300_fpga_default-g2cba65b.zip/ > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n300_fpga_default-g2cba65b.zip!/ > > > /27285 kB / 27285 kB (100%) n3xx_n320_fpga_default-g2cba65b.zip/ > > > /[ERROR] Downloaded SHA256 does not match manifest for > > > https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n320_fpga_default-g2cba65b.zip!/ > > > > >
AW: RFNoC, UHD4.0
I use a n310 and have two 10gigbit for data streaming and one 1gigbit for managing the device… the strange thing about it is that the example flowgraph with rx radio downconverter and rx streamer works without any problems… I run the application on the host pc… What is that receiver profile error about? What can I do about the sha256 error? I also think the problem is rather due to my setup … Thank you, BR Von: Discuss-gnuradio im Auftrag von Marcus D. Leech Gesendet: Mittwoch, 11. Mai 2022 20:54:15 An: discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com Betreff: Re: RFNoC, UHD4.0 On 2022-05-11 14:45, Dobler, Anton wrote: Dear Community, I try to set up a basic flowgraph in GRC consisting out of a null source, a tx streamer and DUC and a TX radio. I use UHD4.0 and GR3.8.2. However, I get the following error message: RuntimeError: RuntimeError: Error during RPC call to `init'. Error message: RuntimeError: Receiver profile out of range RF bandwidth. I tried different settings for sample rate, etc. but still I get that error. I attached the used flowgraph. The second question is with regards to the default fpga images. When I download the images I get the following error: [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg1_fpga_default-g2cba65b.zip! 01137 kB / 01137 kB (100%) e3xx_e310_sg3_fpga_default-g2cba65b.zip [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg3_fpga_default-g2cba65b.zip! 10183 kB / 10183 kB (100%) e3xx_e320_fpga_default-g2cba65b.zip [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e320_fpga_default-g2cba65b.zip! 20729 kB / 20729 kB (100%) n3xx_n310_fpga_default-g2cba65b.zip [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n310_fpga_default-g2cba65b.zip! 14345 kB / 14345 kB (100%) n3xx_n300_fpga_default-g2cba65b.zip [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n300_fpga_default-g2cba65b.zip! 27285 kB / 27285 kB (100%) n3xx_n320_fpga_default-g2cba65b.zip [ERROR] Downloaded SHA256 does not match manifest for https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n320_fpga_default-g2cba65b.zip! What can I do to solve that problem? Any help would be more than welcome! Thanks, BR, Anton What type of USRP? Are you running this on the device itself, or over a network connection? If over a network connection, what type of connection? The SHA256 errors means that there's a problem with the repository, or that your access to the repository is corrupting files, or they're being corrupted on your system as they arrive. I haven't *heard* that the repository has any problems for that release of UHD.
RFNoC, UHD4.0
Dear Community,
I try to set up a basic flowgraph in GRC consisting out of a null source, a tx
streamer and DUC and a TX radio.
I use UHD4.0 and GR3.8.2.
However, I get the following error message:
RuntimeError: RuntimeError: Error during RPC call to `init'. Error message:
RuntimeError: Receiver profile out of range RF bandwidth.
I tried different settings for sample rate, etc. but still I get that error. I
attached the used flowgraph.
The second question is with regards to the default fpga images. When I download
the images I get the following error:
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg1_fpga_default-g2cba65b.zip!
01137 kB / 01137 kB (100%) e3xx_e310_sg3_fpga_default-g2cba65b.zip
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e310_sg3_fpga_default-g2cba65b.zip!
10183 kB / 10183 kB (100%) e3xx_e320_fpga_default-g2cba65b.zip
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/e3xx/uhd-2cba65b/e3xx_e320_fpga_default-g2cba65b.zip!
20729 kB / 20729 kB (100%) n3xx_n310_fpga_default-g2cba65b.zip
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n310_fpga_default-g2cba65b.zip!
14345 kB / 14345 kB (100%) n3xx_n300_fpga_default-g2cba65b.zip
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n300_fpga_default-g2cba65b.zip!
27285 kB / 27285 kB (100%) n3xx_n320_fpga_default-g2cba65b.zip
[ERROR] Downloaded SHA256 does not match manifest for
https://files.ettus.com/binaries/cache/n3xx/uhd-2cba65b/n3xx_n320_fpga_default-g2cba65b.zip!
What can I do to solve that problem?
Any help would be more than welcome!
Thanks,
BR,
Anton
rfnoc_radio_duc.grc
Description: rfnoc_radio_duc.grc
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# SPDX-License-Identifier: GPL-3.0
#
# GNU Radio Python Flow Graph
# Title: RFNoC: Radio -> DUC Example
# GNU Radio version: 3.8.2.0
from distutils.version import StrictVersion
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print("Warning: failed to XInitThreads()")
from PyQt5 import Qt
from gnuradio import eng_notation
from gnuradio import blocks
from gnuradio import gr
from gnuradio.filter import firdes
import sys
import signal
from argparse import ArgumentParser
from gnuradio.eng_arg import eng_float, intx
import ettus
from gnuradio import uhd
from gnuradio import qtgui
class rfnoc_radio_duc(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "RFNoC: Radio -> DUC Example")
Qt.QWidget.__init__(self)
self.setWindowTitle("RFNoC: Radio -> DUC Example")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "rfnoc_radio_duc")
try:
if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
self.restoreGeometry(self.settings.value("geometry").toByteArray())
else:
self.restoreGeometry(self.settings.value("geometry"))
except:
pass
##
# Variables
##
self.samp_rate_rf = samp_rate_rf = 122.88e6
self.samp_rate = samp_rate = 1e6
self.gain = gain = 0
self.freq = freq = 1e9
self.rfnoc_graph = ettus_rfnoc_graph = ettus.rfnoc_graph(uhd.device_addr(",".join(('', ''
##
# Blocks
##
self._samp_rate_rf_tool_bar = Qt.QToolBar(self)
self._samp_rate_rf_tool_bar.addWidget(Qt.QLabel('Sampling Rate (Hz)' + ": "))
self._samp_rate_rf_line_edit = Qt.QLineEdit(str(self.samp_rate_rf))
self._samp_rate_rf_tool_bar.addWidget(self._samp_rate_rf_line_edit)
self._samp_rate_rf_line_edit.returnPressed.connect(
lambda:
AW: Realtime Kernel, UHD 4.0, GNURadio
Dear Community, Thank you for your suggestions and information. I will give all of it a try! I really appreciate the spirit of this mailing list! Best regards, Anton Von: Discuss-gnuradio im Auftrag von Johannes Demel Gesendet: Freitag, 6. Mai 2022 09:01 An: discuss-gnuradio@gnu.org Betreff: Re: Realtime Kernel, UHD 4.0, GNURadio Hi Anton, This guide may help you: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks I usually use the CPU Governor, Thread Priority Scheduling, Adjust Network Buffers, and Adjust Ethernet MTU sections. I can run flowgraphs at 30.72MSps without hiccups. Thus, I suggest you check your host capabilities and probably more important: Check that GR is compiled and installed with `CMAKE_BUILD_TYPE=Release`. Besides, you may want to investigate which thread (and thus GR block) is the culprit. A first simple approach would be to use htop and find out which thread is close to 100% CPU load. If you change the htop Display Options to "Show custom thread names" it should be fairly simple to get a better understanding of your issue. Cheers Johannes On 05.05.22 20:52, Dobler, Anton wrote: > Dear community, > > > I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as > a SDR. > > > When I execute the benchmark_rate example with DPDK enabled, I do not > see any under- or overruns even with the sampling rate set to 125 MHz, > however using GNURadio - DPDK enabled here as well - I do not achieve > that high sampling rate. The limit seems to be around 30MHz though. > > > Do you know, apart from using taskset and isolcpus any other possibility > to achieve higher sampling rates? > > > Would it be an option to use the realtime kernel available for Ubuntu > 20.04 and is this kernel compatible with GNURadio? > > > Any help also with regards to the usage of taskset and isolcpus would be > highly appreciated! > > > Thank you in advance! > > > BR, > > > Anton >
Realtime Kernel, UHD 4.0, GNURadio
Dear community, I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as a SDR. When I execute the benchmark_rate example with DPDK enabled, I do not see any under- or overruns even with the sampling rate set to 125 MHz, however using GNURadio - DPDK enabled here as well - I do not achieve that high sampling rate. The limit seems to be around 30MHz though. Do you know, apart from using taskset and isolcpus any other possibility to achieve higher sampling rates? Would it be an option to use the realtime kernel available for Ubuntu 20.04 and is this kernel compatible with GNURadio? Any help also with regards to the usage of taskset and isolcpus would be highly appreciated! Thank you in advance! BR, Anton
AW: 3D plots or image display in GR
Hi Marcin, Take a look at this: https://github.com/antondobler/gr-SurfaceInspector? I recognized that there is still a problem concerning memory. I have not found that error until now, however if you can make any improvements for that block let me know! Should be kind of a starting point! ?BR Von: Discuss-gnuradio im Auftrag von Marcin Wachowiak Gesendet: Dienstag, 14. September 2021 23:23 Cc: GNURadio Discussion List Betreff: Re: 3D plots or image display in GR Thank You for the help and suggestions. Anton Dobler is your port of vis3d to 3.8 available somewhere on Github? I tried to look for your fork but didn't find it. (The only thing having the modification in regard to 3d plot was: https://github.com/chrisruk/gr-inspector , but it has some problems after install like: AttributeError: module 'inspector' has no attribute 'vis3d_vf', even after sudo ldconfig and so on) Your port/implementation would be very useful to start from with 3D in GR. Martin Braun, gr-specest will save me a lot of time so that I can focus on understanding what is going on inside. Kind regards, Marcin Wachowiak On Tue, 14 Sept 2021 at 11:00, Martin Braun mailto:martin.br...@ettus.com>> wrote: Marcin, gr-specest (https://github.com/kit-cel/gr-specest/) has some cyclostationary code, as well as some matplotlib-based plotting thereof. The code was written in the Py2k era and might be out-of-date. But it might be an inspiration! --M On Mon, Sep 13, 2021 at 9:57 PM Marcin Wachowiak mailto:marcin.r.wachow...@gmail.com>> wrote: Hello, I would like to experiment with some cyclostationary signal detection in GNU Radio. In order to visualize the results, I need some kind of 3D plot or 2D image plot (to visualize matrix values). Having searched for similar topics on the internet and mailing lists I decided to ask here. What could be the best approach to obtain such plots in GR? Should I try to introduce a new Qt block or use an embedded python block with matplotlib (create a sequence of plots, animation)? I can also do simple postprocessing after collecting the data but live visualization or one with tolerable latency would be most desirable. Maybe I can utilize some of the existing blocks like constellation sink and change the colours of points accordingly to values in the matrix? Please let me know your thoughts. Kind regards, Marcin Wachowiak
AW: 3D plots or image display in GR
Hi, You can check vis3d from https://github.com/gnuradio/gr-inspector/tree/maint-3.7/lib. This gives you a qt surface plot. I ported this block to 3.8 and it works so far. Still bit buggy but at least it enables 3d "realtime" plotting. cheers Von: Discuss-gnuradio [discuss-gnuradio-bounces+anton.dobler=unibw...@gnu.org] im Auftrag von Marcin Wachowiak [marcin.r.wachow...@gmail.com] Gesendet: Montag, 13. September 2021 21:55 An: GNURadio Discussion List Betreff: 3D plots or image display in GR Hello, I would like to experiment with some cyclostationary signal detection in GNU Radio. In order to visualize the results, I need some kind of 3D plot or 2D image plot (to visualize matrix values). Having searched for similar topics on the internet and mailing lists I decided to ask here. What could be the best approach to obtain such plots in GR? Should I try to introduce a new Qt block or use an embedded python block with matplotlib (create a sequence of plots, animation)? I can also do simple postprocessing after collecting the data but live visualization or one with tolerable latency would be most desirable. Maybe I can utilize some of the existing blocks like constellation sink and change the colours of points accordingly to values in the matrix? Please let me know your thoughts. Kind regards, Marcin Wachowiak
AW: USRP, GPIO toggling and Gnuradio
Could it be that the set_gpio_attr() command resets the OUT register before setting the new value? BR Von: Marcus D Leech Gesendet: Samstag, 11. September 2021 22:01 An: Ed Criscuolo Cc: Dobler, Anton; Discuss-gnuradio@gnu.org Betreff: Re: USRP, GPIO toggling and Gnuradio Good thought. But this is an N310. No daughter cards Sent from my iPhone On Sep 11, 2021, at 12:06 PM, Ed Criscuolo wrote: ?Assuming you have room for an additional daughtercard, have you considered using a Basic RF card instead of GPIO? May require some signal level conditioning of the output, but should go plenty fast enough. @(^.^)@ Ed Sent from my iPhone On Sep 10, 2021, at 12:08 PM, Dobler, Anton mailto:anton.dob...@unibw.de>> wrote: Is there any alternative to the standard GPIO UHD interface, that allows me the desired speed
AW: AW: AW: AW: USRP, GPIO toggling and Gnuradio
Dear all,
I tried a UHD C++ application for testing GPIO switching times and I get at a
toggle period of roughly 17us using the following code:
while(stop_signal_called==false)
{
tx_radio_ctrl->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
GPIO_BIT(4));
tx_radio_ctrl->set_gpio_attr(gpio, std::string("OUT"), "LOW",
GPIO_BIT(4));
}
It seems like this is the upper limit concerning toggling period possible.
Toggling the GPIOs with a period of 100us should thus be feasible...
Does anyone has an advice how to write a low latency OOT block for GNURadio?
Is there a GR-API call to priorize a block?
Thank you for any hints!
Von: Marcus D. Leech
Gesendet: Freitag, 10. September 2021 19:47
An: Dobler, Anton; discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com
Betreff: Re: AW: AW: AW: USRP, GPIO toggling and Gnuradio
On 2021-09-10 1:37 p.m., Dobler, Anton wrote:
Thank you for that explanation! Does the transaction regarding the GPIO states
use the SFP+ ports or the management connection?
I will go for the raw c++ application and come back to the list ASAP.
Thank you all for your answers!
That's a good question, and one for which I don't have an answer I'm certain
of. Copying the usrp-users mailing list.
Your device is an "MPM" device, which is a server on the Linux CPU on your
device that handles "management of the radio" via
RPC calls. Browsing (very cursory) the code, it seems that it "gets" things
like I2C and SPI, so it probably also handles GPIO
transactions, it most definitely "lives" on the management interface.
?
Von: Marcus D. Leech <mailto:patchvonbr...@gmail.com>
Gesendet: Freitag, 10. September 2021 18:59
An: Dobler, Anton; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Betreff: Re: AW: AW: USRP, GPIO toggling and Gnuradio
On 2021-09-10 12:08 p.m., Dobler, Anton wrote:
Is there any alternative to the standard GPIO UHD interface, that allows me the
desired speed and is this issue I see related to gnuradio and its scheduler or
rather to the UHD API for the GPIOs??
BR,
Anton?
Every GPIO state transition requires a transaction across your network
interface, and then into the FPGA GPIO logic. That's the absolute upper limit
on
toggling the GPIOs from the host.
You can test how fast you can make this go with a "raw" UHD C++ program. Once
you've established how fast it can potentially go, then you start
evaluating how to approach this latency with GR. Right now, the waters are
very muddy, and I am not the one to comment on GR latencies, etc.
____
Von: Marcus D. Leech <mailto:patchvonbr...@gmail.com>
Gesendet: Freitag, 10. September 2021 18:04
An: Dobler, Anton; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Betreff: Re: AW: USRP, GPIO toggling and Gnuradio
On 2021-09-10 11:54 a.m., Dobler, Anton wrote:
I am extracting the package rate of a receive signal using a rather complex GRC
flowgraph, i.e. I am detecting the preamble of a receive signal and generate a
clock from here. This clock signal period is within the range of 100us - 1ms.
Toggling GPIOs using the standard GPIO interface for signals this fast is
likely not going to be very speedy.
The GR experts will have to answer your other questions.
AW: AW: AW: USRP, GPIO toggling and Gnuradio
Thank you for that explanation! Does the transaction regarding the GPIO states use the SFP+ ports or the management connection? I will go for the raw c++ application and come back to the list ASAP. Thank you all for your answers! ? Von: Marcus D. Leech Gesendet: Freitag, 10. September 2021 18:59 An: Dobler, Anton; discuss-gnuradio@gnu.org Betreff: Re: AW: AW: USRP, GPIO toggling and Gnuradio On 2021-09-10 12:08 p.m., Dobler, Anton wrote: Is there any alternative to the standard GPIO UHD interface, that allows me the desired speed and is this issue I see related to gnuradio and its scheduler or rather to the UHD API for the GPIOs?? BR, Anton? Every GPIO state transition requires a transaction across your network interface, and then into the FPGA GPIO logic. That's the absolute upper limit on toggling the GPIOs from the host. You can test how fast you can make this go with a "raw" UHD C++ program. Once you've established how fast it can potentially go, then you start evaluating how to approach this latency with GR. Right now, the waters are very muddy, and I am not the one to comment on GR latencies, etc. Von: Marcus D. Leech <mailto:patchvonbr...@gmail.com> Gesendet: Freitag, 10. September 2021 18:04 An: Dobler, Anton; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Betreff: Re: AW: USRP, GPIO toggling and Gnuradio On 2021-09-10 11:54 a.m., Dobler, Anton wrote: I am extracting the package rate of a receive signal using a rather complex GRC flowgraph, i.e. I am detecting the preamble of a receive signal and generate a clock from here. This clock signal period is within the range of 100us - 1ms. Toggling GPIOs using the standard GPIO interface for signals this fast is likely not going to be very speedy. The GR experts will have to answer your other questions.
AW: AW: USRP, GPIO toggling and Gnuradio
Is there any alternative to the standard GPIO UHD interface, that allows me the desired speed and is this issue I see related to gnuradio and its scheduler or rather to the UHD API for the GPIOs?? BR, Anton? Von: Marcus D. Leech Gesendet: Freitag, 10. September 2021 18:04 An: Dobler, Anton; discuss-gnuradio@gnu.org Betreff: Re: AW: USRP, GPIO toggling and Gnuradio On 2021-09-10 11:54 a.m., Dobler, Anton wrote: I am extracting the package rate of a receive signal using a rather complex GRC flowgraph, i.e. I am detecting the preamble of a receive signal and generate a clock from here. This clock signal period is within the range of 100us - 1ms. Toggling GPIOs using the standard GPIO interface for signals this fast is likely not going to be very speedy. The GR experts will have to answer your other questions.
AW: USRP, GPIO toggling and Gnuradio
PS: To clarify the 20us:
If I do not use a sleep function in that OOT block and run the flowgraph, I
measure a switching time of the GPIOs of 20us no matter which sample rate I
use I
f I use a sleep function the toggling period really depends on the
corresponding flowgraph's complexity.
Using a very simple flowgraph consisting out of a signal generator and that
GPIO block I get 5kHz rect signal properly shown on a oscilloscope.
Using the more complex flowgraph to extract package rate from a received signal
I am far out of scope of the desired toggling period...
Von: Dobler, Anton
Gesendet: Freitag, 10. September 2021 17:54
An: Marcus D. Leech; discuss-gnuradio@gnu.org
Betreff: AW: USRP, GPIO toggling and Gnuradio
I am extracting the package rate of a receive signal using a rather complex GRC
flowgraph, i.e. I am detecting the preamble of a receive signal and generate a
clock from here. This clock signal period is within the range of 100us - 1ms.
As I wrote in my first message, the work function with the sleep timer works
for simple flowgraphs using a sampling rate of up to 10kHz. After that the
toggling period stays more or less the same, I guess this is because of the
rescheduling time limit as Jeff Long already stated.
However, I am wondering, why the block needs a sleep function at all, since the
threshold_ff_impl.cc, whose work function is almost the same as the one I use,
does not need that and still has the proper sampling...
I read about the ATR functionality and that there are three fast-path methods
for a USRP device (uhd::tx_streamer::send(), uhd::rx_streamer::recv(), and
uhd::tx_streamer::recv_async_msg()).
Do you think wiring the GPIOs to the ATR functionality and toggling them by
switching tx_stream on/off would be a better solution?
As a second idea, I was wondering if using a input vector to the block of a
certain size (e.g. 1000 items) would be a better approach than using the
noutputitems, which I think have been only two items (still need to run the
perf counters...)? I guess the scheduler runs the work function of each block
completely, doen't it?
Thank you for your help!
BR,
Anton
Von: Discuss-gnuradio
im Auftrag von Marcus D. Leech
Gesendet: Freitag, 10. September 2021 17:36
An: discuss-gnuradio@gnu.org
Betreff: Re: USRP, GPIO toggling and Gnuradio
On 2021-09-10 10:18 a.m., Dobler, Anton wrote:
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal generator that produces a
square wave signal.
The block's work function looks like this:
int GPIO_IO_impl::work(int noutput_items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
{
const float *in_signal = (const float *) input_items[0];
for(int i=0; i < noutput_items; i++) {
if(in_signal[i] >= d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
0x)
}
if(in_signal[i] < d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xff);
}
boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long
long)d_samp_period));
}
return noutput_items;
}
The sleep function is important in that without it, regardless of the sampling
rate of the square wave signal, the pin is switched with a period of 20us. If I
use the sleep function, the whole thing works better, but only up to a sampling
rate of about 20kHz. I have read a little bit about the function of the
scheduler in GNURadio, but I did not find a solution.
Starting from the standing approach, I have tried using both Timed Commands and
Boost Signals, with the result that the pins are switched completely
asynchronously. Since I don't really know what to do at this point, I wanted to
ask if any of you had experience with this kind of OOT block in GNURadio.
Best regards,
Anton
Could you clarify--you WANT the pins to be switched at a very high rate--that
is you expect your input signal to be switching between thresholds with a
period smaller than 20us?
AW: USRP, GPIO toggling and Gnuradio
I am extracting the package rate of a receive signal using a rather complex GRC
flowgraph, i.e. I am detecting the preamble of a receive signal and generate a
clock from here. This clock signal period is within the range of 100us - 1ms.
As I wrote in my first message, the work function with the sleep timer works
for simple flowgraphs using a sampling rate of up to 10kHz. After that the
toggling period stays more or less the same, I guess this is because of the
rescheduling time limit as Jeff Long already stated.
However, I am wondering, why the block needs a sleep function at all, since the
threshold_ff_impl.cc, whose work function is almost the same as the one I use,
does not need that and still has the proper sampling...
I read about the ATR functionality and that there are three fast-path methods
for a USRP device (uhd::tx_streamer::send(), uhd::rx_streamer::recv(), and
uhd::tx_streamer::recv_async_msg()).
Do you think wiring the GPIOs to the ATR functionality and toggling them by
switching tx_stream on/off would be a better solution?
As a second idea, I was wondering if using a input vector to the block of a
certain size (e.g. 1000 items) would be a better approach than using the
noutputitems, which I think have been only two items (still need to run the
perf counters...)? I guess the scheduler runs the work function of each block
completely, doen't it??
Thank you for your help!
BR,
Anton
Von: Discuss-gnuradio
im Auftrag von Marcus D. Leech
Gesendet: Freitag, 10. September 2021 17:36
An: discuss-gnuradio@gnu.org
Betreff: Re: USRP, GPIO toggling and Gnuradio
On 2021-09-10 10:18 a.m., Dobler, Anton wrote:
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal generator that produces a
square wave signal.
The block's work function looks like this:
int GPIO_IO_impl::work(int noutput_items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
{
const float *in_signal = (const float *) input_items[0];
for(int i=0; i < noutput_items; i++) {
if(in_signal[i] >= d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
0x)
}
if(in_signal[i] < d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xff);
}
boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long
long)d_samp_period));
}
return noutput_items;
}
The sleep function is important in that without it, regardless of the sampling
rate of the square wave signal, the pin is switched with a period of 20us. If I
use the sleep function, the whole thing works better, but only up to a sampling
rate of about 20kHz. I have read a little bit about the function of the
scheduler in GNURadio, but I did not find a solution.
Starting from the standing approach, I have tried using both Timed Commands and
Boost Signals, with the result that the pins are switched completely
asynchronously. Since I don't really know what to do at this point, I wanted to
ask if any of you had experience with this kind of OOT block in GNURadio.
?
Best regards,
Anton
Could you clarify--you WANT the pins to be switched at a very high rate--that
is you expect your input signal to be switching between thresholds with a
period smaller than 20us?
AW: USRP, GPIO toggling and Gnuradio
PS: Forgot to mention that I am using a USRP N310 and its front panel GPIO...
Thank you for your help!?
Von: Discuss-gnuradio
im Auftrag von Dobler, Anton
Gesendet: Freitag, 10. September 2021 16:18
An: discuss-gnuradio@gnu.org
Betreff: USRP, GPIO toggling and Gnuradio
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal generator that produces a
square wave signal.
The block's work function looks like this:
int GPIO_IO_impl::work(int noutput_items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
{
const float *in_signal = (const float *) input_items[0];
for(int i=0; i < noutput_items; i++) {
if(in_signal[i] >= d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
0x)
}
if(in_signal[i] < d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xff);
}
boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long
long)d_samp_period));
}
return noutput_items;
}
The sleep function is important in that without it, regardless of the sampling
rate of the square wave signal, the pin is switched with a period of 20us. If I
use the sleep function, the whole thing works better, but only up to a sampling
rate of about 20kHz. I have read a little bit about the function of the
scheduler in GNURadio, but I did not find a solution.
Starting from the standing approach, I have tried using both Timed Commands and
Boost Signals, with the result that the pins are switched completely
asynchronously. Since I don't really know what to do at this point, I wanted to
ask if any of you had experience with this kind of OOT block in GNURadio.
?
Best regards,
Anton
USRP, GPIO toggling and Gnuradio
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal generator that produces a
square wave signal.
The block's work function looks like this:
int GPIO_IO_impl::work(int noutput_items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
{
const float *in_signal = (const float *) input_items[0];
for(int i=0; i < noutput_items; i++) {
if(in_signal[i] >= d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
0x)
}
if(in_signal[i] < d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xff);
}
boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long
long)d_samp_period));
}
return noutput_items;
}
The sleep function is important in that without it, regardless of the sampling
rate of the square wave signal, the pin is switched with a period of 20us. If I
use the sleep function, the whole thing works better, but only up to a sampling
rate of about 20kHz. I have read a little bit about the function of the
scheduler in GNURadio, but I did not find a solution.
Starting from the standing approach, I have tried using both Timed Commands and
Boost Signals, with the result that the pins are switched completely
asynchronously. Since I don't really know what to do at this point, I wanted to
ask if any of you had experience with this kind of OOT block in GNURadio.
?
Best regards,
Anton
