Re: [USRP-users] Firmware images for X310-RFNOC?
On 11/26/2018 06:03 PM, Paul Boven via USRP-users wrote: Hi Marcus, everyone, On 25/11/2018 19:47, Marcus D. Leech via USRP-users wrote: OK, just tried the attached flow-graph in the lab, using: [mleech@lab ~]$ uhd_usrp_probe --args addr=192.168.10.2 [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; UHD_4.0.0.rfnoc-devel-702-geec24d7b The above text suggested to try the rfnoc-devel branch instead of the master branch for uhd/host. With that, I've gotten RFNOC to work, thanks! Below some further details on what I managed to piece together for now, in case anyone wants to comment. I'm using the default FPGA image for the X310, which has only the radio and the DDC/DUC blocks for RFNOC, as the images with more blocks are currently unavailable. RFNOC receiving (with TwinRX) works, but often the frequency doesn't get set correctly on startup. Changing the frequency (e.g. via a QT range slider) regularly causes the command link from PC to USRP to die. Samples from USRP to PC keep flowing, that part is quite stable. This may be related to a known issue that is being worked on. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi Marcus, everyone, On 25/11/2018 19:47, Marcus D. Leech via USRP-users wrote: OK, just tried the attached flow-graph in the lab, using: [mleech@lab ~]$ uhd_usrp_probe --args addr=192.168.10.2 [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; UHD_4.0.0.rfnoc-devel-702-geec24d7b The above text suggested to try the rfnoc-devel branch instead of the master branch for uhd/host. With that, I've gotten RFNOC to work, thanks! Below some further details on what I managed to piece together for now, in case anyone wants to comment. I'm using the default FPGA image for the X310, which has only the radio and the DDC/DUC blocks for RFNOC, as the images with more blocks are currently unavailable. RFNOC receiving (with TwinRX) works, but often the frequency doesn't get set correctly on startup. Changing the frequency (e.g. via a QT range slider) regularly causes the command link from PC to USRP to die. Samples from USRP to PC keep flowing, that part is quite stable. For the TwinRX, the data rate seems to be 100MS/s complex, so the RFNOC Radio block already takes care of converting the samples (real samples, second Nyquist zone on either I or Q ADC input) into complex values. As a first test, I used the RFNOC Radio Block and DDC to make a tunable WBFM radio, using the 'CORDIC' input to the DDC block to select the station. This works very well now (apart from the issues noted above). Build process: Host: Ubuntu 18.04 LTS 1) UHD: git clone http://github.com/EttusResearch/uhd cd uhd/host git checkout rfnoc-devel mkdir build; cd build cmake -DENABLE_RFNOC=ON -DCMAKE_INSTALL_PREFIX=/usr .. make package sudo dpkg -i uhd_4.0.0.rfnoc-devel-702-geec24d7b_Ubuntu-18.04-x86_64.deb 2) GNU Radio: git clone --recursive http://github.com/gnuradio/gnuradio cd gnuradio git checkout maint-3.7 mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr -DCPACK_DEBIAN_ARCHIVE_TYPE=gnutar .. make package sudo dpkg -i gnuradio_3.7.13.4_Ubuntu-18.04-x86_64.deb 3) GR-Ettus: git clone http://github.com/EttusResearch/gr-ettus cd gr-ettus mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr .. make gr-ettus doesn't have a 'make package' target in the Makefile, so I created a package by hand using "fakeroot DESTDIR=`pwd`/fakeroot make install" and then building a Debian package out of that. Next steps: build an FPGA image with a few more interesting RFNOC blocks. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
On 11/25/2018 07:22 AM, Paul Boven via USRP-users wrote: Hi again, On 11/22/18 6:45 PM, Marcus D. Leech via USRP-users wrote: Your radio block is set to a sample rate of 100e6, whereas the X310 uses a sample clock of 200e6. This may be why things are getting stuffed up. I've now tried 200 MHz for the radio block. Still getting the same error messages, and nothing in the FFT plot. Regards, Paul Boven. OK, just tried the attached flow-graph in the lab, using: [mleech@lab ~]$ uhd_usrp_probe --args addr=192.168.10.2 [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; UHD_4.0.0.rfnoc-devel-702-geec24d7b [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 4320 bytes. [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a [WARNING] [GPS] update_cache: Malformed GPSDO string: LC_XO, Firmware Rev 0.929a [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1309 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001) [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: 0xD0C0) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) [WARNING] [X300] Cannot update master clock rate! X300 Series does not allow changing the clock rate during runtime. _ / | Device: X-Series Device | _ |/ | | Mboard: X310 | | revision: 6 | | product: 30410 | | mac-addr0: 00:80:2f:0a:ef:5c | | mac-addr1: 00:80:2f:0a:ef:5d | | gateway: 192.168.10.1 | | ip-addr0: 192.168.10.2 | | subnet0: 255.255.255.0 | | ip-addr1: 192.168.20.2 | | subnet1: 255.255.255.0 | | ip-addr2: 192.168.30.2 | | subnet2: 255.255.255.0 | | ip-addr3: 192.168.40.2 | | subnet3: 255.255.255.0 | | serial: F51382 | | FW Version: 6.0 | | FPGA Version: 35.0 | | FPGA git hash: 7d5d8db | | RFNoC capable: Yes | | | | Time sources: internal, external, gpsdo | | Clock sources: internal, external, gpsdo | | Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, ref_locked | | _ | |/ | | | RX Dboard: A | | | ID: TwinRX Rev A (0x0091) | | | Serial: 30C1130 | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: TwinRX RX0 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 93.0 step 1.0 dB | | | | Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz | | | | Connection Type: II | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Frontend: 1 | | | | Name: TwinRX RX1 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 93.0 step 1.0 dB | | | | Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz | | | | Connection Type: QQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _ | |/ | | | RX Dboard: B | | | ID: TwinRX Rev B (0x0093) | | | Serial: 30F4F7C | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: TwinRX RX0 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 93.0 step 1.0 dB | | | | Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz | | | | Connection Type: II | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Frontend: 1 | | | | Name: TwinRX RX1 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 93.0 step 1.0 dB | | | | Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz | | | | Connection Type: QQ | | | | Uses LO
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi again, On 11/22/18 6:45 PM, Marcus D. Leech via USRP-users wrote: Your radio block is set to a sample rate of 100e6, whereas the X310 uses a sample clock of 200e6. This may be why things are getting stuffed up. I've now tried 200 MHz for the radio block. Still getting the same error messages, and nothing in the FFT plot. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
On 11/22/2018 12:37 PM, Paul Boven via USRP-users wrote: Hi, On 22/11/2018 16:20, Marcus D. Leech via USRP-users wrote: On 11/22/2018 09:26 AM, Paul Boven via USRP-users wrote: A simple flowgraph (see attached image) using RFNOC:Radio, RFNOC:DDC and a QT GUI frequency, together with Device3, starts and runs but no data is produced. Instead, it generates a lot of error messages, "timeout on chan 0" and "ValueError: Bad CHDR or packet fragment". Check your ethernet MTUs and the packet sizes setup in your device3 block. I had this issue the other day, and the MTU on my ethernet interface had been set larger than it could actually support, resulting in truncated-by-the-interface packets. Thanks for the quick reply. The MTU of the network doesn't seem to be the issue. I've tried on two different network cards on my PC (both Intel 1G cards). The MTU of the Ethernet card is set to 9000, and this is known to work. uhd_usrp_probe chooses a packet size of 8000 bytes. When running tcpdump at the same time, I can see that packets of 8000 bytes are being received. It looks like it sends about 1 second of data in 8000 bytes packets from UDP port 49153 to port 33894, and then the remaining traffic is just 16 byte packets being exchanged between PC and USRP. Regards, Paul Boven. Your radio block is set to a sample rate of 100e6, whereas the X310 uses a sample clock of 200e6. This may be why things are getting stuffed up. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi, On 22/11/2018 16:20, Marcus D. Leech via USRP-users wrote: On 11/22/2018 09:26 AM, Paul Boven via USRP-users wrote: A simple flowgraph (see attached image) using RFNOC:Radio, RFNOC:DDC and a QT GUI frequency, together with Device3, starts and runs but no data is produced. Instead, it generates a lot of error messages, "timeout on chan 0" and "ValueError: Bad CHDR or packet fragment". Check your ethernet MTUs and the packet sizes setup in your device3 block. I had this issue the other day, and the MTU on my ethernet interface had been set larger than it could actually support, resulting in truncated-by-the-interface packets. Thanks for the quick reply. The MTU of the network doesn't seem to be the issue. I've tried on two different network cards on my PC (both Intel 1G cards). The MTU of the Ethernet card is set to 9000, and this is known to work. uhd_usrp_probe chooses a packet size of 8000 bytes. When running tcpdump at the same time, I can see that packets of 8000 bytes are being received. It looks like it sends about 1 second of data in 8000 bytes packets from UDP port 49153 to port 33894, and then the remaining traffic is just 16 byte packets being exchanged between PC and USRP. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
On 11/22/2018 09:26 AM, Paul Boven via USRP-users wrote: Hi everyone, After quite a bit of trial and error, I've managed to build a GNU Radio environment that includes RFNOC. My environment consists of: uhd-3.14, gnuradio-3.7.13.4, gr-ettus (master). uhd_usrp_probe shows that the X310 is detected, and has the expected RFNOC blocks on board (DmaFIFO_0, Radio_0, Radio_1, DDC_0/1, DUC_0/1). The USRP in question is an X310 with a TwinRX board. A simple flowgraph (see attached image) using RFNOC:Radio, RFNOC:DDC and a QT GUI frequency, together with Device3, starts and runs but no data is produced. Instead, it generates a lot of error messages, "timeout on chan 0" and "ValueError: Bad CHDR or packet fragment". Is my expectation correct that such a simple flowgraph should work? Is the fact that the TwinRX has two radios (one on I, one on Q) perhaps a problem here? Am I missing something obvious still? The way I built and installed the software is documented below, comments very much appreciated. 1) Remove anything gnuradio/uhd related. 2) Build UHD: git clone https://github.com/EttusResearch/uhd cd uhd/host mkdir build; cd build cmake -DENABLE_RFNOC=ON -DCMAKE_PREFIX=/usr .. make package sudo dpkg -i uhd_3.14.0.0-220-g97933b15_Ubuntu-18.04-x86_64.deb 3) Build GNU Radio: git clone --recursive https://github.com/gnuradio/gnuradio cd gnuradio checkout maint-3.7 mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr -DCPACK_DEBIAN_ARCHIVE_TYPE=gnutar .. make package sudo dpkg -i gnuradio_3.7.14.4_Ubuntu-18.04-x86_64.deb 4) Build gr-ettus: git clone https://github.com/EttusResearch/gr-ettus cd gr-ettus mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr .. make (manually created a package using PREFIX and fakeroot) dpkg -i gr-ettus*.deb The above results in a seemingly working gnuradio-companion which includes RFNOC blocks Regards, Paul Boven. Check your ethernet MTUs and the packet sizes setup in your device3 block. I had this issue the other day, and the MTU on my ethernet interface had been set larger than it could actually support, resulting in truncated-by-the-interface packets. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
