Hi All,

I have attempted to run fsk_modem_app with some adjustments to the setup through reading various OpenCPI documentation.

fsk_modem_app.xml runs without errors but the received loopback signal image file isn't readable by using the eog fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin command.

The FSK_App_Getting_Started_Guide_E31x document on the final page has an example image of a spectrum analyzer with the bandwidth of the signal being about 500 MHz. My signal bandwidth is about 200 MHz and falls off a lot sharper than the example signal. This points to the transmitted signal being an issue.

From experience with Ettus SDRs the hardware hasn't been defective so it's assumed the software is the issue.

Network mode is the used mode as it is used in guides and forum posts more often. Listed content is not necessarily in order of 'discovery'.

The general format of the information below is as follows:

<Location of presented information (title/section, forum post etc.)>

<Information from the section/forum post/etc.>

Running a Test Application

FSK_App_Getting_Started_E31x, Section 9

Suggests running some commands in the terminal for more documentation.

In terminal, in ocpi.osps.e3xx/applications/FSK directory:

export OCPI_CDK_DIR=/home/<user>/Documents/opencpi/cdk

make show

Instructions then appear in terminal.

Suggests four steps for executing a test application:

1. Build ACI and/or input test data (development system)

2. Setup the OCPI_LIBRARY_PATH (remote system)

3. Execution of application (remote system)

4. Verification of output data (development system)

Build ACI

According to make show described above this builds input data, ACI executable and filter coeffecients.

cd into /opencpi/projects/osps/ocpi.osp.e3xx/applications/fsk_dig_radio_ctrlr

ocpidev build --rcc-platform xilinx19_2_aarch32

I execute this command and target-xilinx19_2_aarch32 folder is created with <fsk_dig_radio_ctrlr, fsk_dig_radio_ctrlr.o, fsk_dig_radio_ctrlr.o.deps>

FSK_app, Section 4.4

ocpidev build --rcc-platform xilinx19_2_aarch32 (xilinx13_3 used in the example). As above.

This is just a comment that the build command is also expressed in this section of FSK_app.

"discuss Digest, Vol 34, Issue 3", Forum Post, Adam

Adam suggests that the fsk_modem needs to be build in the e3xx project not the assets project.

SD Card OpenCPI environment for E310, Forum Post, Aaron

Aaron mentions HDL assembly for e31x needs to be built. This needs to be done in projects/osps/ocpi.osp.e3xx/hdl/assemblies/fsk_modem folder using:

ocpidev build --hdl-platform e31x

I am unsure what this does but executing the command doesn't return any errors.

OCPI_LIBRARY_PATH

If the OCPI_LIBRARY_PATH isn't set correctly there is usually an error so it's assumed that the library paths are correct when I'm running the test application.

Path used is

export OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts:/mnt/ocpi_core/artifacts:/mnt/ocpi_e31x/artifacts:/mnt/ocpi_assets/hdl/assemblies/fsk_modem:/mnt/ocpi_core/hdl/assemblies/fsk_modem:/mnt/ocpi_e31x/hdl/assemblies/fsk_modem/

which produces no errors with the ocpirun -x -t 15 fsk_modem_app.xml command.

Initial questions: 

What should OCPI_LIBRARY_PATH be set to? Does each platform have a suggested OCPI_LIBRARY_PATH?

Does it matter where the OCPI_LIBRARY_PATH command is ran? Only seems to matter if relative paths are used.

Some doc. examples use export OCPI_LIBRARY_PATH, some use just use OCPI_LIBRARY_PATH (FSK_app, Section 5.6). Assumption is that 'export' is required, recommended paths are just stated as the path not the actual command.

FSK_App_E31x, Section 5.4

Mentions going to OpenCPI Application Development Guide for information about OCPI_LIBRARY_PATH.

OpenCPI Application Development Guide, Section 2, Page 8

Last parapgraph has some comments about OPCI_LIBRARY_PATH that are critical. Too much information to copy to here. It does mention that the order of the OCPI_LIBRARY_PATH list is important.

FSK_Dig_Radio_Ctrlr, Section 3.1

