[Discuss OpenCPI] Re: Requesting help with fsk_modem_app on Ettus E310, OpenCPI version 2.4.0
On 2/17/22 11:30 AM, chris_at_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_at_lists.opencpi.org
> To unsubscribe send an email to discuss-leave_at_lists.opencpi.org
Received on Thu Feb 17 2022 - 18:44:23 CST
This archive was generated by hypermail 2.3.0
: Fri Jun 05 2026 - 08:45:25 CDT