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 R5700 are
trademarks of ThinkRF
Corporation.
HARDWARE WARRANTY AND LIMITATION OF LIABILITY
Read this warranty carefully before you use the product.
R5700 Real Time Spectrum Analyzers with GNSS 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.
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
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.
Table43: Max, Min, and Required Multiples for SPP and Samples-per-word for Different Data Output
Format .................................................................................................................................... 77
Table 44: HiSLIP Message Header Format ............................................................................................. 88
Table 45: ThinkRF Vendor Specific Message Type Value Definitions ..................................................... 89
Table 46: ThinkRF Data Channel Initialization Transaction ..................................................................... 89
} .................... 38
16 Q16
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 R5700 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 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
www.thinkrf.com/support/ or by calling +1.613.369.5104.
Before contacting Support, please have the following information available:
•R5700's serial number and product version, which are located on the identification
label on the R5700's underside.
•The firmware version running on the R5700.
•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.
R5700 Functional Overview
This section overviews the R5700'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 R5700 Real Time Spectrum Analyzer (RTSA) with GNSS (Global Navigation
Satellite System) provides the benefits of a high-performance software-defined RF
receiver, digitizer and analyzer along with integrated GNSS technology offering location
and time information in one package. With patent-pending software-defined RF receiver
technology, the RTSA provides industry leading combined sensitivity, tuning range, wide
instantaneous bandwidth (IBW) and scan rate. Additionally, it provides real-time
sophisticated triggering and capture control. Figure 1 illustrates an RTSA solution
system example.
R5700 Functional Overview
The R5700 is designed for stand-alone, remote and/or distributed wireless signal
analysis. Whether using as a single unit or a network of radio sensors, R5700 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;
•test and measurement;
•monitoring and surveillance;
•research;
•OEM integration.
The R5700 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 325 kSample/sec 24-bit narrowband (NB) ADC with a dynamic range in excess of
100 dB;
•a GNSS module with embedded 10MHz reference clock source for further RTSA’s
time synchronization;
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide12
R5700 Functional Overview
•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.
Figure 1: R5700 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 (page 42) for controlling and obtaining status
from the RTSA and the VITA-49 Radio Transport (VRT) protocol (page 26) for digitized
data and its associated context information.
In addition, API libraries, written in C/C++, Python, MATLAB and/or NI LabVIEW, are
provided for quick interfacing, data acquisition and as well as for spectral analysis. 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 (GUIs) or
any applications included in each release package.
Refer to Appendix A for how to connect to an 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 R5700 provides system level control and status commands as defined in Table 1.
13ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
R5700 Functional Overview
Table 1: System Level Control/Status Commands with GNSS
SCPI CommandDescription
:SYSTemPage 46
: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
:MODE?Gets the current capture mode of the RTSA (i.e. sweeping, streaming or
block mode)
:COMMunicate
:HISLip
:SESSion?Returns the HiSLIP connection’s session ID
:LAN<commands>Subset of commands for configuring/querying RTSA's LAN settings
:ERRor
[:NEXT]?Returns the next error code and message from the SCPI error/event
queue
:ALL?Returns all the error codes and messages from the SCPI error/event
queue
:CODE
[:NEXT]?Returns next the error code from the SCPI error/event queue
:ALL?Returns all the error codes from the SCPI error/event queue
:COUNt?Returns the number of errors in the SCPI error/event queue
:FLUShClears the R5700'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 R5700 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 an 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
:SYNC[?]Sets/ gets the System time synchronization source via network or SCPI,
or disable
:STATusPage 57
:OPERation
[:EVENt]?Queries the Operation Status Register for any operation event
:CONDition?Queries the Operation Condition Register for any operation event
:ENABle[?]Enables or queries bits in the Operation Enable Register
:NTRansition[?]Enables or queries bits in the Operation Negative Transition Register
:PTRansition[?]Enables or queries bits in the Operation Positive Transition Register
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide14
R5700 Functional Overview
SCPI CommandDescription
:PRESETPresets the R5500 (similar to *RST)
:QUEStionable
[:EVENt]?Queries the Questionable Status Register for any questionable event
:CONDition?Queries the Questionable Condition Register for any questionable event
:ENABle[?]Enables or queries bits in the Questionable Enable Register
:NTRansition[?]Enables or queries bits in the Questionable Negative Transition Register
:PTRansition[?]Enables or queries bits in the Questionable Positive Transition Register
:TEMPerature?Returns the R5700's internal ambient temperature
:GNSS
[:Enable][?]Enables or queries the status of the GNSS module
:POSitionQueries the last known GNSS position in degrees latitude, degrees
:REFerence?Queries which timing reference source used to discipline the 10 MHz
See SCPI Command Set section (page 42 onward) for further details on the commands.
longitude and altitude in meters
GNSS reference oscillator
Caution pertaining to multi-users: See Appendix A: Connecting to RTSA for important
notes on this caution.
The Architecture
The R5700 is an integrated wireless radio receiver, digitizer/analyzer and GNSS
technology. 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;
•obtain device’s location position and time as provided by the GNSS through VRT
packets (page 32); and
•have time-stamped with data output.
Traces and sweeps are controlled by the capture controller as illustrated in the Digitizer
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.
When the GNSS module is enabled, GNSS position and time information is sent to users
through VRT context packets roughly every second (see VRT’s Formatted GPS
Geolocation section). Besides two existing internal and external 10 MHz reference clock
sources, the GNSS module also provides a third 10MHz reference clock source option to
provide synchronized time-stamp for VRT packets (see SOURce Commands).
15ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
(Note: The GPS (GNSS) option is included in this model)
The R5700 supports different RFE modes of operation and subsequent DSP capabilities
as per Table 2 and as described in the following subsections.
Table 2: Radio RFE Modes and DSP Data Output Formats
ModeDescriptionFreq Range
(MHz)
ZIF
SH
SHN
HDR
DD
1
For SH and SHN modes, when the decimation is used, a frequency shift of 35MHz will be applied
automatically to bring the R5700's center frequency back to the zero IF. Thus, the data output will
be I and Q.
2
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 - max
Receiver
Direct Digitization
0.009 - 50
Receiver
2
IBW
(MHz)
0.1I
50I
DSP Data Output Format
NoneCIC/DecFrequency Shift
14I14 Q14
14
I14 Q
14
I14 Q
24
14
I
14 Q14
1
14
1
14
--
1
I14 Q
I14 Q
I14 Q
I14 Q
14
14
14
14
R5700 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 36) for the exact VRT data output
formats as well as packing method.
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide16
R5700 Functional Overview
RF Receiver Front-End
The Receiver portion of Figure 2 shows a block diagram of the RFE within the R5700.
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 9kHz 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 R5700-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) based Direct Digital Synthesizer (DDS) as described in the
Digital Down Converter subsection.
The HDR radio mode supports a tuning resolution of 10Hz. No further fine tuning is
available.
The remaining radio mode, DD, supports 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 R5700'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.
17ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
R5700 Functional Overview
D C
O f f s e t
F c - 5 0 M H z
F c + 5 0 M H z
1 2 5 M H z
F c
A n a l o g f i l t e r
S i g n a l
I m a g e
X d B
F r e q u e n c y
F
c
F r e q u e n c y
F
c
F c + F s
F c - F s
c a l i b r a t e I Q
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.
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.
Figure 4: IQ Offset Correction
Table 3: RF Front-End Control/Status Commands
SCPI CommandDescription
:INPutPage 63
:ATTenuator[?]
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide18
Enables/disables the front-end's attenuation for R5700-408 & their
variants only
R5700 Functional Overview
SCPI CommandDescription
:VARiable[?]
:GAIN[?]
:HDR[?]
:MODE[?]
:SOURcePage 66
:REFerence
:PLL[?]
:PPS[?]
[:SENSe]Page 67
:DECimation[?]Sets the decimation rate as an exponent of 2 (i.e. rate = 2
:FREQuency
:CENTer[?]Sets the center frequency of the RFE
:IF?Queries the IF frequencies that are used for the current input mode and
: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
:SHIFt[?]Sets the frequency shift value (not available for HDR mode)
:LOCK
:REFerence?Queries the lock status of the PLL reference clock
:RF?Queries the lock status of the RFE's PLL
Sets the variable attenuation for R5700-418 and -427 & their variants
Sets the input gain stage for R5700-418, -427 & their variants
Sets gain level for the NB ADC of of the HDR signal path
Selects the receiver mode of operation
Selects the 10MHz reference clock source
Selects the PPS input source
level
where level =
0, 1, 2 - 10)
center frequency
current the RTSA's center frequency
See SCPI Command Set section (page 42 onward) for further details on each set of
commands.
Digital Signal Processing
The R5700 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.
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.
19ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
R5700 Functional Overview
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.
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
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 R5700
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 R5700 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
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide20
R5700 Functional Overview
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.
Figure 6: Association between Time and Frequency Domain
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.
See TRIGger Commands (page 72) or SWEep's trigger (page 85) 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 R5700'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 72
21ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
SCPI CommandDescription
:TYPE[?]Sets or disable the trigger type including LEVel | PERiodic | PPS | PULSe
:LEVel[?]Sets the frequency range and amplitude of a frequency domain level
:PERiodic[?]Sets the time period of a periodic trigger
See TRIGger Commands (page 72) or SWEep's trigger (page 85) 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.
R5700 Functional Overview
| WORD | NONE
trigger
Note: Besides the information provided in the following sections, refer to appnotes “740050 Data Acquisition” and “74-0071 Sweep Synchronization with I and Q output” for
more information, including examples.
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.
The :TRACe:BLOCk (page 75) command initiates a block capture of continuous IQ data
(available to be "pulled" from the R5700 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 77) command initiates the streaming of IQ data (which is
"pushed" from the R5700). 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.
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide22
R5700 Functional Overview
Table 5: Trace Capture Control Commands
SCPI CommandDescription
:TRACePage 74
: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 =
:SPPacket[?]Defines the number of samples per VRT packet
:STReam
:STARtInitiates the capture, storage and streaming of IQ data
:STOPStops streaming
See TRACe Commands section (page 74) 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.
:PACKets * SPP)
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 78
: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
23ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
R5700 Functional Overview
SCPI CommandDescription
: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 63
:VAR[?]As defined in :INPut:ATTenuator:VARiable, page 63
:DECimation[?]As defined in [:SENSe]:DECimation, page 67
: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 70
:GAIN
:HDR[?]As defined in :INPut:GAIN:HDR, page 65
:MODEAs defined in :INPut:MODE, page 65
: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 76
:SPPacket[?]As defined in :TRACe:SPPacket, page 76
:TRIGger
:TYPE[?]As defined in :TRIGger:TYPE, page 73
:LEVel[?]As defined in :TRIGger:LEVel, page 73
:PERiodic[?]As defined in :TRIGger:PERiodic, page 74
See SWEep Commands section (page 78) for further details.
Synchronized Sweep
The R5700 supports a synchronized sweep function for the purposes of comparing the
same signal received via multiple R5700s.
Synchronized sweep is an extension of the external trigger capability. One of the R5700s
in a network is configured to be the master (:SYSTem:SYNC:MASTer ON) and the other
R5700s 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 R5700 Real Time Spectrum Analyzer Programmer's Guide24
R5700 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 78) for further interface details or contact
ThinkRF's Support for more information.
25ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
VITA-49 Radio Transport Protocol
VITA-49 Radio Transport Protocol
The section describes the R5700'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 R5700 to
another equipment using an industrial standard.
R5700'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 R5700 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 R5700
Table 7: The Categories of VRT Packet Streams Supported by ThinkRF's R5700
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
Receiver Context Packet Class Stream
26ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
VITA-49 Radio Transport Protocol
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 R5700.
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 R5700.
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 R5700.
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. See Table 8 for the list of Stream Identifiers used to identify these
different Packet Classes.
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 R5700's RF receiver.
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide27
1.Pkt Type is 0100 to indicate this is a context packet.
2.C is set to 0 to indicate there is no Class Identifier in the packet.
3.R is 00 as they are reserved bits.
4.TSM (TimeStamp Mode) is 0, indicating that context packet timestamps are
precise.
5.TSI (TimeStamp-Integer) field is 01, indicating that integer (seconds) part of the
timestamps are in Coordinated Universal Time (UTC).
6.TSF (TimeStamp-Fractional) field is 10, indicating that the fractional part of the
timestamp measures in real time picosecond resolution.
7.Pkt Count starts at 0000 and increments 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 is the 32-bit word, 0x90000001
10. Timestamp - Integer Seconds is in UTC format and represents the number of
seconds occurred since Midnight, January 1, 1970, GMT.
11. Timestamp - Integer Picoseconds counts 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 follows 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, see Table 11, 3rd column)
Table 10: Receiver Context Indicator Field Positions
13. The Context Fields section contains a context field for every field that is indicated
to be present in the Context Indicator Field. The fields is arranged 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
Indicator
Bit Name
Bit
Position
Context Field Type# of Words in
Context Fields
Period of
Validity
I31Context Field Change Indicator0N/A
R30Reference Point1Persistent
F27RF Reference Frequency2Persistent
G23Gain1Persistent
T18Temperature1Persistent
28ThinkRF R5700 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 is expressed in units of Hertz. The RF Reference
Frequency sub-field uses 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 R5700 has a temperature sensor and will report changes in temperature to the
system. The value of the Temperature field is expressed in units of degrees Celsius (°C).
The Temperature field uses the 32-bit format shown in Table 14 with the upper 16 bits
reserved and is set to zero. The Temperature value is expressed in signed two’scomplement 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.
ThinkRF R5700 Real Time Spectrum Analyzer Programmer's Guide29
VITA-49 Radio Transport Protocol
The valid range of the Temperature field is -273.15 °C to +511.984375 °C. The
resolution of the Temperature field is 0.015625 °C (1/64 °C).
For examples, a Temperature field value of:
•0x0040 represents +1 °C,
•0xFFC0 represents -1 °C,
•0x0001 represents +0.015625 °C, and
•0xFFFF represents -0.015625 °C.
Digitizer 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 R5700's IF digitizer.
Table 15: Digitizer Context Packet Class Structure
Context Fields (Variable Size, see Table 17, 3rd column)
1.Pkt Type is 0100 to indicate this is a context packet.
2.C is 0 to indicate there is no Class Identifier in the packet.
3.R is 00 as they are reserved bits.
4.TSM is 0, indicating that context packet timestamps are precise.
5.TSI field is 01, indicating that integer (seconds) part of the timestamps are in UTC.
6.TSF field is 10, indicating that the fractional part of the timestamp measures real
time picosecond resolution.
7.Pkt Count starts at 0000 and increments 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 size of the entire context packet, including all headers, the
context indicator field and context sections.
9.Stream Identifier is the 32-bit word, 0x90000002.
10. Timestamp - Integer Seconds is in UTC format and will represent the number of
seconds occurred since Midnight, January 1, 1970 GMT.
11. Timestamp - Integer Picoseconds counts 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 follows the format indicated in Table 16.
Table 16: Digitizer Context Indicator Field Bit Positions
13. The Digitizer Context Fields section contains a context field for every field that is
indicated to be present in the Context Indicator Field. The fields is arranged in the
30ThinkRF R5700 Real Time Spectrum Analyzer Programmer’s Guide
Loading...
+ 77 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.