WSDRTEMP can share the connection to ADALM-PLUTO with other SDR Applications.
WSDRTEMP can be executed in multiple instances to monitoring more Pluto together. See Multiple instances of the WSDRTEMP section on this page. Each session has private settings, where the user can configure the device’s IP address, poll time in seconds, and other parameters.
The main window size and position are saved and restored on successive sessions. The range scaling of the virtual meters can be done by the Min and Max controls. The alarms state and the temperature trend will show by the two indicators in the right lower panes.
Alarm Off = The temperature is normal
Warning = Blinking yellow, the warning temp is reached
Overheat = Blinking red, the device is overheating
Temperature trend states
Wait… = The application is running for a few seconds, or the configuration has changed from the user. It’s the start of the temperature trend analysis.
Heating = The device is in a heating trend
Cooling = The device is in a cooling trend
Steady = Shows green, the temperature is in steady-state
Open the configuration panel from the Settings menu:
Poll time accepts from 1 to 59 seconds by default. This range is related to the 60 sec of time default of the temperature trend analysis process.
Temp warning defines the warning temp zone threshold, and Temp max defines the threshold of overheat.
If desired, it’s possible to specify a CSV file where the application logs the temperatures at the frequency defined by the Poll time field.
Field list of CSV files:
First field: Date and time of reading yyyy-mm-gg hh:mm:ss
Second field: TRX temp
Third field: FPGA temp
Example of CSV line: 2020-10-31 10:12:59,32.46,30.69
At need, you can specify applications or script files on fields “Application or script to start when…”. These applications or script files are launched by WSDRTEMP when the follows conditions are reached:
Steady: Is launched when TRX and FPGA devices reach a steady-state temp. For steady-state, the application expects by default max 2 degrees of temp shift inside the 60-sec window.
Warning: Is launched when the TRX or the FPGA device reaches the threshold defined by the Temp warning field.
Overheat: Is launched when the TRX or the FPGA device reaches the threshold defined by the Temp max field.
Normal: Is launched when the temperature of TRX and FPGA returns to the normal value from a warning or overheat state.
WSDRTEMP tracks the applications or scripts executions. No new start of external applications will performed if they still running.
Multiple instances of the WSDRTEMP
WSDRTEMP can monitor one device at a time. If a second instance of the application is run, WSDRTEMP catches the configuration lock and asks the user if supersede is desired.
To monitoring more devices at a time, WSDRTEMP should be run with the parameter -config followed by a number from 0 to 7. The number parameter defines the configuration to use.
Create a shortcut and modify the target field adding -config number, for example:
Target with “WSDRTEMP -config 0” is like to run the application without that parameter, because config 0 is the default.
From version 0.4.0, SATSAGEN can handle two devices. In this dual device mode, the first device defined act as RX and the second as TX.
This mode improves the dynamic range of the system because it eliminates the internal crosstalk of devices.
Dual device mode settings
To enable this mode, select Two devices on tab Devices in Settings and specify the device that will act as RX in the first pane and device that will act as TX in the second. If neither devices are specified and the fields Connection string override are left blank, the default URI will be used for devices. The default URI for the first device is ip:192.168.2.1 and the second is ip:192.168.3.1.
If you have changed the default user and password of devices, you can save these on the program in safe encrypted mode, click buttons, and set credentials. These credentials will be used for sending commands useful to identify the devices uniquely. For example, these credentials will be used by the program to sending the commands to reverse the activity Led blinking of the devices when buttons Led On will be clicked. With buttons labeled Led On you can easily identify a device, the Led activity normal blinking of the related device will reverse.
The settings of the TX device in dual-mode have a checkbox labeled Discipline XO; if checked, the TX device is tuning with periodically XO correction values according to the position and shaping of the signal received in the dual-mode by RX device. These corrections are running during the scans and calibrations only with appropriate RX amplitude. This feature aid in mitigating the drift of the standard TCXO. Without this feature, the drift of standard TCXO in dual device mode can considerably affect the amplitudes read during the scans.
The feature Discipline XO is not active when:
Frequency is below 71 MHz
RX or TX offset are specified.
The TSA scan modality is in multiplier offset or harmonic.
The RX amplitude drops below -20 dBm for the fine correction according to signal shaping.
The RX amplitude drops below -60 dBm for the correction according to the signal position.
The tab Level correction has a new section in dual device mode where can be specified the custom linearization files for RX and TX devices running in this modality:
Dual device mode operation
The dual device mode operation is the same as a standard single device; also, the user interfaces not change. The only difference is the small virtual LED in the right lower of the panel of TSA. This LED indicates the Discipline XO feature’s status with green color when normal condition and displays the value used for correction, in this example, -222 Hz.
I suggest before to do a calibration and execute the measures, to let running for some scans with a loopback cable. This trick allows the Discipline XO feature to reach the optimal correction for the TX device.
The best condition is reached when the temperature of devices is in steady-state, mostly when the devices use standard TCXO components.
Generator with LO frequency output
Set the generator to DC to turn off the modulation of the carrier:
This feature improves the generator output; moreover, the harmonics can be easily calculated because the output frequency is the same as the TX LO. In this mode, a DC is applied to the I and Q input of the TX mixer.
plutotx is a very simple console application that drives Adalm Pluto to generate a CW tone on the frequency and power level selected by the user.
I hope that the information and the C source that you will read below can be a small help for all developers who want to create a new SDR project.
From the archive available for download you will also find the binaries compiled for Windows and Linux x86, so it could also be useful to those who are not developers but simply have an interest in experimenting with Pluto.
plutotx v.1.1 (16 november 2020)
File size: 705.865 Bytes
- F: 2,147GHz limit
- I: Output bursts issue
- I: Switching off any DDS second tone active
- A: Include, library and instruction to compile under Windows and Linux
Author: Alberto Ferraris IU1KVL - http://www.albfer.com
This program is free software: you can redistribute it and/or modify
it under the terms of the version 3 GNU General Public License as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
#define URIPLUTO "ip:192.168.2.1"
#define MINFREQ 50000000
#define MAXFREQ 6000000000
#define MINDBM -89
#define MAXDBM 10
#define REFTXPWR 10
#define FBANDWIDTH 4000000
#define FSAMPLING 4000000
#define FCW 1000000
struct iio_channel *tx0_i, *tx0_q;
void stderrandexit(const char *msg, int errcode, int line)
fprintf(stderr, "Error:%d, program terminated (line:%d)\n", errcode, line);
fprintf(stderr, "%s, program terminated (line:%d)\n",msg, line);
void CWOnOff(int onoff)
int main(int argc, char* argv)
struct iio_context *ctx;
struct iio_device *phy;
struct iio_device *dds_core_lpc;
struct iio_channel *tx_chain;
struct iio_channel *tx_lo;
const char *value;
long long freq;
printf("Usage: plutotx kHz dBm [uri]\n");
if(freq<MINFREQ || freq>MAXFREQ)
stderrandexit("Frequency is not in range",0,__LINE__);
if(dBm<MINDBM || dBm>MAXDBM)
stderrandexit("dBm is not in range",0,__LINE__);
ctx = iio_create_context_from_uri(argv);
ctx = iio_create_context_from_uri(URIPLUTO);
stderrandexit("Pluto is not expanded",0,__LINE__);
stderrandexit("Error retrieving phy model",0,__LINE__);
phy = iio_context_find_device(ctx, "ad9361-phy");
dds_core_lpc = iio_context_find_device(ctx, "cf-ad9361-dds-core-lpc");
tx0_i = iio_device_find_channel(dds_core_lpc, "altvoltage0", true);
tx0_q = iio_device_find_channel(dds_core_lpc, "altvoltage2", true);
tx_chain=iio_device_find_channel(phy, "voltage0", true);
tx_lo=iio_device_find_channel(phy, "altvoltage1", true);
if(!phy || !dds_core_lpc || !tx0_i || !tx0_q || !tx_chain || !tx_lo)
stderrandexit("Error finding device or channel",0,__LINE__);
//enable internal TX local oscillator
//disable fastlock feature of TX local oscillator
//power on TX local oscillator
//full duplex mode
//calibration mode to manual
printf("TX ON! Q to exit or E to keep TX ON and exit\n");
if(ch=='q' || ch=='Q')
if(ch=='e' || ch=='E')
WARNING: At the first start, the application will perform on the device the frequency and bandwidth extension needed for the use of the 70MHZ-6000MHZ range, forcing the firmware to “see” the AD9363 transceiver as an AD9364.The extension is required for the application to work, but if you don’t want it to happen, don’t start SATSAGEN.
I would like to thank my friends Gianni IW1EPY, Domenico I1BOC and Mauro IZ1OTT for giving me the idea, the support in every sense, the radio components and the equipment necessary for the realization of the project!
A special thanks goes to Boian Mitov for the GREATS libraries www.mitov.com used in SATSAGEN!
Below you will found another valuable contribution by Gianni and at the end of the post you will find a short video that illustrates the application basics.
“As Adalm Pluto owner I become acquainted to this device using radio programs (SDR Console, SDRAngel) to link Oscar 100. But for this kind of hardware my asking was for a measurement system. I have test cheap network analyzer in the range of 4,4 GHz, vector analyzer up to 900 MHz and my idea was to set Pluto in this class of instruments using the extended range 70 MHz to 6 GHz. After some encouraging trials from the RF point of view but disappointing for the measurement time delay in Matlab, I drag my friend Alberto into this adventure to have an acceptable measurement time using C libraries. Apart the nice Alberto’s program I add some Hardware notes. Adalm Pluto it is born for sure not for a professional measurement instruments so some drawbacks can be expected. Due to the large bandwidth usage forced by the program (original Pluto frequency usage spans from 325 MHz to 3,8 GHz) the input and output impedance for sure are not 50 ohms. A pair of attenuators on input and output mitigate the problem, for sure reducing the usable dynamic range but acceptable for HamRadio users. Using two 10 dB attenuators remain 40 dB down to the calibration level and 20 up in case of insertion of an active device under test. The missing metal box generate some crosstalk problems in the upper range of frequency specially if Pluto is moved around metal frames or touched by fingers… some people have reboxed it. The present structure (Pluto plus optional attenuators) allows a direct measurement of transfer function of filters, amplifiers, a directional coupler or a reflection bridge is mandatory for impedance measurement. Is possible to attach a file to correct the deviation of output power over the frequency sweep, unluckily every Pluto have its own variance. By now I have analyzed 5 devices and the correction curve are available. With the linearization file the output power can maintain an error of 1 dB versus 10 : 12 dB of the unleveled , most of this nonlinearity is located in the range from 50 to 300 MHz end 4.5 to 6 GHz obviously where Pluto was not designed for. The receiver gain and the generator attenuator do not increase the linearization error, so one linearization file is enough. Pay attention to not overload the receiver or saturate the generator but this behavior become immediately evident. To enhance the dynamic linearization is possible to apply a -40 dB calibration using a correct attenuator. This linearization performs in the range thill -40 db but almost kill the response from -40 to -60, in any case due to cross talk end receiver erroring this range is severely degraded even without this correction. All the level of the RX Gain and the Output Power and the attenuators that you have inserted at the I/O are programmable. Any idea of improvement ? This is the list of future enhancement: Calibration using a directional coupler or bridge averaging open and short. Offset between transmitter and receiver in order to test conversion systems. Harmonic response of devices in order to test amplifiers or multipliers. Open to suggestions. I think that Adalm Pluto with SATSAGEN, covering 7 Ham bands, will be useful in designing and testing to every ones involved in RF field. IW1EPY“
This equipment is a precise clock generator, able to provide programmable frequencies from 8KHz to 200MHz on three independent outputs.
The generation of the signals is provided by a Si5351A. In this application, the Si5351A PLL uses as a reference a disciplined oscillator (GPSDO) based on the G7020-KT chip.
The control of GPSDO, PLL and the user interface (a 101X80 pixel color LCD and an encoder) is provided by an ATMega328P operating at 3.3V-8MHz.
Power is supplied by a 3.7V 600mA lpo battery which guarantees about four hours of use. The battery is connected to the step-up module which provides 5V for some modules and 3.3V through two LDOs via a CPU-controlled mosfet switch; the use of the mosfet guarantees the switching off of the appliance if the battery level drops. This switch circuit allows to have a quiescent current close to 0 uA. The charge and discharge control of the battery is also provided by the CPU and the TP4056/DW01A chips for charging and the overcharge protection and in additional overdischarge protection in the event of a CPU lock. The battery level is constantly displayed on the LCD, both during discharge and charging phases.
The “heart” of the generator is a VCTCXO oscillator which provides the reference to the G7020-KT GPS module and the Si5351A. The control voltage of the VCTCXO is given by a MCP4725 DAC (12bit resolution and I2C interface). The values sent to the DAC are processed by the CPU based on the feedback received from the GPS module about the offset of the reference oscillator with respect to the one hooked to the satellite. The CPU receives UBX messages about the Drift clock from the G7020-KT via a serial connection. The DAC is equipped with an internal EEPROM memory that allows the sending of the control voltage preset to VCTCXO at moment of power-up, to speed up the GPS syncronize.
From the user interface it is possible to set the frequencies and power levels of the three outputs of the Si5351, respectively with a resolution of 1Hz and with four different output levels; 0.76DBm, 7DBm, 10DBm and 12DBm. The equipment has also a fourth output in SMA, concerning the PPS output of the GPS module synthesizer, also this last output is programmable from the user interface in frequency from 1Hz to 24MHz (for an acceptable phase noise, use only 48MHz sub-multiples) and in duty cycle from 1% to 99%. It is possible to set the PPS active only during the GNSS sync, moreover it is also possible to set manually the value sent to the DAC, a useful function for example to speed up calibration in the event of VCTCXO replacement.
All the above settings can be saved in the EEPROM of the CPU so that after a few seconds from a subsequent restart, the equipment generates the frequencies with the saved settings.
The yellow LED on the panel shows the PPS output signal negate (LED off = high signal), while the green LED indicates the correction operation performed on the VCTCXO: LED off = no GPS reception or PDO higher than 5 (minimum level to consider the clock drift), LED flashing = tDOP less than 5, clock drift above +/- 4ns and a correction of the VCTCXO voltage by the DAC is in progress, LED on steady = clock drift below +/- 5ns.
Finally, the following dynamically updated values are displayed on the GPS screen: number of satellites used, the DOP (time dilution of precision), the clock drift value expressed in ns (corresponding to an oscillator deviation of 0.026 Hz per unit ), the type of fixed none, 2D or 3D, the position in longitude and latitude and meters above sea level, date and time in UTC, and finally the value of the voltage sent by the DAC to the VCTCXO in the range from 0 to 4095 (in steps of about 0.8mv); the VCTCXO responds to the control voltage in a negative way, so as the voltage rises the frequency of the VCTCXO drops.