SA API
Theory of Operation

The flow of any program interfacing a Signal Hound device will be as follows:

  1. Open a USB 2.0 connected SA44/SA124 spectrum analyzer and obtain a unique handle to the device. The handle will be used for all subsequent function calls.
  2. Configure the device, such as setting the frequency sweep ranges or the I/Q sample rate.
  3. Initiate the device for a particular mode of operation, whether it be frequency domain sweeps or I/Q streaming.
  4. Get data from the device. Which functions are called and what data is returned depends on the mode of operation.
  5. Abort the current mode of operation.
  6. Close the device.

The API provides functions for each step in this process. We have strived to mimic the functionality and naming conventions of SCPIs IviSpecAn Class Specification where possible. It is not necessary to be familiar with this specification but those who are should feel comfortable with our API immediately. The following sections further detail each of the six steps listed above.

Opening a Device

Before attempting to open a device programmatically, it must be physically connected to a USB 2.0 port with the provided cable. Ensure the power light is lit on the device and is solid green. Once the device is connected it can be opened. The functions saOpenDevice and saOpenDeviceBySerialNumber provide this functionality. These functions return an integer ID to the device that was opened. Up to SA_MAX_DEVICES devices may be connected and interfaced through our API using the IDs. The integer ID returned is required for every function call in the API, as it uniquely identifies which device you are interfacing.

First Time Opening a New Device

All Signal Hound SA series spectrum analyzers need two calibration files to operate. These files reside on internal flash memory for newer models, and on older models, on the Signal Hound web server. The files are copied to the host machine the first time a device is opened on a particular machine. The files are saved at C:/ProgramData/SignalHound cal_files. For models that need the calibration data from the Signal Hound server, the first time the device is opened the host PC needs to have an active network connection. Downloading this file from our server, or pulling it from the device internal flash can cause the first invocation of saOpenDevice to block for up to 10 seconds. Once these files are on a host PC this process does not need to be performed again. If the devices have been used in Spike, then the calibration files will already exist on the host PC.

Configuring the Device

Once the device is opened, it may be configured. The API provides a number of configuration routines for its many operating states. Configuration routines modify the device global state, such as the sweep frequency or I/Q sampling rate. The configurations do not take effect until the device is initiated.

Initiating the Device

Each device has two states:

  1. A global state set through the API configure routines.
  2. An operational/running state.

All configurations functions modify the global state which does not immediately affect the operation of the device. Once you have configured the global state to your liking, you may re-initiate the device into a mode of operation, in which the global state is copied into the running state. At this point, the running state is separate and not affected by future configuration function calls.

The saInitiate function is used to initialize the device and enter one of the operational modes. The device can only be in one operational mode at a time. If saInitiate is called on a device that is already initialized, the current mode is aborted before entering the new specified mode.

Retrieving Data from the Device

Once a device has been successfully initiated you can begin retrieving data from the device. Every mode of operation returns different types, and different amounts of data. The Modes of Operation section will help you determine how to collect data from the API for any given mode. Helper routines are also used for certain modes to determine how much data to expect from the device.

Aborting the Current Mode

Aborting the operation of the device is achieved through the saAbort function. This causes the device to cancel any pending operations and return to an idle state. Calling saAbort explicitly is never required. If you attempt to initiate an already active device, saAbort will be called for you. Also if you attempt to close an active device, saAbort will be called. There are a few reasons you may wish to call saAbort manually though.

  • Certain modes combined with certain settings consume large amounts of resources such as memory and the spawning of many threads. Calling saAbort will free those resources.
  • Certain modes such as Real-Time Spectrum Analysis consume many CPU cycles, and they are always running in the background whether or not you are collecting and using the results they produce.
  • Aborting an operational mode and spending more time in an idle state may help to reduce power consumption.

Closing the Device

When you are finished, you must call saCloseDevice. This function attempts to safely close the USB 2.0 connection to the device and clean up any resources which may be allocated. A device may also be closed and opened multiple times during the execution of a program. This may be necessary if you want to change USB ports, or swap a device.