SATSAGEN v.0.9.3.3 / GPIB support

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 CmdGetDeviceReadyDeviceReadyStatusMaskCmdTestError, 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: testDeviceReadyBeforeReadtestErrorRead, 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

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:

A scan with the TX level correction and the RX level correction TSA both enabled.

In this screenshot, the same scan with the TX level correction and the RX level correction TSA both disabled.

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.

The INI Edit Tool with the curvecorrTX.ini file loaded

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

port0 for all the entries, except for devices that have multiple channels, like Pluto rev C/D, in this case, means all ports, only for the first channel ports, and 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)
port0 for all the entries, except for devices that have multiple channels, like Pluto rev C/D, in this case, means all ports, only for the first channel ports, and 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.

An RTL-SDR V4 device connected to an ADALM-PLUTO through a loopback cable

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.

A late 1960s HP 8601A generator/sweeper

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:

0 MHz-53.40 dBm
1,5 MHz-46,90 dBm
1,6 MHz-51,90 dBm
6 MHz-42,60 dBm
9,3 MHz-38,50 dBm
11,6 MHz-37,80 dBm
21 MHz-42,40 dBm
25 MHz-47,50 dBm
27,8 MHz-53,90 dBm
28,2 MHz-44,50 dBm
50 MHz-46,20 dBm
  • 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: