Support for ADALM-PLUTO SDR?

[peterg10]

Any chance this new SDR could get a SoapyPluto ??

$99, hackable range 70-6000Mhz TX and RX.

[starvald]

+1 pretty please :)

[guruofquality]

Cool! Any volunteers that have the hardware and can fill in a few functions? I'm happy to give repo access/guidance of any sort.

[peterg10]

Unfortunately I'm not a coder but I have hardware and will do whatever I can to help test and document.

[pavel-demin]

Since the default firmware for ADALM-PLUTO communicates with a computer via IIO and PothosSDR has already a source and a sink for IIO, then it's possible that ADALM-PLUTO works with PothosSDR out of the box.

I suppose that a new Soapy module could be relatively easily made based on the code from PothosIIO. If it's so, then a better name for this module would probably be SoapyIIO.

Does it make sense?

I don't have ADALM-PLUTO to test it with PothosIIO. It would be interesting if somebody could test it.

Another possibility would be to use gr-osomsdr patched by Alexandru Csete together with SoapyOsmo.

[pavel-demin]

For information. Here is a link to the source code of the GNU Radio blocks for IIO and ADALM-PLUTO:

https://github.com/analogdevicesinc/gr-iio

[FiachAntaw]

As @pavel-demin said, the default PlutoSDR firmware operates using an IIO sink/source buffer device, so it should be possible to just point the PothosIIO sink and source blocks at the device. The blocks should automatically expose the input/output channels as streams and the controls as signals/slots. It should be possible to get TX/RX working without needing any custom code, though a helper block that wraps the source/sink blocks and configures settings like sample rate would probably make things easier.

To actually get the IIO blocks to work you'll have to run them locally on the Zynq itself. Pothos can be compiled on the Zynq (or cross-compiled) without the GUI component, then connected to from a full PothosFlow instance via the PothosUtil Proxy Server. All block metadata will propagate across the network (so long as the block is in the correct affinity zone). This approach also means some processing can be done on the Zynq itself, whicb might be useful given the USB 2.0 interface.

If it's desirable to support this device in SoapySDR itself (since it is an SDR), it might be worth migrating the IIO bindings to a separate project so they can be used in both Soapy and PothosIIO.

[jocover]

my soapy plutosdr plugin , rx channel is working fine https://github.com/jocover/SoapyPlutoSDR

[guruofquality]

Another possibility would be to use gr-osomsdr patched by Alexandru Csete together with SoapyOsmo.

@pavel-demin The issue here is that SoapyOsmo cannot wrap modules that just instantiate a gr block internally. That would be difficult because it would require actually pulling in gnuradio itself and traversing the hierarchy of connected blocks. I looked at it once for pull in the audio support, but SoapyOsmo has its limits.

If it's desirable to support this device in SoapySDR itself (since it is an SDR), it might be worth migrating the IIO bindings to a separate project so they can be used in both Soapy and PothosIIO.

@FiachAntaw Thats probably going to be more flexible and lightweight in the long run to have a SoapyIIO. Most of the complication is already wrapped up in libiio, so having both a SoapyIIO and PothosIIO is just fine and they might compliment each other. SoapyIIO might get customizations to make a particular device appear more SDR-like so its easer to get working in a SDR GUI application, where PothosIIO might expose other things because its wrapping a custom FPGA design.

In any case, looks like jocover already did this :-)

then a better name for this module would probably be SoapyIIO.

SoapyIIO for many devices is probably a better way to handle this so long as there isnt a bunch of customization on top of libiio, looking at jocover/SoapyPlutoSDR implementation. I dont think there is any customization. I suppose that SoapyIIO would bring in some other FMCOMM boards?

We might need some specific board detection so the labels show up nicely in GUI and tools. Example discovery args "label" might say "PlutoSDR some identifier" where the identifier is the ip address, serial number, or mac, just something unique to identify the board.

my soapy plutosdr plugin , rx channel is working fine https://github.com/jocover/SoapyPlutoSDR

@jocover extremely cool. What do you think about SoapyIIO vs SoapyPlutoSDR name? I suppose we should figure that out. And as always, I'm happy to host it here.

[guruofquality]

I guess this is working as intended, so post further issues here: https://github.com/jocover/SoapyPlutoSDR I'm happy to host the project on this github project, but otherwise all of the links point to jocover/SoapyPlutoSDR