Hello,

Apologies in advance that this is quite a long first post.

I am new to using OpenCPI, and have just created a development environment based on Ubuntu 18.04.6 LTS, Xilinx Vitis/Vivado 19.2 and OpenCPI Release 2.4.0.  The target system is an Ettus USRP E310.

Following the ‘OpenCPI Installation Guide’ (v2.4.0), the videos provided on YouTube and advice from elsewhere on this forum I believe that I have managed to build everything that is required, and have created a working SD card from which I can boot the USRP E310 successfully.  I also added an NFS share to the Ubuntu development PC.

After opening an SSH session to the E310, I edited the script ‘default_mynetsetup.sh’, saved it as ‘/run/media/mmcblk0p1/opencpi/mynetsetup.sh’, and executed it to set the the E310 system up in network mode.  The E310 appears to have initialised correctly, and I can access the NFS share to the Ubuntu host PC.

As a first test of the E310 platform, I wanted to run some of the test applications that were provided within the osps/ocpi.osp.e3xx project.  Following comments that I’ve read in the forums, I decided to leave the FSK application alone for now and instead started with the ‘fsk_modem_app’ from the directory ‘fsk_dig_radio_ctrlr’.

I connected a loop-back RF cable between the TRX-B and RX2-B ports of the E310, browsed to the location of the application on the NFS share, and ran it using the command:

ocpirun -v -d -t 15 fsk_modem_app.xml

The command runs and completes successfully, however in repeated runs I have never received a complete / un-corrupted copy of the OpenCPI logo in the returned data file (displayed on the Ubuntu host using the script provided in the fsk_dig_radio_ctrlr/scripts directory).

An example of the output I’m getting is attached to this post.

Looking at the debug information returned by the application on the SSH terminal, I believe that the underlying cause is probably buffer under-runs, as implied by the output:
Property 849: drc.tx_qdac0.samp_count_before_first_underrun = "60060937"
Property 850: drc.tx_qdac0.num_underruns = "611818"
in the SSH output provided by the application after it has completed the RF operations.

Is there anyone here who could please provide some advice on what I should be changing / altering to get the application working correctly?

Thanks in advance,

Chris Cotton

Hi James,

Thanks for the reply.  I’ve done a bit more debugging, and discovered the following:

1. Moving the test image to the Ettus E310 (I actually copied the entire fsk_dig_radio_ctrlr directory from the OpenCPI developement PC over to /home/root/fsk_dig_radio_ctrlr and ran the application from there) did not appear to have any impact on the number of reported underruns.  However, adding a buffer between the file_read and the mfsk_mapper did appear to resolve the issue, both with the image file stored locally on the Ettus and when accessing the image over the NFS share.  Code snippet provided below:

<Instance Component="ocpi.core.file_read">
<Property Name="fileName" Value="/dev/shm/opencpi.jpeg"/>
<Property Name="messageSize" Value="128"/>
<Property Name="messagesInFile" Value="false"/>
<Property Name="opcode" Value="1"/>
<Property Name="granularity" Value="1"/>
</Instance>
<Instance Component="ocpi.assets.comms_comps.mfsk_mapper" Connect="zero_pad">
<Property Name="symbols" Value="-32768,32767"/>
</Instance>
<Connection>
<Port Instance="file_read" Name="out"/>
<Port Instance="mfsk_mapper" Name="in" Buffercount="4"/>
</Connection>

2. The command I was using in my first post was flawed.  Comparing the input and output data, I realized that the program needs to run for a significantly longer time for the entire file to be transmitted / received at the data rate used by the fsk_modem_app.xml application.

Changing the command to:
ocpirun -v -d -t 75 fsk_modem_app.xml
gives the program sufficient time to receive the entire test image.  75 seconds is pretty much the bare minimum required to get the whole file transferred.

3. The test program does not appear to stop receiving data until the timer expires, resulting in ‘junk’ being stored in the output file after the end of the transmitted image.

Unfortunately, I am still getting errors in the received image file.  Analyzing the outgoing image (idata/opencpi.jpeg) and the received file (fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin) with a hex editor and diff tools, I can see that there are typically between 10 and 20 errors - usually single bit errors - scattered throughout the received file in any given run.

