Requesting help with fsk_modem_app on Ettus E310, OpenCPI version 2.4.0

C
chris@qelectronics.co.uk
Thu, Feb 17, 2022 4:30 PM

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

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
JK
James Kulp
Thu, Feb 17, 2022 6:44 PM

On 2/17/22 11:30 AM, chris@qelectronics.co.uk wrote:

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?

If the input data file is being accessed via network (presumably via the
NFS mount), the performance is dependent on the network capabilities.
The "file_read" component could be running on either the dev
host(server), or locally on the ARM.
If the former, the worker is locally reading the file and then sending
the data over a network connection to the next component.
If the latter, the worker is remotely reading (via NFS), and then
forwarding the data locally to the next component.
Finally, if the latter, you could copy the input file to make it a local
file so that the file_read running on the ARM CPU is reading locally.

You can specify where the file_read worker is actually executing by
using the --platform option (-P) to ocpirun.

If underrun is really the problem, this third case should improve it.

Thanks in advance,

Chris Cotton


discuss mailing list -- discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.org

On 2/17/22 11:30 AM, chris@qelectronics.co.uk wrote: > > 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? > If the input data file is being accessed via network (presumably via the NFS mount), the performance is dependent on the network capabilities. The "file_read" component could be running on either the dev host(server), or locally on the ARM. If the former, the worker is locally reading the file and then sending the data over a network connection to the next component. If the latter, the worker is remotely reading (via NFS), and then forwarding the data locally to the next component. Finally, if the latter, you could copy the input file to make it a local file so that the file_read running on the ARM CPU is reading locally. You can specify where the file_read worker is actually executing by using the --platform option (-P) to ocpirun. If underrun is really the problem, this third case should improve it. > Thanks in advance, > > Chris Cotton > > > _______________________________________________ > discuss mailing list -- discuss@lists.opencpi.org > To unsubscribe send an email to discuss-leave@lists.opencpi.org
C
chris@qelectronics.co.uk
Fri, Feb 18, 2022 8:31 PM

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>

  1. 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.

  1. 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

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
C
chris@qelectronics.co.uk
Fri, Feb 18, 2022 8:38 PM

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

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
JK
James Kulp
Fri, Feb 18, 2022 8:41 PM

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>