If using a platform with multiple slots available, the intended slot-specific bitstream must occur first in the OCPI_LIBRARY_PATH. This similar to explaination in OpenCPI Application Development Guide, Section 2, Page 8.

make show instructions from FSK application directory suggested OCPI_LIBRARY_PATH(s):

Test 1:

export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts

Test 2:

export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.dc_offset_iq_imbalance_mixer_cic_dec_rp_cordic_fir_real_e31x_cfg_1rx_0tx_mode_2_cmos_cnt_1rx_0tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH

Test 3:

export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.mfsk2_zp16_fir_real_phase_to_amp_cordic_cic_int_e31x_cfg_0rx_1tx_mode_2_cmos_cnt_0rx_1tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH

Test 4:

export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.fsk_modem_e31x_cfg_1rx_1tx_mode_2_cmos_cnt_1rx_1tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH

I assume :$OCPI_LIBRARY_PATH is done for the slot-specific bitstream reasoning mentioned in FSK_Dig_Radio_Ctrlr, Section 3.1.

"discuss Digest, Vol 34, Issue 3", Forum Post, Adam

For the Zed with fmcomms2 he used:

export OCPI_LIBRARY_PATH=/mnt/ocpi_assets/hdl/assemblies/fsk_modem:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts

but suggested to use for the e310:

export OCPI_LIBRARY_PATH=/mnt/ocpi_e31x/hdl/assemblies/fsk_modem:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts

Trying both exports individually end with an error after doing ocpirun -v -x -t 15 fsk_modem_app.xml:

Exiting for exception: No acceptable implementations found in any libraries for "ocpi.platform.drc".  Use log level 8 for more detail.

FSK_App_Getting_Started_Guide, Section 7.2.1

This section suggests using:

$ export OCPI_LIBRARY_PATH=/mnt/net/cdk/xilinx19_2_aarch32/artifacts:/mnt/ocpi_assets/applications/FSK/../../hdl/assemblies/fsk_modem:/mnt/ocpi_assets/applications/FSK/../../artifacts

This doesn't really make sense, why not just use /mnt/ocpi_assets/artifacts and /mnt/ocpi_assets/hdl/assemblies/fsk_modem?

Adding :/mnt/net/cdk/xilinx19_2_aarch32/artifacts to my library path doesn't change the result of the ocpirun command.

FSK_Dig_Radio_Ctrlr, Section 3.1

The following assets are built and their build artifacts (FPGA bitstream file/shared object file) are contained within the directory list of the OCPI_LIBRARY_PATH environment variable.

–fsk_filerw assembly

–fsk_modem assembly (from assets project, or same assembly XML w/ another BSP-specific container XML in another BSP-specific project)

–file_read.rcc (from core project)

–mfsk_mapper.rcc–zero_pad.rcc

–Baudtracking_simple.rcc

–real_digitizer.rcc

–file_write.rcc (from core project)

OpenCPI Application Development Guide, Section 11

"By limiting the artifacts available (accessed via the OCPI_LIBRARY_PATH environment variable setting), the system requirements are reduced to the minimum."

FSK_App_E31x, Section 7 and Section 7.1

This section has a list of artifacts required for the e31x application.

Also mentions:

"Each required RCC worker corresponds to a required target-<shortened-rcc-platform>/<worker>.so artifact. All required HDL workers (together) correspond to a single required <assembly><platform><platform-config><container>.bitz artifact."

Does that mean that for each platform only 2 OCPI_LIBRARY_PATHs need to be specified, one to target-<shortened-rcc-platform>/<worker>.so and one to <assembly><platform><platform-config><container>.bitz?

ie.

/mnt/ocpi_e31x/applications/fsk_dig_radio_ctrlr/target-xilinx19_2_aarch32

and

/mnt/ocpi_e31x/exports/artifacts

Running just these two OCPI_LIBRARY_PATHs gives below error:

Available containers are:  0: PL:0 [model: hdl os:  platform: e31x], 1: rcc0 [model: rcc os: linux platform: xilinx19_2_aarch32]

