AlbFer

• GPIB support
• Three-device setup
• LMX2595 support
  • Stand-alone startup of PLL synthesizers
• Harmonic Extended Filter

Three-device setup

From this release, a third SDR device can be configured in the Devices tab in Settings to extend the functionality of the Satsagen VNA:

Set three devices by clicking on the corresponding radio button, next click the RX/2 device tab, and set the SDR device you want to use as the third device.

Finally, in the SNA/VNA Mode tab, select the VNA item from the Mode list and Dual RX-Device from the Dual Port Interface list.

With the above configuration, the VNA will use the third device as a second receiver, and it will be available for S11 and S21 measurements in real time without manually switching the DUT connections.

The mandatory conditions for the correct functioning of the three-device configuration are:

• A common reference clock source (the CLK Source in the above image). Alternatively, the external clock source is connected only to the first device, and the reference to the other two is provided with a daisy chain connection.
• Devices 1 and 3 designated to the RX role must have two synchronized RX channels, so with the current version 0.9.3.3, only Pluto rev. C/D devices are compatible.
• Device 2, designated as TX, can also have only one TX channel, but this requires two ports, TX+ and TX-, or the addition of a splitter. Several devices are compatible with the TX device, including Pluto and the PLL synthesizers LMX2595, ADF4251, and others.

LMX2595 support

By connecting an LMX2595 board to Satsagen, the application can function as a Generator/sweeper and Tracker in SNA/VNA operations from about 100MHz up to and beyond 20GHz with an output power capable of achieving more than sufficient dynamic range for the characterization needs of filters and other DUTs.

Satsagen with an LMX2595 as TX device, and an ADALM-PLUTO as RX device in fifth harmonic mode, can provide approximately 40dB of dynamics at 24 GHz!

To improve measurements above 20GHz, a cavity filter should be used to reduce the fundamental of the LMX2595 (at frequencies above 15 GHz, an internal chip doubler is activated) because it can become “important” and saturate the first stages of the RX device. Two coupled guide transactions can be used as a filter.

Support for boards with the LMX2595 PLL synthesizer is provided via a USB interface consisting of an Arduino microcontroller or a Raspberry Pi Pico. See the page relating to this multifunction interface USBDAALBFER for the schematics, sources, and binaries that can be used.

Some tips for using this PLL board:

• Using a Raspberry Pi Pico (and Pi Pico 2) is preferable because the input and output work at the same 3.3V level as the LMX2595, so there is no need for voltage level adaptation components. Furthermore, uploading the firmware to the Pi Pico can be reduced to simply copying the binary file provided here onto the Pi Pico disk, which is activated by holding down the button and inserting the USB into the PC, so there is no need to equip yourself with the Arduino compilation environment.
• On some LMX2595 boards from China, part of the connector pin silkscreen is on the back of the board:

• The LMX2595 5V power supply should be supplied via a dedicated USB port or with a separate power supply, as the board during operation can reach absorption peaks of 400mA and more, therefore, it is not recommended to power it via the 5V pin of the microcontroller, whether it is an Arduino or a Raspberry.
• The GND connection between the LMX2595 board and the microcontroller is also important to ensure correct SPI operation. It should be done with short connections and using more GND pins on the microcontroller near the pins dedicated to the SPI.
• Finally, metal containers are recommended for the LMX2595 board and the receiving device (ADALM-PLUTO).

Stand-alone startup of PLL synthesizers

From this version, there is a function that allows you to program the Arduino or Pico interface combined with a supported PLL synthesizer, such as the LMX2595 just seen, for stand-alone use, that is, the interface and the PLLs can function as CW generators at a fixed frequency and power simply by powering them, even disconnected from Satsagen. This feature can be useful if a temporary local oscillator is needed for our down-converter or up-converter projects.

To use the above functionality, follow these steps:

• Start the application with the devices connected
• Start the Generator and set the desired frequency and power
• By keeping the Generator ON, click on the Save the Generator state to the device menu under Settings -> Device stored settings.

You can turn off Satsagen and disconnect the interface and PLL devices from the PC now. If the interfaces with the PLLs are powered via USB or with a separate power supply, they will automatically start at the preset frequency and output power, without the aid of Satsagen as a driver.

To reset the above setting on the interface, so that it no longer starts automatically and stops the PLLs from working as stand-alone CW generators, repeat the above procedure with the Generator turned OFF:

• Start the application with the devices connected
• Leave the Generator turned OFF and click on the Save the Generator state to the device menu under Settings -> Device stored settings.

You can turn OFF Satsagen now and disconnect the interface and PLL devices from the PC; the stand-alone operation setting has been reset.

Harmonic Extended Filter

