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">
<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


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