I have also done some testing with a 72kB bitmap image (a scaled-down copy of the provided JPEG test image), to which I have attached a suitable header (including some 0x55 0x55 preamble and the 0xFACE sync word, copied from the provided test image).  With the bitmap, it is easier to see the errors, as they usually appear as single corrupted pixels in the output (see attached image).

Is this to be expected with the limitations of the demonstration fsk_modem_app and the Ettus E310, or is there a simple way to improve performance?  Could the bit-errors be hardware related?

Thanks,

Chris Cotton

It appears that bitmap images do not attach correctly in this forum; I have converted the output to JPG so that it can be uploaded here.

Thanks,

Chris Cotton

Good digging....

I'll let others chiime in with their e31x experiences.

I regularly run this on a pluto (same hardware, zynq+ad9361, although smaller FPGA/zynq), and it doesn't require the extra buffering and has no bit errors with a coax loopback.

But I usually use server mode, not network (NFS) mode.

BTW, using "--duration" rather than "--timeout" means it runs for that amount of time and "succeeds", rather than --timeout, which "fails" when the time expires.

I use --duration 15 or 20 on pluto to get the image, which always has "extra stuff" at the end. This app has no encoding for "end".

On 2/18/22 3:31 PM, chris@qelectronics.co.uk wrote:

Hi James,

Thanks for the reply. I’ve done a bit more debugging, and discovered the following:

1) Moving the test image to the Ettus E310 (I actually copied the entire fsk_dig_radio_ctrlr directory from the OpenCPI developement PC over to /home/root/fsk_dig_radio_ctrlr and ran the application from there) did not appear to have any impact on the number of reported underruns. However, adding a buffer between the file_read and the mfsk_mapper did appear to resolve the issue, both with the image file stored locally on the Ettus and when accessing the image over the NFS share. Code snippet provided below:

<Instance Component="ocpi.core.file_read"><br></br> <Property Name="fileName" Value="/dev/shm/opencpi.jpeg"/><br></br> <Property Name="messageSize" Value="128"/><br></br> <Property Name="messagesInFile" Value="false"/><br></br> <Property Name="opcode" Value="1"/><br></br> <Property Name="granularity" Value="1"/><br></br> </Instance><br></br> <Instance Component="ocpi.assets.comms_comps.mfsk_mapper" Connect="zero_pad"><br></br> <Property Name="symbols" Value="-32768,32767"/><br></br> </Instance><br></br> <Connection><br></br> <Port Instance="file_read" Name="out"/><br></br> <Port Instance="mfsk_mapper" Name="in" Buffercount="4"/><br></br> </Connection><br></br>

2) The command I was using in my first post was flawed. Comparing the input and output data, I realized that the program needs to run for a significantly longer time for the entire file to be transmitted / received at the data rate used by the fsk_modem_app.xml application.

Changing the command to:
ocpirun -v -d -t 75 fsk_modem_app.xml
gives the program sufficient time to receive the entire test image. 75 seconds is pretty much the bare minimum required to get the whole file transferred.

3) The test program does not appear to stop receiving data until the timer expires, resulting in ‘junk’ being stored in the output file after the end of the transmitted image.

Unfortunately, I am still getting errors in the received image file. Analyzing the outgoing image (idata/opencpi.jpeg) and the received file (fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin) with a hex editor and diff tools, I can see that there are typically between 10 and 20 errors - usually single bit errors - scattered throughout the received file in any given run.

I have also done some testing with a 72kB bitmap image (a scaled-down copy of the provided JPEG test image), to which I have attached a suitable header (including some 0x55 0x55 preamble and the 0xFACE sync word, copied from the provided test image). With the bitmap, it is easier to see the errors, as they usually appear as single corrupted pixels in the output (see attached image).

Is this to be expected with the limitations of the demonstration fsk_modem_app and the Ettus E310, or is there a simple way to improve performance? Could the bit-errors be hardware related?

Thanks,

Chris Cotton

<pre class="moz-quote-pre" wrap="">_______________________________________________
discuss mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.opencpi.org">discuss@lists.opencpi.org</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:discuss-leave@lists.opencpi.org">discuss-leave@lists.opencpi.org</a>