These tests use the ad9361_config_proxy.rcc which require setting the
delays to a known-good value. This has been exemplified in a separate BSP
project, which does work correctly:
https://gitlab.com/opencpi/osp/ocpi.osp.e3xx/-/blob/develop/applications/ad9361_adc_test/scripts/run_app.sh#L97
Are these values being set correctly for your platform?
---------- Forwarded message ---------
From: Brian Padalino <bpadalino_at_gmail.com>
Date: Fri, Apr 3, 2020 at 12:18 PM
Subject: [Discuss OpenCPI] AD9361 ADC/DAC Test Applications
To: <discuss_at_lists.opencpi.org>
I am porting the AD9361 ADC/DAC test applications to my platform and I am
getting some very confusing results.
At first I was only running the ADC test since I know the DAC test uses the
ADC lines in a local loopback mode. Without the ADC lines figured out, I
thought it was very silly to try the DAC test. The ADC test runs the PRBS
and gives me around 30% BER across all samplerates and timings. I looked
at the saved off samples to ensure the device is being put into the correct
mode. I did not check the values against a known sequence or anything.
I then decided to look at the DAC test and saw there is are a few tests:
all 0x0, all 0xF, all 0x5, all 0xA, LFSR. I figured I would just try
running these tests to see if I could deduce any behavior for the paths.
To my surprise, the BER came back at 0% for all these tests. The PRBS
test, on the other hand, still comes back around 30% BER.
This has me very confused. I have to assume that if I sent LFSR data into
the TX side, and it comes back perfectly on the RX side, then the interface
timing is good, right? I don't understand why the PRBS test fails with
around 30% errors.
Has anyone else run this test on a different platform lately? I saw some
documents alluding to an Ettus E3xx test. Does it run perfectly on that?
I'm scratching my head on the different BER values for the tests. Any
insight would be appreciated.
Thanks,
Brian
Received on Fri Apr 03 2020 - 17:53:30 CDT