In SNA scans with tracking generator, especially in harmonic mode, we noticed the presence of unwanted “peaks”, for example around 24 GHz, due to the combination of the high RX Gain setting required and the presence of harmonics of the RX local oscillator falling right in the IF range.

From this version of Satsagen, you can activate an EF filter, similar in operation to the one already present in the Spectrum Analyzer, also for TSA/SNA operations, by clicking on the EF button in the central panel of the application:

The EF filter will eliminate the above artifacts during the scan by taking two separate readings for each point, slightly shifting the frequency of the RX local oscillator. The filter will compare the pair of readings, eliminating signals present at the same frequency on only one of the two readings, an unmistakable sign of artifacts due to the RX local oscillator.

On the other hand, using the EF filter will cause a slight slowdown in SNA scans.

• GPIB support
• GPIB template
• PLL Templates
• Importing (and exporting) templates
• Device status control fields
• Start, end connection commands and alternative way to serial poll status byte
• Power Meter Template
• GPIB Terminal
• How Backspace Works in the GPIB Terminal

GPIB support

Using a GPIB->USB serial adapter like the AR488 project, Satsagen can drive devices with an IEEE488 GPIB/HP-IB interface.

Version 0.9.3.3 can drive synthesized generators and power meters as Satsagen TX and RX devices.

Some old devices are directly supported and are listed among the usable devices in Settings->Devices; other synthesized generators and power meters can be configured using two template models if you know their command syntax.

Why use Satsagen to drive GPIB/HP-IB devices?

In addition to simply acting as a remote control of devices, Satsagen can work as a link between multiple heterogeneous devices to create SNA/VNA instruments. E.g., Satsagen becomes a scalar SNA instrument by connecting a generator and a power meter both in GPIB/HP-IB, or an SNA/VNA by combining a GPIB/HP-IB generator and an SDR receiver such as ADALM-PLUTO.

With Satsagen, it is allowed to drive multiple GPIB/HP-IB devices using a dedicated interface for each device or with a single interface connected on a GPIB/HP-IB BUS where the devices to be controlled have different addresses, but it is not allowed to use two devices on the same GPIB/HP-IB BUS at the same time.

GPIB template

GPIB templates are configuration files in .ini format that allow Satsagen to drive devices on the GPIB bus.

In Satsagen version 0.9.3.3, there are two configuration models, one for driving synthesized generators and another for power meters.

In the Documents\Satsagen\Settings directory, you will find two template files that you can copy and modify to suit your needs to generate the final templates to import into Satsagen: templatePLL_commented.ini for synthesized generators and templatePM_commented.ini for power meters.

Then copy the templates with a name of your choice into the same “Documents\Satsagen\Settings” directory, and edit them with Notepad.

PLL Templates

PLL templates allow Satsagen to drive synthesized generators on the GPIB bus. They have a unique section called CUSTOMGPIBPLL.

The mandatory fields that need to be customized to drive the generators synthesized on GPIB are:

• DeviceAddr: GPIB address
• fGEN: initial frequency in Hz. It can be changed from the Satsagen Generator panel. For example, put a frequency of your choice in the range of the device.
• TXAttGEN: Initial attenuator setting in dBm. This parameter can also be changed from the Generator panel. For example, set a value to obtain the lowest possible initial output power.
• XO_FREQUENCY: reference frequency in Hz. Most devices use a reference frequency of 10 MHz, so fill in with 10000000.
• REFTXPWR: Fill with the maximum output power of the device expressed in dBm
• MINFREQTX: compile with the minimum frequency in Hz allowed by the device
• MAXFREQTX: Compile at the maximum frequency in Hz allowed by the device
• MINTXATT: Fill in the dB value of the device attenuator to get the minimum output power. For example -110
• MAXTXATT: Fill in the dB value of the device attenuator to get the maximum output power. Usually, this should be set to 0
• TXATTNSTEP: Fill in the dB granularity of the device attenuator, usually 10, 1, or 0.1
• CmdCWON: command to activate output, for example, RF1
• CmdCWOFF: command to turn off output, for example, RF0
• CmdDefSetPwrOut: command to set the output level of the device. For example PL followed by one of the following Satsagen variables and usually terminated by the suffix DB: %PWRDBMDEC% will be replaced with the value in dBm including the sign and a decimal, %PWRDBMINT% will be replaced with the integer value in dBm including the sign or %PWRDBMSIGN% which will be replaced only by the sign character. An example command could be PL%PWRDBMDEC%DB, Satsagen will then send the device to set an output value of, for example, -30 dBm, the command PL-30.0DB in this case.
• CmdDefSetVFO: Command to set the device frequency in Hz. For example, CW#SATSAGENVARIABLE#HZ, where #SATSAGENVARIABLE# can be: %FREQGHZDEC% for full frequency in GHz with decimals, for example, 10.368200125. %FREQGHZ% frequency in GHz only, for example 10. %FREQMHZDEC% full frequency in MHz with decimals, for example 10368.200125. %FREQMHZ% frequency in MHz without decimals, for example 10368. %FREQMHZONLY% represents only the MHz portion, for example, 368 if the full frequency in GHz is 10.368200125. %FREQKHZDEC% full frequency in kHz with decimals, for example 10368200.125. %FREQKHZ% frequency expressed in kHz without decimals, for example 10368200. %FREQKHZONLY% only the portion in kHz, for example, 200. %FREQHZ% complete frequency expressed in Hz, for example 10368200125. %FREQHZONLY% only the portion in Hz, for example, 125. An example command could be: CW%FREQHZ%HZ, Satsagen, then to set the frequency in the example 10368200125 Hz, the following string: CW10368200125HZ.

A minimal template INI file for working with synthesized generators might therefore look like this:

[CUSTOMGPIBPLL]
DeviceAddr=19
fGEN=2000000000
TXAttGEN=-60
XO_FREQUENCY=10000000
REFTXPWR=12
MINFREQTX=2000000000
MAXFREQTX=18000000000
MINTXATT=-110
MAXTXATT=0
TXATTNSTEP=1
CmdCWON=RF1
CmdCWOFF=RF0
CmdDefSetPwrOut=PL%PWRDBMDEC%DB
CmdDefSetVFO=CW%FREQHZ%HZ

Importing (and exporting) templates

Import the above file into Satsagen’s memory to make the template configuration operational.

From the Devices tab in Settings, choose GPIB/Custom PLL Synthesizer from the Model list and import the .ini file using the Load Template button.

If the syntax check is successful, Satsagen will display a confirmation message confirming the import. The GPIB/Custom PLL Synthesizer device can be used with the newly created configuration in subsequent sessions.

Re-importing another file using the Load Template button will cause the configuration to be overwritten in memory.

The active configuration in memory can be exported to an .ini file using the Export Template button. It is also possible to export the contents of the configuration in memory to an existing .ini file; this can be useful to preserve any comments not present in memory and that would be lost if you exported the configuration to a new file.

Many other fields can be used in a template to optimize the GPIB device operations and add functionality.

Device status control fields

If the device allows it, the fields that verify the PLL lock status of the synthesized generator should be added. This check is necessary if, following the sending of commands such as ON and OFF of the CW, setting of the output power and frequency, the device does not provide an automatic lock check after receiving commands. In such conditions, the control may not work correctly, generating errors or application crashes during use.

The most common method for verifying the PLL lock is by testing a bit of the device’s status byte (or word).

The PhaseLockedStatusMask and PhaseLockedStatusBitNegate fields define how to test the status bit for PLL lock verification.

The PhaseLockedStatusMask field defines the mask to “extract” the bit from the status. For example, if the bit indicating the PLL lock weights 16, the mask should be set to PhaseLockedStatusMask=16 (or 0x10 in hexadecimal). If the device flags that the PLL lock occurs when the above bit is zero, with a negated logic, then we should set PhaseLockedStatusBitNegate =1.

An alternative methodology to test the PLL lock offered by Satsagen in case the status byte (or word) does not provide it, is to send a command and analyze the result of that command. With the CmdGetPhaseLocked field, we define the command to send to the device, and with RegEx2MatchMessagePhaseLocked, the regular expression to use to match the result when the PLL lock occurs. For example, if the command to test the PLL lock is LOCK?, then we set CmdGetPhaseLocked=LOCK?, and if the answer is simply the number 1 for the lock and 0 for the unlock, then we will have to set RegEx2MatchMessagePhaseLocked=[1]. If CmdGetPhaseLocked is defined, the mask on the status byte seen previously will have no effect.

It is also possible to adjust the timing of the aforementioned lock verification mechanism, whether using the status byte or a command. Using the timeoutPhaseLock field, we define the timeout in milliseconds after which, if the above methods have not detected the lock, the procedure goes into error and the application stops, informing the user. With usSleepPhaseLockWaitCycle, we define the wait in microseconds between one test and the other until a positive response is received or the timeout seen previously expires. This parameter is useful for not needlessly overloading the device with requests.

In the worst case scenario where the device does not provide any method to check the lock status, it is possible to insert a fixed delay in milliseconds after sending the commands, quantifiable based on checks that should be performed manually, for example by sending the commands with the GPIB terminal available in the Satsagen application. These delays can be specified with the following fields:

msSleepAfterCWTurnONOFF wait in milliseconds after sending CW ON or OFF command

msSleepAfterSetPwrOut wait in milliseconds after sending the power output command

