Hi, 
Guest
Pic
Sign In

usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Firmware images for X310-RFNOC?

PB
Paul Boven
Thu, Nov 22, 2018 2:26 PM

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.

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.
Attached image
MD
Marcus D. Leech
Thu, Nov 22, 2018 3:20 PM

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.

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.
PB
Paul Boven
Thu, Nov 22, 2018 5:37 PM

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.

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.
MD
Marcus D. Leech
Thu, Nov 22, 2018 5:45 PM

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.

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.
PB
Paul Boven
Sun, Nov 25, 2018 12:22 PM

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.

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.
MD
Marcus D. Leech
Sun, Nov 25, 2018 6:47 PM

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: 0xF1F0D00000000000)
[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: 0x12AD100000000001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.0 step 0.0 Hz
|  |  |  |  Connection Type: QQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Codec: B
|  |  |  |  Name: ads62p48
|  |  |  |  Gain range digital: 0.0 to 6.0 step 0.5 dB
|  |    _____________________________________________________
|  |    /
|  |  |      TX Dboard: A
|  |  |  Serial: 30C755A
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Frontend: 0
|  |  |  |  Name: Unknown (0xffff) - 0
|  |  |  |  Antennas:
|  |  |  |  Sensors:
|  |  |  |  Freq range: 0.000 to 0.000 MHz
|  |  |  |  Gain Elements: None
|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|  |  |  |  Connection Type: IQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Codec: A
|  |  |  |  Name: ad9146
|  |  |  |  Gain Elements: None
|  |    _____________________________________________________
|  |    /
|  |  |      TX Dboard: B
|  |  |  ID: Unknown (0x0092)
|  |  |  Serial: 30F716C
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Frontend: 0
|  |  |  |  Name: Unknown (0x0092) - 0
|  |  |  |  Antennas:
|  |  |  |  Sensors:
|  |  |  |  Freq range: 0.000 to 0.000 MHz
|  |  |  |  Gain Elements: None
|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|  |  |  |  Connection Type: IQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Codec: B
|  |  |  |  Name: ad9146
|  |  |  |  Gain Elements: None
|  |    _____________________________________________________
|  |    /
|  |  |      RFNoC blocks on this device:
|  |  |
|  |  |  * DmaFIFO_0
|  |  |  * Radio_0
|  |  |  * Radio_1
|  |  |  * DDC_0
|  |  |  * DDC_1
|  |  |  * DUC_0
|  |  |  * DUC_1

[mleech@lab ~]$

With matching gr-ettus, gr-uhd, etc.

I'm running gnuradio:

3.7.12.0

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: 0xF1F0D00000000000) [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: 0x12AD100000000001) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000) [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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.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: 80000000.0 to 80000000.0 step 0.0 Hz | | | | Connection Type: QQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: B | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _____________________________________________________ | | / | | | TX Dboard: A | | | Serial: 30C755A | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: Unknown (0xffff) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: A | | | | Name: ad9146 | | | | Gain Elements: None | | _____________________________________________________ | | / | | | TX Dboard: B | | | ID: Unknown (0x0092) | | | Serial: 30F716C | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: Unknown (0x0092) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: B | | | | Name: ad9146 | | | | Gain Elements: None | | _____________________________________________________ | | / | | | RFNoC blocks on this device: | | | | | | * DmaFIFO_0 | | | * Radio_0 | | | * Radio_1 | | | * DDC_0 | | | * DDC_1 | | | * DUC_0 | | | * DUC_1 [mleech@lab ~]$ With matching gr-ettus, gr-uhd, etc. I'm running gnuradio: 3.7.12.0
rfnoc_test.grc (12.91 KB)
PB
Paul Boven
Mon, Nov 26, 2018 11:03 PM

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.

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.
MD
Marcus D. Leech
Tue, Nov 27, 2018 12:39 AM

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.

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.
Next page
Empathy v1.0   2026 ©emwd.com
Documentation