Signal Hound BB60C User manual

BB60A and BB60C Application
Programming Interface (API)
Programmers Reference Manual

Signal Hound | Overview
1
BB60A and BB60C Application Programming Interface (API)
Programmers Reference Manual
2015, Signal Hound, Inc.
35707 NE 86th Ave
La Center, WA 98629 USA
Phone [phone] • Fax [phone]
Version 3.0
6/24/2015
Requirements, Operation, Function Definitions, Examples

2
Overview | Signal Hound
Table of Contents
Overview ...........................................................................................................................................4
Legend......................................................................................................................................................................4
Contact Information.................................................................................................................................................4
Build/Version Notes...........................................................................................................................4
What’s New in Version 3.0.......................................................................................................................................5
What’s New in version 2.0 .......................................................................................................................................5
Updating From Version 1.2 or Later ........................................................................................................................5
Requirements ....................................................................................................................................5
Theory of Operation...........................................................................................................................6
Opening a Device .....................................................................................................................................................6
Configuring the Device.............................................................................................................................................6
Initiating the Device .................................................................................................................................................6
Retrieve Data from the Device.................................................................................................................................7
Abort the Current Mode ..........................................................................................................................................7
Closing the Device....................................................................................................................................................7
Calibration................................................................................................................................................................7
Modes of Operation...........................................................................................................................8
Swept Analysis .........................................................................................................................................................8
Real-Time Analysis ...................................................................................................................................................9
I/Q Streaming...........................................................................................................................................................9
Gain and Attenuation in the Streaming Mode .................................................................................................10
Audio Demodulation..............................................................................................................................................10
Scalar Network Analysis .........................................................................................................................................10
Sweeping versus Streaming..............................................................................................................11
Multi-Threading...............................................................................................................................11
Multiple Devices and Inter-process Device Management ..................................................................11
API Functions...................................................................................................................................12
bbGetSerialNumberList..........................................................................................................................................12
bbOpenDeviceBySerialNumber .............................................................................................................................12
bbOpenDevice........................................................................................................................................................13
bbCloseDevice........................................................................................................................................................14
bbConfigureAcquisition .........................................................................................................................................14
bbConfigureCenterSpan.........................................................................................................................................15
bbConfigureLevel ...................................................................................................................................................16
bbConfigureGain ....................................................................................................................................................16
bbConfigureSweepCoupling ..................................................................................................................................17
bbConfigureWindow..............................................................................................................................................19
bbConfigureProcUnits............................................................................................................................................19
bbConfigureIO........................................................................................................................................................20
bbConfigureDemod................................................................................................................................................21
bbConfigureIQ........................................................................................................................................................22
bbConfigureRealTime ............................................................................................................................................23
bbInitiate................................................................................................................................................................24

Signal Hound | Overview
3
bbFetchTrace .........................................................................................................................................................25
bbFetchRealTimeFrame .........................................................................................................................................26
bbFetchAudio.........................................................................................................................................................27
bbFetchRaw ...........................................................................................................................................................27
bbQueryTraceInfo ..................................................................................................................................................29
bbQueryRealTimeInfo ............................................................................................................................................30
bbQueryTimestamp ...............................................................................................................................................30
bbQueryStreamInfo ...............................................................................................................................................31
bbAbort..................................................................................................................................................................31
bbPreset.................................................................................................................................................................32
bbSelfCal ................................................................................................................................................................33
bbSyncCPUtoGPS ...................................................................................................................................................34
bbGetDeviceType...................................................................................................................................................34
bbGetSerialNumber ...............................................................................................................................................35
bbGetFirmwareVersion..........................................................................................................................................35
bbGetDeviceDiagnostics ........................................................................................................................................36
bbAttachTg.............................................................................................................................................................36
bbIsTgAttached ......................................................................................................................................................37
bbConfigTgSweep ..................................................................................................................................................37
bbStoreTgThru .......................................................................................................................................................38
bbSetTg ..................................................................................................................................................................39
bbGetTgFreqAmpl..................................................................................................................................................39
bbGetAPIVersion....................................................................................................................................................40
bbGetErrorString....................................................................................................................................................40
Error Handling .................................................................................................................................41
Device Connection Errors ......................................................................................................................................41
Appendix .........................................................................................................................................41
Code Examples.......................................................................................................................................................41
Common...........................................................................................................................................................41
Sweep Mode ....................................................................................................................................................42
Real-Time Mode ...............................................................................................................................................42
I/Q Streaming Example ....................................................................................................................................43
Using a GPS Receiver to Time-Stamp Data ............................................................................................................44
Code Example...................................................................................................................................................45
Bandwidth Tables...................................................................................................................................................46

