Rohde & Schwarz has added the R&S RTM-K18 spectrum analysis and spectrogram option to its R&S RTM oscilloscope family, making the R&S RTM the only oscilloscope in its class that can analyze the time domain while simultaneously analyzing the spectrum, logic and serial protocol. Interactions such as those that occur in electronic devices with RF components are quickly analyzed in a single measurement.
Time and spectrum analyses can be configured completely independently of one another. This means that users can simultaneously analyze signal details that differ in time and frequency, with the optimum settings for each. Separate implementation of the signal paths makes this possible. Like a spectrum analyzer, important parameters such as center frequency and resolution bandwidth can be specifically configured to match each measurement task. The hardware-implemented digital downconverter (DDC) reduces the spectrum to the components relevant for analysis. As a result, the R&S RTM offers a fast, reactive analysis of embedded designs.
Additional displays for min. hold, max. hold and average, as well as markers for automatic peak value searches, support the user during spectrum analysis. Changes in the spectrum over time or sporadic unwanted signals are immediately visible in the spectrogram display. The amplitudes versus frequency and time are color coded.
With the R&S RTM-K15 history and segmented memory option, users can load all acquisition components from the 460 MSa deep memory and analyze them with the R&S RTM measurement functions.
The R&S RTM portfolio, which already consists of models with 200 MHz, 350 MHz and 500 MHz bandwidth, now includes two-channel and four-channel models with 1-GHz bandwidth. The new models exhibit the same analog characteristics, offering true 1mV/div at the full bandwidth and full ADC resolution with exceedingly low 270 µV noise.
By Oliver Montenbruck, Richard B. Langley, and Peter Steigenberger
Over the past several years, some users of the GPS navigation system have already benefitted from the addition of various new signals in addition to the legacy C/A- and P(Y)-code. With the introduction of the Block IIR-M satellites in 2005, a new civil signal (L2C) was transmitted on the L2 frequency, and a new signal on a new frequency (L5) was introduced as a standard signal with the Block IIF satellites beginning in 2010. These new signals provide direct access to dual-frequency observations and thus enable improved ionospheric corrections for civil, including aeronautical, users. In addition, a new Civil Navigation (CNAV) broadcast message has been defined in the GPS Interface Specifications (IS-GPS-200 and IS-GPS-705).
This message will be transmitted jointly on the L2C and L5 signals and provides a variety of useful new parameters. Compared to the legacy L1 C/A-code navigation message, the CNAV message also offers an increased flexibility concerning the type, sequence, and repeat rate of specific messages.
CNAV messages have already been broadcast over the past two years by the Michibiki (QZS-1) satellite of the Japanese Quasi-Zenith Satellite System (QZSS), which shares many aspects of the GPS signal design. In contrast to this, Block IIR-M and IIF GPS satellites have only transmitted dummy messages so far and a fully operational CNAV transmission is only foreseen once the ongoing modernization of the GPS control segment has been completed.
Triggered by various interest groups, the Global Positioning Systems Directorate has just conducted a first test campaign with live CNAV transmissions on L2C and L5 over the two-week period from June 15 to 29 (see Global Positioning System Modernized Civil Navigation (CNAV) Live-Sky Broadcast Test Plan.) It served as a first opportunity for end users and receiver manufacturers to test the decoding and use of the new messages under a wide range of different configurations.
CNAV messages have a common length of 300 data bits and are identified by a message type number that signifies their contents. The messages presently defined for GPS are summarized in Table 1. For QZSS, complementary messages have been established, which enable, among other features, a rebroadcast of GPS-specific data to QZSS users.
Table 1. Summary of CNAV message types transmitted by space vehicles (SVs). Messages marked by an asterisk were transmitted during the recent CNAV test campaign.
Message
Type
CNAV Message Title
Function/Purpose
0*
Default
Default message (transmitted when no message data is available)
10*
Ephemeris 1
SV position parameters for the transmitting SV
11*
Ephemeris 2
SV position parameters for the transmitting SV
12*
ReducedAlmanac
Reduced almanac data packets for seven SVs
13
Clock Differential Correction
SV clock differential correction parameters
14
Ephemeris Differential Correction
SV ephemeris differential correction parameters
15*
Text
Text (29 eight-bit ASCII characters)
30*
Clock, Iono & Group Delay
SV clock correction parameters, ionospheric and group delay correction parameters (inter-signal correction parameters)
31
Clock & Reduced Almanac
SV clock correction parameters, reduced almanac data packets for four SVs
Other than the legacy L1 navigation message, which adheres to a fixed order of subframes, the sequence of CNAV messages can be varied widely to provide users with an optimized set of low latency information and parameters that change infrequently. As a baseline, the two ephemeris message types 10 and 11 are combined with any of the clock-and-auxiliary data messages (types 30 through 37) to provide users with the orbit and clock data of the received satellites. With a transmission duration of 12 seconds per CNAV message on L2C, a minimum of 36 seconds is required to transfer this information to the user if no other messages are transmitted. On L5, which operates at twice the data rate, a new frame is transmitted once every 6 seconds yielding a minimum of 18 seconds for the broadcast of ephemeris and clock data.
The recent test campaign started at 18:00 GPS Time on Saturday, June 15, 2013, with the transmission of message types 10, 11, 15, and 30 on a first space vehicle (PRN24) and included PRN12 from 18:42 onwards. Other space vehicles were sequentially phased in until all active IIR-M and IIF satellites (except for the recently launched IIF-4 satellite) transmitted CNAV on the supported signals. When the test ended exactly two weeks later (June 29, 18:00 GPST), all participating satellites were transmitting a complex master frame of 15 x 4 = 60 individual messages, which was repeated once every 12 minutes (on L2C). Each minor frame comprised the two ephemeris messages and at least one clock-data message (see Table 2).
Table 2. Sequence of message types in a CNAV master frame.
Message Types
10
11
15
30
10
11
32
33
10
11
12
35
10
11
12
30
10
11
12
33
10
11
12
35
10
11
12
30
10
11
32
33
10
11
15
35
10
11
32
30
10
11
12
33
10
11
12
35
10
11
12
30
10
11
12
33
10
11
12
35
Other messages included a reduced almanac (message type 12) and a text message (message type 15) with dummy content (“THIS IS A GPS TEST MESSAGE.”)
The CNAV data were recorded by selected multi-GNSS monitoring stations of the German Aerospace Establishment (Deutsches Zentrum für Luft- und Raumfahrt or DLR) and the University of New Brunswick (UNB), which were specifically configured to record raw GPS navigation frames in addition to the normal observation data. The stations are located at Singapore (SIN0); Sydney, Australia (UNX2); Maui, U.S.A. (MAO0); and Hartebeesthoek, South Africa (HRAG); as well as Fredericton, Canada (UNB) and are equipped with either Javad Delta-G2/G3TH or NovAtel OEM6 receivers. Following initial validation, the raw and decoded data from the CNAV test will be made available to interested users through the Multi-GNSS Experiment (MGEX) of the International GNSS Service (see http:/igs.org/mgex) to facilitate the development of user software and suitable data formats (such as an extended RINEX navigation message format).
The CNAV orbit and clock data were updated once every two hours and offer a slightly higher bit resolution than their legacy counterparts. However, the accuracy of the ephemeris data has not yet been evaluated nor compared to that of the L1 C/A-code navigation data.
As indicated above, the CNAV data can also provide a particularly compact form of almanac data known as the reduced almanac. It does not offer clock information (that is not normally required for a signal search) and assumes a circular orbit, which reduces the overall accuracy. Still, it can be transmitted (and repeated) in a much shorter time interval than the legacy almanac, which requires a total of 12.5 minutes. Each reduced almanac message (message type 12) provides orbit information for a total of seven satellites and it takes a set of five such messages to convey information for a complete constellation. For the master frame layout described above, the full constellation reduced almanac is repeated twice within 12 minutes on L2C (and half this time on L5).
Novel types of CNAV data not covered by the legacy navigation message include the differential code biases (also known as inter-system corrections or ISCs), which are required for pseudorange-based positioning with signals other than the legacy P(Y)-code (in addition to the established Timing Group Delay parameter or TGD). An overview of TGD and ISC values broadcast by the various satellites participating in the CNAV test is given in Table 3.
Table 3. Differential code biases (in nanoseconds) of GPS Block IIR-M and IIF satellites broadcast during the test campaign as part of the message type 30 CNAV messages.
SV Type
SVN
PRN
TGO
ISC L1CA
ISC L2C
ISC L5I5
ISC L5Q5
IIR-M
48
07
-10.71
-0.84
6.52
IIR-M
50
05
-10.24
-0.32
5.41
IIR-M
52
31
-13.04
-0.55
7.36
IIR-M
53
17
-10.24
-0.84
6.17
IIR-M
55
15
-10.24
-0.47
5.62
IIR-M
57
29
-9.31
-0.76
5.06
IIR-M
58
12
-12.11
-0.76
6.64
IIF
62
25
5.59
-2.07
-5.24
-0.38
-0.87
IIF
63
01
8.38
-2.30
-7.57
0.38
2.15
IIF
65
24
2.79
-0.26
-2.27
2.27
3.70
Another important achievement is the provision of Earth orientation parameters (EOP) in message 32, which provides GPS users with access to the celestial reference frame. EOPs were transmitted during the second test week and updated on a daily basis (see Table 4). Knowledge of these parameters is of particular interest for GPS-based orbit determination and navigation of spacecraft (in low Earth orbit), which is preferably referred to an inertial rather than an Earth-fixed coordinate system.
Table 4. Daily Earth orientation parameters from the CNAV test campaign (pole coordinates and dUT1 (UT1-UTC) time differences and derivatives).
Epoch (GPST)
x_p
(arcseconds)
x_p_dot
(arcseconds per day)
y_p
(arcseconds)
y_p_dot
(arcseconds per day)
dUT1
(seconds)
dUT1_dot
(seconds per day)
June 22, 0:00
0.13517
0.00104
0.39657
-0.00054
0.06341
-0.00046
June 23, 0:00
0.13621
0.00102
0.39604
-0.00056
0.06295
-0.00049
June 24, 0:00
0.13740
0.00101
0.39535
-0.00058
0.06231
-0.00053
June 25, 0:00
0.13815
0.00099
0.39487
-0.00060
0.06164
-0.00063
June 26, 0:00
0.13846
0.00096
0.39443
-0.00062
0.06078
-0.00067
June 27, 0:00
0.13885
0.00094
0.39381
-0.00064
0.06004
-0.00067
June 28, 0:00
0.13947
0.00093
0.39310
-0.00066
0.05909
-0.00063
June 29, 0:00
0.13987
0.00090
0.39246
-0.00068
0.05842
-0.00053
Overall, CNAV offers exciting prospects for improved GPS utilization and users may look forward to the next test campaigns, which will tentatively be conducted once every six months.
As a side note, it should be mentioned that individual satellites could be observed to transmit various types of non-standard CNAV messages as well as CNAV messages with improper data (such as an invalid week count) after the end of the main test campaign. Various receivers in the MGEX network, which were processing the received CNAV messages internally and which put full confidence in their proper contents, were mislead by such information. During the actual test campaign, all data appeared fully valid and no problems were reported by the stations.
OLIVER MONTENBRUCK is the head of the GNSS Technology and Navigation Group at DLR’s German Space Operations Center in Oberpfaffenhofen, Germany.
RICHARD B. LANGLEY is a professor in the Department of Geodesy and Geomatics Engineering at the University of New Brunswick, Fredericton, New Brunswick, Canada.
PETER STEIGENBERGER is a staff member in the Institut für Astronomische und Physikalische Geodäsie of the Technische Universität München (TUM) in Munich, Germany.
Emerging GNSS applications in automobiles support regulation, security, safety, and financial transactions, as well as navigation, guidance, traffic information, and entertainment. The GNSS sub-systems and onboard applications must demonstrate robustness under a range of environments and varying threats. A dedicated automotive GNSS test center enables engineers to design their own GNSS test scenarios including urban canyons, tunnels, and jamming sources at a controlled test site.
By Mark Dumville, William Roberts, Dave Lowe, Ben Wales, NSL, Phil Pettitt, Steven Warner, and Catherine Ferris, innovITS
Satellite navigation is a core component within most intelligent transport systems (ITS) applications. However, the performance of GNSS-based systems deteriorates when the direct signals from the satellites are blocked, reflected, and when they are subjected to interference. As a result, the ability to simulate signal blockage via urban canyons and tunnels, and signal interference via jamming and spoofing, has grown fundamental in testing applications.
The UK Center of Excellence for ITS (innovITS), in association with MIRA, Transport Research Laboratory (TRL), and Advantage West Midlands, has constructed Advance, a futuristic automotive research and development, and test and approvals center. It provides a safe, comprehensive, and fully controllable purpose-built road environment, which enables clients to test, validate and demonstrate ITS. The extensive track layout, configurable to represent virtually any urban environment, enables the precise specification of road conditions and access to infrastructure for the development of ITS innovations without the usual constraints of excessive set up costs and development time.
As such, innovITS Advance has the requirement to provide cityscape GNSS reception conditions to its clients; a decidedly nontrivial requirement as the test track has been built in an open sky, green-field environment (Figure 1).
Figure 1. innovITS Advance test circuit (right) and the environment it represents (left).
NSL, a GNSS applications and development company, was commissioned by innovITS to develop Skyclone in response to this need. The Skyclone tool is located between the raw GNSS signals and the in-vehicle system. As the vehicle travels around the Advance track, Skyclone modifies the GNSS signals to simulate their reception characteristics had they been received in a city environment and/or under a jamming attack. Skyclone combines the best parts of real signals, simulated scenarios, and record-and-replay capabilities, all in one box. It provides an advanced GNSS signal-processing tool for automotive testing, and has been specifically developed to be operated and understood by automotive testing engineers rather than GNSS experts.
Skyclone Concept
Simulating and recreating the signal-reception environment is achieved through a mix of software and hardware approaches. Figure 2 illustrates the basic Skyclone concept, in which the following operations are performed.
In the office, the automotive engineer designs a test scenario representative of a real-world test route, using a 3D modelling tool to select building types, and add tunnels/underpasses, and jammer sources. The test scenario is saved onto an SD card for upload onto the Skyclone system.
The 3D model in Skyclone contains all of the required information to condition the received GNSS signals to appear to have been received in the 3D environment.
The Skyclone system is installed in a test vehicle that receives the open-air GNSS signals while it is driven around the Advance track circuit.
The open-air GNSS signals are also received at a mobile GNSS reference receiver, based on commercial off-the-shelf GNSS technology, on the test vehicle. It determines the accurate location of the vehicle using RTK GNSS. The RTK base station is located on the test site.
The vehicle’s location is used to access the 3D model to extract the local reception conditions (surrounding building obstructions, tunnels attenuations, jamming, and interference sources) associated with the test scenario.
Skyclone applies satellite masking, attenuation, and interference models to condition/manipulate raw GNSS signals received at a second software receiver in the onboard system. The software receiver removes any signals that would have been obstructed by buildings and other structures, and adds attenuation and delays to the remaining signals to represent real-world reception conditions. Furthermore, the receiver can apply variable interference and/or jamming signatures to the GNSS signals.
The conditioned signals are then transmitted to the onbaord unit (OBU) under test either via direct antenna cable, or through the air under an antenna hood (acting as an anechoic chamber on top of the test vehicle). Finally, the GNSS signals produced by Skyclone are processed by the OBU, producing a position fix to be fed into the application software.
Figure 2. Skyclone system concept.
The Skyclone output is a commercial OBU application that has been tested using only those GNSS signals that the OBU receiver would have had available if it was operating in a real-world replica environment to that which was simulated within the Skyclone test scenario.
Skyclone Architecture
The Skyclone system architecture (Figure 3) consists of five principal subsystems.
Office Subsystem Denial Scenario Manager. This software has been designed to allow users to readily design a cityscape for use within the Skyclone system. The software allows the users to select different building heights and styles, add GNSS jamming and interference, and select different road areas to be treated as tunnels.
Figure 3. Baseline Skyclone system architecture.
City Buildings. The Advance test site and surrounding area have been divided into 14 separate zones, each of which can be assigned a different city model. Ten of the zones fall inside of the test road circuit and four are external to the test site. Each zone is color-coded for ease of identification (Figure 4).
Figure 4. Skyclone city zones.
The Skyclone system uses the city models to determine GNSS signal blockage and multipath for all positions on the innovITS Advance test site. The following city models, ordered in decreasing building height and density, can be assigned to all zones: high rise, city, semi urban, residential, and parkland.
Interference and Jamming. GNSS jamming and interference can be applied to the received GNSS signals. Jamming is set by specifying a jamming origin, power, and radius. The power is described by the percentage of denied GNSS signal at the jamming origin and can be set in increments of 20 percent. The denied signal then decreases linearly to the jammer perimeter, outside of which there is no denial.
The user can select the location, radius, and strength of the jammer, can select multiple jammers, and can drag and drop the jammers around the site.
Tunnels. Tunnels can be applied to the cityscape to completely deny GNSS signals on sections of road. The user is able to allocate “tunnels” to a pre-defined series of roads within the test site. The effect of a tunnel is to completely mask the sky from all satellites.
Visualization. The visualization display interface (Figure 5) provides a graphical representation of the scenario under development, including track layout, buildings, locations, and effects of interference/jammers and tunnels. Interface/jammer locations are shown as hemispherical objects located and sized according to user definition. Tunnels appear as half-cylinder pipes covering selected roads.
Figure 5. 3D visualisation display.
Reference Subsystem
The reference subsystem obtains the precise location of the test vehicle within the test site. The reference location is used to extract relevant vehicle-location data, which is used to condition the GNSS signals.
The reference subsystem is based on a commercial off-the-shelf real-time kinematic GPS RTK system, capable of computing an accurate trajectory of the vehicle to approximately 10 centimeters. This position fix is used to compute the local environmental parameters that need to be applied to the raw GNSS signals to simulate the city scenario.
A dedicated RTK GNSS static reference system (and UHF communications links) is provided within the Skyclone system. RTK vehicle positions of the vehicles are also communicated to the 4G mesh network on the Advance test site for tracking operational progress from the control center.
Vehicle Subsystem
The vehicle subsystem acquires the GNSS signals, removes those that would be blocked due to the city environment (buildings/tunnels), conditions remaining signals, applies interference/jammer models, and re-transmits resulting the GNSS signals for use by the OBU subsystem.
The solution is based on the use of software GNSS receiver technology developed at NSL. In simple terms, the process involves capturing and digitizing the raw GNSS signals with a hardware RF front end. Figure 6 shows the system architecture, and Figure 7 shows the equipment in the innovITS demonstration vehicle.
Figure 6. Skyclone hardware architecture.
The digitized signals are then processed in NSL’s software receiver running on a standard commercial PC motherboard. The software receiver includes routines for signal acquisition and tracking, data demodulation and position determination.
In the Skyclone system, the raw GNSS signals are captured and digitized using the NSL stereo software receiver. The software receiver determines which signals are to be removed (denied), which signals require conditioning, and which signals can pass through unaffected. The subsystem does this through accurate knowledge of the vehicle’s location (from the reference subsystem), knowledge of the environment (from the office subsystem), and knowledge of the satellite locations (from the vehicle subsystem itself).
The Skyclone vehicle subsystem applies various filters and produces a digital output stream. This stream is converted to analog and upconverted to GNSS L1 frequency, and is sent to the transmitter module located on the same board.
The Skyclone transmitter module feeds the analog RF signal to the OBU subsystem within the confines of a shielded GPS hood, which is attached to the vehicle on a roof rack. An alternative to the hood is to integrate directly with the cable of the OBU antenna or through the use of an external antenna port into the OBU. The vehicle subsystem performs these tasks in near real-time allowing the OBU to continue to incorporate non-GNSS navigation sensors if applicable.
Onboard Unit Subsystem
The OBU subsystem, typically a third-party device to be tested, could be a nomadic device or an OEM fitted device, or a smartphone. It typically includes a GNSS receiver, an interface, and a software application. Examples include:
Navigation system
Intelligent speed adaptation system
eCall
Stolen-vehicle recovery system
Telematics (fleet management) unit
Road-user charging onboard unit
Pay-as-you-drive black-box
Vehicle-control applications
Cooperative active safety applications
Vehicle-to-vehicle and vehicle-to-infrastructure systems.
Tools Subsystem Signal Monitor
The Skyclone Monitor tool provides a continuous monitoring service of GNSS performance at the test site during tests, monitoring the L1 frequency and analyzing the RF singal received at the reference antenna. The tool generates a performance report to provide evidence of the open-sky GNSS conditions. This is necessary in the event of poor GNSS performance that may affect the outcome of the automotive tests. The Skyclone Monitor (Figure 8) is also used to detect any spurious leaked signals which will highlight the need to check the vehicle subsystem. If any spurious signals are detected, the Skyclone system is shut down so as to avoid an impact on other GNSS users at the test site. A visualization tool (Visor) is used for post-test analysis displaying the OBU-determined position alongside the RTK position within the 3D environment.
Figure 8. GNSS signal and positioning monitor.Figure 9. 3D model of city.
Performance
Commissioning of the Skyclone system produced the following initial results. A test vehicle was installed with the Skyclone and RTK equipment and associated antennas.. The antennas were linked to the Skyclone system which was installed in the vehicle and powered from a 12V invertor connected to the car power supply. The output from the RTK GPS reference system was logged alongside the output of a commercial third-party GNSS receiver (acting as the OBU) interfaced to the Skyclone system. Skyclone was tested under three scenarios to provide an initial indication of behavior: city, tunnel, and jammer.
The three test cenarios were generated using the GNSS Denial Scenario Manager tool and the resulting models stored on three SD cards. The SD cards were separately installed in the Skyclone system within the vehicle before driving around the test site.
City Test. The city scenario consisted of setting all of the internal zones to “city” and setting the external zones to “high-rise.”
Figure 10A represents the points as provided by the RTK GPS reference system installed on the test vehicle. Figure 10B includes the positions generated by the COTS GPS OBU receiver after being injected with the Skyclone output. The effect of including the city scenario model is immediately apparent. The effects of the satellite masking and multipath model generate noise within the position tracks.
Figure 10A. City scenario: no Skyclone.Figure 10B. City scenario: withSkyclone.
Tunnel Test. The tunnel scenario consists of setting all zones to open sky. A tunnel is then inserted along the central carriageway (Figure 11). A viewer location (depicted by the red line) has been located inside the tunnel, hence the satellite masking plot in the bottom right of Figure 11 is pure red, indicating complete masking of satellite coverage. The output of the tunnel scenario is presented in Figure 12. Inclusion of the tunnel model has resulted in the removal of all satellite signals in the area of track where the tunnel was located in the city model. The color shading represents signal-to-noise ratio (SNR), an indication of those instances where the output of the test OBU receiver has generated a position fix with zero (black) signal strength, hence the output was a prediction. Thus confirming the tunnel scenario is working correctly.
Figure 11. 3D model of tunnel.Figure 12. Results.
Jammer Test. The jammer test considered the placement of a single jammer at a road intersection (Figure 13). Two tests were performed, covering low-power jammer and a high-power jammer. Figure 14A shows results from the low-power jammer. The color shading relates to the SNR as received within the NMEA output from the OBU, which continued to provide an output regardless of the jammer. However, the shading indicates that the jammer had an impact on signal reception.
Figure 13. Jammer scenario.Figure 14A. Jammer test results: low power interference.Figure 14B. Jammer test results: high-power interference.
In contrast the results of the high-power jammer (Figure 14B) show the effect of a jammer on the OBU output. The jammer denies access to GNSS signals and generates the desired result in denying GNSS signals to the OBU. Furthermore, the results exhibit features that the team witnessed during real GNSS jamming trials, most notably the wavering patterns that are output from GNSS receivers after they have regained tracking following jamming, before their internal filtering stabilizes to nominal behaviors.
The Future
The Advance test site is now available for commercial testing of GNSS based applications. Current activity involves integrating real-world GNSS jammer signatures into the Skyclone design tool and the inclusion of other GNSS threats and vulnerabilities.
Skyclone offers the potential to operate with a range of platforms other than automotive. Unmanned aerial systems platforms are under investigation. NSL is examining the integration of Skyclone features within both GNSS simulators as well as an add-on to record-and-replay tools. This would enable trajectories to be captured in open-sky conditions and then replayed within urban environments.
Having access to GNSS signal-denial capability has an immediate commercial interest within the automotive sector for testing applications without the need to invest in extensive field trials. Other domains can now benefit from such developments. The technology has been developed and validated and is available for other applications and user communities.
