How to make friends PLUTO and HDSDR

Not so long ago, impulsively bought a cute SDR transceiver for children and youth - ADALM PLUTO. To my regret, it works with a bunch of software for LINUX, but my favorite HDSDR does not support it. Without thinking twice, I began to deal with this problem and here is what came of it:

Analog Devices addresses its PLUTO to students. All software for PLUTO is open and is freely available. The company’s website has a page where you can find almost all the necessary information about the operation of PLUTO. Most of the software is written under Linux and students are advised to use GNU Radio, MATLAB, etc.

I have a purely amateur radio interest in PLUTO. An SDR with a range from 70MHz to 6GHz (after disclosure ) for just 150 American money is a miracle. How many experiments can be done! See how much everything is integrated there:

Apparently, AD believes that hams themselves should write drivers for popular programs, so until recently, even SDR # was not supported. But SDR # doesn’t suit me, because I need good CAT support in a program to synchronize frequency with a transceiver. I would like to try to use HDSDR as a panoramic receiver by connecting it to the first intermediate frequency of the transceiver. So, there is only one way out - to integrate HDSDR and PLUTO yourself.

Using Google, I quickly found out that to solve my problem, I need to create a special ExtIO_.dll library in Winrad format . This library serves as a software bridge between the HDSDR and the desired SDR receiver. Fortunately, the library interface is well documented . In addition, there are quite a few ready-made library implementations for various receivers on github: RTL_SDR, LimeSDR , etc. There was a place to see how to write code. The library itself is quite old-school, no new technologies, pure C89, as they wrote 20 years ago. At least you don’t need to learn a new programming language, which already inspired hope for success.

Essentially, ExtIO_.dll needs to be implemented with dozens of functions that allow you to initialize SDR equipment, start and stop signal reception, save and restore the specified settings. For me, the most incomprehensible moment was the format of the exchange of streaming data between the receiver and HDSDR, but more on that below.

Now the question has arisen how to control PLUTO programmatically. There are actually several control options. I found at least two: either directly with the chip through the libad9361.dll library , or through the IIO library . The latter option seemed simpler and more well described to me, so I settled on it. In this library, all equipment settings are available in the form of some kind of XML structure, an individual element is accessed by the textual name of the property, which is quite convenient. More detailed description of the library can be found here. The huge advantage of the library is that it comes with command line utilities, with which you can always quickly change the desired receiver settings. Thus, you do not need to implement all the SDR settings in the HDSDR interface, you can get by with the necessary minimum. And loading some exotic FIR filter can be done from the command line, if ever, such a need arises. Data Streams in IIO:

Programmatically, learning how to control PLUTO from HDSDR was pretty quick and easy. It was a little harder to get a satisfactory result in streaming data, especially since I had no previous experience with SDR. Here you need to understand that the data comes from the SDR receiver in the form of a stream of I / Q / I / Q ... I / Q samples. Each sample is an unsigned 16-bit integer, of which only 12 low-order bits matter. At the same time, HDSDR has a dozen options for receiving data streams. Which one is more convenient and better is not entirely clear to me. As a result, I settled on the option, which in ExtIO is called exthwUSBdata16, i.e. actually one to one how the IIO library gives data.
The next problem was the transfer of data between the IIO receive buffers and HDSDR. The latter receives data in blocks that are multiples of 512 bytes, and IIO cannot output data in this format. I had to make an intermediate buffer and transfer the stream through it. Transmission code is shown below.

DWORD WINAPI GeneratorThreadProc( __in  LPVOID lpParameter )
{
	int16_t	iqbuf[EXT_BLOCKLEN * 2];
	ssize_t	nbytes_rx;
	char	*p_dat, *p_end;
	ptrdiff_t	p_inc;
	int	iqcnt = 0; // pointer to sample in iqbuf
	while ( !gbExitThread )
	{
		nbytes_rx = iio_buffer_refill(rxbuf);
		p_inc = iio_buffer_step(rxbuf);
		p_end = (char *)iio_buffer_end(rxbuf);
		for (p_dat = (char *)iio_buffer_first(rxbuf, rx0_i); p_dat < p_end; p_dat += p_inc) {
			iqbuf[iqcnt++] = ((int16_t*)p_dat)[0];
			iqbuf[iqcnt++] = ((int16_t*)p_dat)[1];
			if (iqcnt == EXT_BLOCKLEN * 2) { // buffer full
				iqcnt = 0;
				pfnCallback(EXT_BLOCKLEN, 0, 0.0F, &iqbuf[0]);
			}
		}
	}
	gbExitThread = false;
	gbThreadRunning = false;
	return 0;
}

Using the indicated cycle, it was possible to achieve a stream transfer of 4 MS / s, above this value the data does not have time to be transmitted and the signal is received with stuttering, although the iron seems to be able to send 20 MS / s and even higher. Increased the priority of the thread in which the loop spins to THREAD_PRIORITY_TIME_CRITICAL, increased the size of the buffers. No result. Moreover, when the buffer was increased to 1 MB, normal reception was impossible at the minimum flow rate. More here does not mean better. If you have ideas on how to increase speed, please share in the comments.

I must say that 4 MS / s is quite enough for my purposes, the band more than covers any amateur HF band. Yes, and on the VHF and microwave bands enough for most tasks. As a result, the library is written, the HDSDR window with PLUTO turned on for reception looks something like this:

All library code is available on github here . Feel free to use it for your experiments with ADALM PLUTO.

73 de R2AJP