4
Overview | Signal Hound
Overview
The manual is a reference for the Signal Hound BB60C/A application programming interface (API). The
API provides a set of C routines used to control the Signal Hound BB60A and BB60C. The API is C ABI
compatible, so it can be called from a number of other languages and environments such as Java, C#,
Python, C++, Matlab, and Labview.
This manual will describe the requirements and knowledge needed to program to the API. If you are
new to the API you should read the sections in this order: Build/Version Notes, Requirements, Theory of
Operation, and Modes of Operation.
If you want to start programming immediately, the appendix contains a number of code examples.
The Build/Version Notes details the available builds for the API and notes major changes to API versions.
The Requirements section details the physical and operational needs to use the API.
The Theory of Operation section details how to interface the device and covers every major component
a program will implement when interfacing a Signal Hound broadband device.
The Modes of Operation section attempts to teach you how to use the device in each of its operational
modes, from the required functions, to interpreting the data the device returns.
The API Functions section covers every function in depth. The knowledge learned in the Theory and
Modes of Operation sections will help you navigate the API functions.
The Appendix provides various code examples and tips.
Legend
Broadband Device A Signal Hound BB-series spectrum analyzer.
Device Shortened for broadband device, for brevity.
Instantaneous Bandwidth The usable bandwidth at the intermediate frequency of the device.
20MHz for the BB60A. 27MHz for the BB60C.
RBW Resolution Bandwidth
VBW Video Bandwidth
Contact Information
We are interested in your feedback and questions. Please report any issues/bugs as soon as possible.
We will maintain the most up to date API on our website. We encourage any and all criticisms or ideas.
We would love to hear how you might improve the API.
All programming and API related questions should be directed to [e-mail]
All hardware/specification related questions should be directed to [e-mail]
Build/Version Notes
Windows builds for x86 and x64 are available
As of Version 3.0.5 a 64-bit Linux API build is available.
The Windows builds are compiled with Visual Studio 2012 and any application using this library will
require distributing the VS2012 redistributable libraries.
Build notes for the Linux API are provided in the Linux SDK found on the Signal Hound website.

Signal Hound | Requirements
5
What’s New in Version 3.0
Version 3.0 coincides with the release of the SpikeTM, Signal Hounds latest spectrum analyzer software.
With this release comes the ability to open specific BB60C devices. BB60A devices lack the firmware to
perform this task. See bbGetSerialNumberList and bbOpenDeviceBySerialNumber for more information.
What’s New in version 2.0
Version 2.0 and greater introduces support for the BB60C as well as numerous performance
improvements and flexible I/Q data streaming (see Modes of Operation: I/Q Streaming). The API can
target both the BB60A and BB60C with virtually no changes to how one interfaces the API.
Updating From Version 1.2 or Later
This section contains notes of interest for users who are currently using version 1.2 of the API and who
are updating their code base to use version 2.0.
Function names and the API file names may have changed from an earlier version. This is due to
making the API device agnostic. Functionally the API remains the same, so simply updating to the
newer naming scheme will be all that is necessary to interface a newer API.
Intermediate frequency (IF) streaming has been replaced with I/Q streaming but IF streaming can
still be performed. See bbInitiate for more information on how to set up IF streaming.
bbQueryDiagnostics has been deprecated and replaced with bbGetDeviceDiagnostics. This change
removes unnecessary access to hardware diagnostic information specific to the BB60A.
Requirements
Windows Development Requirements
Windows 7/8
Windows C/C++ development tools/environment. Preferably Visual Studio 2008 or later. If
Visual Studio 2012 is not used, then the VS2012 redistributables will need to be installed.
The API header file. (bb_api.h)
The API library (bb_api.lib) and dynamic library (bb_api.dll) files.
Linux Development Requirements
64-bit Linux operating system. (Tested and developed on Ubuntu 14.04)
Modern C++ compiler (Built using g++)
The API header file. (Included in SDK)
The API shared library (Included in SDK)
FTDI USB shared library (Included in SDK and available for download from manufacturer)
libusb-1.0 shared library (Available from most package managers)
Administrator(root) access to either run applications which use the API or install rules to allow
non-root access to the device.
For full requirements and installation information, see the README in the Linux SDK.
General Requirements
A basic understanding of RF spectrum analysis.
A Signal Hound BB60 spectrum analyzer.
Dual / Quad core Intel I-series processors, preferably 2nd generation (Sandy Bridge) and later.
Real-time analysis may be inadequate on hardware less performant than this. Most aspects