msSleepAfterSetVFO waits in milliseconds after sending the set frequency command

Identical in syntax to the lock check just seen, there are as many fields available to inquire the device’s ready status, which can be used before sending new commands. In order, DeviceReadyStatusMask, DeviceReadyStatusBitNegate, CmdGetDeviceReady, RegEx2MatchMessageDeviceReady, timeoutDeviceBusy, and usSleepDeviceBusyWaitCycle.

Always similar in syntax, the following fields are also available for checking for errors: ErrorStatusMask, ErrorStatusBitNegate, CmdTestError, and RegExTestError. In this case, the parameters related to timeouts and waits could not be used, while two fields allow you to read from the device a description of the error just encountered: CmdGetError and RegExGetError.

The above control fields for lock, device ready, and error presence must be activated in the “sections” relating to the main commands of CW ON and OFF, output power setting, and frequency setting. This is done by setting the fields testPhaseLockedxxx, testDeviceReadyBeforexxx, testDeviceReadyAfterxxx, and testErrorxxx to 1.

The configuration example for a PLL template seen previously will become the following, complete with lock, ready, and error control fields:

[CUSTOMGPIBPLL]
;;;Definizione generale del dispositivo
DeviceAddr=19
fGEN=2000000000
TXAttGEN=-60
XO_FREQUENCY=10000000
REFTXPWR=12
MINFREQTX=2000000000
MAXFREQTX=18000000000
MINTXATT=-110
MAXTXATT=0
TXATTNSTEP=1
;;;Definizione dei test su lock PLL, device ready ed error
PhaseLockedStatusMask=16
PhaseLockedStatusBitNegate=1
timeoutPhaseLock=3000
usSleepPhaseLockWaitCycle=20000
;;;-------------------------------------------------------
DeviceReadyStatusMask=8
DeviceReadyStatusBitNegate=0
timeoutDeviceBusy=3000
usSleepDeviceBusyWaitCycle=20000
;;;-------------------------------------------------------
ErrorStatusMask=2
ErrorStatusBitNegate=0
;;;Definizione dei comandi principali e attivazione dei test
testDeviceReadyBeforeCWONOFF=1
CmdCWON=RF1
CmdCWOFF=RF0
testErrorCWONOFF=1
testDeviceReadyAfterCWONOFF=1
testPhaseLockedCWONOFF=1
;;;---------------------------------------------------------
testDeviceReadyBeforeSetPwrOut=1
CmdDefSetPwrOut=PL%PWRDBMDEC%DB
testErrorSetPwrOut=1
testDeviceReadyAfterSetPwrOut=1
testPhaseLockedSetPwrOut=1
;;;---------------------------------------------------------
testDeviceReadyBeforeSetVFO=1
CmdDefSetVFO=CW%FREQHZ%HZ
testErrorSetVFO=1
testDeviceReadyAfterSetVFO=1
testPhaseLockedSetVFO=1

Finally, among the device status control fields (which only have a visual function) are those that allow you to read the temperature or monitor the oven of the device’s reference crystal, updating the color and information in the main Satsagen window via the LED located next to the Power On button.

Specify with CmdReadTemp the command to send to obtain the device temperature, for example, CmdReadTemp=TEMP?. At the same time, specify RegEx2DecodeMessageReadTemp with the regular expression that allows to extract from the response to the previous command the temperature value including sign and decimal part, for example, RegEx2DecodeMessageReadTemp=([-+]?\d+(?:.\d+)?)

If the device does not provide a temperature reading command, but via a status byte bit if the oven of the reference crystal has reached the operating temperature, then OvenStatusMask can specify the mask of the bit in question, for example if it is the bit with weight 4, OvenStatusMask=4 and if it is negated, i.e. zero when the oven is at temperature, add OvenStatusBitNegate=1.

Start/end connection commands, and an alternative to serial poll

With the CmdInit and CmdEndConn fields, you can specify any commands to send to the device when connecting and disconnecting Satsagen. With CmdInitResponseToTrace=1, you activate the sending of the response of the CmdInit command to the trace log; this can be useful if the CmdInit sends a command to query the device version, which can then be read in the Satsagen trace.

Finally, it is possible to have Satsagen use an alternative method to the GPIB serial poll to read the status byte (or word), if available from the device. With the CmdGetDeviceStatus field, you define the command to send to obtain the status byte, and with RegEx2DecodeDeviceStatus, the regular expression to use to match the numerical value of the status byte, RegEx2DecodeDeviceStatus=\d?, for example.

Power Meter Template

Power Meter templates allow Satsagen to drive Power Meters on the GPIB BUS. They have a unique section called CUSTOMGPIBPM.

