How to make friends PLUTO and HDSDR

Not so long ago, impulsively bought a nice SDR transceiver for children and youth - ADALM PLUTO. To my regret, it works with a bunch of software under LINUX, but my favorite HDSDR does not support it. Without thinking twice, I began to deal with this problem and this 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 encouraged to use GNU Radio, MATLAB, etc.

I have a purely radio amateur interest in PLUTO. SDR with a range from 70 MHz to 6 GHz (after disclosure ) for only 150 American money is a miracle. How many experiments you can spend! 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 the SDR # does not suit me, since I need good CAT support in the program for synchronizing the frequency with the transceiver. HDSDR also want to try to use as a panoramic receiver, connecting it to the first intermediate frequency transceiver. So, the only way out is to integrate HDSDR and PLUTO yourself.

With the help of Google, I quickly found out that in order to solve my problem, I needed to create a special ExtIO_.dll library in Winrad format. This library serves as a software bridge between 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 look at how to write code. The library itself is completely old-school, no new technologies, pure C89, as they wrote 20 years ago. At the very least, there is no need to learn a new programming language, which already gave hope for success.

In fact, ExtIO_.dll needs to be implemented with a dozen 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 was how to control PLUTO programmatically. In fact, there are several options for management. I found at least two: directly by the chip through the library libad9361.dll , or through the library IIO . The last option seemed to me more simple and well described, so I stopped at it. In this library, all the hardware settings are available in the form of some kind of XML structure, the appeal to a separate element follows the textual name of the property, which is quite convenient. More information about the library can be found here . A huge advantage of the library is that it comes with command line utilities, with which you can always quickly change the desired receiver setting. Thus, it is not necessary to implement all the SDR settings in the HDSDR interface; you can get by with the necessary minimum. A download of some exotic FIR filter can be done from the command line, if ever there is such a need. Data streams in IIO:

Software learning how to control PLUTO from HDSDR was pretty quick and easy. It was somewhat more difficult to obtain a satisfactory result on the transfer of streaming data, especially since I had no previous experience with SDR. Here we must understand that the data comes from the SDR receiver as a stream of I / Q / I / Q ... I / Q samples. Each sample is without a signed 16-bit integer, of which only 12 low bits have a value. At the same time, HDSDR has about a dozen variants of received data streams. Which one is more convenient and better is not quite clear to me. As a result, I settled on a variant which is called exthwUSBdata16 in ExtIO, i.e. in fact, one-to-one, as the IIO library gives data.
The next problem was the transfer of data between the IIO and HDSDR receive buffers. The latter receives data in units of multiples of 512 bytes, and IIO cannot provide data in this format. I had to make an intermediate buffer and pass the stream through it. The transfer 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 this cycle, it was possible to achieve a stream transmission of 4 MS / s, above this value the data do not have time to be transmitted and the signal reception comes with stuttering, although the iron seems to be capable of giving up 20 MS / s and even higher. Increased the priority of the thread in which the loop is spinning to THREAD_PRIORITY_TIME_CRITICAL, increased the size of the buffers. No result. Moreover, with an increase in the buffer to 1 MB, normal reception was impossible at the minimum flow rate. More does not mean better. If you have any ideas how to increase the speed, please share in the comments.

I must say that 4 MS / s is enough for my purposes, the band is more than covering any radio amateur HF range. Yes, and VHF and microwave band is enough for most tasks. As a result, the library is written, the HDSDR window with PLUTO enabled is like this:

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

73 de R2AJP