6
Theory of Operation | Signal Hound
other than real-time analysis will perform as expected with no issues on the suggested
hardware.
Theory of Operation
The flow of any program interfacing a broadband device will be as follows.
1) Open a USB 3.0 connected BB60A/BB60C.
2) Configure the device.
3) Initiate a device mode of operation
4) Retrieve data from the device
5) Abort the current mode of operation
6) Close the device
-Calibration
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.
Let’s look at each step in detail of a typical program interfacing a Signal Hound spectrum analyzer.
Opening a Device
Before attempting to open a device programmatically, it must be physically connected to a USB 3.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 function bbOpenDevice provides this functionality. This function
returns an integer handle to the device which was opened. Up to eight devices may be connected and
interfaced through our API using the handle. The integer handle returned is required for every function
call in the API, as it uniquely identifies which broadband device you are interfacing.
Configuring the Device
Once the device is opened, it must be configured. The API provides a number of configuration routines
and many operating states. Most of this manual discusses configuring the device. In the Modes of
Operation section, each operating mode and its relevant configuration routines are discussed. All
configuration functions will modify a devices’global state. Device state is discussed more in the next
section (Initiating the Device). The API provides configurations routines for groupings of related
variables. Each configuration function is described in depth in the API functions section. All relevant
configuration routines should be invoked prior to initialization to ensure a proper device state. Certain
functions will enforce boundary conditions, and will note when either a parameter is invalid or has been
clamped to the min/max possible value. Ensuring each routine configures successfully is required to
ensure proper device operation. Different modes of operation will necessitate different boundary
conditions. Each function description will detail these boundaries. We have also provided helpful macros
in the header file to help check against these boundaries.
Initiating the Device
Each device has two states.
1) A global state set through the API configuration routines.
2) An operational/running state.

Signal Hound | Theory of Operation
7
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 broadband spectrum analyzer has multiple modes of operation. The bbInitiate 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 bbInitiate is called on a device that is already initialized, the current mode is aborted
before entering the new specified mode. The operational modes are described in the Modes of
Operation section.
Retrieve Data from the Device
Once a device has been successfully initialized 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.
Abort the Current Mode
Aborting the operation of the device is achieved through the bbAbort function. This causes the device
to cancel any pending operations and return to an idle state. Calling bbAbort explicitly is never
required. If you attempt to initiate an already active device, bbAbort will be called for you. Also if you
attempt to close an active device, bbAbort will be called. There are a few reasons you may wish to call
bbAbort manually though.
-Certain modes combined with certain settings consume large amounts of resources such as
memory and the spawning of many threads. Calling bbAbort 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 bbCloseDevice.This function attempts to safely close the USB 3.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.
Calibration
Calibration is an important part of the device’s operation. The device is temperature sensitive and it is
important a device is re-calibrated when significant temperature shifts occur (+/- 2 °C).Signal Hound
spectrum analyzers are streaming devices and as such cannot automatically calibrate itself without
interrupting operation/communication (which may be undesirable). Therefore we leave calibration to
the programmer. The API provides two functions for assisting with live calibration,
bbGetDeviceDiagnostics and bbSelfCal. bbGetDeviceDiagnostics can be used to retrieve the internal
device temperature at any time after the device has been opened. If the device ever deviates from its
temperature by 2 degrees Celcius or more we suggest calling bbSelfCal. Calling bbSelfCal requires the

8
Modes of Operation | Signal Hound
device be open and idle. After a self-calibration occurs, the global device state is undefined. It is
necessary to reconfigure the device before continuing operation. One self-calibration is performed upon
opening the device.
Note: The BB60C does not require the use of bbSelfCal for device calibration. Instead, for the BB60C, if
the device deviates in temperature, simply call bbInitiate again which will re-calibrate the device at its
current operating temperature.
Modes of Operation
Now that we have seen how a typical application interfaces with the API, let’s examine the different
modes of operation the API provides. Each mode will accept different configurations and have different
boundary conditions. Each mode will also provide data formatted to match the mode selected. In the
next sections you will see how to interact with each mode.
For a more in-depth examination of each mode of operation (read: theory) refer to the Signal Hound
BB60C/A user manual.
Swept Analysis
Swept analysis represents the most traditional form of spectrum analysis. This mode offers the largest
amount of configuration options, and returns traditional frequency domain sweeps. A frequency domain
sweep displays amplitude on the vertical axis and frequency on the horizontal axis.
The configuration routines which affect the sweep results are
bbConfigureAcquisition() –Configuring the detector and linear/log scaling
bbConfigureCenterSpan() –Configuring the frequency range
bbConfigureLevel() –Configuring reference level and internal attenuators
bbConfigureGain() –Configuring internal amplifiers
bbConfigureSweepCoupling() –Configuring RBW/VBW/sweep time
bbConfigureWindow() –Configuring window functions for certain RBWs
bbConfigureProcUnits() –Configure VBW processing
Once you have configured the device, you will initialize the device using the BB_SWEEPING flag.
This mode is driven by the programmer, causing a sweep to be collected only when the program
requests one through the bbFetchTrace() function. The length of the sweep is determined by a
combination of resolution bandwidth, video bandwidth and sweep time.
Once the device is initialized you can determine the characteristics of the sweep you will be collecting
with bbQueryTraceInfo(). This function returns the length of the sweep, the frequency of the first bin,
and the bin size (difference in frequency between any two samples). You will need to allocate two arrays
of memory, representing the minimum and maximum values for each frequency bin.
Now you are ready to call bbFetchTrace(). This is a blocking call that does not begin collecting and
processing data until it is called. Typical sweep times might range from 10ms –100ms, but certain
settings can take much more time (full spans, low RBW/VBWs).

Signal Hound | Modes of Operation
9
Determining the frequency of any point returned is determined by the function where ‘n’ is a zero based
sample point.
𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 𝑜𝑓 𝑛′𝑡ℎ 𝑠𝑎𝑚𝑝𝑙𝑒 𝑝𝑜𝑖𝑛𝑡 𝑖𝑛 𝑟𝑒𝑡𝑢𝑟𝑛𝑒𝑑 𝑠𝑤𝑒𝑒𝑝 = 𝑠𝑡𝑎𝑟𝑡𝐹𝑟𝑒𝑞 + 𝑛 ∗ 𝑏𝑖𝑛𝑆𝑖𝑧𝑒
Real-Time Analysis
The API provides the functionality of an online real-time spectrum analyzer for the full instantaneous
bandwidth of the device (20MHz for the BB60A, 27MHz for the BB60C). Through the use of FFTs at an
overlapping rate of 50%, the spectrum results have no blind time (100% probability of intercept) for
events as short as 50ns. Due to the demands in processing, restrictions are placed on resolution
bandwidth. Video bandwidth is non-configurable.
The configuration routines which affect the spectrum results are
bbConfigureAcquisition() –Configure detector and linear/logarithmic scale
bbConfigureCenterSpan() –Configure center frequency and span of no more than
the devices maximum instantaneous bandwidth, specified in the header macros.
bbConfigureLevel() –Configure reference level and attenuators
bbConfigureGain() –Specify internal amplifiers
bbConfigureSweepCoupling() –Specify RBW
bbConfigureRealTime() –Specify the real-time update rate and frame scale
The number of sweep results far exceeds a program’s capability to acquire, view, and process, therefore
the API combines sweeps results for a user specified amount of time. It does this in two ways. One, is
the API either max holds or averages the sweep results into a standard sweep. Also the API creates an
image frame which acts as a density map for every sweep result processed during a period of time. Both
the sweep and density map are returned at rate specified by the function bbConfigureRealTime. For a
full example of using real-time see Appendix: Code Examples: Real-Time Mode.
I/Q Streaming
The API is capable of providing programmers with a continuous stream of digital I/Q samples from the
device. The digital I/Q stream consists of interleaved 32-bit floating point I/Q pairs scaled to mV. The
digital samples are amplitude corrected providing accurate measurements. The I/Q data rate at its
highest is 40MS/s and can be decimated down by a factor of up to 128 (in powers of two). Each
decimation value further reduces the overall bandwidth of the I/Q samples, so the API also provides a
configurable band pass filter to control the overall passband of a given I/Q data stream. The I/Q data
stream can also be tuned to an arbitrary frequency value.
Configuration routines used to prepare streaming are
bbConfigureCenterSpan() –Set the center frequency of the I/Q data stream.
bbConfigureLevel() –See Gain and Attenuation in the Streaming Mode
bbConfigureGain() –See Gain and Attenuation in the Streaming Mode
bbConfigureIO() –Configure the BNC ports of the BB60.
bbConfigureIQ() –Specify the decimation and bandwidth of the I/Q data stream.
Once configured, initialize the device with the BB_STREAMING mode and the BB_STREAM_IQ flag. Data
acquisition begins immediately. The API buffers ~3/4 second worth of digital samples in circular buffers.
It is the responsibility of the user application to poll the samples via bbFetchRaw() fast enough to

10
Modes of Operation | Signal Hound
prevent the circular buffers from wrapping. We suggest a separate polling thread and synchronized data
structure (buffer) for retrieving the samples and using them in your application.
NOTE: Decimation / Filtering / Calibration occur on the PC and can be processor intensive on certain
hardware. Please characterize the processor load.
I/Q streaming is also the only mode in which you can time stamp data (See Appendix:Using a GPS
Reciever to Time-Stamp Data) and determine external trigger locations (See bbFetchRaw()).
Gain and Attenuation in the Streaming Mode
Gain and attenuation are used to control the path the RF takes through the device. Selecting the proper
gain and attenuation settings greatly affect the dynamic range of the resulting signal. When gain and
attenuation are set to automatic, the reference level is used to control the internal amplifiers and
attenuators. Choosing a reference level slightly above the maximum expected power level ensures the
device engages the best possible configuration. Manually configuring gain and attenuation should only
be used after testing and observation.
Audio Demodulation
Audio demodulation can be achieved using bbConfigureDemod(), bbFetchAudio(), and
bbInitiate().See bbConfigureDemod() to see which types of demodulation can be performed.
Settings such as gain, attenuation, reference level, and center frequency affect the underlying signal to
be demodulated.
bbConfigureDemod() is used to specify the type of demodulation and the characteristics of the filters.
Once desired settings are chosen, use bbInitiate() to begin streaming data. Once the device is
streaming it is possible to continue to change the audio settings via bbConfigureDemod() as long as the
updated center frequency is not +/- 8 MHz of the value specified when bbInitiate() was called. The
center frequency is specified in bbConfigureDemod().
Once the device is streaming, use bbFetchAudio() to retrieve 4096 audio samples for an audio sample
rate of 32k.
Scalar Network Analysis
When a Signal Hound tracking generator is paired together with a BB60C spectrum analyzer, the
products can function as a scalar network analyzer to perform insertion loss measurements, or return
loss measurements by adding a directional coupler. Throughout this document, this functionality will be
referred to as tracking generator (or TG) sweeps.
Scalar Network Analysis can be realized by following these steps
1. Ensure a Signal Hound BB60C spectrum analyzer and tracking generator is connected to your PC.
2. Open the spectrum analyzer through normal means.
3. Associate a tracking generator to a spectrum analyzer by calling bbAttachTg. At this point, if a TG
is present, it is claimed by the API and cannot be discovered again until bbCloseDevice is called.

Signal Hound | Sweeping versus Streaming
11
4. Configure the device as normal, setting sweep frequencies and reference level (or manually
setting gain and attenuation).
5. Configure the TG sweep with the bbConfigTgSweep function. This function configures TG sweep
specific parameters.
6. Call bbInitiate with the BB_TG_SWEEP mode flag.
7. Get the sweep characteristics with bbQueryTraceInfo.
8. Connect the BB and TG device into the final test state without the DUT and perform one sweep
with bbFetchTrace. After one full sweep has returned, call bbStoreTgThru with the
TG_THRU_0DB flag.
9. (Optional) Configure the setup again still without the DUT but with a 20dB pad inserted into the
system. Perform an additional full sweep and call bbStoreTgThru with the TG_THRU_20DB.
10. Once store through has been called, insert your DUT into the system and then you can freely call
the get sweep function until you modify the configuration or settings.
If you modify the test setup or want to re-initialize the device with a new configuration, the store
through must be performed again.
Sweeping versus Streaming
All modes of operation fall within two categories, sweeping and streaming. In any sweeping mode, the
device operates only when requested. For example, requesting a trace triggers a single trace acquisition,
otherwise the device and API are idle. Sweeping is very responsive and switching between different
types of sweep modes is very quick. Streaming modes are modes in which the API is continually
receiving a stream of digitized IF from the device. The device is never idle in these modes. Once this
process is started, it takes about ½ second to abort any streaming operation, to ensure all
channels/pipes have been cleared and the device is ready for its next command.
Note: Entering a streaming mode is nearly instantaneous if the device is coming from an idle or sweep
mode.
Depending on your application this ½ second abort time may not be acceptable (switching bands
quickly/changing settings quickly). If you are interested in utilizing a streaming mode to fully
characterize a signal of interest, a good approach might be to start in the standard sweep mode and
switch to a streaming mode once you identified a frequency of interest.
Multi-Threading
The BB60 API is not thread safe. A multi-threaded application is free to call the API from any number of
threads as long as the function calls are synchronized. Not synchronizing your function calls will lead to
undefined behavior.
Multiple Devices and Inter-process Device Management
The API is capable of managing multiple devices within one process. In each process the API manages a
list of open devices to prevent a process from opening a device more than once. You may open multiple
devices by specifying the serial number or allowing the API to discover them automatically.

12
API Functions | Signal Hound
If you wish to use the API in multiple processes it is the user’s responsibility to manage a list of devices
to prevent the possibility of opening a device twice from two different processes. Two processes
communicating to the same device will result in undefined behavior. The two functions responsible for
opening new devices are not thread safe and access to those functions must also be restricted by the
programmer. One possible way to manage inter-process information like this is to use a named mutex
on a Windows system.
API Functions
bbGetSerialNumberList
Get a list of available devices connected to the PC
bbStatus bbGetSerialNumberList(int serialNumbers[8], int *deviceCount);
Parameters
serialNumbers A pointer to an array of at minimum 8 contiguous integers. It is
undefined behavior if this array pointed to by serialNumbers is not 8
integers in length.
deviceCount Pointer to an integer.
Description
This function returns the devices that are unopened in the current process. Up to 8 devices max will be
returned. The serial numbers of the unopened devices are returned for BB60Cs and a zero is returned
for each BB60A. The array will be populated starting at index 0 of the provided array. All unused values
will be populated with the sentinel value of -1. The integer pointed to by deviceCount will equal the
number of devices reported by this function upon returning.
Return Values
bbNoError No error, function returned successfully.
bbNullPtrErr One required pointer parameter to this function is null.
bbOpenDeviceBySerialNumber
Open one Signal Hound device
bbStatus bbOpenDeviceBySerialNumber(int *device, int serialNumber);
Parameters
device Pointer to an integer. If successful, the integer pointed to by device will
contain a valid device number which can be used to identify a device for
successive API function calls.
serialNumber User provided serial number.
Description

Signal Hound | API Functions
13
The function attempts to open the device with serial number specified by the serialNumber parameter.
Only BB60C devices can be opened by specifying the serial number. If the serial number specified is zero,
the first BB60A found will be opened. If a device cannot be found matching the provided serial number,
the function will return unsuccessful. If a device is opened successfully , a handle to the device will be
returned through the device pointer which can be used to target that device for other API calls.
The function when successful is a blocking call and takes about 3 seconds to finish.
If you wish to target multiple devices or wish to target devices across processes see Multiple Devices
and Inter-process Device Management.
Return Values
bbNoError No error, device number opened and returned successfully.
bbNullPtrErr The parameter device is null. The device is not opened.
bbDeviceNotOpenErr The device was unable to open. This can be returned for many reasons
such as the device is not physically connected, eight devices are already
open or there is an issue with the USB 3.0 connection.
bbUncalibratedDevice This message is returned as a warning and notes the device has not
been calibrated. If you see this warning, contact Signal Hound.
bbOpenDevice
Open one Signal Hound broadband device
bbStatus bbOpenDevice(int *device);
Parameters
device If successful, a device number is returned. This number is used for all
successive API function calls.
Description
This function attempts to open the first BB60A/C it detects. If a device is opened successfully , a handle
to the device will be returned through the device pointer which can be used to target that device for
other API calls.
This function when successful, takes about 3 seconds to perform.
If you wish to target multiple devices or wish to target devices across processes see Multiple Devices
and Inter-process Device Management.
Return Values
bbNoError No error, device number opened and returned successfully.
bbNullPtrErr The parameter device is null. The device is not opened.

14
API Functions | Signal Hound
bbDeviceNotOpenErr The device was unable to open. This can be returned for many reasons
such as the device is not physically connected, eight devices are already
open or there is an issue with the USB 3.0 connection.
bbUncalibratedDevice This message is returned as a warning and notes the device has not
been calibrated. If you see this warning, contact Signal Hound.
bbCloseDevice
Close one Signal Hound broadband device
bbStatus bbCloseDevice(int device);
Parameters
device Handle to the device being closed.
Description
This function is called when you wish to terminate a connection with a device. Any resources the device
has allocated will be freed and the USB 3.0 connection to the device is terminated. The device closed
will be released and will become available to be opened again.
Return Values
bbNoError The device closed successfully.
bbDeviceNotOpenErr The device specified is not open.
bbConfigureAcquisition
Change the detector type and choose between linear or log scaled returned sweeps
bbStatus bbConfigureAcquisition(int device, unsigned int detectorType, unsigned int
verticalScale);
Parameters
device Handle to the device being configured.
detectorType Specifies the video detector. The two possible values for detector type
are BB_AVERAGE and BB_MIN_AND_MAX.
verticalScale Specifies the scale in which sweep results are returned int. The four
possible values for verticalScale are BB_LOG_SCALE, BB_LIN_SCALE,
BB_LOG_FULL_SCALE, and BB_LIN_FULL_SCALE.
Description
detectorType specifies how to produce the results of the signal processing for the final sweep.
Depending on settings, potentially many overlapping FFTs will be performed on the input time domain
data to retrieve a more consistent and accurate final result. When the results overlap detectorType
chooses whether to average the results together, or maintain the minimum and maximum values. If
averaging is chosen, the min and max trace arrays returned from bbFetchTrace() will contain the same
averaged data.

Signal Hound | API Functions
15
The verticalScale parameter will change the units of returned sweeps. If BB_LOG_SCALE is provided
sweeps will be returned in amplitude unit dBm. If BB_LIN_SCALE is return, the returned units will be in
milli-volts. If the full scale units are specified, no corrections are applied to the data and amplitudes are
taken directly from the full scale input.
Return Values
bbNoError Function completed successfully.
bbDeviceNotOpenErr The device handle provided points to a device that is not open.
bbInvalidDetectorErr The detector type provided does not match the list of accepted values.
bbInvalidScaleErr The scale provided does not match the list of accepted values.
bbConfigureCenterSpan
Change the center and span frequencies
bbStatus bbConfigureCenterSpan(int device, double center, double span);
Parameters
device Handle to the device being configured.
center Center frequency in hertz.
span Span in hertz.
Description
This function configures the operating frequency band of the broadband device. Start and stop
frequencies can be determined from the center and span.
-start = center –(span / 2)
-stop = center + (span / 2)
The values provided are used by the device during initialization and a more precise start frequency is
returned after initiation. Refer to the bbQueryTraceInfo() function for more information.
Each device has a specified operational frequency range. These limits are BB#_MIN_FREQ and
BB#_MAX_FREQ. The center and span provided cannot specify a sweep outside of this range.
There is also an absolute minimum operating span of 20 Hz, but 200kHz is a suggested minimum.
Certain modes of operation have specific frequency range limits. Those mode dependent limits are
tested against during bbInitiate() and not here.
Return Values
bbNoError Device successfully configured.
bbDeviceNotOpenErr The device handle provided points to a device that is not open.
bbInvalidSpanErr The span provided is less than the minimum acceptable span.
bbFrequencyRangeErr The calculated start or stop frequencies fall outside of the operational
frequency range of the specified device.

16
API Functions | Signal Hound
bbConfigureLevel
Change the attenuation and reference level of the device
bbStatus bbConfigureLevel(int device, double ref, double atten);
Parameters
device Handle to the device being configured.
ref Reference level in dBm.
atten Attenuation setting in dB. If attenuation provided is negative,
attenuation is selected automatically.
Description
When automatic atten is selected, the API uses the ref provided to choose the best gain settings for an
input signal with amplitude equal to reference level. If an atten other than BB_AUTO_ATTEN is specified
using bbConfigureLevel(), the ref parameter is ignored.
The atten parameter controls the RF input attenuator, and is adjustable from 0 to 30 dB in 10 dB steps.
The RF attenuator is the first gain control device in the front end.
When attenuation is automatic, the attenuation and gain for each band is selected independently. When
attenuation is not automatic, a flat attenuation is set across the entire spectrum.
It is recommended to set automatic gain and attenuation and set the reference level to a value slighly
higher than the expected inpu power level.
Return Values
bbNoError Device successfully configured.
bbDeviceNotOpenErr The device handle provided points to a device that is not open.
bbReferenceLevelErr The reference level provided exceeds 20 dBm.
bbAttenuationErr The attenuation value provided exceeds 30 db.
bbConfigureGain
Change the RF/IF gain path in the device
bbStatus bbConfigureGain(int device, int gain);
Parameters
device Handle to the device being configured.
gain A gain setting.
Description
To return the device to automatically choose the best gain setting, call this function with a gain of
BB_AUTO_GAIN.

Signal Hound | API Functions
17
The gain choices for each device range from 0 to BB#_MAX_GAIN.
When BB_AUTO_GAIN is selected, the API uses the reference level provided in bbConfigureLevel() to
choose the best gain setting for an input signal with amplitude equal to the reference level provided.
After the RF input attenuator (0-30 dB), the RF path contains an additional amplifier stage after band
filtering, which is selected for medium or high gain and bypassed for low or no gain.
Additionally, the IF has an amplifier which is bypassed only for a gain of zero.
For the highest gain settings, additional amplification in the ADC stage is used.
Return Values
bbNoError Device successfully configured.
bbDeviceNotOpenErr The device handle provided does not point to an open device.
bbInvalidGainErr This is returned if the gain value is outside the range of possible inputs.
bbConfigureSweepCoupling
Configure sweep processing characteristics
bbStatus bbConfigureSweepCoupling(int device, double rbw, double vbw, double
sweepTime, unsigned int rbwType, unsigned int rejection);
Parameters
device Handle to the device being configured.
rbw Resolution bandwidth in Hz. Use the bandwidth table in the appendix to
determine good values to choose. As of 1.07 in non-native mode, RBW
can be arbitrary. Therefore you may choose values not in the table and
they will not clamp.
vbw Video bandwidth (VBW) in Hz. VBW must be less than or equal to RBW.
VBW can be arbitrary. For best performance use RBW as the VBW.
sweepTime Suggest a sweep time in seconds.
In sweep mode, this value specifies how long the BB60 should sample
spectrum for the configured sweep. Larger sweep times may increase
the odds of capturing spectral events at the cost of slower sweep rates.
The range of possible sweepTime values run from 1ms -> 100ms or
[0.001 –0.1].
In the real-time configuration, this value represents the length of time
data is collected and compounded before returning a sweep. Values for
real-time should be between 16ms-100ms [0.016 –0.1] for optimal use.
In zero span mode this is the length of the returned sweep as a measure
of time. Sweep times for zero span must range between 10us and
100ms. Values outside this range are clamped.