The mandatory fields that need to be customized to drive the Power Meters on the GPIB BUS are:

• DeviceAddr: GPIB address
• REFGAIN0: offset from reading. With this field, we can specify an offset in dB that Satsagen will apply to the reading before displaying it. Normally, REFGAIN0=0 should be set to zero, but it can be set to an offset value for device calibration if the device does not provide it internally.
• MINFREQRX: Specify with this field the minimum frequency in Hz of the Power Meter device.
• MAXFREQRX: Specify with this field the maximum frequency in Hz of the Power Meter device.
• MAXINPUT: indicates the maximum power allowed by the Power Meter, expressed in dBm
• DYNAMICRANGE: the dynamics of the Power Meter expressed in dB. For example, with DYNAMICRANGE=106 and the previous field MAXINPUT=6, the Power Meter can measure from -100 dBm to +6 dBm.
• nreadsmeanTSA: is the number of readings for calculating the average for each TSA scan point if the Power Meter is used as an RX device in an SNA configuration, i.e., combined with a second device with the role of TX, tracking generator.
• CmdReadPwr: This is the command to send to the device to perform the power reading.
• RegEx2DecodeMessageReadPwr: is the regular expression to use to extract (match) the reading value from the response of the previous command (CmdReadPwr).

A minimal template INI file for operation with Power Meters could therefore look like the following:

DeviceAddr=8
REFGAIN0=0
MINFREQRX=1000000
MAXFREQRX=200000000
MAXINPUT=6
DYNAMICRANGE=106
nreadsmeanTSA=1
CmdReadPwr=IPW,TRG
RegEx2DecodeMessageReadPwr=([-+]?\d+(?:\.\d+)?)

The control fields CmdGetDeviceReady, DeviceReadyStatusMask, CmdTestError, and CmdGetError, already seen in the previous chapter of the PLL template, can also be used with the same syntax in the configuration for the Power Meters. The fields that activate the controls for the Power Meters are: testDeviceReadyBeforeRead, testErrorRead, and testDeviceReadyAfterFailedRead.

The above configuration example will then become the following if the control fields are completed:

;;;Definizione generale del dispositivo
DeviceAddr=8
REFGAIN0=0
MINFREQRX=1000000
MAXFREQRX=200000000
MAXINPUT=6
DYNAMICRANGE=106
nreadsmeanTSA=1
;;;Definizione dei test su device ready ed error
DeviceReadyStatusMask=8
DeviceReadyStatusBitNegate=0
timeoutDeviceBusy=3000
usSleepDeviceBusyWaitCycle=20000
;;;-------------------------------------------------------
ErrorStatusMask=2
ErrorStatusBitNegate=0
;;;Definizione del comando principale e attivazione dei test
testDeviceReadyBeforeRead=1
CmdReadPwr=IPW,TRG
testErrorRead=1
RegEx2DecodeMessageReadPwr=([-+]?\d+(?:\.\d+)?)
testDeviceReadyAfterFailedRead=1

Finally, it is also possible to use the following fields, identical in syntax to those already seen in the previous chapter, PLL Template:

CmdInit, command sent when connecting, and CmdInitResponseToTrace, if it is 1, it sends the CmdInit response to the trace log. CmdEndConn, command sent when disconnecting. CmdGetDeviceStatus, the alternative command to the serial poll status byte, and RegEx2DecodeDeviceStatus, a regular expression to match the numerical value of the status. CmdReadTemp is the command to read the device temperature, and RegEx2DecodeMessageReadTemp is to extract the double value of the temperature with a regular expression. OvenStatusMask, an alternative to the previous command, status bit that determines if the oven is at temperature, and OvenStatusBitNegate to deny it.

GPIB Terminal

Satsagen includes a terminal with which you can “talk” to the device connected to GPIB for debugging/troubleshooting purposes.

To open the terminal, click Open GPIB terminal from the View menu, even with Satsagen in Power Off.

At this point, the application will present a list of available interfaces:

Select the desired interface and double-click or click Ok.

Once connected, a terminal will open in verbose mode from where you can send commands either to the interface (preceded by ++) or directly to the device at the default address, 1.

To change the address in use, give the command ++addr x , where x is the GPIB device number. With ++help, we get the list and description of the interface commands preceded by ++. For a complete description, refer to the AR488 documentation.

Remember to close the terminal at the end of the operations to free up the serial port, to let Satsagen connect to the device and control it.

How Backspace Works in the GPIB Terminal

You will probably find that the backspace key has no effect when using the terminal, or the cursor appears to move back, but in the line buffer, this does not happen, so if you use it to correct a command, it will still be sent to the device incorrectly.

To solve this problem, you need to edit the AR488.ino file in the AR488 sources and add the following lines that enable backspace to work.

 // handle the backspace in verbose mode - albfer 21/12/2024
      case 0x7f:
      case 0x8:
      if(isVerb && pbPtr)
        pbPtr--;
        else
        {
        addPbuf(c);
        isEsc = false;
        }
      break;  

The above lines should be inserted inside the parseInput(char c) function, from the line following switch(c){ to obtain the first lines of this function in this way:

uint8_t parseInput(char c) {

  uint8_t r = 0;

  // Read until buffer full
  if (pbPtr < PBSIZE) {
    if (isVerb && c!=LF) dataPort.print(c);  // Humans like to see what they are typing...
    // Actions on specific characters
    switch (c) {
      // handle the backspace in verbose mode - albfer 21/12/2024
      case 0x7f:
      case 0x8:
      if(isVerb && pbPtr)
        pbPtr--;
        else
        {
        addPbuf(c);
        isEsc = false;
        }
      break;        
      // Carriage return or newline? Then process the line
      case CR:
      case LF:
.
.
.

Recompile with the Arduino environment and reload to the interface.

The SATSAGEN RX/TX correction tables also called compensation/linearization tables are used to fix some lack of the supported devices, mainly for:

• Absence of an automatic leveling control ALC
• Poor linearity of the LNA, mixer, and other RF components

The goal is to obtain the device output power as the user set within +/- 1dB of tolerance in the whole device frequency range, and the same reliable levels displayed to the Spectrum Analyzer scope.

The tables are text files in INI format located in the Documents/satsagen/settings directory and loaded in memory at the application power on.

The complete pathname of the tables is specified in the Level correction tab under Settings:

The tables can be enabled/disabled from the same tab with the following checkboxes:

The TX level correction check enables the output leveling for the Generator, Sweeper, and Spectrum Analyzer with Tracking (TSA).

The RX level correction TSA check enables the read level compensation for the Spectrum Analyzer with tracking.

The RX level correction SA check enables the read level compensation for the Spectrum Analyzer only.

The following two examples are made using an ADALM-PLUTO with a loopback cable running a TSA scan for the whole range frequency with the correction tables enabled and not:

The tables are precompiled and deployed with the Satsagen setup with all the supported device characterization made using some device samples. However, customization may be necessary, we’ll see how to do this later.

The standard TX linearization table file name distributed with the SATSAGEN setup is curvecorrTX.ini.

In a simplified way, the TX linearization table contains a list of entries Hz=dB for each supported device where the Hz is the frequency and dB is the variation compared to the corrected expected power at that frequency: a minus dB value corresponds to a final increment of TX power. Other fields are available, we’ll see them later.

The TX linearization table acts on the TX device attenuator, by correcting with increments or decrements the output power.

The RX compensation table acts on levels read from the device by correcting it passively instead, so for example, if the device reads -40 dBm and should be -30 dBm, the RX compensation table increments of -10 dB to display the corrected value of -30 dBm on the spectrum.

The standard RX compensation table file name distributed with the SATSAGEN setup is curvecorrRX_PLUTOCGT.ini.

In both RX/TX tables cases, an interpolation occurs if the test frequency is between two table entries.

The INI Edit Tool

It is possible to edit the correction tables’ INI files with an editor like Notepad for customizing purposes, but it is a hell.

Another way, but only a bit more user-friendly, is using the INI Edit Tool included in Satsagen.

Always make a backup copy of your INI files before using the INI Edit tool.

To use the tool, open it from the Level correction tab under Settings by clicking the INI Edit Tool button.

It is useful to leave the INI Edit Tool open, closing the Settings window only, to use it during the Spectrum Analyzer operations.

This tool is like a database table editor. The tool window comprises an editable grid at the top, a navigator bar at the bottom, a list containing the devices supported, and some function buttons.

The table starts empty and the device table selected corresponds to the first device supported, the ADALM-PLUTO.

You can start by editing a new table, selecting other devices, or importing an existing one with the Import button.

You can save to INI files with the Export button. All functions are related only to the selected device, e.g., if you made an export, only that table will be modified on the destination INI file specified.

When you export to the active configured INI file, this is automatically reloaded, and the changes become running.

Follow an example of using the INI Edit Tool to modify an entry of the RX correction table and view the result live (Prerequisite: a configured ADALM-PLUTO USB or Ethernet connected with a loopback cable.):

• Make a backup copy of the curvecorrRX_PLUTOCGT.ini file in documents\satsagen\settings
• Go to Settings, Level correction tab, and open the INI Edit Tool
• Close the Settings window leaving the INI Edit Tool window open
• Import the curvecorrRX_PLUTOCGT.ini file from the documents\satsagen\settings directory with the INI Edit Tool
• Setup and run a TSA scan as shown in the following screenshot

• Modify an entry, like the 1190 MHz from -4 dB to -10 dB
• Confirm the modification with the Post button from the navigator toolbar
• Export to the curvecorrRX_PLUTOCGT.ini file confirming the overwrite
• It should be visible on the display the modification applied:

• Restore the entry with the original value of -4 dB and export to the curvecorrRX_PLUTOCGT.ini file again

Deep on the RX/TX correction table fields

The RX correction table fields

Freq: frequency in Hz
cordB: dB correction as explained above
min_GAdB and max_GAdB: specify the RX Gain range scope
type: 0 for fundamental frequency correction entries
           1 for fundamental frequency additional correction *
           2 for third harmonic frequency correction entries
           3 for fifth harmonic frequency correction entries
          12 for third harmonic frequency additional correction
          13 for fifth harmonic frequency additional correction

port: 0 for all the entries, except for devices that have multiple channels, like Pluto rev C/D, in this case, 0 means all ports, 1 only for the first channel ports, and 2 only for the second channel ports

With the min_GAdB and max_GAdB fields, it is possible to specify an RX Gain range where the Hz and CordB fields act. These fields are useful for characterizing specific non-linearity device behaviors linked to RX gain ranges.

The 1, 12, and 13 types are additional correction entries, useful to specify specific characterization within frequency ranges of the 0, 2, and 3 types of entries.

*Type 1 entries have a special feature: the Hz field of type 1 entries does not refer to the frequency of the spectrum but to the frequency of the receiver LO. They can therefore be used to describe additional corrections depending on the frequency of the local oscillator. This corresponds for example to the center frequency set when using the Spectrum Analyzer.

The following simple example of the RX compensation table describes a linear compensation that starts from 1 MHz to 1 GHz with a 10 dB ending correction. The two entries of type 1 describe an additional correction of +4 dB within the 300 MHz to 400 MHz range for the 0 to 10 RX gain db range only.

The TX correction table fields

Freq: frequency in Hz
cordB: dB correction as explained above
min_GAdB and max_GAdB: specify the TX power Gain range scope only for entries of type 1.
type: 0 for fundamental frequency correction entries
           1 for fundamental frequency additional correction within the TX power range specified by min_GAdB and max_GAdB columns
           2 for third harmonic frequency correction entries (used by the NF/G analyzer only)
port: 0 for all the entries, except for devices that have multiple channels, like Pluto rev C/D, in this case, 0 means all ports, 1 only for the first channel ports, and 2 only for the second channel ports

How to write a correction table

Creating a correction table requires a lot of dedication and time, and last but not least, some needed tools to complete this task are not always available in our labs.

Normally you don’t need to create a table from scratch, because these are already included in the distribution for all supported devices, rather it’s about customization. However, it can be useful to see how to create a new table to understand the use of all the table fields.

Prerequisites

• A reliable supported device like an ADALM-PLUTO can speed up the operations.
• A calibrated synthetized generator with a sweeper option
• A calibrated power meter or a calibrated Spectrum Analyzer

If the table to be created is for a device that has a frequency range that falls partly within that of an ADALM-PLUTO then it is best to use an ADALM-PLUTO primarily as a reference instrument and use a synthetized generator with a sweeper option, a Power Meter and a Spectrum Analyzer for the remaining frequency range not covered.

An example of table creation from scratch

We want to create an RX compensation table for the RTL-SDR V4 device.

Generally, The first step is to write the RX side’s fundamental type entries (type 0). These entries will describe the device’s behavior in its fundamental frequency range. E.g., for AD936x-based devices it is from about 55 MHz to about 6 GHz, for R82x-based devices, like the RTL-SDR V4 with the up-converter option, it is from about 500 kHz to about 28 MHz for the HF range, and from about 28 MHz to about 1700 MHz for the VHF/UHF range. The next step should be to write the RX side’s harmonic type entries (type 2,3,12 and 13), but now only the fundamental type entries are needed for the RTL-SDR V4 device.

Connect an ADALM-PLUTO to an RTL-SDR V4 device with a loopback cable and two 10 dB attenuators, so the Pluto acts as a TX reference appliance.

Setup SATSAGEN as follows:

Power On SATSAGEN and start the Spectrum Analyzer w/Tracking with the following setup:

Wait about 10 minutes to let the devices enter at a steady temperature and the discipline XO function syncs well the TX frequency to the RX device frequency.

The resultant trace should be the device RX curve characterization with a -30 dB offset.

You could copy the result as a new RX compensation table by subtracting the -30 dB offset constant from the values ​​and you would be done.

SATSAGEN includes a feature that aids us in this task to reduce the manual drastically, the following chapter explains how to export the last completed TSA scan to a Correction Table:

Export the last completed TSA scan to a Correction Table

SATSAGEN version 0.9.1.0 includes a feature that exports the TSA scan result to a correction table.

This feature can be used when at least one scan is completed and available.

To start the export use the menu item File->Export->Export last completed TSA scan to the RX (or TX) Correction Table.

If you export to the RX correction table, it is assumed that the device under test is the RX and the TX device used in the scan is the reference. The data will be saved in the INI file defined as File INI RX correction in Settings, Level correction tab.

If you export to the TX correction table it is assumed that the device under test is the TX, then the data will be saved in the INI file defined as File INI TX correction.

To complete the work started in the previous chapter, we choose the Export last completed TSA scan to the RX Correction Table option. The following dialog box will open:

The top part of the dialog contains the Min GadB, Max GadB, Type, and Port target fields. We can leave these fields unchanged to create the compensation table for the fundamental type entries for the RTL-SDR v4 device.

The lower part of the dialog contains the Min step dB and Offset dB fields. The Min step dB field allows you to define the minimum step in dB for creating a new entry in the destination table to significantly reduce the number of entries created compared to the definition of the source scan. The Offset dB field is automatically calculated by subtracting the RX Gain value from the TX Pwr value.

Then, keeping the fields in the dialog box unchanged and clicking on OK, SATSAGEN will sequentially read the result of the 512 scan points and create as many entries in the RX correction table with the characteristics defined in the upper part of the window, subtracting the Offset dB from the values ​​and verifying that at least one Offset dB step is respected between one entry and another.

The destination table must be empty for the fields defined in the upper part of the dialog, otherwise the export function stops and displays an error. This check is performed to protect against the corruption of existing tables.

Once the export and creation of the RX compensation table are complete, the following confirmation message will be displayed.

We still have to create entries in the RX compensation table for the remaining frequency range from 0 to 50 MHz not covered by the ADALM-PLUTO reference device just used.

How to create a RX correction table using an external sweep generator

To continue the previous work of characterizing the RTL-SDR V4 device we now need to configure an external calibrated sweep generator.

Configure the sweep generator to sweep slowly at about 1 MHz per second over the range of about 0 to 50 MHz, with an output of -30 dBm CW.

Connect the RTL-SDR V4 to the sweep generator keeping the 10 dB attenuator.

Leave the Satsagen configuration unchanged, as used in the previous paragraph.

Run the Spectrum Analyzer with the Max Hold checked with the following setup.

Let it run for a few minutes until the spectrum is sufficiently defined.

Zoom the spectrum to highlight the most level changes and note them.

You should get a list similar to this:

• Make a backup copy of the curvecorrRX_PLUTOCGT.ini file in documents\satsagen\settings
• Go to Settings, Level correction tab, and open the INI Edit Tool
• Close the Settings window leaving the INI Edit Tool window open
• Import the curvecorrRX_PLUTOCGT.ini file from the documents\satsagen\settings directory with the INI Edit Tool
• Select the RTL-SDR V4 device from the device model list
• Insert the above entries at the top of the table, decreasing the dBm levels of the -30 dB offset.

• Export to the curvecorrRX_PLUTOCGT.ini file confirming the overwrite

A further tuning

One odd behavior I noticed in the RTL-SDR V4 device, which may not be visible in a scan like the one used above, is a reading increase of about 5 dB when the Spectrum Analyzer center frequency is set up from about 500 kHz to exactly 2200 kHz.

A couple of type 1 entries illustrated in the chapter Deep on the RX/TX correction table fields added at the end table can be used to correct this problem:

A TX linearization table creation from scratch

To create a TX linearization table of a supported device in SATSAGEN, proceed exactly in the same way as illustrated in the previous example, where the compensation table for the RTL-SDR V4 device was created, with the only difference that the devices must be inverted!

So, for the frequency range covered by ADALM-PLUTO, this will be configured as an RX device in the Devices tab in Settings, and the device under test as a TX device. The export to the TX correction table will be performed at the end of the scanning procedure

For the range not covered by ADALM-PLUTO, the SATSAGEN Generator/Sweeper is configured to perform a scan in the required range and an external calibrated Spectrum Analyzer is connected to the TX device to obtain the Max Hold curve to be manually written in the TX correction INI file using the INI Edit tool.

Notes on the correction tables compiling

The Satsagen application reads the tables sequentially from the first record to the last. The application does not run an entry sort. The by-frequency field entry sorting task, from the min device frequency to the max device frequency is left to the user. In addition, the user should pay attention to the group by fields: the entries must be grouped by the port field, type field, and the min_GAdB and max_GAdB range.

The following image is an example that includes a set of entries correctly sorted and grouped by: