The information in this
guide is furnished for
informational use only
and is subject to change
without notice. ThinkRF
Corporation assumes no
responsibility or liability
for any errors or
inaccuracies that may
appear in this document.
No part of this
publication may be
reproduced, published,
stored in an electronic
database, or transmitted,
in any form or by any
means, electronic,
mechanical, recording,
or otherwise, for any
purpose, without the
prior written permission
of ThinkRF Corporation.
Trademarks
ThinkRF, the ThinkRF
logo and R5500 are
trademarks of ThinkRF
Corporation.
The following are
trademarks or registered
trademarks of their
respective companies or
owners:
Windows, Windows XP /
Microsoft Corporation
All other brand or
product names are
trademarks or registered
trademarks of their
respective companies or
owners.
ThinkRF Corp
390 March Road
Kanata, ON K2K 0G7
(613) 369-5104
HARDWARE WARRANTY AND LIMITATION OF LIABILITY
Read this warranty carefully before you use the product.
WSA5000 and R5500 Real Time Spectrum Analyzers are warranted for
workmanship and materials for a period of one (1) year from the date of shipment as
identified by the Customer’s packing slip or carrier waybill. ThinkRF reserves the
right to void the warranty on any equipment that has been altered or damaged due
to Customer negligence, unauthorized repair, misuse of equipment, evidence of
physical or environmental damage, transportation abuse or removal of any ThinkRF
identification labels or serial numbers.
It will remain the responsibility of the Customer, having obtained a Return Material
Authorization (RMA) and shipping instructions from ThinkRF, to return, at the
Customer's expense, the defective unit to ThinkRF’s repair facilities. ThinkRF will
incur shipping charges for the return of warranty repaired equipment. The RMA
number can be secured by calling ThinkRF Customer Service and Support (1-613369-5104). If the product does not fall within ThinkRF’s warranty period or the
product is found to be functioning as designed, then under the terms of ThinkRF’s
warranty policy, all costs of repairs and shipping will be charged directly to the
Customer. ThinkRF will warrant repaired units for a period of 90 days from date of
shipment from ThinkRF to the Customer. If the remaining period on the original
hardware warranty is greater than 30 days, then ThinkRF will honor this remaining
warranty period.
THINKRF EXPRESSLY DISCLAIMS ALL OTHER WARRANTIES AND
CONDITIONS, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT
LIMITATION, WARRANTIES, CONDITIONS OR REPRESENTATIONS OF
WORKMANSHIP, MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, DURABILITY, OR THAT THE OPERATION OF THE HARDWARE OR
LICENSED SOFTWARE WILL BE ERROR FREE. IN NO EVENT WILL THINKRF
BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES.
USE OF PRODUCTS IN HIGH RISK ACTIVITIES
THINKRF PRODUCTS ARE INTENDED FOR STANDARD INDOOR COMMERCIAL
USE. WITHOUT THE APPROPRIATE NETWORK DESIGN ENGINEERING, THEY
MUST NOT BE USED FOR ANY “HIGH RISK ACTIVITY”, as described in this
paragraph. Customer acknowledges and agrees that the products supplied
hereunder are not fault-tolerant and are not designed, manufactured or intended for
use or resale as on-line control equipment in hazardous environments requiring fail
safe performance including but not limited to the operation of nuclear facilities,
aircraft navigation or communication systems, air traffic control, direct life support
machines, or weapons systems, in which the failure of products could lead directly to
death, personal injury, or severe physical or environmental damage, all of which are
examples of “High Risk Activity”. THINKRF AND ITS SUPPLIERS EXPRESSLY
DISCLAIM ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR HIGH
RISK ACTIVITIES.
GNU General Public License
This device contains free firmware: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 2 of the License, or (at your option) any later version. This
program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details. GNU General Public License is available at
http://www.gnu.org/licenses.
Table 39: Max, Min, and Required Multiples for SPP and Samples-per-word for Different Data Output
Format .................................................................................................................................... 70
Preface
This preface describes the audience for, the organization of, and conventions used in this
document. It also identifies related documentation and explains how to access electronic
documentation.
Audience
This document is written for software developers wishing to develop and/or maintain a
software interface to the R5500 and who have a basic understanding, familiarity and
experience with network test and measurement equipment.
Conventions
This section describes the conventions used in this document.
Grayed-out Font
Indicates a command or a feature is not yet available in the current release.
Courier Font
Illustrates this is an example for a command or a concept.
Light Blue Font
Contains hyperlink to the referenced source that can be clicked on.
Normal Bold Font
When used within a sentence or a paragraph, it emphasizes an idea to be paid attention
to particularly.
Red Font
Conveys special information of that section.
Note: This symbol means take note. Notes contain helpful suggestions or references to
additional information and material.
Caution: This symbol means be careful. In this situation, you might do something that
could result in equipment damage or loss of data.
Warning: This symbol means danger. You are in a situation that could cause bodily
injury. Before you work on any equipment, be aware of the hazards involved with
electrical circuitry and be familiar with the standard practices for preventing accidents.
Obtaining Documentation and Releases
You can access the most current ThinkRF documentation and the latest release bundles
at http://www.thinkrf.com/resources.
Document Feedback
Please send your comments about this document or our other documentation to
support@thinkrf.com.
Thank you, we appreciate your comments.
Obtaining Technical Assistance
The ThinkRF Support website provides online documents for resolving technical issues
with ThinkRF products at http://www.thinkrf.com/resources.
For all customers who hold a valid end-user license, ThinkRF provides technical
assistance 9 AM to 5 PM Eastern Time, Monday to Friday. Contact us at
support@thinkrf.com or by calling +1.613.369.5104.
Before contacting Support, please have the following information available:
•R5500's serial number and product version, which are located on the identification
label on the R5500's underside.
•The firmware version running on the R5500.
•Versions of ThinkRF software you are using, potentially including the S240, API
libraries to third-party applications.
•The operating system and version you are using.
R5500 Functional Overview
This section overviews the R5500's functionality and protocols used, and summarizes the
SCPI command sets for controlling the individual functions.
Note: This is a living and evolving document. We welcome your feedback.
The features and functionality described in this section may exist in the current product
firmware release or are scheduled for a future product firmware release (grayed out
commands and/or text). Please refer to Appendix F: SCPI Commands Quick Reference
for the complete list of commands and the availability information. No hardware upgrade
is required at each feature release (unless specified though unlikely).
System Overview
The R5500 Real Time Spectrum Analyzer (RTSA) is a high-performance softwaredefined RF receiver, digitizer and analyzer, as illustrated in Figure 1. With patentpending software-defined RF receiver technology, the RTSA provides industry leading
combined sensitivity, tuning range, instantaneous bandwidth (IBW) and scan rate.
Additionally, it provides real-time sophisticated triggering and capture control.
R5500 Functional Overview
The R5500 is designed for stand-alone, remote and/or distributed wireless signal
analysis. It is ideal for monitoring, management and surveillance of transmitters, whether
they are in-building or spread across a geographic area. Applications include, but are not
limited to:
•5G wireless technology;
•research;
•test and measurement;
•monitoring;
•OEM integration.
The R5500 hardware largely consists of:
•a hybrid super-heterodyne, direct-conversion and direct-digitization RF receiver
front-end (RFE);
•receiver front end inputs and outputs to support clock synchronization, and IF
outputs for high-end digitization;
•a 125 MSample/sec 14-bit wideband (WB) ADC with a dynamic range of greater
than 70 dB;
•a 300 kSample/sec 24-bit narrowband (NB) ADC with a dynamic range in excess of
100dB;
•a Xilinx's Zynq FPGA with built-in dual-core ARM®-based processor, Gigabit
Ethernet interface and custom embedded digital signal processing (DSP) logic;
•1 GB of DDR3 shared between firmware and real-time caching of digitized data;
•a general purpose input/output (GPIO) port.
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide12
R5500 Functional Overview
Figure 1: R5500 Functional Block Diagram
ThinkRF's products conform with standardized protocols for interoperability. ThinkRF
provides application programming interfaces (APIs) designed for easy integration with
third-party applications. Standard protocols include the Standard Commands for
Programmable Instruments (SCPI) protocol for controlling and obtaining status from the
RTSA and the VITA-49 Radio Transport (VRT) protocol for digitized data and its
associated context information.
In addition, API libraries, written in C/C++, Python, MATLAB and NI LabVIEW, are
provided for quick interfacing, data acquisition and as well as for spectral analysis with
MATLAB® applications. The Python API is built within the PyRF development framework
and is open-source under BSD licensing. PyRF handles the low-level details of real-time
acquisition, signal processing and visualization, and provides feature rich libraries,
example applications and source code, all specific to the requirements of signal analysis.
Usage examples are provided through the available source codes of the Graphical User
Interfaces (GUI) or any applications included in each release package.
Refer to Appendix A for how to connect to a RTSA and Appendix B for the protocol on
how to find any RTSAs available on the local network. The source code provided for the
aforementioned APIs and GUIs/applications would serve as examples.
The R5500 provides system level control and status commands as defined in Table 1.
Table 1: System Level Control/Status Commands
SCPI CommandDescription
:SYSTemPage 44
:ABORtAborts the current data capturing process and puts the RTSA system into
a normal manual mode (i.e. sweep, trigger, and streaming will be aborted)
:CAPTure
13ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
R5500 Functional Overview
SCPI CommandDescription
:MODE?Gets the current capture mode of the RTSA (i.e. sweeping, streaming or
block mode)
:COMMunicate
:LAN<commands>Subset of commands for configuring/querying RTSA's LAN settings
:ERRorReturns the error code and messages from the SCPI error/event queue
[:NEXT]?
:ALL?
:FLUShClears the R5500's internal data storage buffer of any remaining data that
has not transferred out of the RTSA
:LOCK
:HAVE?Returns the current lock state of the task specified
:REQuest?Requests the R5500 to provide a lock on a specific task such that only the
application that has the lock can perform the task
:OPTions?Returns comma separated 3-digit values to represent the hardware
option(s) or features available with a particular RTSA model
:SYNC
:MASTer[?]Sets a RTSA unit to be the master or slave for a synchronization trigger
system with multiple units. Affects :TRIGger:TYPE PULSe or WORD.
:WAIT[?]Sets the delay time in nanoseconds that the system must wait after
receiving the trigger signal before performing data capture
:VERSion?Returns the SCPI version number that the instrument complies with
:DATE[?]Sets/reads date
:TIME[?] Sets/reads time
:ADJustAdjust the system time relative to it's current time
:SYNC[?]Sets/ gets the System time synchronization source via network or SCPI,
or disable
:STATus?Status of the time synchronization
:STATusPage 55
:OPERationReturns the standard Operation Status Register (OSR) for any event
[:EVENt]?
:CONDition?
:ENABle[?]
:PRESETPresets the R5500 (similar to *RST)
:QUEStionableReturns the standard Questionable Status Register (QSR) for any event
[:EVENt]?
:CONDition?
:ENABle[?]
:TEMPerature?Returns the R5500's internal ambient temperature
See SCPI Command Set section (page 40 onward) for further details on the commands.
Caution pertaining to multi-user: The current firmware version of the R5500 allows
multiple applications to connect to the unit simultaneously but it does not support
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide14
R5500 Functional Overview
independent sessions. Therefore, the actions of one user may over-write those of
another. This could potentially damage the unit for instance if the front-end's gain were
incorrectly set. If multiple applications are connecting to the unit, it is advised that only
one of those is controlling the unit at any time.
The Architecture
The R5500 is an integrated wireless radio receiver and digitizer/analyzer. It has an
embedded capture controller that enables users to:
•define and execute real-time and sophisticated triggers, traces and sweeps;
•configure the radio RFE and DSP in association with those traces or sweeps; and
•time-stamping and data output for captures.
Traces and sweeps are controlled by the capture controller as illustrated in the upper
portion of Figure 2. A trace and a sweep are defined as a single (block or continuously
streamed) capture and a series of captures, respectively, each with their associated
hardware configurations.
The R5500 supports different RFE modes of operation and subsequent DSP capabilities
as per Table 2 and as described in the following subsections.
15ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
R5500 Functional Overview
Table 2: Radio RFE Modes and DSP Data Output Formats
1
Mode
DescriptionFreq Range
(MHz)
ZIF
SH
SHN
HDR
DD
HIF
1
The RFE Mode availability is product dependent.
2
For SH and SHN modes, when the decimation is used, a frequency shift of 35MHz for non-WBIQ
models will be applied automatically to bring the R5500's center frequency back to the zero IF.
Thus, the data output will be I and Q.
3
In DD mode, there is no frequency tuning except for performing frequency shift. When
decimation is applied, the decimation will be around the zero frequency.
Zero-IF Receiver50 - max100I14 Q
Super-Heterodyne
50 - max40I
Receiver
SH Receiver with
50 - max10I
narrower BW
High Dynamic Range
50 - max0.1I
Receiver
Direct Digitization
0.1 - 50
Receiver
High IF Receiver50 - max--–––
3
IBW
(MHz)
50I
DSP Data Output Format
NoneCIC/Dec Frequency Shift
14I14 Q14
14
14
24
14
I14 Q
I14 Q
2
14
2
14
--
I
14
I14 Q
I14 Q
I14 Q
I14 Q
14
14
14
14
R5500 complies to VRT protocol for sending digitized IF data packets and their
associated context information depending on the capture mode. It is very important to
follow the VRT's IF Data Packet Class section (page 34) for the exact VRT data output
formats as well as packing method.
RF Receiver Front-End
The lower portion of Figure 2 shows a block diagram of the RFE within the R5500. The
architecture consists of a super-heterodyne (SH) front-end with a back-end that utilizes
an I/Q mixer similar to that in a direct-conversion (or zero-IF) receiver.
Depending on the frequency of the signals being analyzed, one of the three receiver
signal processing paths is selected. Signals in the frequency range 100kHz to 50MHz
are directly digitized, while all other signals are translated to the frequencies of the first IF
block via one of the other two signal processing paths. The IF block consists of a bank of
multiple SAW filters. SAW filter selection depends on the frequency of the input signal.
The output of the SAW filter feeds the I/Q mixer.
The three signal processing paths are further classified into different modes of operation
for the capture engine as shown in Table 2. The radio modes ZIF, SH, SHN and HDR
support tuning the center frequency from 50MHz to the maximum frequency supported by
the particular product model (ex. 8GHz, 18GHz, and 27GHz for R5500-x08, -x18, and
-x27, respectively, where x is a model number variant).
The ZIF, SH and SHN radio modes support a tuning resolution of 10Hz. Digital
frequency shifting is then used to enhance the tuning resolution to the nearest 1Hz
(±0.23Hz). The frequency shifting technology used is an embedded Numerically
Controlled Oscillator (NCO) (a Direct Digital Synthesizer or DDS) as described in the
Digital Down Converter subsection (page 19).
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide16
R5500 Functional Overview
DC
Offset
Fc-50 MHz
Fc+50 MHz
125 MHz
Fc
Analog filter
The HDR radio mode supports a tuning resolution of 10Hz. No further fine tuning is
available.
The remaining radio mode, DD, support 50MHz IBW direct digitization of the baseband
from the external RF IN. Hence, this mode does not support frequency tuning of the
radio although the DSP's frequency shift mode may be applied.
Direct-Conversion Receiver Technology
Direct-conversion (or ZIF) receivers are ideal for signal analysis of wideband waveforms,
such as 4G/LTE, Wi-Fi and Bluetooth. With that benefit comes the drawback of both IQ
and DC offsets which are inherent to direct-conversion technology.
DC Offset Correction
The R5500's WB ADC sampling rate is 125 MSa/s, intermediate frequency (IF) is 0 and
the entire IF bandwidth is 125MHz. The analog filter results in an amplitude roll-off at
approximately +50MHz around the center frequency Fc, as illustrated in Figure 3.
Direct-conversion receivers have a DC offset at the center of the band. The offset is
primarily compensated for in real-time in the receiver hardware but there always is some
residual offset that (depending on the application and bandwidth of interest) might need
to be compensated for in software. Several options such as calibration or dynamic offset
compensation in software have been described in the open literature.
Figure 3: DC Offset with Amplitude Roll-Off at +50MHz
If the application only needs to utilize up to 50MHz of IBW, a simple alternative to DC
offset compensation is to use the SH mode of operation.
IQ Offset Correction
Direct-conversion receivers have phase and/or amplitude offsets between in-phase (I)
and quadrature (Q) components of the baseband signal. Due to this, when an FFT is
performed on digitized baseband data where there is a signal tone present, there will be
an ‘image’ at the same frequency offset from the center frequency as the tone itself. This
is illustrated in Figure 4.
17ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
R5500 Functional Overview
Signal
Image
XdB
Frequen cy
F
c
Frequen cy
F
c
Fc+Fs
Fc-Fs
calibrateIQ
Figure 4: IQ Offset Correction
A correction algorithm would be needed to adjust this offset necessary for signal analysis,
especially for the ZIF mode. The ThinkRF's APIs have included a correction.
Table 3: RF Front-End Control/Status Commands
SCPI CommandDescription
:INPutPage 59
:SOURcePage 61
[:SENSe]Page 62
:ATTenuator[?]
:VARiable[?]
Enables/disables the front-end's attenuation (on some models)
Sets the variable attenuation for R5500-418 and -427
:GAIN[?]Sets the input gain stage for a R5500-418, -427 & their variants
:HDR[?]
:MODE[?]
Sets gain level for the NB ADC of of the HDR signal path
Selects the receiver mode of operation
:REFerence
:PLL[?]
:RESET
:DECimation[?]Sets the decimation rate as an exponent of 2 (i.e. rate = 2
Selects the 10MHz reference clock source
Resets the 10MHz reference selection to INTernal source
0, 1, 2 - 10)
level
where level =
:FREQuency
:CENTer[?]Sets the center frequency of the RFE
:IF?Queries the IF frequencies that are used for the current input mode and
center frequency
:INVersion?Queries if a spectral inversion is required at a given frequency
:LOSCillator?Gets the frequency of the external LO 1, 2 or 3 in corresponding to
current the RTSA's center frequency
:SHIFt[?]Sets the frequency shift value (not available for HDR mode)
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide18
R5500 Functional Overview
SCPI CommandDescription
:LOCK
:REFerence?Queries the lock status of the PLL reference clock
:RF?Queries the lock status of the RFE's PLL
:OUTputPage 66
:MODE[?]Selects the IQ output path to be from the external connector or the
See SCPI Command Set section (page 40 onward) for further details on each set of
commands.
Digital Signal Processing
The R5500 has embedded DSP blocks to provide further signal processing capabilities,
such as DDC with up to 10 levels of decimation and FFT computation.
Digital Down Converter
The DDC block takes the frequency band of interest and shifts it down in frequency, then
provides decimation of the sampling rate to one that is lower and consistent with the
bandwidth of the signal of interest. This enables channelization of signals having
bandwidth smaller than the IBW.
digitizer
Referring to Figure 5, the DDC has two major elements, an NCO (DDS) and a down
sampling with filtering. The NCO generates a complex sinusoid, which is mixed with the
IQ input using a complex multiplier, to shift or offset the signal spectrum from the selected
carrier frequency. This process provides the frequency fine-tuning (and shifting) feature
as mentioned in the previous subsections.
I
Q
in
in
fs
fsfs
I
Q
out
out
NCO (DDS)
Figure 5: DDC Functional Block Diagram
The complex multiplication is then followed by either a finite impulse response (FIR) filter
or cascaded integrator-comb (CIC) filters with a FIR filter combined. The CIC filter has a
‘droop’ associated with it in the passband. In order to compensate for this droop, the CIC
filter is followed by a compensating FIR filter. Each filter type has its own decimator.
19ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
Triggers
R5500 Functional Overview
This whole process effectively reduces the sample rate and filters the signal to remove
adjacent channels, minimize aliasing, and maximize the received signal-to-noise ratio.
Note: The use of the NCO converts the in-phase signal (I data) input of the receiver's
DD, SH and SHN processing paths to complex I and Q data output. See Table 2.
Triggers provide a means of qualifying the storage of captured time domain IQ data
based on an external, periodic or frequency domain event. Triggering can be considered
a means of filtering signals of interest for the purposes of subsequent visualization
and/or analysis.
The following describes the different types of triggers and their common controls.
Selection of different types is mutually exclusive.
Frequency Domain Triggering
Frequency domain triggering relies on the embedded real-time FFT mechanism to
transform the sampled signal from the time domain to the frequency domain. The R5500
uses a 1024 point real-time FFT core embedded within the FPGA to transform 1024 time
domain IQ samples to 1024 frequency domain FFT bins. Each bin is an average of the
spectral activity over a range of 125MHz divided by the DDC decimation rate divided by
the 1024 FFT points.
The frequency domain triggering supported by R5500 is a level trigger type, used to
capture any signal above the noise floor within a specified frequency range. The user
defines a single amplitude level within a frequency range. The frequency range
encompasses all FFT bins with center frequencies within the range defined by START
and STOP. If the sampled signal amplitude exceeds the defined trigger level at any
single sample within the defined frequency range, the trigger will occur and the
subsequent IQ data capture will proceed.
Figure 6 illustrates the association of the time domain and the frequency domain. The
internal frequency domain data lags the time domain data by 1024 samples at the rate of
125 MSa/s. After a trigger event is detected, the subsequent time domain IQ data is then
stored to memory.
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide20
R5500 Functional Overview
The measurable range of the input signal, and the corresponding allowable trigger level
range, varies depending on the selected center frequency, the calibrated reference level
and the attenuation setting. The threshold level error is approximately ±3 dBm or less
when the trigger level is set within the range mentioned in the :TRIGger:LEVel command.
Figure 6: Association between Time and Frequency Domain
See TRIGger Commands (page 67) or SWEep's trigger (page 79) for further details.
Periodic Triggering
Periodic triggering provides a means of capturing a defined amount of IQ data on a
periodic basis. Periodic triggering is typically used for statistical analysis of the captured
signal.
External Triggering
External triggering provides a means of synchronized triggering based on the receiving of
a trigger signal provided via the R5500's GPIO. The trigger “signal” could be a single
pulse, PPS or a sync-word. See Synchronized Sweep (page 24) for additional details.
Caution: The pulse and sync-word is applied to the GPIO's TRIG IN pin, while PPS is
through PPS pin. Contact ThinkRF's Support for details on how to use the GPIO port
prior to connecting anything to the port.
Table 4: Trigger Control/Status Commands
SCPI CommandDescription
:TRIGgerPage 67
:TYPE[?]Sets or disable the trigger type including LEVel | PERiodic | PPS | PULSe
| WORD | NONE
:LEVel[?]Sets the frequency range and amplitude of a frequency domain level
trigger
:PERiodic[?]Sets the time period of a periodic trigger
21ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
See TRIGger Commands (page 67) or SWEep's trigger (page 79) for further details.
Capture Controller
The Capture Controller provides a means of defining and performing simple traces and
complex sweeps. For example, it allows for:
•the definition and execution of a complex sweep;
•the interruption of that sweep;
•the execution of a specific trace; and
•the resumption of the previous sweep.
Caution: The configurations of the capture engine associated with :TRACe and :SWEep
commands are fully independent of each other. A :TRACe command uses the
configurations of the capture engine based on the root :INPut, :SENSe and :TRIGger
commands. It does not use the configurations based on the :SWEep command subset.
Trace Capture Control
The :TRACe capture control initiates the capture, storage and conditionally the sending of
IQ data through triggering when used. It supports both streaming and block mode
capture.
R5500 Functional Overview
The :TRACe:BLOCk (page 69) command initiates a block capture of continuous IQ data
(available to be "pulled" from the R5500 per command issued). Once it is issued, data
will be stored instantly (conditional on triggering), contiguously and reliably and are
available to be read. The maximum size of a block is limited by the memory device in the
RTSA.
The :TRACe:STReam (page 71) command initiates the streaming of IQ data (which is
"pushed" from the R5500). Once it is issued, data packets will be sent instantly
(conditional on triggering) and continuously on best effort basis (in other words, data
might not be continuous from one packet to the next once the internal buffer is full).
The execution of the trace capture could be conditioned by the triggering. The triggering
may be enabled or disabled via the :TRIGger:TYPE command, thereby, supporting freerun or triggered signal searches.
Table 5: Trace Capture Control Commands
SCPI CommandDescription
:TRACePage 68
:BLOCk
:DATA?Initiates the sending of the IQ data captured
:PACKets[?]Sets the number of IQ data packets to be captured per block (a block =
:PACKets * SPP)
:SPPacket[?]Defines the number of samples per VRT packet
:STReam
:STARtInitiates the capture, storage and streaming of IQ data
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide22
R5500 Functional Overview
SCPI CommandDescription
:STOPStops streaming
See TRACe Commands section (page 68) for further details.
Sweep Capture Control
The :SWEep capture control provides the ability to define and execute simple or complex
sweeps. A sweep setup consists of defining a list or multiple lists and executing one of
the defined lists, with each list consisting of one or more entries storing different capture
engine configurations. A list may be edited, deleted and/or executed using the
:SWEep:LIST command set.
The :SWEep:ENTRy commands provide the ability to define the capture engine
configurations equivalent to most of :INPut, :SENSe, :TRACe and :TRIGger commands
for each sweep entry. Sweep entries are identified by an index number and may be
inserted, edited and/or deleted like rows in a table or spreadsheet.
There are slight differences between the configuration options for trace versus sweep
captures. The sweep allows for definition of a range of center frequencies whereby the
center frequency is incremented in frequency by a step value. Level triggers may be
defined over the entire range of center frequencies. Sweeping does not support time
delayed triggers.
In addition, sweep mode data packets, whether VRT context or digitized data, are
“streamed” or “pushed” from the RTSA (similar to :TRACe:STReam).
Table 6: Sweep Capture Control/Status Interface
SCPI CommandDescription
:SWEepPage 72
:LIST
:ITERations[?]Defines the number of times the list is repeated during execution
:STARtBegins execution of the current sweep list from the first entry
:STATus?Get the current sweep status
:STOPStops execution of the current sweep list
:ENTRyAll entry commands operate on the current list
:COPYCopies the settings of an existing sweep entry into the current settings for
quick editing
:COUNt?Gets the number of entries available in the list
:DELETEDeletes the specified entry or all entries
:NEWSets the sweep entry settings to default values
:READ?Gets the settings of an existing sweep entry
:SAVESaves the current editing entry to the end of the list or before the specified
ID location in the list when the integer value is given
:ATTenuatorAs defined in :INPut:ATTenuator, page 59
:VAR[?]As defined in :INPut:ATTenuator:VARiable, page 59
:DECimation[?]As defined in [:SENSe]:DECimation, page 62
23ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
R5500 Functional Overview
SCPI CommandDescription
:FREQuency
:CENTer[?]Defines the center frequency of the RFE or a range of frequencies that
are stepped by the value defined by the :FREQuency:STEP
:STEP[?]Defines the amount of frequency that the center frequency is stepped by
:SHIFt[?]As defined in [:SENSe]:FREQuency:SHIFt, page 65
:GAIN
:HDR[?]As defined in :INPut:GAIN:HDR, page 60
:MODEAs defined in :INPut:MODE, page 61
:DWELl[?] Sets the maximum amount of time waited for a trigger to occur after which
the trigger is aborted
:PPBlock[?]Same as :TRACe:BLOCk:PACKets, page 70
:SPPacket[?]As defined in :TRACe:SPPacket, page 70
:TRIGger
:TYPE[?]As defined in :TRIGger:TYPE, page 67
:LEVel[?]As defined in :TRIGger:LEVel, page 67
:PERiodic[?]As defined in :TRIGger:PERiodic, page 68
See SWEep Commands section (page 72) for further details.
Synchronized Sweep
The R5500 supports a synchronized sweep function for the purposes of comparing the
same signal received via multiple R5500s.
Synchronized sweep is an extension of the external trigger capability. One of the R5500s
in a network is configured to be the master (:SYSTem:SYNC:MASTer ON) and the other
R5500s are configured as slaves (:SYSTem:SYNC:MASTer OFF). The master and
slaves are configured with a sweep list, in which each sweep entry has a synchronization
trigger type (:SWEep:ENTRy:TRIGger:TYPE PULSE | WORD). The synchronization
trigger is generated and delivered from the master's GPIO to that of the slaves to indicate
the beginning of a capture.
Figure 7 provides a synchronization trigger example using sync-word. The master sends
the sync-word when the setup of its front-end has been completed. Master and slaves
are also individually configured with a delay variable (:SYSTem:SYNC:WAIT <nsec> with
a resolution of 8 nsec). This delay wait time accounts for the typical worst-case front-end
setup time and for differences in the synchronization cable length. Master and slaves
then begin the capture upon the expiration of the wait (or delay).
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide24
R5500 Functional Overview
front end setup
capture...........
syncpreamble
front end setupcapture...........
sweep step
MASTER
sent
syncword
received
syncword
delay
delay
setup
and
capture
setup
and
capture
SLAVE
syncpreamble
syncpreamble
front end setup
front end setup
capture...........
missed capture
sweep step
MASTER
sent
syncword
received
syncword
delay
delay
setup
and
capture
setup
and
capture
SLAVE
syncpreamble
The front-end setup time is typically of approximately 200 usec but is variable due to the
embedded running processes. Referring to Figure 8, if the front-end setup time on one
(or more) of the slaves is longer than the combined duration of the master's setup time
plus the sync-word plus the slave's delay, then the slave will miss the beginning of the
capture. The host-side application that is collating the capture data may recognize the
missed capture by noting the timestamps and/or frequency of the capture data within the
associated VRT Receiver Context packets. The rate of sweep versus the amount of
missed captures may be balanced by adjusting the delay values.
Figure 7: Synchronized Sweep using Sync-Word
Figure 8: Synchronized Sweep with a Missed Capture
See SWEep Commands section (page 72) for further interface details or contact
ThinkRF's Support for more information.
25ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
VITA-49 Radio Transport Protocol
VITA-49 Radio Transport Protocol
The section describes the R5500's VRT Information Class as per the "VITA Radio
Transport (VRT) Draft Standard" Specification VITA-49.0 – 2007 Draft 0.21.
Purpose
Convey an arbitrary 100MHz of IF data and associated information from the R5500 to
another equipment using an industrial standard.
R5500's VRT Overview
ThinkRF's VRT supports four different packet streams of information defined and
organized as shown in Figure 9 and Table 7. The streams of packets are sent when the
data capture is started. The context packets carry the R5500 settings information
associated with the immediate following IF data packets.
Receiver Context Stream
Reference Point
Digitizer Context Stream
Extension Context Stream
RECEIVERDIGITIZER
IF Data Stream
Figure 9: Connectivity and 4 Different Packet Streams Supported by R5500
Table 7: The Categories of VRT Packet Streams Supported by ThinkRF's R5500
Standard FormatsCustom Formats
Contents
Context
Data
IF Context Packet Stream
conveys metadata concerning IF Data
Packet Stream and the settings
- Digitizer Context Packet Class Stream
- Receiver Context Packet Class Stream
IF Data Packet Stream
conveys discrete time sampled signal
data
Extension Context Packet Stream
conveys additional Context concerning IF
or Extension Data Packet Stream
- Extension Context Packet Class Stream
Extension Data Packet Stream
conveys any signal or data derived from a
signal
- IF Data Packet Class Stream
- Currently not used
26ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
VITA-49 Radio Transport Protocol
Receiver Context Packet Class Stream
The Receiver Context Packet Class Stream is used to convey informational messages
about changes in the configuration and status of the RF receiver in the R5500.
Digitizer Context Packet Class Stream
The Digitizer Context Class Stream is used to convey information messages about
changes in the configuration and status of the IF digitizer in the R5500.
Extension Context Packet Class Stream
The Extension Context Packet Class Stream is used to convey metadata for the IF Data
Packet Stream, which no provision has been made in the IF Context Packet Stream.
IF Data Packet Class Stream
The IF Data Packet Stream is used to convey complex IQ samples from the digitizer to
devices external to the R5500.
Table 8 summarizes numerically the list of Stream Identifiers used by ThinkRF for
different Packet Class Stream. Each ID will be mentioned in the subsequent
corresponding Packet Class sections.
Table8: A List of Stream Identifiers As Used by ThinkRF for Different Packet Classes
Stream IdentifierPacket Class
0x90000001Receiver Context
0x90000002Digitizer Context
0x90000003IF Data – {I14Q14} Format
0x90000004Extension Context
0x90000005IF Data – {I14} Format
0x90000006IF Data – {I24} Format
Packet Classes and Streams
This section describes in details the rules and structure of those Packet Classes and
Streams. By definition, a series of packets instantiated from the same Packet Class
form a Packet Stream.
Note: All data words in each VRT packets are in big-endian order, and sent MSB first.
Receiver Context Packet Class
This Packet Class is a type of IF Context Packet Class. The packet information conveys
changes in the configuration and status of the R5500's RF receiver.
ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide27
1. Pkt Type shall be set to 0100 to indicate this is a context packet.
2. C shall be set to 0 to indicate there is no Class Identifier in the packet.
3. R shall be set to 00, because they are reserved bits.
4. TSM (TimeStamp Mode) shall be set to 0, indicating that context packet
timestamps are precise.
5. TSI (TimeStamp-Integer) field shall be set to 01, indicating that integer (seconds)
part of the timestamps are in Coordinated Universal Time (UTC).
6. TSF (TimeStamp-Fractional) field shall be set to 10, indicating that the fractional
part of the timestamp measures in real time picosecond resolution.
7. Pkt Count shall start at 0000 and increment once for each context packet, until
reaching 1111 (or 15), where it shall rollover to 0000 on the next count.
8. Pkt Size indicates the total number of 32-bit words in the entire context packet,
including all headers, the context indicator field and context sections.
9. Stream Identifier shall be the 32-bit word, 0x90000001
10. Timestamp - Integer Seconds shall be in UTC format and will represent the
number of seconds occurred since Midnight, January 1, 1970, GMT.
11. Timestamp - Integer Picoseconds shall count the number of picoseconds past
since the last increment of the Timestamp seconds field. See the Picosecond
Timestamp Words Format section for the format.
12. The Context Indicator Field shall follow the format indicated in Table 10.
TSI TSF Pkt CountPkt Size
S
M
Stream Identifier (1 word)
Timestamp - Integer Seconds (1 word)
Timestamp - Integer Picoseconds (2 words)
Context Indicator Field (1 word)
Context Fields (Variable Size)
Table 10: Receiver Context Indicator Field Positions
13. The Context Fields section shall contain a context field for every field that is
indicated to be present in the Context Indicator Field. The fields shall be ordered in the identical order of their occurrence in the Context Indicator Field. See Table
11 for the definition and associated value of each field.
Table 11: Receiver Context Field Definition and Values
Bit NameContext Field# of Words in Field Period of Validity
IContext Field Change Indicator0N/A
RReference Point1Persistent
FRF Reference Frequency2Persistent
GGain1Persistent
TTemperature1Persistent
28ThinkRF R5500 Real Time Spectrum Analyzer Programmer's Guide
VITA-49 Radio Transport Protocol
Context Field Change Indicator
The Context Field Change Indicator is used to indicate when some context value of the
system has changed. One or more of the other bits in the indicator field will be also set,
indicating which values have been changed and have their updated values in the context
fields that follow. It is possible that a context packet may be sent where the Context Field
Change Indicator is set to 0, indicating that no change has occurred.
RF Reference Frequency
The RF Reference Frequency communicates the frequency of origin for the signal. The
value of the RF Reference Frequency shall be expressed in units of Hertz. The RF
Reference Frequency sub-field shall use the 64-bit, two’s-complement format as shown
in Table 12. This field has an integer and a fractional part, with the radix point to the right
of bit 20 in the second 32-bit word. This gives the RF Reference Frequency a range of
±8.79THz with a resolution of 0.95μHz.
Integer RF Ref. Value (11..0), HzFractional RF Reference Value(19..0)
Gain
The gain is a 32-bit value that is split into two 16-bit values, representing the Stage 1 and
Stage 2 gain values. The Stage 1 gain represents the amount of gain in the front-end
system, the RF gain. The Stage 2 gain represents the amount of gain in the back-end
system, the IF gain.
Each gain value is a signed two's-complement number, having two sub-fields, bits 15:7
being the integer value, and 6:0 being the fractional value. This gives each gain figure a
range of ±256dB with a resolution of 1/128dB (0.0078125dB).
The R5500 has a temperature sensor and will report changes in temperature to the
system. The value of the Temperature field shall be expressed in units of degrees
Celsius (°C). The Temperature field shall use the 32-bit format shown in Table 14 with
the upper 16 bits reserved and shall be set to zero. The Temperature value shall be
expressed in signed two’s-complement format in the lower 16 bits of this field. This field
has an integer and a fractional part, with the radix point to the right of bit 6.