18
API Functions | Signal Hound
rbwType The possible values for rbwType are BB_NATIVE_RBW and
BB_NON_NATIVE_RBW. This choice determines which bandwidth table is
used and how the data is processed. BB_NATIVE_RBW is default and
unchangeable for real-time operation.
rejection The possible values for rejection are BB_NO_SPUR_REJECT and
BB_SPUR_REJECT.
Description
The resolution bandwidth, or RBW, represents the bandwidth of spectral energy represented in each
frequency bin. For example, with an RBW of 10 kHz, the amplitude value for each bin would represent
the total energy from 5 kHz below to 5 kHz above the bin’s center. For standard bandwidths, the API
uses the 3 dB points to define the RBW.
The video bandwidth, or VBW, is applied after the signal has been converted to frequency domain as
power, voltage, or log units. It is implemented as a simple rectangular window, averaging the amplitude
readings for each frequency bin over several overlapping FFTs. A signal whose amplitude is modulated at
a much higher frequency than the VBW will be shown as an average, whereas amplitude modulation at
a lower frequency will be shown as a minimum and maximum value.
Native RBWs represent the bandwidths from a single power-of-2 FFT using our sample rate of 80 MSPS
and a high dynamic range window function. Each RBW is half of the previous. Using native RBWs can
give you the lowest possible bandwidth for any given sweep time, and minimizes processing power.
However, scalloping losses of up to 0.8 dB, occurring when a signal falls in between two bins, can cause
problems for some types of measurements.
Non-native RBWs use the traditional 1-3-10 sequence. As of version 1.0.7, non-native bandwidths are
not restricted to the 1-3-10 sequence but can be arbitrary. Programmatically, non-native RBW’s are
achieved by creating variable sized bandwidth flattop windows.
sweepTime applies to regular sweep mode and real-time mode. If in sweep mode, sweepTime is the
amount of time the device will spend collecting data before processing. Increasing this value is useful for
capturing signals of interest or viewing a more consistent view of the spectrum. Increasing sweepTime
has a very large impact on the amount of resources used by the API due to the increase of data needing
to be stored and the amount of signal processing performed. For this reason, increasing sweepTime also
decreases the rate at which you can acquire sweeps.
In real-time, sweepTime refers to how long data is accumulated before returning a sweep. Ensure you
are capable of retrieving as many sweeps that will be produced by changing this value. For instance,
changing sweepTime to 32ms in real-time mode will return approximately 31 sweeps per second
(1000/32).
Rejection can be used to optimize certain aspects of the signal. Default is BB_NO_SPUR_REJECT, and
should be used in most cases. If you have a steady CW or slowly changing signal, and need to minimize
image and spurious responses from the device, use BB_SPUR_REJECT. If you have a signal between 300
MHz and 3 GHz, need the lowest possible phase noise, and do not need any image rejection,
BB_BYPASS_RF can be used to rewire the front end for lowest phase noise.

Signal Hound | API Functions
19
Return Values
bbNoError Device successfully configured.
bbDeviceNotOpenErr The device handle provided points to a device that is not open.
bbBandwidthErr rbw fall outside device limits.
vbw is greater than resolution bandwidth.
bbInvalidBandwidthTypeErr rbwType is not one of the accepted values.
bbInvalidParameterErr rejection is not one of the accepted values.
bbConfigureWindow
Change the windowing function
bbStatus bbConfigureWindow(int device, unsigned int window);
Parameters
device Handle to the device being configured.
window The possible values for window are BB_NUTALL, BB_BLACKMAN,
BB_HAMMING, and BB_FLAT_TOP.
Description
This changes the windowing function applied to the data before signal processing is performed. In real-
time configuration the window parameter is permanently set to BB_NUTALL. The windows are only
changeable when using the BB_NATIVE_RBW type in bbConfigureSweepCoupling(). When using
BB_NON_NATIVE_RBW, a custom flattop window will be used.
Return Values
bbNoError Device successfully configured
bbDeviceNotOpen The device handle provided points to a device that is not open.
bbInvalidWindowErr The value for window did not match any known value
bbConfigureProcUnits
Configure video processing unit type
bbStatus bbConfigureProcUnits(int device, unsigned int units);
Parameters
device Handle to the device being configured.
units The possible values are BB_LOG,BB_VOLTAGE,BB_POWER, and
BB_BYPASS.
Description
The units provided determines what unit type video processing occurs in. The chart below shows which
unit types are used for each units selection.