Exiting for exception: No acceptable implementations found in any libraries for "ocpi.core.file_read".  Use log level 8 for more detail.

OpenCPI Arguments

FSK_App_E31x, Section 5.3

Look in this section for arguments for the FSK application. This sets the Ettus internal parameters (ie. gain, RX/TX port used).

FSK_app, Section 5.5

Arguments are given in this section for the FMCOMMS2 and the FMCOMMS3. These could be used to compare with the Ettus arguments in FSK_App_E31x, Section 5.3.

fsk_dig_radio_ctrl_demo_txrx_sma_loopback_xilinx13_4_e31x.sh

In opencpi/projects/osps/ocpi.osp.e3xx/applications/fsk_dig_radio_ctrlr/scripts/fsk_dig_radio_ctrl_demo_txrx_sma_loopback_xilinx13_4_e31x.sh there is a command:

OCPI_HDL_SIMULATORS= \

OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts/:/mnt/ocpi_core/artifacts/:/mnt/osps/ocpi.osp.e3xx/artifacts \

./target-xilinx13_4/fsk_dig_radio_ctrlr \

--rx-data-stream-ID SMA_RX2A \

--rx-baud-rate 5699 \

--rx-tuning-freq-MHz 2450 \

--rx-gain-mode manual \

--rx-gain-dB 12 \

--tolerance-rx-tuning-freq-MHz 0.1 \

--tolerance-rx-gain-dB 1 \

--tx-data-stream-ID SMA_TRXA \

--tx-baud-rate 5699 \

--tx-tuning-freq-MHz 2450 \

--tx-gain-mode manual \

--tx-gain-dB -28 \

--tolerance-tx-tuning-freq-MHz 0.1 \

--tolerance-tx-gain-dB 1 -d\

fsk_dig_radio_ctrlr_e31x_txrx.xml

Executing above (with -l 8 and xilinx13_4 = xilinx19_2_aarch32) gives the error:

OCPI( 8:951.0262):    Rejected: worker name is "dig_radio_ctrlr_fmcomms_2_3-1.rcc", while requested worker name is "dig_radio_ctrlr_e31x"

OCPI( 8:951.0262): Error Exception: No acceptable implementations found in any libraries for "ocpi.core.dig_radio_ctrlr".  Use log level 8 for more detail.

Exiting for exception: No acceptable implementations found in any libraries for "ocpi.core.dig_radio_ctrlr".  Use log level 8 for more detail.

fsk_dig_radio_ctrl_demo_tx_xilinx13_4_e31x.sh

Same path as above with different script.

OCPI_HDL_SIMULATORS= \

OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts/:/mnt/ocpi_core/artifacts/:/mnt/osps/ocpi.osp.e3xx/artifacts \

./target-xilinx13_4/fsk_dig_radio_ctrlr \

--tx-data-stream-ID SMA_TRXA \

--tx-baud-rate 5699 \

--tx-tuning-freq-MHz 2450 \

--tx-gain-mode manual \

--tx-gain-dB -28 \

--tolerance-tx-tuning-freq-MHz 0.1 \

--tolerance-tx-gain-dB 1 -d\

fsk_dig_radio_ctrlr_e31x_tx.xml

I didn't run this as the former script seemed more complete.

Executing Application

FSK_app, Section 5.2

This describes how to physically setup the Ettus and what the different tests do. The txrx test mentions that the gain setting assumes that an RF splitter will be used. RF splitter was used for my tests so gain should be correct.

The input file has a 0xFACE prepended byte pattern. Running the .xml mentions that it detects this value. It also mentions "Since this test is executed for a duration, rather than total image recognition, it is not uncommon that the output file will be larger than the actual size of the input image". This has also been seen in practice.

SD Card OpenCPI environment for E310, Forum Post, Aaron

The FSK application directory has been replaced with fsk_dig_radio_controller. We are in the processes of removing legacy applications. To run the fsk_modem_app.xml the e31x and xilinx19_2_aarch32

platform depend on ocpi.core, ocpi.assets, ocpi.platform, and ocpi.osp.e31x projects.

