AD9361 ADC/DAC Test Applications
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
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@gmail.com
Date: Fri, Apr 3, 2020 at 12:18 PM
Subject: [Discuss OpenCPI] AD9361 ADC/DAC Test Applications
To: discuss@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
On Fri, Apr 3, 2020 at 1:54 PM Davis Hoover dhoover@geontech.com wrote:
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?
I am setting them according to a known good set for this radio from a
different application that was run on it.
Regardless, my confusion stems from why both the ADC and DAC tests which
use the PRBS show 30% BER, but the DAC tests which do not use the PRBS but
still use the TX and RX paths show 0% BER.
My thought is that if the RX-only path doesn't work, why would the TX path?
Sorry for the confusion. Still perplexed.
Thanks,
Brian
No worries. It may be helpful to run the target-*/calculate...
executable on the .out files for both the ADC and DAC tests to observe
whether the data looks like reasonable LFSR data. Check the arguments
on that executable, there should be an option for printing out the
0s/1s which make LFSR behavior obvious. It's also useful to parse the
output for, e.g. "1 of which had bit errors"
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Fri, Apr 3, 2020 at 2:08 PM
Subject: Re: [Discuss OpenCPI] Fwd: AD9361 ADC/DAC Test Applications
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Fri, Apr 3, 2020 at 1:54 PM Davis Hoover dhoover@geontech.com wrote:
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?
I am setting them according to a known good set for this radio from a
different application that was run on it.
Regardless, my confusion stems from why both the ADC and DAC tests
which use the PRBS show 30% BER, but the DAC tests which do not use
the PRBS but still use the TX and RX paths show 0% BER.
My thought is that if the RX-only path doesn't work, why would the TX path?
Sorry for the confusion. Still perplexed.
Thanks,
Brian
On Fri, Apr 3, 2020 at 2:17 PM Davis Hoover dhoover@geontech.com wrote:
No worries. It may be helpful to run the target-*/calculate...
executable on the .out files for both the ADC and DAC tests to observe
whether the data looks like reasonable LFSR data. Check the arguments
on that executable, there should be an option for printing out the
0s/1s which make LFSR behavior obvious. It's also useful to parse the
output for, e.g. "1 of which had bit errors"
Just for clarification, do you mean PRBS or LFSR? It seems on the DAC side
there is a mode for sending LFSR data into the device, and reading it back
out versus the PRBS which is internally generated to the AD9361.
Which do you mean for this?
Thanks,
Brian
The AD9361 BIST PRBS mode utilizes an on-AD9361 LFSR. The OpenCPI
applications for both the AD9361 BIST PRBS, which verifies the ADC
interface, and the AD9361 BIST loopback, which verifies the DAC and ADC
interface, each utilize the same bitwise LFSR verification on the .out
file(s).
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Fri, Apr 3, 2020 at 2:34 PM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: AD9361 ADC/DAC Test Applications
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Fri, Apr 3, 2020 at 2:17 PM Davis Hoover dhoover@geontech.com wrote:
No worries. It may be helpful to run the target-*/calculate...
executable on the .out files for both the ADC and DAC tests to observe
whether the data looks like reasonable LFSR data. Check the arguments
on that executable, there should be an option for printing out the
0s/1s which make LFSR behavior obvious. It's also useful to parse the
output for, e.g. "1 of which had bit errors"
Just for clarification, do you mean PRBS or LFSR? It seems on the DAC side
there is a mode for sending LFSR data into the device, and reading it back
out versus the PRBS which is internally generated to the AD9361.
Which do you mean for this?
Thanks,
Brian
On Fri, Apr 3, 2020 at 2:45 PM Davis Hoover dhoover@geontech.com wrote:
The AD9361 BIST PRBS mode utilizes an on-AD9361 LFSR. The OpenCPI
applications for both the AD9361 BIST PRBS, which verifies the ADC
interface, and the AD9361 BIST loopback, which verifies the DAC and ADC
interface, each utilize the same bitwise LFSR verification on the .out
file(s).
So this is where the confusion comes from. There is a mode which runs such
that the data_src is set to 'mode=lfsr', the spec is here:
The script is here:
And it's called here:
But the PRBS test is called here:
So if I comment out the PRBS test, and only run the loopback test - things
work spectacularly great - 0% BER.
But the PRBS test runs with 30% BER.
I suppose I should have clarified specifically I am using the loopback test
when it shows 0% BER.
Does this help shed any light on anything, especially regarding my
confusion? I would have thought the loopback test would fail miserably if
the PRBS test also does. But this is not the case.
Thanks,
Brian
Okay I'm with you now. Your confusion is definitely warranted. Something's
gotta be different between the PRBS and loopback... May be worth trying to
manually run each PRBS/loopback test by running ocpirun -p on the command
line and using the calculate BER executable on the output files. Double
check which assembly is loaded in each case to ensure it's not loading a
different one - ocpihdl get should show an assembly UUID.
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Fri, Apr 3, 2020 at 3:08 PM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: AD9361 ADC/DAC Test Applications
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Fri, Apr 3, 2020 at 2:45 PM Davis Hoover dhoover@geontech.com wrote:
The AD9361 BIST PRBS mode utilizes an on-AD9361 LFSR. The OpenCPI
applications for both the AD9361 BIST PRBS, which verifies the ADC
interface, and the AD9361 BIST loopback, which verifies the DAC and ADC
interface, each utilize the same bitwise LFSR verification on the .out
file(s).
So this is where the confusion comes from. There is a mode which runs such
that the data_src is set to 'mode=lfsr', the spec is here:
The script is here:
And it's called here:
But the PRBS test is called here:
So if I comment out the PRBS test, and only run the loopback test - things
work spectacularly great - 0% BER.
But the PRBS test runs with 30% BER.
I suppose I should have clarified specifically I am using the loopback test
when it shows 0% BER.
Does this help shed any light on anything, especially regarding my
confusion? I would have thought the loopback test would fail miserably if
the PRBS test also does. But this is not the case.
Thanks,
Brian