ADALM Pluto as dual channel SDR

[fasleitung3]

Recently, we had a discussion about the Kraken SDR and its performance,
in particular with respect to phase stability for interferometry
experiments. For an interferometer with just one baseline a dual
receiver, however, is sufficient. There are a number of options such as
the Ettus Research range of products (and some clones of these), the
Lime SDR (however, no longer available), and probably a few more. I
briefly want to report on using the ADALM Pluto for that purpose. While
the ADALM Pluto is designed as a single channel unit, the internal
tranceiver chip is actually dual channel. In the more recent hardware
revisions of this product (Rev C onwards) this second channel is made
available via U.fl conncetors on the board.
I was interested in using this for interferometry. I first test was
done by connecting a dual channel signal generator to the inputs and
varying the phase between the two input signals. This worked perfectly
well. In a stability test over serveral hours, no phase drift was
observed. Even disconnecting the ADALM Pluto completely from power and
turning it on again resulted in the same phase relationship as before.
This encouraged me to do a quick and dirty experiment with two "coffee
can" antennas each with an LNA to observe fringes from the sun.
I have attached a plot of the fringe pattern. The fringe time is about
4 minutes. The spikes are due to RFI, and the traces are from the two
I1/Q2 and I2/Q1 correlations which have a phase difference of 90° as
expected. The software was straight forward Python reading chunks of
samples and doing the calculation.
In conclusion, the ADALM Pluto is a suitable device for interferometry
experiments.
And Rich, just befor you ask: Yes, this can be a subject of a SARA
article once I have done a full qualification ;-)

Best regards,
Wolfgang

[Marcus D. Leech]

On 09/10/2023 10:10, 'fasleitung3' via Society of Amateur Radio

Was this with the "stock" firmware on the Pluto?

[fasleitung3]

Am Montag, den 09.10.2023, 10:26 -0400 schrieb Marcus D. Leech:
> Was this with the "stock" firmware on the Pluto?

Yes, just enabling the second channel.
There is a good youtube tutorial at
https://www.youtube.com/watch?v=ph0Kv4SgSuI

Wolfgang

[Marcus D. Leech]

On 09/10/2023 11:17, 'fasleitung3' via Society of Amateur Radio

Thanks for this.

Looks like the PlutoSDR source in Gnu Radio doesn't know anything about
the 2nd channel :(

[fasleitung3]

Am Montag, den 09.10.2023, 11:50 -0400 schrieb Marcus D. Leech:
>
> Looks like the PlutoSDR source in Gnu Radio doesn't know anything
> about
> the 2nd channel :(
>

You need to use the FMComms2/3/4 source block for this.
However, there seems to be an issue which I was not able to resolve so
far: Looking at a constellation sink on each channel everything looks
good. However, using your "simple_correlator" does not give any
reasonable results. On the other hand, your simple_correlator works
fine with a Lime SDR. I have not found the time to resolve this
discrepancy.
As I mentioned I have used a direct python script instead of Gnuradio.

Wolfgang

[Marcus D. Leech]

On 09/10/2023 12:07, 'fasleitung3' via Society of Amateur Radio

Yup, found the FMCOMMS2/3/4 source info.  Turns out that there's a
data-handling bug in the libraries somewhere deep in IIO
  or FMCOMMS that makes the Q stream invalid.

I don't know how far the fix has propagated from Analogs GITHUB to
actual  Linux distros, etc.

[Marcus D. Leech]

On 09/10/2023 12:07, 'fasleitung3' via Society of Amateur Radio

If you want to go down the path of using a PPA for a more-recent Gnu
Radio package, there's one for Ubuntu 22.04 published
  by Josh Morman of the Gnu Radio project.   This will include the
fixes in gr-fmcomms sub-packages.

https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases

[Marcus D. Leech]

On 09/10/2023 12:07, 'fasleitung3' via Society of Amateur Radio

Here's a bug-tracker link for this issue:

https://github.com/gnuradio/gnuradio/pull/6142

The fix has been back-ported to Gnu Radio 3.10, but since this was only
a year ago, it's likely not going to be
  an update in Ubuntu 22.04, but is likely in Ubuntu 23.04.

[fasleitung3]

Thanks Marcus,
This explains why it would not work as expected with gnuradio. For the
time beiing I will leave it as it is as I am not using gnuradio for the
interferomater application anyway. But it is good to know for future
projects.
Wolfgang

> --

[Marcus D. Leech]

On 09/10/2023 14:34, 'fasleitung3' via Society of Amateur Radio

Astronomers wrote:
> Thanks Marcus,
> This explains why it would not work as expected with gnuradio. For the
> time beiing I will leave it as it is as I am not using gnuradio for the
> interferomater application anyway. But it is good to know for future
> projects.
> Wolfgang

I'll note in passing that the Rev-C and newer units also include an
external clock input, and I wonder if
  larger receiver arrays could be built?  My recollection is that with
the clocking on the AD9361, you'll
  have a phase ambiguity, and because the units don't have any kind of
time-stamping or "trigger"
  input, you'll still need to time-align, more-or-less the same way
that KrakenSDR does it...

The other option is to have 1 receiver per *baseline*.  This doubles the
number of receivers you need,
  but only requires mutual phase coherency across a single baseline. 
Of course, for stationary sources, you
  could measure 1 baseline per day or something, and build up your set
of visibilities over time.   This is actually
  how places like VLA do it, but at a much larger number of
participating antennas at any given time...