FSK_App_Getting_Started_Guide, Section 7.3

$ ./target-xilinx13_3/FSK txrx

Does ./target-xilinx19_2_aarch32/fsk_dig_radio_ctrlr txrx need to be called? Or something similar? Why is there a method of using the .target directory and a method for using the .xml for running the application?

"discuss Digest, Vol 34, Issue 3", Forum Post, Adam

ocpirun -v -d -x -t 15 fsk_modem_app.xml

which runs the application fine.

Output Verification

cd assets/applications/fsk_dig_radio_ctrlr

eog fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin

Note that the fsk_modem_app.xml writes to fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin. Shouldn't it write to fsk_dig_radio_ctrlr_e31x_txrx.bin or equivalent?

Known Issues

FSK_Dig_Radio_Ctrlr, Section 5.1  and FSK_app, Section 5.8

"The demodulation algorithm currently suffers from limited carrier recovery ability which can cause the output image to be corrupted or non-existent when using the txrx mode. If using an SMA loopback for txrx mode on a RF transceiver where the RX and TX data stream’s LOs are sourced by the same clock (which is the case on FMCOMMS2/3), carrier recovery is not expected to be an issue."

Note that the Ettus RX LO and TX LO are different clocks so this is potentially an issue.

FSK_App_E31x, Section 5.6

"The rx and tx modes suffer from limited carrier recovery ability. The requested center frequency may need to be adjusted to a value other than the exact expected nominal value."

"Sometimes the radio can get into an unwanted state. If unusual results are seen, run ocpihdl unload and rerun the application."

Note that ocpihdl unload doesn't work and returns the following error:

fpga_manager fpga0: Invalid bitstream, could not find a sync word. Bitstream must be a byte swapped .bin file

fpga_manager fpga0: Error preparing FPGA for writing

Hardware limitations

FSK_Dig_Radio_Ctrlr, Section 2.1

Doesn't explicitly mention xilinx19_2_aarch32 or e31x are supported hardware configurations but the last dot point suggests it may work.

USRP E310 Datasheet, Features

Up to 10 MS/s sample data transfer rate to ARM processor. This is between the PS-Dual Core ARM and the PL-FPGA.

Is this limiting the data rate of the transmitted signal?

Ethernet limitations

Workstation PC ethernet port only capable of 1 Gbps. Shouldn't be a problem as the signals bandwidth is less than 5 MHz.

Closeout

Is it possible to remove obsolete documents and update supporting documentation? Information about OCPI_LIBRARY_PATH and the arguments for .target-<rss-platform> appear to be scattered over several documents. Is it possible to make the requirements for OCPI_LIBRARY_PATH clearer?

Is it worth removing obsolete information/documents? Having obsolete information can make troubleshooting confusing with so much conflicting or incorrect information.

I understand it's an open source project so my assumption would be this isn't a full time commitment from contributors. Plus documentation is always a boring task.

All documentation was sourced from https://opencpi.gitlab.io/releases/latest/ if that helps with my comments/people reading this post.

I hope someone else out there potentially finds this useful. Apologise for the large post.

I should clarify what I have done so far:

RF Splitter used between TX and RX. One signal going to spectrum analyzer. 30dB attenuator at RX. 20 dB attenuator into spectrum analyzer.

While in the opencpi/projects/osps/ocpi.osp.e3xx/applications/fsk_dig_radio_ctrlr folder (development host):

ocpidev build --rcc-platform xilinx19_2_aarch32

ocpidev build --hdl-platform e31x

On remote system:

export OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts:/mnt/ocpi_core/artifacts:/mnt/ocpi_e31x/artifacts:/mnt/ocpi_assets/hdl/assemblies/fsk_modem:/mnt/ocpi_core/hdl/assemblies/fsk_modem:/mnt/ocpi_e31x/hdl/assemblies/fsk_modem/

Then in osps_e31x/applications/fsk_dig_radio_ctrlr:

ocpirun -v -x -t 15 fsk_modem_app.xml

I understand. It is a rather large post too. Thanks for the heads up.