
Revision 23.5.0
1. Help
To request technical assistance, ask questions, or provide feedback on how to improve Skydel or this user manual, please contact Safran at simulationsupport@nav-timing.safrangroup.com or via the user forum at learn.safran-navigation-timing.com↗. To stay up to date on the latest Skydel news and information, please visit our website: www.safran-navigation-timing.com↗.
Additional documentation can be found on the Safran Support Documents↗ webpage as well as the Skydel User Forums: learn.safran-navigation-timing.com↗.
1.1. About This Manual
The Safran Skydel User Manual explains how to configure and use Skydel with different hardware setups and operating systems. If you purchased a turnkey solution from Safran or one of its Value-Added Resellers, you were provided with additional documentation specific to your hardware setup.
This user manual is organized into 4 sections:
-
Using Skydel: Explains how to operate Skydel.
-
Hardware Selection: Describes the hardware required to build a GNSS simulator with the Skydel software.
For users that have purchased the Skydel software only. -
Simulator Hardware Components: Describes how to connect hardware for different use cases
For users that have purchased the Skydel software only. -
Software Installation: Explains how to install firmware, drivers, and Skydel.
For users that have purchased the Skydel software only.
1.1.1. GSG-8 Resource
If you are using Skydel on a turnkey solution, you can find additional information here:
-
GSG-8: GSG-8 Quick Start Guide↗
2. Acronyms
Acronym | Description |
---|---|
BIOS |
Built In Operating System |
BOM |
Bill Of Materials |
CPU |
Central Processing Unit |
CUDA |
Compute Unified Device Architecture |
DAC |
Digital to Analog Converter |
DUT |
Device Under Test |
FPGA |
Field Programmable Array |
FTP |
File Transfer Protocol |
GBAS |
Ground Based Augmentation System |
GNSS |
Global Navigation Satellite System |
GPS |
Global Positioning System |
GPSDO |
GPS Disciplined Oscillator |
GPU |
Graphical Processing Unit |
GSG |
GNSS Signal Generator is a device that is able to create simulated satellite signals and generate real RF signals |
I/Q (IQ) |
Amplitude of In-Phase (I) and Quadrature (Q) of carrier |
JTAG |
Joint Test Action Group |
LEO |
Low Earth Orbit |
MEO |
Medium Earth Orbit |
MIMO |
Multiple Input Multiple Output |
MTU |
Maximum Transmission Unit |
NI |
National Instruments |
NMEA |
National Marine Electronics Association |
OCXO |
Oven-Controlled Crystal Oscillator |
PC |
Personnal Computer |
PPS |
Pulse Per Second |
RAM |
Random Access Memory |
RF |
Radio Frequency |
RTK |
Real-Time Kinematic |
SBAS |
Satellite Augmentation System |
SDR |
Software Defined Radio |
SFP (SFP+) |
Small Form-factor Pluggable |
SMA |
SubMiniature version A |
TX |
Transmission |
TX/RX |
Transmission/Reception |
UHD |
USRP Hardware Driver |
USB |
Universal Serial Bus |
USRP |
Universal Software Radio Peripheral |
VCTCXO |
Voltage Controlled, Temperature Compensated Oscillator |
3. Basic GNSS Simulation Concepts
Performance testing of GNSS equipment designs is crucial in today’s complex RF landscape. The Skydel simulation engine was designed to reproduce a range of satellite constellations, realistic conditions, and even attacks. Skydel excels at recreating a broad variety of real-world scenarios.
To run your first successful simulation with Skydel, you don’t need to read this entire manual. You can start by reading the Power Levels: Live Sky vs. Simulation section followed by the Simulator Hardware Components, and then jump directly to Running Your First Simulation.
3.1. Power Levels: Live Sky vs. Simulation
The main objective of a GNSS simulator is to create a RF signal identical to the “Live Sky” at the GNSS receiver’s RF input connector. The next 2 diagrams depict the difference between the propagation of the real signal and the simulated signal (using a USRP SDR as an example).


As you can see in the simulation case, the signal power level can be much higher at the output of the SDR compared to the live sky. We strongly recommend that you:
|
In general, when a GNSS receiver is receiving the RF signal from the live sky, the signal power level at the antenna is -130 dBm. The antenna amplifies the RF signal power level to about -110 dBm at the GNSS receiver’s input.
In the default simulation scenario, the GNSS simulator should create a signal with the same power level as the GNSS receiver’s input. Depending on the SDR model used, a different attenuation level may need to be applied to the signal emitted by the SDR.
3.2. Data Flow (IQ Data)
The Skydel simulation engine creates a digital signal (made of millions of IQ samples per second). This signal is converted to an analog signal (and then to RF).
IQ data is extremely useful for the following uses:
-
Playback: an IQ file (or mutliple) can be used as a recording.
-
Spoofing: an IQ file can be used as a spoofed signal along with a jamming transmitter.
-
Software-in-the-loop: an IQ File can be sent to a software-defined GNSS receiver without having to go through digital to analog and analog to digital conversion.
-
Research: an IQ file can be processed, modified, and combined with other IQ files.
-
CRPA: User can create multiple IQ files, one for each element of the CRPA.

-
Skydel, through a computer setup, generates real-time I/Q samples that represent the GNSS baseband signals;
-
The I/Q samples are pushed over the transport link (Ethernet or USB);
-
The I/Q samples are queued in the SDR buffer. The SDR pulls the samples from the buffer at a steady rate and converts them to RF;
-
When the SDR has more than one output, the signals are combined into a single RF cable;
-
The RF signal is attenuated before it is sent through a DC Block and reaches the GNSS receiver being tested.
3.3. Additional Resources
Here are some additional resources that can help you get started with your GNSS simulation:
4. Using Skydel
4.1. What is Skydel?
Skydel is a software application that uses GPU-accelerated computing to generate GNSS signals in real-time. Skydel generates signals in the form of I/Q data. This data can be saved to disk for offline analysis, or it can be pushed to a SDR in real-time to transform the I/Q data into RF at the appropriate carrier frequency. Skydel supports a variety of SDRs. To keep the documentation short, examples in this document section will assume that you are using a hardware setup comprising of a single Ettus X300 radio.
4.2. Launching Skydel
4.2.1. Splash Screen
A splash screen will display licensee information stored in the USB dongle (or license encrypted file if you are not using a dongle).

Click Continue to open Skydel.
4.2.2. Welcome Screen
After launching Skydel, the welcome screen lets you create a new configuration, open an existing configuration, or reload the last used configuration. You can read the Configurations section of this manual for more details. Click New Configuration to access the Skydel main window.
The most common way to use Skydel is to launch a single instance of Skydel. On a Linux system, simply type skydel-sdx in the terminal. In Windows, locate Safran’s Skydel in the start menu and click on it.
4.2.3. Main Window

The Skydel main window contains 5 important areas:
- Title Bar
-
The title bar displays information about the Skydel multi-instance id, configuration name, and whether it is saved or not.
- Menu Bar
-
The menu lets you save or load configurations, edit the preferences, undo or redo changes, etc.
- Dashboard
-
The dashboard is the horizontal blue bar that contains the Start and Arm buttons. It also displays the current simulation elapsed time, the simulator state, and the current simulation time in various formats (Gregorian, GPS week/second).
- Main Window Tabs
-
On the left-hand side, there are 5 Main Window Tabs: Settings, Receiver, Map, Automate, and Interference. Clicking on a tab will affect the Main Window Tab Content in the center. *Note: if the Advanced Jammers feature is enabled in your copy of Skydel, the Interference tab will not appear and additional options will appear in the Settings tab.
- Main Window Tab Content
-
The central content area changes according to the Main Window Tab selection.
4.2.4. Main Window Subtabs
The Settings, Receiver, and Map Tabs feature a horizontal divider that allows you to divide the display window according to your preferences. The top portion of the window displays content determined by the choice of Main Window Tab (i.e., map, receiver feed, etc.), while the bottom portion offers 5 subtabs corresponding to views of: Constellations, Deviation, Spectrums, Performance and Status Log.
The subtabs panel can be collapsed or expanded using the arrow button located at the far right of the horizontal divider.
- Constellations
-
This subtab information about the GNSS satellites that are simulated. You can find more detailed information here.

If you don’t see satellites in the sky view, it may be because the selected constellation is not included in your scenario. See section Output to add signals to your configuration. |
- Deviation
-
This subtab displays a graphic, in real-time, showing the deviation between the position generated by the simulator and the position calculated by the receiver under test. This subtab will not display any information unless Skydel is connected to the NMEA serial port of the receiver under test. See section Receiver for more details.

- Spectrums
-
This subtab displays the spectrum based on the generated IQ data. It displays an ideal spectrum based on digital data and does not represent the real output at the radio Tx connector. This view should not be used for taking precise measurements. However, it is very useful for visualizing the content of each output.

The Spectrums subtab will display the trace only while the simulation is running. The content that is displayed depends on the scenario.
On a slower computer, it may be necessary to disable the Spectrums. You can change this in the Preferences. |
- Performance
-
The Performance subtab is used to have an insight on the system’s performance and stability. The right graph is a detailed view on the last second of simulation, while the left graph is a summary of the last minute of simulation.

The Skydel real-time engine performs a massive amount of calculations in real-time. If you create complex scenarios with many signals, jammers, and spoofers, or if you want to reduce the latency to just a few milliseconds, you might be pushing the hardware to its limit. If at any given time during the execution of a scenario the simulator is unable to perform these calculations in real-time, it may stop and display the following error message in the Status Log: “Streaming buffer underrun”.
The Performance graph helps you visualize how close to the hardware limit your scenario is, before it results in an error. This can be used to confirm that long scenarios will run reliably on the system.
To better understand the graph, it is useful to first understand the principles of how the Skydel real-time engine works. The engine processes the simulation in 1 millisecond chunks, and each of them has to pass through 3 workers:
-
The Constellation Worker
-
The Modulation Worker
-
The Streamer Worker
The combination of these workers is known as the pipeline. The time it takes for a chunk to go through the pipeline is a major factor in determining the latency of the system. Since a chunk is 1 millisecond of simulation, the radio consumes them at a steady rate of 1000Hz (real-time). The real-time engine is allowed to process these chunks in advance, but this is capped by the Engine Latency set in the Preferences. An underrun (also known as underflow) occurs when the engine is unable to provide a chunk to the radio in time.
The Performance graph records the start and finish times when the chunks pass through each worker.

The time displayed on the vertical axis shows how far in advance the chunk was processed, compared to the moment it will be transmitted by the radio. As previously stated, the Engine Latency limits how much in advance a chunk can be processed. The traces should therefore always be located under the Engine Latency line.

A healthy and stable system should always begin to work on a chunk near the Engine Latency threshold. In other words, the blue trace should be as close as possible to the Engine Latency line. If the blue trace is below the Engine Latency, it means the simulator is falling behind; if it doesn’t catch up rapidly, an underrun will occur. Depending on the system, it’s possible to have the blue trace near the Engine Latency line, but still have the other traces falling down, depending on the specific worker that has the bottleneck.

You can find the individual chunk traces of the last second in the right graph of the Performance subtab, while the summary graph generates a trace for each second of simulation from the earliest start and latest finish times of each worker. It takes 1000 chunks to make one second of simulation, so the workers are displayed in the detailed graph using thin vertical lines which may appear as a single pixel. It is possible to zoom in the graph in order to see individual traces.

There are many factors that can cause the simulation engine to fall back, catch up, and possibly underrun. Some features might require more processing power or interfere with the radio capacity to transport chunks. If you get underruns, try to observe the Performance graph in order to find any pattern that might occur before the error. You might be able to associate the patterns with something in your scenario, such as an excessive transmission of commands in a short period of time, or an external factor, such as another application competing for CPU or GPU time. If you have built your simulator with your own hardware instead of using a turnkey system from Safran, make sure you follow all guidelines to optimize the Operating System and use appropriate hardware. The Skydel engine performs better on Linux, so Windows users will see more glitches on the Performance graphs. For that reason, Linux is strongly recommended for hardware-in-the-loop simulation when low latency is required.
- HIL
-
If your software license includes Hardware-In-the-Loop option, Skydel will show the HIL subtab. The graph shown in this subtab is a powerful visualization tool that is designed to make precise diagnosis and give you the confidence the HIL integration is working exactly as you expect. Read the HIL Graph section for more details.

- Status Log
-
This subtab is complementary to the dashboard which displays the current state of the simulator. Sometimes, it is not enough to know the simulator’s state. If the simulator is in an error state, or in an incomplete state, the Status Log will display information to provide additional context.

4.2.5. Simulator State
The simulator state is visible in the dashboard and the status log subtab. Typically, you will see Ready or Running state. However, there are other states you should be aware of.

- Ready
-
Ready means that the simulator is ready to start. Clicking the Start button will begin the simulation. You may get an error if you haven’t selected an Output. In this case, Skydel will simply display a message inviting you to add an output and select signals. Clicking the Arm button will initialize the plug-in instances then the hardware and stay in the Armed state until the user clicks the Start button.
- Initializing
-
Initializing means that the simulator is preparing the plug-in instances for simulation and the radio for streaming; this happens when you click the Start button. Depending on the selected output and plug-in instances, this state may appear for only a fraction of a second or for up to 10 seconds.
- Armed
-
Armed means the hardware is initialized and ready to start. If you clicked the Arm button (instead of the Start button), the simulator will stay in the armed state until you click the Start button. While Skydel is in an armed state, you may change some of the settings. For example, it is possible to move a slider to change the initial power of a satellite before the simulation starts. However, if you are using a timing receiver to synchronize the simulation start time, changes to the settings while in the armed state will be discarded when the simulation starts.
- Streaming RF
-
Streaming RF means that the simulator is running.
- Error
-
Error means that the simulator is in an error state. The simulator will display the Status Log subtab and automatically return to the ready state.
- Incomplete
-
Incomplete means that Skydel is missing the information required to start a simulation. This can happen when a trajectory type such as a track or route hasn’t been created properly. In this case, you will also notice that Skydel does not display the satellites in the sky view. The reason is quite simple: Skydel does not know the receiver position, so it is not able to calculate the elevation and azimuth of the satellites relative to the receiver.
4.2.6. Command Line Options
When starting Skydel, you can add multiple command line arguments and a configuration file name. For example, the following command will launch Skydel, skip the splash screen and automatically load my_config.sdx configuration.
skydel-sdx --skip-splash ~/Documents/Skydel-SDX/Configurations/my_config.sdx
There are many command line arguments. Use the --help command to get the complete list of commands.
skydel-sdx --help
Command | Description |
---|---|
skip-splash |
Skip the Splash Screen that displays the licensee information. |
skip-onboarding |
Skip the Welcome Screen dialog box inviting the user to choose between creating a new configuration, loading an existing configuration, or loading the last used configuration. |
reset-window |
Reset window state and geometry. |
width |
Set window width in pixels. |
height |
Set window height in pixels. |
instance-id |
If your software license allows multiple instance of Skydel to run simultaneously, this command is used to specify the instance id. The instance id is used in the API library to identify which instance of Skydel you want to connect to. |
full-screen |
Start Skydel in full screen mode (use as much space as possible and hide the title bar). |
minimized-window |
Start Skydel in minimized window size. Implicitly set skip-splash and skip-onboarding options. |
maximized-window |
Start Skydel in maximized window size (use as much space as possible but does not hide the window’s title bar). |
run-in-background |
Start Skydel with the window hidden. Implicitly set skip-splash and skip-onboarding options. |
log-path |
Set the folder where the Skydel log should be stored. ex: --log-path=~/archives/ |
output-path |
Set the folder where the Skydel Output repertory should be stored. |
skip-release-note |
Skip the release notes window. |
hil-port |
Explicitly set the HIL UDP port. |
spoofing |
Start Skydel spoofing instance. Read Advanced Spoofing for details. |
4.2.7. Launching Multiple Instances of Skydel
If your license permits, you can launch more than one instance of Skydel at a time on the same computer. This enables you to have two configurations (or more) running at the same time. This can be used to simulate:
-
multiple vehicles;
-
multiple antennas;
-
multiple vehicles with Real-Time-Kinematics (RTK).
If your installation can run multiple instances of Skydel, your current licenses will display a Multi-Instance of 2 or higher.
Spoofing is another type of Skydel instance that requires a specific feature activation. |
4.3. Licensing
4.3.1. USB Dongle
Most of the time, the Skydel licenses are delivered on a USB dongle. This USB dongle contains information such as the serial number, licensee name, and a list of enabled features (usually a list of GNSS signals). Users have the flexibility to move the dongle to any computer properly configured to run Skydel.
4.3.2. License Feature List
You can review your current Skydel licenses by following these steps:
-
Open Skydel;
-
Click on the Help tab;
-
Select About Skydel…
The following information will be displayed:
-
Skydel Version, SHA code, and release date;
-
License dongle serial number;
-
Licensee name;
-
Highest version of Skydel that you can upgrade to with the current license;
-
Number of Skydel instances that can run simultaneously (Multi-Instance);
-
Number of output antennas allowed for anechoic mode option;
-
Number of spoofing instance(s) allowed;
-
Listing which features are currently enabled with the license.

The SHA code and release date in the official software release is most likely to differ from the image above. |
4.3.3. License Update
A new license file will be required if you purchase additional features. In order to update the license, follow the instructions below:
-
Open Skydel;
-
Go to the Help tab;
-
Select Update License;
-
Select the new license file;
-
Click Open;
-
The license file will update, and Skydel will close.
Reopen Skydel and verify that the new licenses appear correctly in the About screen.
4.4. Preferences
Skydel preferences are global settings that persist across configurations, power cycles, and Skydel instances. These preferences can be accessed from the Edit menu in Skydel.

The preferences are organized in categories (tabs). Depending on your license or detected hardware, some categories or specific attributes in a category might not show. |
4.4.1. General
You can control the location on your hard drive where Skydel will save configurations, logs, and other data.

The Spectrums visible by default option can be unchecked if your computer does not have the processing power to generate FFT in real-time or if you would like to reduce the work load on the CPU and GPU.
The streaming buffer preference was moved to the Performance tab. |
4.4.2. Proxy
If you are behind a firewall, Skydel will be unable to connect to openstreetmap.org↗. This will prevent the street maps from properly loading. Contact your network administrator to obtain the proxy information. You can enter this information into the proxy preferences; this will then enable Skydel to connect to openstreetmap.org↗.

4.4.3. Synchronization
These preferences are used to synchronize one or many radios with an external timing receiver that can generate a PPS output, such as the OctoClock-G from Ettus. Detailed timing diagrams can be found here.

4.4.3.1. PPS OUT Delay
This value controls the delay applied to RF transmission to align the RF with the PPS OUT signal. This preference is used only if both Sync Time Master and Sync Time Slave are unchecked. In this case, the SDR is using its own internal PPS reference. See section Synchronize Simulators for Sync Time settings details.
The value is calibrated for different sampling rates. The user may adjust this value if it is necessary to offset or align the PPS OUT signal of the SDR with the PPS signal of the GNSS receiver under test. In most cases, the value should be left to its default.
PPS OUT Delay applies only for Ettus X300/X310 or NI USRP-294xR/295xR SDR. |
4.4.3.2. PPS IN Delay
This value represents a delay between a reference PPS pulse (on the PPS IN port) and the beginning of the RF signal. The default value is 2000.000000ms. The resolution is 0.000001ms (1ns). The effectiveness of this value differs depending on the radio type you are using (examples follow).
4.4.3.2.1. Ettus N310, X300/X310, NI USRP-294xR/295xR
This value is only effective when Skydel is set as a Master in the Synchronize Simulators page. The Delay value is transmitted by the Skydel master to each connected slave instance of Skydel, such that they will start at the exact same time. The user can adjust this value if necessary to align the PPS OUT signal of the SDR with the PPS signal of their GNSS receiver.
In most cases, the value should be left to its default.
NOTE: An external PPS must be provided (using an OctoClock-G for example).
4.4.3.2.2. Dektec Cards (DTA-2115B and DTA-2116)
This value is effective whether or not Skydel is set as a Master in the Synchronize Simulators page. If Skydel is configured to be a Master, the PPS IN Delay value is transmitted by the Skydel master to each connected slave instance of Skydel, such that they will start at the exact same time. The default value is calibrated in order to perfectly synchronize the RF signal to the PPS rising edge at the PPS IN port of either the Dektec DTA-2115B or the DTA-2116.
NOTE 1: When your system uses a Clock/PPS distribution module (such as the Safran CDM-5 in the GSG-8), you can use the PPS IN value to account for the time delay between the rising edge at the input of the Clock/PPS distribution module to the PPS IN port of the DTA-2115B or DTA-2116. In the case of the Safran CDM-5 card, this delay is 18ns.
NOTE 2: The recommended PPS IN Delay setting is the value minus 2000ms (default value). A modulo 1000ms operation is then applied to the resulting delay. Ex: if the value is 3200ms, the effective PPS In delay setting is 200ms.
4.4.3.3. Client / Server Settings
To synchronize radios connected to different computers, each computer running Skydel must talk to each other. If the radios are connected to the same computer, but used by different Skydel instances, each instance must talk to each other as well. In any event, one of the Skydel instances must be defined as the server (master) while each of the other Skydel instances are clients (slaves). The client settings control which server the Skydel slaves will try to connect to. The server settings control which port the Skydel master will listen on. You can read more details about this in the Synchronize Simulators section.
4.4.3.4. GPS Timing Receiver
You can synchronize radios to the output of a timing receiver. This can be used to synchronize Skydel to the live sky or some other signal source. The timing receiver can be an OctoClock-G from Ettus or another receiver that supports NMEA messages (required sentences are "$GPGGA" and "$GPRMC"). The accuracy of this type of synchronization is better than 50 ns.
4.4.3.4.1. Generic GPS Timing Receiver
To connect to a generic GPS timing receiver, you must select the Serial Port option and choose your receiver in the Edit dialog. Under Windows, it will typically be "COM4". Under Linux, it will typically be "ttyACM0". See Receiver section for more details.
4.4.3.4.2. Octoclock-G
To connect to an Octoclock-G, you must select the IP Address option and write the Octoclock-G’s IP address in the Edit dialog. Typically, the IP address is "192.168.10.3".
To use the OctoClock-G, connect a GPS signal source (such as live sky) to the GPS antenna port on the front. See section the GPS Timing Receiver section for connection details.
The OctoClock-G supplies 5 volts through the GPS antenna port. Ensure that you are using a 5-volts antenna! If you are not using a 5-volts antenna, use a DC-Block to isolate the GPS antenna port. If you are using a 12-volts antenna, you will have to use the DC-Block and find some other means of powering the antenna. |
Allow approximately 15 minutes for the GPS lock light to turn green. The following conditions may prevent the GPS lock light from turning green:
-
poor signal level;
-
bad satellite geometry;
-
poor multipath conditions;
-
poor ground plane conditions;
-
inability to download ionospheric data;
-
“time has gone backwards” issue: you may need to restart the OctoClock if the current time of the signal source jumps backward in time.
Once the OctoClock GPS lock light turns green, you can create a time-synchronized simulation. You can read the Start Time and the Synchronize Simulators **sections for more details.
4.4.4. USRP
You can change the USRP preferences to specify preferred default values when adding USRP radios in the Output settings.

The frame size is the actual size of the packets transferred over 10 GbE. The X300 SDR performs best when the frame size is set to 8000 bytes, but not all network adapters can support it. If your network adapter does not support this frame size, you will get “Transmission Sequence Error” messages when starting the simulation. The default value is 4096 bytes and it works for all network adapters.
In all cases, the jumbo packets must be enabled in your network adapter’s driver settings. For Linux, see how to set the MTU size in section Network Card Driver: 10 GbE Intel X520-DA2. For Windows, see how to enable jumbo packets in section Network Card Driver: 10 GbE Intel X520-DA2. |
The default IP address setting controls the IP address that will be used by default for any new radio that you add to the Output settings. This setting is only provided for convenience. Skydel will always use the IP address specified in the output settings.
The default clock should be set to GPSDO only if the SDR is equipped with a GPSDO precision clock. GNSS simulation requires a high precision 10 MHz source.
Users have the option to stop the simulation or not when a USRP "Sequence Error" occurs. Usually, a sequence error occurs when there is a problem in the communication link between the computer and the radio. The recommended setting (stop on sequence error) is checked be default.
If you run a long simulation (multiple hours or days), the likelihood of dropping a packet increases. The consequence of dropping a packet is a short period (ms) with no RF signal. Since all packets are timestamped, the RF streaming will resume with the next packet at the appropriate time. |
The GPIO refers to the AUX. I/O DB-15 connector on the front panel of the USRP X300 radio. These I/O can be set in real-time by a custom library which can be loaded by Skydel. See section Trigger (USRP X300 AUX I/O) for an example.
The anechoic chamber hardware description file is used only for the Anechoic Chamber scenario and describes the list of connected radios and some low level instructions to leverage the hardware architecture. This file is referenced here, but edited in the Anechoic Chamber Builder software only.
The anechoic chamber preference appears only if the feature is enabled. |
4.4.5. Dektec
You can change the mapping between a radio output, identified by its device number, and a Dektec card, identified by its serial number.

Radio outputs are by default mapped to Dektec cards in ascending serial number order. This dialog allows you to change this order by selecting a different device number from a drop-down in the left column to associate it with the corresponding card serial number in the right column. If the same device number is used in more than one association, you will get a warning message when trying to navigate to another tab or to quit the Preferences dialog box by clicking on the OK button.
The Dektec tab is only shown if at least one Dektec card is present on the system. |
4.4.6. Performance
You can change the Engine Latency, the Streaming Buffer, as well as the configurable Optimizations in this tab.

Since the Skydel’s version 21.9.0, the Streaming Buffer is no longer as relevant when optimizing a system. The Engine Latency is what gives the Skydel’s real-time engine more room to operate, and will ultimately affect the simulation. To know more about the Engine Latency, read the Performance Graph subtab section.
It is highly recommended to always have the Streaming Buffer larger or equal to the Engine Latency, as doing otherwise can cause underruns on start. You should not play with these preferences unless you desire to optimize the latency of your system. |
The GPU optimization setting will by default choose the best configuration for your setup. It is possible to enable or disable the optimization for all the GPUs used in the setup, or set them individually.
Since Skydel is scalable and we can’t test every configuration possible, the option to enable or disable the optimization is available, but should not be changed by most users. |
The maximum number of signals define the number of signals a simulation can modulate at the same time. Each echo counts as an additional signal. So if you have the direct line of sight and 2 echos it counts as 3 signals.
It is recommended to modify the maximum number of signals only when your GPU’s memory limits the configuration. |
For Advanced Jammers users, you will find in the "Memory" section a preference to preallocate GPU buffers for a given number of AWGN signals. The maximum number of preallocated GPU buffers is 100 per RF Output.

4.5. Configurations
To run simulations with Skydel you need to create, save, open, and modify “Configurations”. Sometimes configurations are called “scenarios”.
Configurations are just like any other type of computer file that is used to save or load. Use the File menu to access these options.

When you make changes to settings or interferences, the configuration will be marked as modified and Skydel will indicate Not Saved in the window’s title bar. After saving the configuration, the indication will disappear until you make new changes.
4.5.1. Create New Configuration
To create a new configuration, click New Configuration in the File menu, or use the Ctrl+N shortcut. If the current configuration is modified (not saved), you will be prompted to discard or save it before creating a new configuration. If you cancel, the current configuration will remain and Skydel will not create a new configuration.
By default, a new configuration does not know anything about your hardware setup and you will need to configure the Output first.
4.5.2. Save Configuration
To save your current configuration, open the File menu and click Save or Save As.
By default, each of your configurations is saved in the Skydel-SDX/Configurations folder. Configuration files use the .sdx filename extension.
4.5.3. Open Configuration
To open an existing configuration, open the File menu and click Open Configuration. If the current configuration is modified (not saved), you will be prompted to discard or save it before opening an existing configuration. If you choose to cancel, the current configuration will remain active and Skydel will not open the configuration.
4.5.4. Set as Default Configuration
Use this option to set the current configuration as the one to use when you create a new configuration.
4.5.5. Reset Default Configuration
Use this option to reset the default configuration to the initial default configuration (factory reset). Clicking this option will not change your current configuration.
4.6. Running Your First Simulation
If you are new to Skydel, we recommend that you follow the instructions in this section to create your first configuration. This is a quick walkthrough of the steps required to get a simple GPS simulation up and running. We will also highlight some interesting features along the way. Refer to the Settings section if you would like more details on a particular area.
This section assumes you have a single radio setup using the Ettus X300 SDR.
4.6.1. Create a New Configuration
Click New Configuration in the File menu (or use Ctrl-N shortcut). If you already have a configuration loaded and modified, you will be prompted to save or discard it.
4.6.2. Add a radio
Next, you will need to add a radio. Navigate to Settings - Output.

A radio may already be enabled in your Set as Default Configuration. If that is the case, you can click on the Clear button to remove all radios. |
Select the X300 SDR in the dropdown list and click the Add button.

The X300 will be added with the default IP address and clock settings. If the default values are incorrect for your hardware setup, click Edit to make the necessary changes and click OK when done.

4.6.3. Select GNSS Signals
Click the Edit button for the RF A output of Radio 1.

Select GPS L1 C/A and click Ok.
You can also select Gaussian Noise. This will reproduce realistic C/No. |

The Signal Selection dialog box enables you to change the output gain. By default, the gain is 80 dB. It means that the signal power level measured at the Tx connector of the X300 is 80 dB stronger than the power level displayed in the simulator. For a receiver on the surface of the Earth, where you would expect power level at -130 dBm, you will actually measure -50 dBm per satellite on the X300 Tx connector. |
For more information about signal selection, refer to the Output section. Or, you can also consult the Additional Resources section.
4.6.4. Select Vehicle Motion
Next, we will configure our vehicle to travel in a circle. Navigate to Settings - Vehicle - Body to change the vehicle motion settings.

Next, select Circular from the dropdown list to choose a circular trajectory. Other details, such as location, speed, and radius of the trajectory can be modified by hitting Edit.

To navigate back to the Settings, click the back arrow.

4.6.5. Start the Simulation
Before you begin a simulation with a connected receiver, make sure that you attenuate the RF signal to a proper power level using RF attenuators. See section Reference Power Level for details. |
To start the simulation, click the Start button. This action is only available when the status is Ready.

The simulator state will change to Initializing for approximately 10 seconds and if there are no issues with the plug-in instances initialization and the hardware setup, the state will then change to Streaming RF. Now the simulation is running.

During the simulation run (Streaming RF), you will see the elapsed time advance. The Stop button stops the simulator and RF streaming, while the Pause button will slow the vehicle to a halt while the simulator continues to stream RF. If you click on the Map tab, you will see the vehicle is not moving when you click Pause, and starts moving again when you click Resume.

If your GNSS receiver is streaming NMEA to a serial or USB port, you may connect to your receiver to parse and analyze the NMEA data in real-time.
4.6.6. Additional Resources
Here are some additional resources that can help you get started when running your first GNSS simulation:
4.7. Settings
When creating and modifying configurations, you will spend the majority of your time in the Settings tab of Skydel. You can access the Settings tab by clicking this button:

Remember that settings are stored in your Configurations. After making changes to settings, you might want to save them for future use.
You can see the settings tab in the image below.

The settings are divided into several categories. Depending on your license, the settings menu may show different categories.
To navigate to a specific category, first click the Settings button. Then click on the appropriate settings menu and sub-menu. In this document, we will refer to these sorts of steps by instructing you to navigate Settings - Vehicle - Body (or something similar).

As you navigate in the Settings, a visible path builds itself at the top of the menu. To leave a nested settings category, click the back arrow.

Alternatively, clicking the parent category (underlined) in the path will move you back one level.
At the bottom of the settings tab, you can see the sky view and the power sliders. You can click & drag the horizontal splitter up and down to adjust the sky view’s dimensions. In the sky view, you can uncheck Show All Systems to display only a single type of constellation at a time. The buttons on the left are called the Constellation Selectors and they let you choose which constellation is shown in the sky view and referenced in the power sliders.
The image below shows the GPS constellation only.

The image below shows the GLONASS constellation only.

You can change the user interface selected signal using the combo box.

The selected signal affects different parts of the user interface:
-
The sliders only change the selected signal, unless the check box "All signals" is selected
-
The power label over or under the power bars is only for the selected signal
-
The satellite power info button opens the dialog for the selected signal


Once the simulation is started or armed, the sliders are enabled as well as the Manual Offset combo box in the power info dialog.
If you place your mouse over a satellite in the sky view, you will see additional information about that particular satellite, such as its elevation and azimuth relative to your receiver.
The sky view does not change as a result of vehicle attitude (yaw, pitch and roll) changes. The DOP values do not change when you select one constellation in particular. The DOP values always include all satellites from all constellations. |
In the upper right corner of the sky view, there is a round button with the letter ‘i’ in it. This button brings up a window with additional information about the sky view.

4.7.1. Output
The Output settings are located in the Settings - Output menu.
The Output settings are where you control which RF output will generate which signals. These settings are what bridge the gap between the software simulation and the hardware signal generation. Proper setup of the output settings is a key component of a successful simulation.
You start by selecting the output type for the simulation. The options are:
-
Anechoic Chamber: This option uses up to 16 X300 Software-defined radios to transmit GNSS and jamming signals inside an anechoic chamber. This option is visible only if the Anechoic Chamber feature is enabled.
-
DTA-2115B: Software-defined radio from DekTec.
-
DTA-2116: Software-defined radio from DekTec.
-
File: The IQ data will be saved to a file on the computer’s hard drive.
-
None: RF is not generated and IQ is not saved, raw logging data is saved.
-
NoneRT: Similar to None but runs in Real Time. Useful when developing automation scripts.
-
X300: Software-defined radio from Ettus Research. Equivalent radios from National Instruments can be used as long as they have the correct firmware. If you have a X310 radio, select X300 in the list.
-
Wavefront Controller: This option requires a special system in order to simulate the behavior of a CRPA. This option is visible only if the Wavefront feature is enabled.
For the remainder of this section, we will be using the X300 SDR output type. Setting up the other output types is very similar, except for Anechoic Chamber which has a dedicated section. Wavefront has its own section too.
4.7.1.1. Radio Selection
In the Settings - Output, select the X300 SDR in the dropdown list and click Add.

If an output is already added, you can click on the Clear button before adding the X300 SDR. You can add multiple outputs, but they must be of the same type. For example, you can add 2 USRP X300 radios, but you can’t add a DTA-2115B after you have added a X300. |
When adding a USRP radio such as the X300, the IP address and clock source are preset with default values as defined in the Preferences. If the default values are incorrect for your setup, click Edit under the radio name to edit the radio settings.

Changing the values here will not change the preferences. |
4.7.1.2. Signal Selection
Take a moment to look at the front of the USRP X300 radio. You will notice that it has an RF A TX port and an RF B TX port.

The markings on the radio correspond to the labels in the Output settings. For example, any signals assigned to RF A in the Output settings will be generated and output by the USRP X300 RF A TX port. To assign signals, click the “Edit” button for the corresponding output.

The Signal Selection dialog box will help you choose the signals that you want to be generated for each output. Start by selecting Upper L-Band (e.g. L1) or Lower L-Band (e.g. L2).

If you have the Advanced Jammer option enabled, the Output Type will also include the Interference option.
If Gaussian Noise is checked, Skydel will add noise to reproduce realistic C/No.
Next, select the signals that you would like this output to generate. As you make selections, you will notice that the dialog box will update the Ideal Sampling Rate as well as disable code types that are not compatible with your current selection. For example, when selecting Galileo E5 AltBOC in the lower L-band, the current sampling rate changes to 60 MSps (Mega Samples per second). Also, the GLONASS G2 and Galileo E6 HAS signals are disabled because they are too far away from the E5 signals to fit within the same RF band. To work around this, you can either choose a radio that can support higher sampling rate or use an additional output (or additional radio).

You may constrain this output to keep its sample rate low by changing the Max Sample Rate to a lower value. Alternatively, you may constrain the output to remain high by changing the Min Sample Rate to a higher value.
Due to a limitation in the hardware, some SDR models require that all outputs must have the same sampling rate. For example, if the signals selection on RF A requires 25 MSps and the signals selection on RF B requires 12.5 MSps, both outputs will be set to 25 MSps. For SDR models with this constraint, the selected sampling rate is always the highest sampling rate of any available output.
Only signals for which you have an active license will be available for choosing.
Galileo E5 AltBOC can be generated if you have an active Galileo E5 license by clicking E5 AltBOC or both E5a and E5b under Signal.
The default gain for the USRP X300 radio is 80 dB. You can change the gain by 1 dB step between 80 dB and 115 dB. See Reference Power Level section below for more details.
Once you have made your signal selection, click the “Ok” button to return to the Output settings. The simulation will not run if you try to assign the same signal to multiple outputs. Once you have completed your signal selection for all outputs, the Output settings should look something like this.

Adding radios and selecting signals can be a repetitive task. You can save the current output settings as the default outputs by using Set as Default Configuration. |
4.7.1.3. Reference Power Level
Once you have selected a radio, you can click the Reference Power button to get the nominal power at the TX connector.

For the X300, the reference power level is -50 dBm at the TX connector for a single GPS L1C/A signal.

4.7.1.4. Optimizing Performance
The main concern when configuring the Output settings is staying within the performance limitations of both the CPU and the GPU. Skydel is a software-defined GNSS simulator, so the number of signals that can be simulated is limited by the performance of the software running on the computer (most simulators are limited by the number of hardware channels they have). The number of signals that can be simulated depends on a number of factors:
-
the number of signals being generated (e.g., [C/A + P] x 10 satellites = 20 signals);
-
the sampling rate of those signals (e.g., 50 MSps, 12.5 MSps);
-
the complexity of those signals (some signals are harder to simulate than others).
If you hit the performance limit of your computer, you have 2 options. Option 1 is to reduce any of the items listed above. Option 2 is to increase the performance of the hardware.
When you select signals with different carrier frequencies, Skydel must increase the sample rate to cover both signals and use a carrier frequency in-between the 2 signals. However, if you assign these signals to different RF outputs (RF A vs RF B), Skydel will reduce the sampling rate. This will greatly reduce the workload for the GPU.
You can disable the spectrum subtab in the preferences to reduce the CPU/GPU workload. |
Once you have completed the signal selection, you can test the performance of the GPU by clicking the Test GPU Speed button. The GPU Benchmark dialog box will display the signals that you have selected in the Output settings. Signal types that you have not selected will not be part of the test. The benchmark assumes 14 satellites for GPS and 10 satellites for each of the other constellations. If you only expect 10 GPS satellites to be in view, you can lower this value to more accurately reflect the conditions you will observe during your simulation.

Once you are satisfied with your selection, click the Start button to begin the test. Once the test has completed, you will see a score for the GPU. A score higher than 1.00 means the GPU performance is sufficient for this signal selection. However, you don’t want to cut it too close, we recommend a score of 1.10 or higher. A score of less than 1.00 means the GPU doesn’t have enough performance to generate the signals in real time. Try reconfiguring the Output settings to use smaller sample rates, reducing the number of satellites, or reducing the number of signals selected.

4.7.1.5. IQ Data Files
To save IQ data to a file, select “File” as the output type and click the “Add” button. (If you already have X300s configured, you will have to delete each of them before proceeding).
Skydel will prompt you to name the file that you would like to save the IQ data to. You should consider saving this data on a hard drive with plenty of space and fast writing speed because IQ data files can grow very large over time. You can add multiple IQ data files by clicking the “Add” button. This step is necessary if you want to save both L1 and L2 data. Add signals to each individual IQ file using the Signal Selection dialog box that is used for X300 SDRs. Once you have selected each of the desired signals, your output settings should look something like this:

When you are ready, start the simulation. Skydel will begin saving data into the specified files.
IQ files can be very large. You will quickly fill up your hard drive if you let the simulation run for too long. |
When saving data to IQ Files, your GPU does not need to pass the performance test. Skydel will generate the file as fast as it is able, which, depending upon the performance of your GPU and your hard drive, may be slower or faster than real-time.
When you generate an IQ file with Skydel, you get 2 files per RF output:
- IQ File Data Format
-
The IQ File uses the extension .iq and contains the raw 16-bit IQ samples in binary format. The file has no header. The first 2 bytes is the integer value for I, the following 2 bytes is the integer value for Q. The pattern simply repeat I,Q,I,Q,I,Q, etc. The integer format is in little endian.

- IQ File Metadata
-
This files uses the extension .xml and is consistent with the GNSS SDR Metadata Standard (http://sdr.ion.org/). It contains multiple fields describing how the .iq file should be read including the sampling rate and center frequency of the signal.
It is normal to have zeros at the beginning of the file. When the simulation starts, the simulator will start the simulation of the transmission of the signals from the GNSS satellite, but since it takes several milliseconds to reach the receiver antenna, the file will be filled with zeros or Gaussian noise until the signals reach the receiver. Typically, that delay is around 70msec depending on the distance of the satellites with the receiver. |
4.7.1.6. Anechoic Chamber
Configuring Safran’s Skydel for an anechoic chamber is a 4-step process:
-
Hardware step: where you list and assign all the connected radios and describe the hardware architecture.
-
Spatial Configuration step: where you select your receiver antenna’s location and you determine the elevation and azimuth of the transmitting antennas relative to this location.
-
Calibration step: where you perform a calibration to precisely measure power and time offset between antennas.
-
Scenario step: where you configure Skydel for a specific simulation scenario.
Step 1 is usually performed by an Safran engineer or qualified personnel. It requires a keen understanding of the computer motherboard and its PCIe bus routing in order to optimize the data transfer between the different peripherals (CPU, GPU, RAM, NIC, etc.). Typically, the result of this step is stored in a file named hardware.xml. The path to this file must be properly set in Skydel USRP preferences.
Steps 2 and 3 are done within the Anechoic Chamber Builder software. Once these steps are complete, the software will output the results into an ANEC file.
Step 4 is done in Skydel.
In the Settings - Output, select the Anechoic Chamber in the dropdown list and click Add. Locate your ANEC file and click Open.

The output settings page is divided in 2 parts:
-
The left part shows a tabulated view with GNSS and Interference tabs.
-
The right part shows a sky view depicting the ANEC file.

The sky view in the Constellations subtab does not show any satellites in view simply because there are no GNSS signals selected in this scenario. Click Select Signals.

Choose the desired signals and click OK. The main window is updated.

The GNSS tab is updated with useful information such as the RF outputs' associations with each signals and satellites. Moving the mouse over a row in the table will highlight in green the corresponding antenna in the sky view on the right (see image below).

In this example, the row indicates that GPS SV ID 3 and 22 are mapped to the same physical output: 1B. The next row also indicates the same output 1B is being used to transmit Galileo SV ID 33.
Below the table you will find a text report listing the angular distance between the GNSS satellite and the physical antenna used for transmission. Skydel will do its best to minimize angular distance, but it is useful to look at this table and validate that the distances are acceptable for your scenario. Here’s a text report example:
Angular Distance (degrees) Constellation Signal SV ID Output -------------------------------------------------- 7.59 Galileo E1 33 1B 7.81 Galileo E1 25 3B 8.34 GPS C/A 3 1B 9.60 GPS C/A 2 3A 12.42 GPS C/A 19 4A 12.57 GPS C/A 28 2B 15.99 Galileo E1 31 2B 16.11 Galileo E1 12 4A 16.97 GPS C/A 12 3B 21.91 Galileo E1 24 3A 24.80 Galileo E1 11 3A 25.02 GPS C/A 6 4A 25.55 GPS C/A 17 4A 27.84 GPS C/A 24 3B 28.34 GPS C/A 22* 1B 31.92 GPS C/A 23* 2A 36.46 GPS C/A 4* 2A
Some SV ID are marked with an asterisk, such as number 22*. It means that the SV ID 22 is currently below the masking angle and should it be moving above the masking angle during the simulation, it will be transmitted using this physical output.
Keep in mind that the mapping is only done once at the beginning and does not updates during the simulation. Therefore, the angular distance between a GNSS satellite and its transmitting antenna may increase during the simulation. |
Some Skydel features are not yet supported with the Anechoic Chamber output:
These constraints are not enforced by Skydel: the user must manually change the receiver trajectory and antenna patterns. |
4.7.1.7. Wavefront
Wavefront output can only be used with the GSG Wavefront system. It leverages the multi-instance synchronization feature of the Skydel software to enable simulation scenarios including high-dynamics trajectories (GNSS and non-GNSS).
GSG Wavefront generates phase-synchronized signals in real-time, to realistically simulate the signals received by a CRPA.
You can find a more detailed description of GSG Wavefront in the product manual. Your GSG Wavefront also includes an XML file. This file describes your hardware architecture and its simulation capability.
Your system contains more than one computer:
-
A Wavefront Controller
-
And one or more GSG - Nodes
It is only necessary to change settings on the Wavefront Controller; those settings also control the Nodes. The following instructions only concern the Wavefront Controller.
To view or change the GSG Wavefront settings, navigate to the Settings - Output menu. Select Wavefront Controller in the dropdown list and click Add. Locate the hardware file and click Open.

The output settings page will display three tabs.
-
Monitor
-
Signals Selection
-
Antenna
4.7.1.7.1. Monitor
The Monitor tab allows you to observe the state of your GSG Wavefront system.

Wavefront systems leverage the multi-instance synchronization feature of Skydel. Connection is fully automated and made in two steps:
-
The Wavefront Controller connects itself to the remote API of all Nodes.
-
On each Node, it activates the Slave mode through remote API in order to synchronize all Skydel simulators.
The API Link LED will be green if the Wavefront Controller is connected to the API of the Node, and the Master Link LED will display green if the instances on the Nodes are synchronized with the Wavefront Controller. If an LED remains red, you should confirm that the associate GSG Node is on and fully operational and that all required Skydel instances are open.
4.7.1.7.2. Signals Selection
This tab summarizes the signal possibilities and settings within your GSG Wavefront system.

To choose GNSS signals, click the "Edit selection" button in the desired band. As you make selections, you will notice that the dialog box will disable code types that are not compatible with your current selection. The compatibility depends on your system’s hardware.

If your system has the Interference option enabled, you can choose an interference group for each band in the list. To configure the groups, navigate to Settings > Interferences (see the Advanced Jamming section). If you don’t need to use interferences for a band, choose the "None" Group.

4.7.1.7.3. Antenna
This last tab allows you to enter your CRPA information for use by the GSG Wavefront system.

The "CRPA Offset" refers to the attachment point and attitude of the antenna’s center relative to the vehicle’s body. The "CRPA Offset" are coordinates in the Body Frame, such as the vehicle’s antenna offset.
A CRPA is different from other antennas due to its multi-elements system. Each element represents a fixed location on the antenna. The "CRPA Elements Offset" refers to the attachment point and attitude of each element relative to the antenna’s center. The "CRPA Elements Offset" are coordinates in the Antenna Frame.

For each CRPA element, you can specify a position offset and a model. Models are saved data representing different antenna models. They can be defined in the Settings - Vehicle - Antenna menu and are assigned in this tab.

If you don’t want to simulate all the elements of your config file, you can disable some. Just by clicking the Enable checkbox for the elements you want to disable.

The disabled elements will also be visible in the monitor tab:

4.7.1.7.4. Phase Graph
The "Wavefront Phase" tab shows a graphic of the real-time phase corrections applied to each of the simulated antenna elements. The first enabled element is the reference. This graphic is updated in real-time, during both the "WF Init" and the "Running" states. During the "WF Init" state, coarse phase corrections are applied to each element, bringing the phase offsets between elements below the acceptance threshold. Then, during the "Running" state, the phase offset between each elements is constantly monitored and compensated. If, for any reason, any of the phase offsets gets above the threshold value, a warning message will show-up in the "Status Log" tab. As you can see on the image, the graphic has vertical bars, which indicates when the phase calibration process changes from coarse calibration to finer calibration steps.
Note that there is a drop-down menu which permits you to view the phase correction for the different simulated RF bands. You can also view the phase corrections for GNSS or Interferences channels.

4.7.2. Start Time
The Start Time settings are located in the Settings - Start Time menu.
Controlling the simulation start time is one of the key considerations when testing GNSS receivers. To compare different test runs, it is often critical to have the same start time values to ensure that the GNSS satellites’ geometry is identical for each run.
Some GNSS receivers will refuse to lock on the simulated signal if their internal clocks cause them to believe the time is incorrect. This is one of the many ways a receiver can protect itself against spoofing. It is sometimes necessary to reset the receiver before each simulation to work around this defense mechanism.
It is not necessary to download a RINEX navigation message file matching the simulation start time. Skydel is capable of extrapolating in both the future and the past.
If you want to use a specific RINEX navigation message file as your ephemeris and almanac for the simulation, you will need to import the RINEX file for each constellation.
There are three ways you can control the start time of the simulation:
-
specify a custom time;
-
use the computer system time;
-
use the time from a timing receiver.
When selecting the timing option to use, a preview will be shown to the right.

4.7.2.1. Custom Time
Setting a Custom Time is the most common method of controlling the start time of the simulation. Every time you run the simulation, it will start at the same time. You can change the custom time by clicking on the time field itself.

You can specify the time with any of the fields provided. The other fields will update to reflect the changes that you have made. For example, you can set the date and time to 7/1/2016 and 07:00:00. The week and second will automatically be updated to 1903 and 457200.

4.7.2.2. Current Computer Time
If you select Current Computer Time, your simulation will be synchronized to the computer system time to within approximately 10 seconds. This is due to the time it takes to start the streaming process with the radios. Synchronizing in this way can be useful if you want your simulation to be close to true time. However, for tight synchronization with a time reference, it is necessary to use a timing receiver.
4.7.2.3. GPS Timing Receiver Time
If you want to synchronize your simulation with more accuracy, you can select GPS Timing Receiver Time. Ensure that your timing receiver preference is set correctly. Once everything is configured correctly, you will be able to see a preview of the start time.
Skydel will communicate with the timing receiver during the initialization process and ensure that the simulation starts at the specified time. This process happens after the radio initialization, so a precise synchronization can be achieved.
If desirable, you can add an offset to the simulation start time computed by the GPS Timing Receiver. The value must be an integer between -3600 and +3600 seconds.
As indicated in the Simulator State section, it is important to know that when using a GPS Timing Receiver, any changes made to the settings while the simulator is in the "Armed state" will be discarded when the simulation starts. |
4.7.2.4. Leap Seconds
You can specify the current leap seconds (LS) value and the date of the next leap seconds future (LSF) event.

The LS value is used by the receiver to convert GPS system time to UTC time. NMEA data is marked with UTC timestamps. If the receiver and the simulator use different LS values to compute the UTC time, it will make the NMEA output difficult to compare, especially in the receiver deviation graph.

If you uncheck (disable) the LSF event, Skydel will set the LSF value in the navigation message to the current leap seconds value regardless of the LSF value that you entered.
Leap Seconds (LS) and Leap Seconds Future (LSF) are relative to GPS Epoch. The corresponding LS and LSF for other constellations are adjusted accordingly. |
If you enable the LSF event checkbox and the simulation start time is set for after the LSF event date, Skydel will use the LSF value as the current leap seconds value. You should keep in mind that the LSF event occurs at the end of the specified day, at exactly midnight UTC. You can see the effective leap seconds value (LS vs. LSF) in the dashboard.
Skydel allows any date for the leap seconds future event, but usually the date is set to either June 30th or December 31st.
When simulating LSF event for GLONASS, consider the following limitations: GLONASS supports leap second event only at end of quarters (Mar 31st, June 30th, September 30th or December 31st). GLONASS does not support adding or substracting more than 1 second during the event. |
4.7.2.5. Duration
By setting the duration you can choose how long you would like the simulation to run. By default, the duration is set to Unlimited.
Click the dropdown box to select the desired duration. If you would like to specify a duration other than what is listed, select the Other option. You can then specify the amount of days, hours, minutes, and/or seconds you would like the simulation to run.

4.7.3. Global
The Global settings are located in the Settings - Global sub-menu.
The Global sub-menu contains the Atmosphere, Earth Orientation Parameters, Logging, Signal Level and Synchronize Simulators Settings.
4.7.3.1. Atmosphere
The Atmosphere settings are located in the Settings - Global - Atmosphere menu.
The Atmosphere sub-menu contains the Nominal and Errors atmosphere settings.
4.7.3.1.1. Nominal
The Nominal atmosphere settings are located in the Settings - Global - Atmosphere - Nominal menu.
You can use the Nominal atmosphere settings to change the ionospheric and tropospheric models being applied to the simulation.

The following ionospheric models are available:
-
None;
-
Klobuchar;
-
Spacecraft;
-
NeQuick;
The following tropospheric models are available:
-
None;
-
Saastamoinen;
-
Stanag;
-
DO-229;
The Spacecraft ionospheric model is meant to be used only for a vehicle in space, above the ionosphere. For the most part, the spacecraft will have a direct line of sight through empty space. However, when the GNSS satellites pass behind the Earth, the line of sight will go through the ionosphere for a short time. During that time, the effect on the GNSS signal is non-negligible.
The NeQuick model is more complex than others so it is only computed periodically. The period T, is set to 1 second. The correction at a given time, t, will correspond to the correction at the last computed time. For example, the ionospheric correction, C(t), for the NeQuick model is computed as follows: 1. C(0 < t < T) = 0. 2. C(T < t < 2*T) = C(0) 3. C(2*T < t < 3*T) = C(T) … N. C((N-1)*T < t < N*T) = C((N-2)*T)
When selecting an Ionospheric model, the model is applied and affects the pseudo-range value of the satellites of all constellations. However, the navigation message will still be populated with values coming from the receiver model. For example, if you use the NeQuick model with a receiver that does not support it you might get some errors.
You can configure the NeQuick ionospheric model by importing MODIP and CCIR files. Click the Import button in the NeQuick tab. You will then be asked to provide an appropriate path. Sample files are located in “Skydel-SDX/Templates”.
When you choose the Spacecraft model for the ionosphere, you should also set the tropospheric model to None. |
4.7.3.1.2. Errors
The Errors atmosphere settings are located in the Settings - Global - Atmosphere - Errors menu.
You can use these settings to add positive offsets to the current ionospheric model.
"Apply delays to ionospheric model" needs to be checked to enable the errors when the simulation runs.

When the errors are enabled, the interactive map shows the current offsets at each Ionospheric Grid Points (IGP) of a ionospheric grid, with either colors or numbers.
Checking "Compensate ionospheric delays in SBAS long term corrections" will add these IGP values in the SBAS long-term corrections (message 26).
You can move and zoom the map to focus on areas of interest. Information related to the point highlighted with the mouse pointer are shown below the map.
The Edit button opens a dialog enabling the modification of the map’s IGP values.

In "Select" mode, you can select points and modify their offset values. Selected points appear in blue, and their offset can be incremented/decremented by the value set in the field next to the +/- buttons. Alternatively, selected points can be set to the value indicated in the field next to the "Set" button.
While selecting with the mouse, holding the Shift Key on the keyboard will add to the current selection, while holding the CONTROL (CTRL) key will remove points from the current selection.
The "Clear" button will reset all the values on the map.
Use the "Panning" mode to move and zoom the map. The "Best fit" button will fit the whole points in the current canvas.
You can import or export a grid in CSV format, where each line describes a grid band (0 to 11), an IGP index (1 to 201, depending on the band) and the offset applied (0 to 99 meters).
Click OK to save your changes or click Cancel to revert them.
4.7.3.2. Earth Orientation Parameters
The Earth Orientation Parameters settings are located in the Settings - Global - Earth Orientation Parameters menu.
Default Earth Orientation Parameters range from January 1st to December 31st of the year of the default simulation start time.
The Import button opens a dialog to import Earth Orientation Parameters from a CSV file.

Below are the column descriptions for each Earth Orientation Parameter.
Column | Description |
---|---|
MJD |
Modified Julian Date. |
X PM, Y PM |
Coordinates or the pole. |
UT1-UTC |
Difference between the Universal Time and Coordinated Universal Time. |
4.7.3.3. Logging
The Logging settings are located in the Settings - Global - Logging menu.

Use the Logging settings to control how Skydel logs data during a simulation.
4.7.3.3.1. Raw
Turn on the Raw Logging option to log simulation data such as satellite trajectories, receiver trajectories, and signal power levels. You may also specify the desired update rate at which data is logged.
If you need only raw data without RF signals, set your output to None and Skydel will generate the raw log files much faster than real time. |
Raw logging at higher rates can interfere with the simulator’s real-time engine on a slower computer. If you experience underrun problems with a radio, either reduce the logging rate or do not log at all while generating RF. |
The logging data can be imported into other tools for analysis purposes. For example, you can use Skydel to generate satellite trajectory data. You can then use this data to model and test the satellite component of your receiver software. This enables you to test your software easily and quickly without the need to use hardware to generate RF signals.
When raw logging is enabled, Skydel will generate:
-
one file for each signal type per Skydel SV ID
-
one file for each multipath echo
-
one file for each visible dynamic transmitter (if using Advanced Jammer)
-
one file for the receiver
Below are the column descriptions for each raw logging files. Column descriptions for a satellite:
Column | Description |
---|---|
Elapsed Time |
The elapsed time of the simulation in milliseconds. |
ECEF X, Y, Z |
ECEF coordinates (meters) of the origin of the transmitted signal (satellite’s antenna phase center plus errors). |
ECEF Error X, Y, Z |
ECEF coordinates errors (offset in meters) from the satellite’s antenna phase center. |
Body Azimuth |
Satellite’s azimuth, in radians, from the receiver’s body position relative to North. |
Body Elevation |
Satellite elevation, in radians, from the receiver’s body position relative to the horizon. |
Range |
Geometrical distance, in meters, between the satellite’s and receiver’s antennas. |
PSR |
Pseudorange, in meters, between the satellite’s and receiver’s antennas. |
ADR |
Accumulated Doppler range, in number of cycles, between the satellite and receiver. |
Clock Correction |
Satellite’s clock correction, in seconds. |
Clock Noise |
Additional clock error, in meters, not accounted for in navigation message. |
Delta Af0 |
Clock offset in seconds. |
Delta Af1 |
Clock drift in seconds per seconds. |
Iono Correction |
Ionospheric corrections, in meters. |
Tropo Correction |
Tropospheric corrections, in meters. |
PSR Offset |
Pseudorange offset, in meters. |
Receiver Antenna Azimut |
Satellite’s azimuth, in radians, from the receiver’s antenna position. |
Receiver Antenna Elevation |
Satellite’s elevation, in radians, from the receiver’s antenna position. |
Receiver Antenna Gain |
Receiver’s antenna gain, in dBi. |
SV Antenna Azimut |
Receiver’s azimuth, in radians, from the satellite’s antenna position. |
SV Antenna Elevation |
Receiver’s elevation, in radians, from the satellite’s antenna position. |
Relative Power Level |
Signal’s relative power level, in dB, corresponding to the sum of the global power offset, the user’s power offset, the receiver’s antenna gain and the satellite’s antenna gain. |
Doppler Frequency |
Doppler frequency, in Hertz, due to satellites' and receivers' antennas dynamics'. |
PSR Change Rate |
Pseudorange rate, in meters per second, due to satellites' and receivers' antennas dynamics'. |
Receiver Carrier Phase Offset |
Phase offset, in radians, caused by the receiver’s antenna phase pattern. This column does not appear in echo log files. |
Satellite Carrier Phase Offset |
Phase offset, in radians, caused by the satellite’s antenna phase pattern. This column does not appear in echo log files. |
Echo Power Loss |
Multipath power offset, in dB, relative to Line of Sight (LOS) signal. This column appears only in echo log file. |
Echo Doppler Offset |
Multipath frequency offset, in Hertz, relative to LOS signal. This column appears only in echo log file. |
Echo Carrier Phase Offset |
Initial phase offset, in radians, in multipath relative to LOS signal. This column appears only in echo log file. |
Echo PSR Offset |
Multipath pseudorange offset, in meters. This column appears only in echo log file. |
GPS TOW |
GPS time of week, in seconds. |
GPS Week Number |
GPS week number. |
SBAS t0 |
SBAS time of the day, in seconds. |
Calibration Offset |
Offset, in meters, applied to the signal during Wavefront simulation. Used to compensate for hardware differences between elements. |
PSR satellite time |
The elapsed time of the simulation when the signal was emitted from the satellite, in milliseconds. |
Column descriptions for receiver:
Column | Description |
---|---|
Elapsed Time |
Elapsed time of the simulation, in milliseconds. |
ECEF X, Y, Z |
ECEF coordinates of the receiver’s antenna, in meters. |
Yaw, Pitch, Roll |
Sum of vehicle’s body and antenna’s rotation angles, in degrees. |
Velocity X, Y, Z |
Velocity of vehicle, in meters per second. |
Accel. X, Y, Z |
Acceleration of vehicle, in meter/seconds. |
GPS TOW |
GPS time of week, in seconds. |
GPS Week Number |
GPS week number. |
Column descriptions for a transmitter:
Column | Description |
---|---|
Elapsed Time |
Elapsed time of the simulation, in milliseconds. |
ECEF X, Y, Z |
ECEF coordinates of the transmitter’s body, in meters. |
Yaw, Pitch, Roll |
Transmitter’s body rotation angles, in degrees. Does not include antenna rotation. |
Transmitter Antenna Gain |
Transmitter antenna gain, in dB. |
Propagation loss |
Power loss, in dB, due to the distance between transmitter and receiver. |
Receiver Antenna Gain |
Receiver’s antenna gain, in dBi. |
Receiver Visibility |
True if the transmitter is visible from the receiver, false otherwise. |
4.7.3.3.2. NMEA
Skydel can also log NMEA-style data. This data will look like the output of a receiver that has tracked the simulation. This can be useful for testing your post-processing tools, or for connecting Skydel to another device that accepts NMEA data. You may also specify the desired update rate at which data is logged.
Skydel uses GPS time (not UTC) in its NMEA output. Also, the altitude in the GGA sentence is based on the ellipsoid model, not the mean sea level. |
4.7.3.3.3. Downlink
It is also possible to log downlink data. The downlink can be logged before message encoding, after, or both. For a message to be logged, the transmitting satellite has to be present.
The downlink format changes depending on the signal type.
For BeiDou D1 and D2, the encoding uses interleaving. Each word uses the following format:
GLONASS encoding uses hamming code. The format is:
For GPS L1 C/A and QZSS L1 C/A, the encoding uses parity. Every data word uses the following format:
The example below is a sample of L1 C/A downlink log.
Elapsed Time (ms),Skydel SV ID,PRN,GPS TOW,GPS Week Number,Subframe,Page,Navigation Message (Hex),Modified 0,1,1,370800.000,2006,1,,22D55589 21D2DEA4 3D644032 2AAAAA95 1555556A 2AAAAA95 15557CFB 3F6925EF 3FC0079E 3E17C87C,No
GPS CNAV uses CRC encoding. The format is the following:
GPS L1C uses CRC encoding. The format is the following:
The L1C message is then encoded using BCH, LDPC and interleaving. The encoded format is the following:
BeiDou B1C uses CRC encoding. The format is the following:
The B1C message is then encoded using BCH, LDPC and interleaving. The encoded format is the following:
Galileo FNAV uses CRC & FEC encoding. The format is the following:
Galileo INAV uses CRC & FEC encoding. The format is the following:
SBAS uses FEC encoding. The format is the following:
Message modifications are included in the logged data.
Skydel includes a Python library to parse the downlink log. The script will parse every line in the log to extract the data in a more usable format. It also includes an example that will parse a downlink log and generate a human-readable output such as this:
Paramater Name,Range,Binary Value,DecimalValue,Unit Preamble,[0, 7],10001011,139, TLM Message,[8, 21],01010101010101,5461, ISF,[22, 22],1,1, Reserved,[23, 23],0,0, Parity 1,[24, 29],001001,9, Truncated TOW Count,[30, 46],01111000101101001,61801, AF,[47, 47],0,0, AS,[48, 48],0,0, SubFrame ID,[49, 51],001,1, PC 1,[52, 53],01,1, Parity 2,[54, 59],100100,36, WN,[60, 69],1111010110,982,week Code L2,[70, 71],01,1, SV Accuracy(URA),[72, 75],0001,1, SV Health,[76, 81],000000,0, IODC,[[82, 83], [210, 217]],0000000010,2, Parity 3,[84, 89],110010,50, L2P,[90, 90],1,1, Reserved 1,[91, 113],01010101010101010101010,2796202, Parity 4,[114, 119],010101,21, Reserved 2,[120, 143],101010101010101010101010,11184810, Parity 5,[144, 149],101010,42, Reserved 3,[150, 173],101010101010101010101010,11184810, Parity 6,[174, 179],010101,21, Reserved 4,[180, 195],1010101010101010,43690, TGD,[196, 203],00001100,5.58793544769e-09,s Parity 7,[204, 209],111011,59, t0C,[218, 233],0101101101101000,374400,s Parity 8,[234, 239],101111,47, af2,[240, 247],00000000,0.0,s/s^2 af1,[248, 263],1111111111100001,-3.52429196937e-12,s/s Parity 9,[264, 269],011110,30, af0,[270, 291],1111100001011111001000,-5.82002103329e-05,s PC 2,[292, 293],01,1, Parity 10,[294, 299],111100,60,
For Windows users, the library can be found in the Skydel-SDX/API/Python/downlink_parser folder.
In the current Skydel version, the following signals support downlink data logging:
|
4.7.3.3.4. RINEX
Skydel can log RINEX data. The RINEX file version generated is V3.03 for all constellations. Skydel will generate one file for each active constellation. Currently, you cannot configure the log sampling rate. A first batch of data is logged when simulation start and the following batches will be logged when Time of Ephemeris change.
The data logging sampling rate for RINEX is:
|
4.7.3.3.5. HIL Input
When HIL Input Logging is checked, the data received from the HIL interface is logged as is. This is useful to determine what was actually received from a remote computer. This data can be compared with the receiver’s trajectory included in the Raw Logging to determine if the HIL input was properly processed by Skydel. Logging at 1000 Hz will also reveal any HIL input problem that may have occurred during the simulation.
4.7.3.4. Signal Level
The Signal Level settings are located in the Settings - Global - Signal Level menu.

You can use the Signal Level settings to control the output power of the satellite signals being generated relative to the nominal value, which depends on your hardware setup. When you configure the output, you can click on the Reference Power button to see the nominal value of your hardware. To adjust the power level of the transmitted signal, you can either change the Global offset or the offset specific to the code type that you are adjusting. By default, Skydel uses a 0 dB global offset, and a realistic offset for all of the other code types. This will correctly model the fact that not all constellations and code types are generated at the same power level. For example, according to the specifications, P-Code should operate at 3 dB less than C/A code.
When using the default settings, the transmit power of a GPS C/A code signal has 80 dB of gain. Typically, for a vehicle on Earth, this will translate into a power level of -50 dBm (measured at the TX port of a X300 radio). When using 60 dB of attenuation, this -50 dBm signal will become -110 dBm. This is the correct power level to simulate a 20 dB LNA. You may refer to the power level section for more details.
To model the noise floor correctly on the X300 Ettus radio, you should use 80 dB of attenuation and a real 20 dB LNA. |
There are three ways you can increase or decrease the power level of a signal:
-
global power offset (+30 dB to -50 dB);
-
code-specific power offset (+10 dB to -50 dB);
-
power sliders (+10 dB to -50 dB);
By using any of these three options, you can obtain a +50 dB increase in the power level of a generated signal. However, it is not recommended to push the power levels this high on too many satellites. At some point, it will end up saturating the I/Q data samples. When this happens, Skydel will warn you that I/Q has been saturated.
If you need to increase the global power offset by more than 30 dB, you can remove some of the attenuation instead.
You can enable or disable the “Signal Strength Model” by checking or unchecking the box.
The Signal Strength Model adjusts the transmit power of each satellite by modeling the following effects:
-
power loss due to the distance between the satellite and the receiver;
-
power loss due to the antenna pattern of the satellite itself. Use the Antenna settings to modify patterns.
The power loss due to the antenna pattern of the receiver is not part of the Signal Strength Model. Use the Vehicle Antenna settings to enable or disable receiver antenna modeling. |
4.7.3.5. Synchronize Simulators
The Synchronize Simulators settings are located in the Settings - Global - Synchronize Simulators menu.
You can use the Synchronize Simulators settings to specify how Skydel instances connect to each other to perform the synchronization. This setting will be used for both multiple Skydel instances running on the same computer as well as synchronization among multiple computers.
Determine which Skydel instance will be the master. Check the Sync Time (Master) check box on that instance of Skydel. Skydel will then begin listening for incoming connections.

Check the Sync Time (Slave) checkbox on each remaining instance of Skydel. These Skydel instances will then connect to the master instance.

At this point, all Skydel instances are connected and will synchronize their radios.
Once you start the simulation on the master instance, each Skydel instance should start running automatically. It does not matter whether each Skydel instance are running on the same computer, or separate ones.
If you are using only one instance of Skydel, and only one Ettus radio such as the X300, you might want to check the Sync Time (Master) checkbox. This will force the radio to use the PPS from an external source. This is important if you are planning on using the PPS output to perform time-error analysis. |
4.7.3.6. Synchronize configuration between master and slaves
Skydel is capable of pushing a master’s configuration to all of the slaves. To do so, in the master instance of Skydel, go to the Settings - Global - Synchronize Simulators section.

Pushing the configuration can be done either manually by clicking the Broadcast now button. It can also be automatically broadcast at every simulation start by checking the Broadcast configuration on simulation start checkbox.
Applying exclusions is used to control which parts of the Slaves' configuration will be retained. For example, if you check the Vehicle Motion filter, after a configuration broadcast all the Slaves will use the master’s configuration, except for the vehicle motion. This can be useful to simulate the same scenario with different vehicles.
When the Skydel Master broadcast a configuration, radios are associated by their names. For example, "Radio 1" on the Master instance will be matched to "Radio 1" on the Slave(s). When excluding Radios only, only the physical radio configuration (IP address and Clock) will be retained by the Slave(s). The output signals configuration will be pushed. To exclude both, check the Outputs and Radios option.
4.7.3.7. Synchronize Simulators with a GPS Timing receiver
It is possible to use the GPS Time from a GPS Timing receiver as the start time of the simulation for all instances of Skydel. For example, this can be very handy when simulating RTK scenarios and you don’t want to reset the GNSS receivers at each simulation.
In this case, only the master instance of Skydel needs to be connected to the GPS Timing Receiver.
For the Master instance: in the "Start Time" settings screen, "GPS Time" must be set to "GPS Timing Receiver Time".
For the Slave instance(s): in the "Start Time" settings screen, "GPS Time" must be set to "Custom Time".
When starting the simulation, the master instance will read the "GPS Timing Receiver" time. This will become the GPS simulation’s start time. The master instance will push this value to each of the slave instances.
In order to have synchronized simulators, each radio must be connected with a common 10 MHz and PPS signal as indicated in the Hardware Setup section.
4.7.3.8. Satellite Data Update
The Satellite Data Update settings are located in the Settings - Global - SV Data Update menu.

Use the settings in this page to control how Skydel updates satellite data during a simulation.
There are two different modes to choose from:
-
Extrapolation
-
Dynamic
The selection of the mode is done either directly in the interface or using the API command SetSVDataUpdateMode.
4.7.3.8.1. Extrapolation Mode
If this mode is selected, Skydel uses the satellite data found in the configuration and extrapolates it forward in time during the simulation. The configuration’s satellite data comes from imported files. If no files were imported by the user, Skydel defaults to the files found in the Skydel-SDX/Templates folder. In the case where multiple blocks are present for a satellite in an imported file, Skydel will only use one. As the simulation advances, the initial block is extrapolated and used for the satellite’s trajectory, ephemeris and almanac.
See sections Import the RINEX file and Data Sets for information regarding the import of satellite data files.
4.7.3.8.2. Dynamic Mode
When selected, Skydel uses satellite data that is dynamically pushed by the user to the engine using the Skydel API. To push a block of satellite data, the PushDynamicSVData command is used.
This mode is currently only available for the following constellations: GPS, Galileo, BeiDou, QZSS and NavIC. |
In Dynamic mode, Skydel only simulates satellites blocks that are pushed. This means Skydel does not use any default or imported satellite data file. In addition, it is possible to start a simulation without any satellites and dynamically add them during the simulation.
When Skydel first receives a block of data for a satellite, it adds that satellite to the simulation. The received block is used to compute the satellite’s trajectory, ephemeris, and almanac. Skydel continues to use this block of data until a new block is received or until the end of the simulation if no new block is pushed by the user.
When receiving additional blocks of satellite data, Skydel uses the new block of data to compute its trajectory and ephemeris (the almanac is not updated with additional blocks). For the trajectory of the satellite, Skydel interpolates between the previous block of data and the new block of data. This interpolation ensures that no jumps occur in the satellite’s trajectory. At the end of the interpolation, Skydel drops the previous block and only uses the new block. The duration of this interpolation depends on the constellation. Blocks can’t be sent during the interpolation period.
The interpolation durations follow this table:
Constellation | Interpolation Duration (seconds) |
---|---|
GPS |
3600 |
Galileo |
300 |
BeiDou |
1800 |
QZSS |
1800 |
NavIC |
2400 |
Python API example
The Python API directory under "Skydel-SDX/API/Python" contains an example script to use Skydel in the Dynamic Update Mode: example_dynamic_sv_data.py.
This script uses a Rinex file containing satellite data blocks for many satellites. It parses the file and pushes the blocks to Skydel at the start of the simulation. See section import the RINEX file and Data Sets for information regarding satellite data files.
This example script only pushes the first block of satellite data for each satellite at the start of the simulation. The same approach can be used to push new blocks of satellite data at a later time during the simulation. |
The script used to parse the Rinex file is also provided: rinex_parser.py. |
Although this example uses a Rinex file, the user is not restricted to the use of this file format – in fact, any satellite data source can be used. Skydel only requires the block of data to be formatted in a particular way, so some parsing may be necessary before pushing the block. See the documentation of the command PushDynamicSVData as well as the parsing script rinex_parser.py.
The example_dynamic_sv_data.py script starts by connecting to the simulator:
sim = RemoteSimulator(True) sim.connect() sim.setVerbose(True)
Then, amongst other configuration, it sets Skydel into the Dynamic Update Mode:
sim.call(SetSVDataUpdateMode(SVDataUpdateMode.Dynamic))
Once the configuration is done, the simulator is then armed:
sim.arm()
The script then parses the Rinex file and obtains the satellite data blocks using the rinex_parser.py script, where rinex_file_path is the path to the Rinex file.
rinex_parser = RinexParser() blocks = rinex_parser.parse(rinex_file_path)
Next, it iterates over the parsed blocks and pushes them to Skydel:
for block in blocks: sim.post(PushDynamicSVData(system, block.sv_id, block.toc, block.params))
Finally, the scripts starts the simulation and disconnects the script from the simulator:
sim.start() sim.disconnect()
The same script can be used at a later time during the simulation to push new blocks of satellite data. In the case of pushing blocks of data during simulation, only the code to parse the file and push blocks is needed. The code to configure the simulator, arm and start the simulation should not be used as the simulation is already running.
4.7.4. GPS
The GPS settings are located in the Settings - GPS sub-menu.
GPS settings control the orbits, downlink data, and signals of the GPS satellites. These settings have no effect on other constellations (i.e., GLONASS, Galileo, BeiDou, QZSS and NavIC), except SBAS. Some Errors can be corrected with SBAS.
4.7.4.1. General
The General settings are located in the Settings - GPS - General menu.
The General settings control the “Issue of Data” (IODC and IODE) of the downlink data. Disabling the checkbox "Override RINEX IODE" makes Skydel use the IODE values from the RINEX instead of the value indicated in the "Issue of Data" button.
The “almanac first upload” offset controls when the first almanac update will occur after the simulation starts. The update can occur in the middle of a message as illustrated in the image below.

By default, the first update will occur 12 hours (43200 seconds) after the start of the simulation. This setting can be changed independently of the update interval. For example, you could set the first update to occur at 300 seconds and then every 43200 seconds after that first update.
In the general settings, you can also import a RINEX, YUMA or SEM file to set the orbits of the GPS Satellites.
To import a RINEX file, click the Import button in the General settings screen. Skydel will prompt you to confirm your intent. You will then be asked to provide a RINEX-compatible file. Sample files are located in “Skydel-SDX/Templates”. Importing a RINEX file will override each of the current Orbits, Perturbations, Clock & Group Delay and Health settings. Note that ionospheric parameters of the RINEX files are not imported.
RINEX Source
RINEX navigation message files can be found here: https://cddis.nasa.gov/archive/gnss/data/daily↗ A registered account is needed to access the RINEX files. For information on navigating in the database and finding the desired RINEX files, please use the following resources from NASA:
|
The “signal propagation delay” should always be checked. When unchecked, the propagation delay and the Doppler shift are removed from the simulation. This feature is useful for calibrating the simulator’s PPS with an oscilloscope before measuring or calibrating a timing receiver. If you want to use Skydel to calibrate or verify the calibration of a timing receiver, contact Safran Trusted 4D Canada’s technical support.
4.7.4.2. Data Sets
The data sets settings are located in the Settings - GPS - Data Sets menu. This menu manages the different data sets imported in the configuration.
A data set describes the state of the satellites in the constellation. This includes orbital, health, perturbation, and signal control information for all satellites. Different data sets can be used to simulate specific parameters for satellite orbits as well as the information transmitted in ephemeris and almanac parts of the navigation messages. Data sets are imported using RINEX, SEM or YUMA files.
In the Data Sets settings page, each column represents an imported data set. Each row represents a type of data set to which a data set is assigned. The data set types are:
-
Ephemeris - parameters from this data set will be used in the "ephemeris" part of the navigation message.
-
Almanac - parameters from this data set will be used in the "almanac" part of the navigation message.
-
Orbit - parameters from this data set will be used to compute the position of the SV’s.

To add a data set to the configuration, click the "Add Data Set…" button and select the RINEX, SEM or YUMA parameter file to import. The name of the data set will by default be the name of the imported file. All data set names must be unique.

By default, there is only the default data set and it is not displayed in the page as shown in the image above.
The active data set is the working set of the user. It is the data set that is displayed in the other settings pages like Orbits, Perturbations, Clock & Group Delay and Health. The name of the current active data set is displayed at the top of these pages. Modifying fields in one of these pages will modify the active data set. Switching to another active data set will not revert the changes made on the previous active data set.

By default, the active data set is the default data set.
Each row (Ephemeris, Almanac, Orbit) represents the assignations of data sets to these data set types. Only one data set can be assigned to a specific data set type - each row is mutually exclusive.
By default, all data set types are assigned to the default data set.
By clicking on any of the data set’s name, a menu containing the following actions will appear:

-
Overwrite data - replace the parameters of the data set with the ones from a new RINEX, SEM or YUMA file.
-
Copy - create a duplicate of the data set.
-
Rename - change the name of the data set.
-
Delete - remove the data set from the list.
Changing assignment of data sets may affect SV’s status see Signal Enable/Disable section. |
4.7.4.3. Message Modification
The Message Modification settings are located in the Settings - GPS - Message Modification menu.
Up to four sub-menus can be present:
- LNAV
-
Use this page to modify the navigation message for L1C/A, as well as P-Code on L1 and L2.
- CNAV
-
Use this page to modify the navigation message for L2C and L5.
- MNAV
-
Use this page to modify the navigation message for M-Code on L1 and L2.
- CNAV-2
-
Use this page to modify the navigation message for L1C.

If only the GPS L1C/A and P-Code features are active, the Message Modification menu displays directly the LNAV message modification page. |
Message Modification settings let you override the downlink data being transmitted by the GPS satellites.
All Message Modifications globally work the same way. The modifications will be applied only if all their specified conditions are met. Some conditions are common to all navigation message types like start time, stop time, sender SV ID and signals. And some are specials to the navigation message type (subframe, page, message type, word, etc…).
If a subframe is partially overlapped by the start and stop time interval, the subframe is considered to be inside the interval. |
Messages modifications can be added either in idle mode or during a simulation. During a simulation, the message modification events are applied at the start of the next navigation message respecting the event’s conditions.
For users sending message modification events during a simulation using the RAPI, take into account the network latency in addition of the latency preference. |
4.7.4.3.1. LNAV
To create a navigation message modification for L1C/A and P-Code, go to Settings - GPS - Message Modification - LNAV and click the Add button.
When creating a message modification, you may choose the start and end time relative to the start of the simulation. In the example shown below, the message modification will begin 15 minutes into the simulation, and will end 30 minutes into the simulation. You can also control which SVs, signals, sub-frames, pages, and words are affected by the modification. You may set bits to 0, 1, or X. The X indicates that the bit will be negated (0 becomes 1, and 1 becomes 0). By default, message modifications will re-compute the parity bits so that the message passes parity. You may disable this by unchecking the “Calculate parity” check box. This is considered to be a form of message corruption because the message will no longer pass parity.

The “X” on the first indicates that it will be negated (0 becomes 1, and 1 becomes 0). Bit negation is disabled by default; enable it by selecting “Enable bit negation”. |
To select the signals which will receive the modification, click on the Change button. Select All to apply to all possible signals, or Selection to manually select which one you want.

The Add button will add the message modification to the list. The dialog box will stay open so that you may easily add a similar message modification. When you are done creating modifications, close the dialog box.

To edit a message modification, simply select the desired line in the list and click on the Edit button.
The navigation message sub-frames and pages are aligned with the beginning of the GPS week. When you set the start and stop times for the modification, they are relative to the simulation start time, not GPS time. Changing the simulation start time could make the message modification ineffective because the specified sub-frame and page are no longer transmitted at the specified modification start and stop times. |
4.7.4.3.2. CNAV
To create a navigation message modification for L2C or L5, go to Settings - GPS - Message Modification - CNAV and click the Add button.

Similar to LNAV message modification, CNAV modifications are defined with conditions and modifications. The modifications (or corruptions) are applied only when each of the conditions are met.
Besides the usual conditions such as start, stop, signals and SV ID, you may specify the message type. You may also specify the message content to match. For example, you may specify that a modification has to be applied only if a portion of the message is matching an expected value. Click the Add button on the Content Match row to enter the expected value.

Click OK to close the Expected Content dialog box.
The content match condition is automatically formatted into a string, becoming in this example: EQUAL(37, 16, 0x8b27)

You can leave the Content Match condition empty. |
Because the CNAV message is 300 bits long and it is not subdivided in words like the LNAV message, it is impractical to show a dialog box with 300 buttons to specify the modifications. Instead, modifications are defined for portions of the message. To do so, click Add in the Modifications section.

Similar to LNAV message modification, you can force bits to zero or one, or you can invert them (i.e., 0 becomes 1 and 1 becomes 0) using the X symbol.
In the example above, the modification 1
-
-
0
X
X
0
-
1
1
0
1
applies to bits 120 through 131.
The table below shows this modification in details.
Bit | Modification |
---|---|
120 |
Set to one |
121, 122 |
Unchanged |
123 |
Set to zero |
124, 125 |
Inverted |
126 |
Set to zero |
127 |
Unchanged |
128, 129 |
Set to one |
130 |
Set to zero |
131 |
Set to one |
Click OK to add the modification. You can add as many modifications as you require.

Once you are finished adding modifications, click Add to add the event to the list.

4.7.4.3.3. MNAV
To create a navigation message modification for M-Code, go to Settings - GPS - Message Modification - MNAV and click the Add button.
MNAV modifications are similar to CNAV message modification. An additional "occurrence" condition is available.
4.7.4.3.4. CNAV-2
To create a navigation message modification for L1C, go to Settings - GPS - Message Modification - CNAV-2 and click the Add button.
CNAV-2 modifications are similar to CNAV message modification. The "message type" condition is replaced with a "page" condition.
4.7.4.4. Message Sequence
The Message Sequence settings appear in the menu only if GPS L2C, L5, M-Code and/or L1C features are enabled on your license.
If more than one of these features are enabled, the Message Sequence settings are located in the Settings - GPS - Message Sequence menu.
If only one of these features is enabled, the Message Sequence menu is replaced with the appropriate settings screen (L2C Message Sequence, L5 Message Sequence, MNAV Message Sequence or CNAV-2 Message Sequence).
Use the Message Sequence settings to modify the transmission order of L2C or L5 messages. Once all messages have been transmitted, the satellites will loop back to the beginning of the sequence.

Use the Message Sequence settings to modify the different pages of L1C messages. The messages will loop on the enabled pages.

4.7.4.5. Orbits
The Orbits settings are located in the Settings - GPS - Orbits menu.
You can use the Orbits settings to control the locations of the satellites within the constellation. To make a change to a satellite’s orbit, you must first select the appropriate SV ID.

Click the value of an orbital parameter to modify it. When modifying a parameter, you have the option to replicate this value for all remaining satellites.

If you want to remove Doppler shift on the satellite, you can uncheck the “Update sat. position during simulation” checkbox. This will violate the laws of physics and suspend the satellite in a fixed location relative to the Earth. This can be useful for certain types of testing.
The Orbits settings will display the parameters of the active data set (see Data Sets).
4.7.4.5.1. Geostationary
You can also put a GPS satellite on a geostationary orbit. To do so, simply check the Geostationary box. You will notice that the orbital parameters are automatically changed to reflect the geostationary orbit. These parameters are read-only when the geostationary box is checked.

When the Geostationary box is checked, the satellite longitude can be modified. Click on the button to enter the desired value.
When you check the Geostationary box, it changes the orbital parameters. When you uncheck the Geostationary box, the previous orbital parameters are not restored. The values stay the same and match the last geostationary longitude entered. |
If your last actions were made in this settings panel and you want to restore the orbital parameters to what they were before you checked the geostationary box, you can use the Undo command (Ctrl+Z) several times until you rollback to the desired settings.

4.7.4.6. Perturbations
The Perturbations settings are located in the Settings - GPS - Perturbations menu.
The Perturbations settings can be used to modify the harmonic corrections of the satellite’s orbit. To make a change to a satellite’s perturbations, you must first select the appropriate SV ID.

You can easily clear the perturbations for a satellite by clicking the Clear Sat button. You can clear the perturbations for all satellites by clicking the Clear All Sat button.
The Perturbations settings will display the parameters of the active data set (see Data Sets).
4.7.4.7. Clock & Group Delay
The Clock & Group Delay settings are located in the Settings - GPS - Signal Control menu.
You can use the Clock & Group Delay settings to modify the satellite clock errors and inter-signal biases. To make a change to a satellite’s clock and group delay, you must first select the appropriate SV ID.

The Clock & Group Delay settings will display the parameters of the active data set (see Data Sets).
4.7.4.8. Health
The Health settings are located in the Settings - GPS - Health menu.
Use the Health settings to modify the health bits being broadcast by the satellites. These values will be broadcast in the ephemeris, the almanac, and in the page 25 health message. To make a change to a satellite’s health you first have to select the appropriate SV ID.

Use the Apply-to-all button to apply the health bits to all satellites.
L1/L2 Signal Health and Data Health are applied to the NAV message for both L1 C/A and P-Code signals. L1, L2 and L5 Health Bits are applied to the CNAV message for L2C signals. L1C Health Bit is applied to the CNAV-2 message for L1C signals. If the health value indicates that the signal is not being transmitted and you want the satellite to stop transmitting the signal, you must manually turn off the RF in the Signal Enable/Disable screen.
The Health settings will display the parameters of the active data set (see Data Sets).
4.7.4.9. Multipath
The Multipath settings are located in the Settings - GPS - Multipath menu.
To simulate multipath propagation, each path (or echo) must be entered manually. To replicate a NLOS (Non-Line-of-Sight) scenario, it’s also possible to disable the direct line of sight so that only echoes will reach the receiver antenna. To do so, uncheck the Line of Sight (LoS) Enabled box.

For each echo, you can control 4 fundamental attributes: pseudorange offset, power loss, Doppler shift and carrier phase offset.

- Pseudorange offset
-
This value indicates the extra distance the echo signal has to travel before reaching the receiver’s antenna. The effect is a time delay between the Line Of Sight signal and the echo signal being added. Note that the time delay is applied to the code and to the carrier of the echo.
- Power loss
-
This value indicates the power loss of the echo signal compared to the Line Of Sight signal. A value of +10dB indicates the echo signal will be 10dB lower than the LoS.
- Doppler shift
-
The Doppler shift of an echo indicates the frequency offset the echo signal has compared to the Line of Sight (LOS) signal. The Doppler Shift will affect the carrier’s phase and frequency as well as the transmission time of the code chips.
- Carrier phase offset
-
The Carrier phase offset is a value added to the echo’s initial carrier phase, compared to the Line Of Sight’s carrier phase. The value has to be set between -180.0 and + 180.0 degrees.
For each satellite, you can add up to 3 echoes per signal. Adding an echo for GPS L1C/A will not automatically add an echo for the other signals on the same satellite: L1P, L2P, L2C, etc. Each of them has to be added individually.
To disable echoes, click on Disable Echoes button. A window will open, letting you specify the echoes that you want to disable.

Check the Reset echo attributes box if you also want to reset the echo attributes (pseudorange offset, power loss, etc.). Otherwise, the echo will be disabled. However, the attributes will be preserved so that you can enable them in the future with the same values.
Each echo requires as much calculation as the direct line of sight signal calculation. Therefore, adding many echoes can tax the GPU significantly. Make sure your graphic card is suitable for a large number of multipath echoes. The impact on the CPU is marginal. |
Click the Summary button to view all multipath echoes in a table format.

- LoS
-
A value of Yes means the direct line of sight signal reaches the receiver antenna. A value of No means only the echoes (if any) will reach the receiver antenna.
- Enabled
-
Enables or disables the echo. If you set the other parameters, but leave the Enabled flag to No (unchecked), the echo will not be simulated. This attribute has no effect on the direct line of sight signal.
4.7.4.9.1. Additional Resources
Here are some additional resources that can help you when simulating multipath propagation :
4.7.4.10. Signal Enable/Disable
The Signals settings are located in the Settings - GPS - Signal Enable/Disable menu.
Use the Signals settings to modify which signals are being broadcast by the satellites. The RF column controls if any signal will be transmitted at all from that satellite. The other columns can turn individual signal types on and off.
If you uncheck the Present flag, it will not transmit any RF and all the other satellites will indicate this satellite as unhealthy.

Assigned data sets (see Data Sets) will have an impact on the presence, RF and signals flags. A satellite that is not present in the "Almanac" data set will not be present in the simulation and its row will be disabled.

Furthermore, a satellite that is not present in either of the "Ephemeris" or "Orbit" data sets cannot be simulated and will therefore have its RF and signals flags disabled.

4.7.4.11. Transmitted PRN
The PRN selection settings are located in the Settings - GPS - Transmitted PRN menu.
Use these settings to modify which PRN should be transmitted by each satellite for each signal.
You simply have to select a SV ID and click the "Edit PRNs…" button.

You can choose the PRN you want to use for each signal.

Some information like the almanac in the navigation messages are provided for each PRN. Skydel will use the SV ID with the appropriate PRN to build the navigation message, but if you assign the same PRN to multiple satellites, Skydel will choose one arbitrarily. |
In most settings page where information is shown for one satellite at the time, such as the orbital settings page, the PRN value is displayed along with the SV ID. If the satellite uses more than one PRN, Skydel will display a more detailed list.


4.7.4.12. Errors
The Errors settings are located in the Settings - GPS - Errors menu.
The Errors menu contains three submenus:
4.7.4.12.1. Pseudorange Offset
In this submenu, you can create biases and ramps on the pseudoranges being simulated. These offsets, like Pseudorange Errors, can be compensated in the SBAS fast correction messages (Messages 2-5).
When you add an offset to a pseudorange, the simulated signal will appear to arrive earlier or later than it normally would. You may use offsets to simulate effects like:
-
clock errors;
-
atmospheric errors;
-
satellite errors;
-
inter-channel bias;
-
spoofing (see also Avanced Spoofing).
Pseudorange offsets can be applied to all SV IDs or to a specific SV ID. You may also have multiple offsets in effect at the same time. Skydel will add each of the offsets together to determine the appropriate total offset at any given time. This is very convenient when trying to simulate complex scenarios such as a receiver clock error ramp (which affects all SV IDs) occurring at the same time as a SV that has a bias in its transmitted signal.
To create a Pseudorange Offset, click the Add button.
Below is an example of creating a pseudorange offset that only affects SV ID 4. Starting at fifteen minutes into the simulation, the offset ramps up to 1 meter over the course of 45 minutes. The offset then stays at 1 meter for 30 minutes, and finally ramps down to zero over the course of another 30 minutes. The entire event will last 2 hours. Checking the Stop box is necessary to enable the Stop field.

When you are finished creating the pseudorange offset, click the Add button. This will add the offset to the list. The “Add Pseudorange Offset” dialog box will stay open so that you can quickly add several offsets. When you are finished adding offsets, you can close the dialog box.

To edit a pseudorange offset, simply select the desired line in the list and click on the Edit button.
4.7.4.12.2. Pseudorange Errors
In this submenu, you can inject an error on the pseudorange of each satellite by enabling functions such as Gauss-Markov, Sine Waves and Offset. These errors, like Pseudorange Offset, can be compensated in the SBAS fast correction messages (Messages 2-5).

4.7.4.12.3. Orbital Errors
In this submenu, you can inject track errors and clock errors on each satellite. These errors can be compensated in the SBAS long term correction messages (Message 25).

SBAS corrections for Pseudorange Errors and Orbital Errors are enabled by default for each satellite. |
4.7.4.13. Antenna
The Antenna settings are located in the Settings - GPS - Antenna menu.
You can use the Antenna settings to change how the satellite’s antenna is modeled. Changing the antenna model will affect the power and phase offset of the transmitted signals. Phase offsets are expressed in angles.
This section refers to parameters pertaining to the GNSS satellite’s antenna (transmitter). For the vehicle antenna (receiver), refer to section Vehicle Antenna. |
4.7.4.13.1. Models
In this submenu, you can manage the antenna models you will use for the space vehicles. You can use a different antenna gain and phase offset patterns for each band and also add an offset in gain patterns. The Basic Antenna is used by default. It can be changed but cannot be removed.

The Models screen allows you to:
-
add a new model
-
rename a model from the list
-
copy (duplicate) an existing model
-
import a model (file)
-
export a model (file)
-
delete a model
When selected, review and modify a model’s patterns (right pane).
A Basic Antenna model is always present in the list. You can edit or copy it, but it cannot be deleted or renamed.
Adding a model will create a new "blank" antenna model.
Importing a model will enable you to reuse a model that was exported from another Skydel configuration through the export button. Exported models are saved on the computer as a model definition file.
For each model, the following pattern choices are available:
-
default (patch antenna)
-
none (isotropic)
-
custom
For gain and phase patterns, you can add an offset.

Clicking the “More” button for a band gain or phase offset brings up a depiction of the antenna model pattern and allows you to import a new pattern from a CSV file.

The 3D model is illustrated in two dimensions using a graph displaying the gain values with a color gradient, and their position in 3D space using the horizontal coordinate system. The graph axis represent the azimuth (x axis, from -180° to 180°) and the elevation (y axis: -90° to 90°).
You can export the antenna gain pattern to a CSV file, modify it, and import it back into Skydel. CSV files are formatted as follows:
-
Each file is a matrix of values (either gain or phase offset). Skydel will automatically create a linear interpolation between each specified value to create a continuous 3D pattern.
-
Values are dB for gain and radians or degrees for phase offset.
-
Rows represents the elevation range of [-90°, 90°] from top to bottom and columns represents azimuth range of [0°, 360°[ from left to right.
-
The first row always represents an elevation of -90°.
-
The last row always represents an elevation of 90°.
-
Every row positioned in-between will partition the elevation pattern.
-
The first column always represents an azimuth of 0°.
-
Every additional column will partition the 360° azimuth range into smaller range of equal size.
For example, in the following file:
1, 2, 3 4, 5, 6 7, 8, 9
-
There are 3 columns. Therefore, the azimuth step size is 120° (360° / NbCols). The first column is for azimuth 0°, second for azimuth 120° and last column is for -120°. At 180°, the pattern loops back to -180°.
-
There are 3 rows. Therefore, the elevation step size is 90° (180° / (NbRows - 1)). The first row is for elevation -90°, second row for elevation 0° and last row is for 90°.
The default pattern for satellites contains 901 lines: elevation step is 0.2° and azimuth is always the same.
4.7.4.13.2. Assignment
Use this screen to assign antenna models to space vehicle. To assign a model, select one or multiple SV IDs in the list, then the model desired, and finally click the Assign to Selection button.

4.7.5. GLONASS
The GLONASS settings are located in the Settings - GLONASS sub-menu.
The GLONASS settings control the orbits, downlink data, and signals of the GLONASS satellites. These settings have no effect on the other constellations (i.e., GPS, Galileo, BeiDou, SBAS, QZSS and NavIC).
The GLONASS settings are nearly identical in operation to the GPS settings. Refer to the GPS settings section for more information. Only the specifics of GLONASS will be described in this section.
4.7.5.1. General
The General settings are located in the Settings - GLONASS - General menu.
To import a RINEX file, click the Select button in the General settings screen.

Skydel will ask you to provide a RINEX-compatible file. Sample files are located in “Skydel-SDX/Templates”. Importing a RINEX file will override each of the current Orbits, Perturbations, and Clock settings.
When importing the RINEX file, Skydel will compare the leap second from the RINEX and the leap second defined in the Start Time settings. If the values mismatch, Skydel will display this warning:

GLONASS is particularly sensitive to leap second errors because its reference time is attached to the UTC time.
The GLONASS RINEX file does not define orbits using Keplerian elements. Instead it provides absolute positions which must be interpolated. These positions are only valid for the given RINEX observation time and can’t be easily extrapolated in the past or future. Therefore, when you import a RINEX file, you must set the simulation Start Time to the same day as the imported RINEX file.

4.7.5.2. Leap Seconds
Unlike other constellations, GLONASS system time is relative to UTC time. Whenever a leap second is added (or subtracted), it directly affects the GLONASS system time. When a second is added, it always occurs at the end of a quarter at midnight UTC. The following image illustrates how Skydel realigns the next subframe with the new UTC time after the leap second event.
When a second is subtracted, the behaviour is similar, but the first transmitted string after the event is String #2.
Leap seconds future event is configured in the Settings - Start Time menu.
4.7.6. GALILEO
The Galileo settings are located in the Settings - GALILEO sub-menu.
The Galileo settings control the orbits, downlink data, and signals of the Galileo satellites. These settings have no effect on the other constellations (i.e., GPS, GLONASS, BeiDou, SBAS, QZSS and NavIC).
The Galileo settings are nearly identical in operation to the GPS settings. Refer to the GPS settings section for more information. Only the specifics of Galileo will be described in this section.
4.7.6.1. F/NAV Source Diversity
The F/NAV Source Diversity settings are located in the Settings - GALILEO - F/NAV Source Diversity menu.

You can use the F/NAV Source Diversity settings to control which almanacs will be broadcast first for each satellite. In the F/NAV navigation message plan, each Galileo satellite can start broadcasting the almanac with an offset for the PRN value. This offset is known as the k parameter in the Galileo ICD. It is set for each of the active satellites, and enables improvements to almanac transport time by exploiting source diversity.
4.7.7. BEIDOU
The BeiDou settings are located in the Settings - BEIDOU sub-menu.
The BeiDou settings control the orbits, downlink data, and signals of the BeiDou satellites. These settings have no effect on the other constellations (i.e., GPS, GLONASS, Galileo, SBAS, QZSS and NavIC).
The BeiDou settings are nearly identical in operation to the GPS settings. Refer to the GPS settings section for more information.
4.7.7.1. Notes on BEIDOU geostationary satellites
Keplerian parameters found in RINEX files cannot be extrapolated for BEIDOU geostationary satellites as they are for other constellations and for other types of satellites. For that reason, BEIDOU geostationary satellites require multiple RINEX blocks to be simulated properly. The simulator will use these blocks and interpolate the position of the satellite correctly.
The default template BEIDOU ephemeris RINEX file found in “Skydel-SDX/Templates” contains two weeks worth of RINEX blocks for GEO satellites. If a longer simulation is required, the users should import their own RINEX files. Note that when the end of the GEO blocks is reached, the simulation will continue, but the position of GEO satellites will become incorrect (a warning will be shown at that point). Also note that an old configuration will not have Beidou GEO satellites: the importation of a new RINEX file will be required in order to activate them.
To ensure the quality of the simulation of BEIDOU GEO satellites, the edition of orbit parameters has been disabled for this type of satellite. This means pages "Orbits" and "Perturbations" have been disabled for GEO satellites.
4.7.8. QZSS
The QZSS settings are located in the Settings - QZSS sub-menu.
The QZSS settings control the orbits, downlink data, and signals of the QZSS satellites. These settings have no effect on the other constellations (i.e., GPS, GLONASS, Galileo, SBAS, BeiDou and NavIC).
The QZSS settings are nearly identical in operation to the GPS settings. Refer to the GPS settings section for more information.
4.7.8.1. L1S augmentations
The L1S augmentations settings are located in the Settings - QZSS - L1S augmentations menu.

The L1S augmentations page allows to set augmentations which will be used to fill the QZSS L1S navigation message.

The Add button will add the L1S augmentation to the list. The dialog box will stay open so that you may easily add a similar L1S augmentation. When you are done creating augmentations, close the dialog box.
Only one augmentation per PRN of each constellation is allowed, as well as a maximum of 23 augmentations in total. |

To edit an augmentation, simply select the desired line in the list and click on the Edit button.
4.7.9. NavIC
The NavIC settings are located in the Settings - NAVIC sub-menu.
The NavIC settings control the orbits, downlink data, and signals of the BeiDou satellites. These settings have no effect on the other constellations (i.e., GPS, GLONASS, Galileo, SBAS, BeiDou and QZSS).
The NavIC settings are nearly identical in operation to the GPS settings. Refer to the GPS settings section for more information.
4.7.10. SBAS
The SBAS settings are located in the Settings - SBAS sub-menu.
SBAS settings control the orbits, downlink data, and signals of the SBAS satellites. These settings have no effect on other constellations (i.e., GPS, GLONASS, Galileo, BeiDou, QZSS and NavIC).
4.7.10.1. General
The General settings are located in the Settings - SBAS - General menu.

The current Skydel version supports fast corrections for GPS and SBAS and long term corrections for GPS only.
4.7.10.2. Message Sequence
The Message Sequence settings are located in the Settings - SBAS - Message Sequence menu.

Each message type has the same 1-second duration. The message sequence changes according to the maximum update interval for each message type.
By default, fast corrections (message types 2, 3, 4 and 5) have a maximum update interval of 6 seconds and the other message types have longer intervals such as 120 seconds or 300 seconds.
When all maximum update interval conditions can not be respected, the default configuration will be used for the generation of the message sequence.
The generated message sequence starts at 12:00:00, is unique and of length defined by the the lowest common denominator of all different maximum update intervals. An offset is applied to the sequence starting index depending on the simulation start time.
Concerning fast corrections, message type 2 will transmit data sets for the first 13 satellites designated in the PRN mask. Message type 3 contains data sets for the following 13 satellites, and so on. If, for example, there are data sets for only 37 satellites to transmit, message types 2, 3 and 4 will be transmitted, but not message type 5 (it’s not needed since data sets are all empty). In this case, the fast corrections message sequence will be 2, 3, 4, 2, 3, 4, 2, 3, 4. This means we can insert 3 other message types before rolling back to fast correction messages.
The delays given in the message 26 consist of the addition of the delays from the current ionospheric model in Settings - Global - Atmosphere - Nominal and the offsets provided in Settings - Global - Atmosphere - Errors (if enabled).
4.7.10.3. Health
The Health settings are located in the Settings - SBAS - Health menu.

When a check box is checked, it means On. For example, if the Ranging is checked, the Ranging is On which means the corresponding bit in the navigation message is set to zero.
The service provider indicates if the SBAS satellite is assigned to WAAS (0), EGNOS (1), MSAS (2), etc. In the Signal Level settings, you can control the power offset for each service provider.
The default service provider might not be adequate if you import a RINEX file.
Use the Apply-to-all button to apply a health parameter to all the satellites.
4.7.10.4. Ionospheric Masks
The Ionospheric Masks settings are located in the Settings - SBAS - Ionospheric masks menu.

This panel describes the content of the SBAS message 18 as an ionospheric grid, where each IGP tells if the position is monitored by the SBAS satellite of the selected service provider. You can switch service providers with the combo box located below the map.
Information about the highlighted IGP (latitude, longitude, flag(s)) is shown below the map. As some IGP from different bands are located at the same coordinates, it is sometimes normal to have different flags for the same position on the map. The points are either blue (band 0 to 8) or orange (bands 9 and 10). Points present on two bands at once are illustrated with two colored triangles.
You can edit the map by selecting first a service provider and then clicking the Edit button. This will open a dialog containing an editable map.

Each IGP can be selected and set to true or false by lighting them up or off with a click of the mouse, or by dragging an area with the mouse to change the value of many points at once.
Rolling over the map with the mouse will highlight the different bands and display their number. You can select or deselect bands using the controls at the top in order to help with setting the different points' values, for example by including or excluding bands. When you deselect a band, its IGPs can’t be edited, thus preventing unwanted changes.
You can import or export the grid for the current service provider in CSV format, where each line describes a grid band (0 to 11), an IGP index (1 to 201, depending on the band) and the flag applied (0 or 1). A button is provided to revert to the default mask. These are the only actions that change all the bands, whether selected or not.
Click OK to save your changes or click Cancel to revert them.
4.7.10.5. Ionospheric GIVEI
The Ionospheric GIVEI settings are located in the Settings - SBAS - Ionospheric GIVEI menu.

They describe the GIVE Indicators (GIVEI) used in the SBAS message 26 on an ionospheric grid, where each IGP describes a GIVEI value between 0 and 15. Each SBAS service provider has a different GIVEI map. You can switch service providers with the combo box located below the map.
Information about the highlighted IGP (latitude, longitude, GIVEI value) is shown below the map.
The Edit button opens a dialog with an editable version of the map of the selected service provider.

The controls provided for the edition of the GIVEI values operate in similar fashion as the ones for Atmospheric Errors.
You can import or export the grid in a CSV file following this format: [band index],[IGP index],[GIVEI value]
Click OK to save your changes or click Cancel to revert them.
4.7.11. Vehicle
The Vehicle settings are located in the Settings - Vehicle menu.
You can use the Vehicle settings to control the trajectory and antenna properties of the simulated vehicle. This vehicle corresponds to the simulated receiver location.
Skydel users require the EXLI license feature in order to simulate vehicle trajectories with speeds higher than 600m/s. |
4.7.11.1. Body
The Body settings are located in the Settings - Vehicle - Body menu.
The Body settings can be used to control the trajectory of the simulated vehicle. To define the vehicle trajectory, select the desired trajectory type and click the Edit button.

The map and location search features of the trajectory editors will not work if you are not connected to the internet. Check the Proxy section for more information.
4.7.11.1.1. Six Degrees of Freedom
Skydel uses the Earth-Centered, Earth-Fixed↗ (ECEF) geographic coordinate system. It represents positions as X, Y and Z coordinates. The point (0,0,0) is defined as the center of mass of the Earth. Its axes are aligned with the international reference pole (IRP) and international reference meridian (IRM) that are fixed with respect to the surface of the Earth.
The z-axis is pointing towards the north. The x-axis intersects the sphere of the Earth at 0° latitude (the equator) and 0° longitude (Greenwich). This means the ECEF rotates with the Earth.

Skydel also supports the Latitude, Longitude and Altitude (LLA) geographic coordinate system. Internally, Skydel always works in ECEF and will convert LLA using the WGS84↗ ellipsoid model. Skydel assumes the altitude in the LLA coordinate is relative to the ellipsoid surface. It is often confused with mean sea level or the geoid model.
Skydel also supports the Earth-Centered Inertial (ECI) coordinate system. Internally, Skydel always works in ECEF and will convert ECI using the current Earth Orientation Parameters.
Skydel uses the Tait-Bryan angles↗, also known as nautical angles. It is the convention normally used for aerospace applications, so that zero degrees elevation represents the horizontal attitude. Among the six possibilities of representing the rotation axes for Tait-Bryan angles, Skydel uses the z-y’-x’’ intrinsic rotation. The rotation angles are yaw, pitch and roll in the NED reference frame. The x axis points north, the y axis points east, and the z axis points towards the center of the Earth. The first rotation is around z axis, the second around y axis and the third around the x axis. This transformation is also known as 3-2-1.
4.7.11.1.2. Fixed
To create a simulation where the receiver never moves, select the Fixed trajectory. This is sometimes referred to as a static trajectory. Click Edit to change the receiver position.

You can specify the latitude, longitude, altitude, yaw, pitch, and roll manually. Alternatively, you can “Use Crosshair Position” or search for a landmark or address. The map will display a preview of the location that you selected.
4.7.11.1.3. Circular
To create a quick trajectory with motion, use the Circular trajectory. A nice feature of the circular trajectory is that it is easy to make it run forever. However, many receivers have difficulty navigating with a perfectly circular trajectory. Radius, speed, and direction are editable parameters.

4.7.11.1.4. Track Playback
A track is defined as a list of locations with timestamps for each location. A NMEA file is a typical example of track, but it could also be a CSV file. If your CSV file contains speed instead of timestamps, then it is a route, not a track.
If you have trajectory data stored in a file already, use the Track Playback trajectory. You can select your vehicle type to be Ground/Water or Airborne/Spaceborne. This selection will determine the type of interpolation that is used on your trajectory.

For ground and water interpolation, Skydel will not go through each location defined in the track file. For airborne and spaceborne, Skydel assumes the data points are generated by a simulator where each location is valid. Skydel will use hundreds of points to interpolate and pass through each location with minimal acceleration and jerk.
You can force the yaw, pitch, and roll to zero. This can be useful if you don’t want to model the attitude of the vehicle to affect the signal power of the received signals (due to antenna pattern modeling). Interpolation can be disabled but this is not recommended. Once you have made your selection, click the edit button to define the trajectory.
When importing a trajectory, you can choose between a NMEA file or a CSV file.

When importing NMEA data, you will be asked to locate a file that contains NMEA strings. Once you have located the file, Skydel will try to import the data and will then display the following report:

The most common source from such a file is the output of a GPS receiver. Skydel will automatically reject sentences if the fix quality is zero. Occasionally, the NMEA file is generated by a trajectory simulation tool and these tools don’t always correctly set the fix quality. If you know that the fix quality is good and want to ignore this attribute while importing the NMEA, check the “Ignore fix quality in GGA sentences” box.

When importing CSV data, you will be asked to locate a csv file that contains trajectory data. This file doesn’t have to be formatted in a specific way. Many formats are compatible with Skydel.

Once you have located the file to import, the Import CSV dialog will appear. Using this dialog, you specify the format of your CSV file. Make sure you set the number of header rows correctly, as it’s easy to forget this step. You can choose between ECEF, ECI or LLA. Then, select which column provide X, Y, and Z for ECEF and ECI (or latitude, longitude, and altitude for LLA). You must also specify the correct units for each parameter.

It is very important to import data with sufficient precision. If the data is truncating too many decimals, the resulting position error will create extreme acceleration and jerk. |
Once you are finished with the Position tab, continue with Attitude and Time.

When importing in ECI, it’s very important that the simulation start time match to trajectory start time since the conversion to ECEF is strongly bound to Earth Orientation Parameters and time. It’s possible to import custom Earth Orientation Parameters. Refer to the Earth Orientation Parameters settings section for more information. |
The CSV importer will display a preview of the decoded information for the first row at the bottom of the dialog box. If the information is properly decoded, it is most likely that Skydel will be able to import the CSV file successfully. Click OK to import the file.

If you are satisfied with the imported trajectory preview, click Finish.
The Attitude tab is optional. |
For best results, we recommend that you use trajectory files that are at least 10 Hz for low dynamics and 100 Hz for high dynamics. This will solve many potential issues with interpolation and inconsistencies. |
The conversion from ECI to ECEF is done at importation. Changing simulation start time or Earth Orientation Parameters after importation will result in an erroneous trajectory. |
4.7.11.1.5. Vehicle Simulation
The Vehicle Simulation trajectory type is a great way to make a fairly realistic trajectory quickly. You can import the data from “Use Street Map” (openstreetmap.org), “Import KML” (Google Earth or earth.google.com), or your own CSV file. The CSV file should contain a list of locations with speed values for each. If your CSV file contains timestamps instead of speed, it is considered to be a track.
For this example, we will select Use Street Map.

You can search for locations using the From and To fields. Or you can right-click on the map and select “Direction From/To Here”. The map will display a preview of your selected trajectory.

Click “Next” when you are ready. You will then be asked to select a vehicle speed.

4.7.11.1.6. Hardware-In-the-Loop
Skydel supports Hardware-In-the-Loop (HIL) trajectories. This trajectory type requires a remote process to connect to Skydel and send the vehicle position in real-time.
Skydel users require the HIL license feature in order to use the HIL trajectory type. |
4.7.11.1.7. Earth-Orbiting Spacecraft
You can easily create Earth-Orbiting Spacecraft trajectories to test spaceborne receivers.

When you click Edit, Skydel will ask for the Keplerian parameters that you would like to use for your trajectory.

When using Earth-Orbiting Spacecraft trajectories, you will be warned that some other settings should change. If you click “Tell me more…”, Skydel will offer to make some of the changes for you.

This diagram depicts a Low Earth Orbit (LEO) trajectory. If your trajectory is close to a LEO, you should click “Use LEO Settings” to accept these changes.

This diagram depicts a Geostationary Earth Orbit (GEO) trajectory. If your trajectory is close to a GEO, you should click “Use GEO Settings” to accept these changes.

A space receiver will have many more satellites in view than a ground receiver. This will require additional computing demand on the GPU. You can easily see this by looking at the sky view. Satellites with a horizontal line are beneath the receiver. Their elevation angle is less than zero. Satellites with a dot have their back to the receiver. Their main beams are facing away from the receiver; therefore, the received power from these signals will be quite low. The blue circle in the middle represents the Earth.

Space receivers are usually not within the main lobe of a given GPS satellite’s main antenna. This results in a very wide range of received power levels. You can see this by looking at the Power Sliders. Notice that weaker satellites each have a dot under their number.

4.7.11.2. Antenna
The Antenna settings are located in the Settings - Vehicle - Antenna menu.
This section refers to parameters pertaining to the vehicle’s antenna (receiver). For the GNSS satellite’s antenna (transmitter), refer to section GPS Antenna Model. |

You can use the Antenna settings to change how the receiver antenna is modeled. Changing the antenna model will affect the power and phase offset of received signals. Phase offsets are expressed in angles.
You can define one or more antenna models in Models and use the Sequencer to specify antenna model changes to occur during the simulation. By default, Skydel uses the default antenna defined in the Models menu.
4.7.11.2.1. Models
This screen shows a list of antenna models available for your simulation.
The Vehicle Antenna Models interface behave exactly like GPS Antenna Models. Gain and phase offset patterns have the same formats. Please refer to the GPS Antenna Models for a complete description.
The default pattern for a vehicle contains 181 lines: elevation step is 1° and azimuth is always the same.
4.7.11.2.2. Antenna Offset
You can also specify the attachment point and attitude of the antenna relative to the vehicle body. The default attachment point (sometimes referred to as “lever arm”) of X = 0, Y = 0, and Z = 0 meters puts the antenna at the center of the vehicle. The default attitude of yaw = 0, pitch = 0, and roll = 0 orients the antenna so that it faces the zenith (towards the sky) when the vehicle is “flying straight and level”. The following diagram illustrates the relationship between the vehicle and X, Y, Z, roll, pitch, and yaw.

4.7.11.2.3. Sequencer
With the sequencer, you can plan antenna model changes that will be effective during simulation. If there’s no antenna defined at time=0 of the simulation, the default antenna will be used until another antenna is specified.

Antenna model changes are persistent; e.g., an antenna will remain active until the end of the simulation if there are no other changes.
4.7.11.3. Elevation Mask
The Elevation Mask settings are located in the Settings - Vehicle - Elevation Mask menu.
You can use the Elevation Mask settings to control which satellites will generate signals during the simulation. By default, “Mask Below Elevation Angle” is enabled and set to 10 degrees. This will disable satellites that have an elevation angle below 10 degrees. You can disable this mask completely (uncheck the box) or modify the angle itself by clicking on the value.

Disabling the “Mask Below Elevation Angle” is not the same as setting it to 0°. When “Mask Below Elevation Angle” is disabled, Skydel will generate signals with any elevation angle, including those below 0°. However, Skydel will still calculate the location of the Earth’s horizon to determine if a satellite’s signals would reach the receiver. In other words, Skydel will never generate a signal that has to pass through the Earth to be received.
You can enable the “Mask Above Elevation Angle” option. This will disable any satellite that is higher than the specified angle. This setting is not used very often and should be avoided unless you are absolutely sure that you know what you are doing.
4.7.12. Advanced Jammer
This section is about the optional Advanced Jammer feature. If you are looking for the basic interference feature, read here. |
When the Advanced Jammer feature is enabled, the Basic Interference tab is hidden and replaced with the Interference submenu located in the Settings - Interference menu.

There are 2 types of advanced jammers available: Dynamic Transmitter and Simplified Transmitter.
- Dynamic Transmitter
-
A dynamic transmitter is defined with a position or a trajectory. The trajectory may even be defined in real-time using the hardware-in-the-loop API. Different waveforms (or signals) may be combined to create a complex jammer waveform. The power level is defined from the transmitter point of view. During the simulation, Skydel automatically calculates the resulting signal at the receiver antenna in real-time and takes into account the transmitter visibility, the transmitter antenna pattern, the propagation loss and the receiver antenna pattern. The transmitter, like the simulated receiver, has six degrees of freedom.
- Simplified Transmitter
-
A simplified transmitter has no position or trajectory. Different waveforms can be combined to create a complex waveform; however, the power is defined from the receiver point of view and will not change as it moves.
One way to look at it is Dynamic Transmitter have its own trajectory while Simplified Transmitter is attached to the receiver. |
Regardless of the transmitter type (dynamic or simplified), each of the parameters can be updated in real-time while the simulation is running. It is also possible to add or remove transmitters during the simulation.
4.7.12.1. Simple dynamic transmitter tutorial
To illustrate how a dynamic jammer works with Skydel, we’ll use a simple scenario where we will create an interference to jam GPS L1 C/A.
The first step is to assign GPS L1 C/A to RF A and then click Edit on RF B.

In the Signal Selection dialog box, choose the Interference output type. By default, the interference group is Group 1 and the central frequency is set to 1575.42 MHz. These values are good for this example; however, we will change the gain to 60 dB and the minimum sampling rate to 12.5 MSps.

Click Ok to close the Signal Selection dialog box. The output configuration should look like this:

As you can see, the gain for RF A is 80 dB and the gain for RF B is 60 dB. Before combining the outputs, RF A must be attenuated by 20 dB. While the difference in gain makes the hardware setup a little more complex, it has the great advantage of offering a much greater jammer-to-signal ratio for testing receivers under extreme conditions.

In the above image, the 60 dB attenuator on the right should actually be slightly less than 60 dB and take into account the signal power loss resulting from the combiner and cables, so that the total attenuation on RF A path is 80dB and the total attenuation on RF B path is 60 dB. |
You can remove the LNA and reduce the 60 dB attenuator accordingly. For example, if the LNA has 20 dB of gain, you can remove it and replace the 60 dB attenuator with a 40 dB attenuator. The power level at the GNSS receiver input will remain the same. The signal-to-noise ratio should remain valid if you have enabled the Gaussian noise option in the RF A output. |
Now that we have Interference Group 1 mapped to RF B, we must add a transmitter. First, click on the interference submenu.

You can add Dynamic or Simplified transmitters in the Interference sub-menu.

Click on "Add Dynamic…" and the “Add Transmitter” dialog box will appear.

Here you can change the transmitter name, reference power, etc. Each of these attributes can be changed later, so simply accept the default values for now. You can see the same options (Group 1 to 16) in the Group dropdown list as found in the Signal Selection dialog box. The difference is that it will tell you if the group is assigned to a physical output. In this case, it informs you that Group 1 is assigned to Radio 1 RF B. Click OK to add the dynamic transmitter.
Each time you add a transmitter, a new sub-menu with the transmitter’s name appears in the Interference sub-menu. In this case, the transmitter’s name is "Transmitter 1".

To configure the transmitter, click on the "Transmitter 1" sub-menu. The dynamic transmitter sub-menu contains four screens (General, Signal, Trajectory and Antenna) and a Remove button. In the General screen, you will see a message highlighted in yellow about an undefined trajectory.

Click on the trajectory button to bring the trajectory page screen of the transmitter. Set the circular trajectory with the following attributes:
-
Center: 45 degrees north, 73 degrees west, 2 m altitude
-
Radius: 101 m
-
Speed: 1 m/s
-
Motion: Counterclockwise

To create an interesting scenario, we will create a receiver trajectory that will cross the transmitter at close range. Set a receiver circular trajectory with the following attributes:
-
Center: 45 degrees north, 73 degrees west, 2 m altitude
-
Radius: 100 m
-
Speed: 1 m/s
-
Motion: Clockwise
Now the transmitter has a trajectory, but it is not transmitting anything. Lets add a Chirp signal.

Change the chirp bandwidth to 10 MHz and the sweep time to 10us. It is possible to add a signal with a different group than the transmitter, this allows a transmitter to jam different groups. To do so, you would have to uncheck "Use Default Group" and then change the signal group. For this example, let "Use Default Group" checked. To add the chirp signal, click Add. You will see the signal added to the list in the main windows. We will not add another chirp signal in this example, so you may click on the Close button.

The power for the chirp is measured in dB. This is relative to the transmitter reference power defined in the General page. Let’s go back in the General screen and reduce the power to -15 dBm. Also, uncheck the Enabled flag. We prefer not to have the jammer enabled when we start the simulation. This will allow some time for the receiver to track and lock on to the GPS signal. We will enable the jammer only after we have a lock on the receiver.

Let’s start the simulator now and connect a receiver in order to view the simulator, the receiver, and the transmitter in the map tab. Depending on the performance of your receiver, it may take more or less time to get the receiver’s solution. However, once you have it, the view in the map should look something like this:

If you expand the transmitter information panel at the right of the map, you will see that the transmitter is not enabled. This means that the transmitter is not broadcasting RF; however, as you can see in the map, the transmitter is moving on a circular path.
In the information panel, you will also find 2 values for the Reference Power: Tx and Rx. The Reference Power Tx is the power level that you set in the General screen of the transmitter. The Reference Power Rx is the perceived reference power at the receiver including the transmitter and receiver antenna patterns and the propagation loss. If you click on the "plus" button at the right of Reference Power (Rx), you will see more details.
The transmitter can be Visible or not by the receiver. If both receiver and transmitter altitude are inferiors to 100km, Skydel uses radio horizon to determine the transmitter visibility. Else Skydel looks if the transmitter is earth-masked.
In the spectrum subtab, you will see that the GPS signal is being transmitted on RF A; however, the spectrum for RF B should remain empty until you enable the transmitter.

Now, go to the transmitter’s General screen and enable the transmitter. You should now see the chirp appearing in the RF B spectrum.

The simulator and the transmitter are both on a circular path and they will soon cross each others path within 1m range. When that occurs, you will see the spectrum power increase rapidly.

At this point, the receiver should experience some heavy jamming and you should have difficulty tracking the signal, as you can see in the Deviation subtab.

As the simulation proceeds and the transmitter fades away, the deviation quickly improves.
This simple dynamic transmitter tutorial was for a -15 dBm jammer. This is a very weak jammer. We leave it to the user to experiment with stronger jammers to see how the jamming radius increases the effect on the receiver being tested.
When you modify a transmitter while the simulation is running, all changes will be lost when you stop the simulation unless you check the option Preserve Runtime Settings in the transmitter’s General screen. It is often easier to design complex waveforms at runtime in order to see the effect in the Spectrum subtab. While doing so, it is strongly recommended that you disconnect the RF output to protect your receiver. |
4.7.12.2. IQ-File Jammer
The "IQ-File" jammer signal type enables the users to inject their own specific jammer waveform.

The waveform is stored in a binary file, containing a baseband IQ-Complex waveform. The format of the file is the same as the one described in section IQ Data Files.
For Skydel to correctly use the binary IQ-Samples file (ex: my-waveform.iq), a metadata file respecting the GNSS SDR Metadata Standard (http://sdr.ion.org/) must be found in the same folder (ex: my-waveform.xml). When using this standard, only metadata files with one Lane, System, Block, Chunk, Lump, Stream, Band and File are supported by Skydel.
Furthermore, the metadata must have the following values:
Chunk Key | Value |
---|---|
sizeword |
2 |
countwords |
2 |
endian |
Little |
padding |
None |
wordshift |
Left |
Stream Key | Value |
---|---|
ratefactor |
1 |
quantization |
16 |
packedbits |
32 |
format |
IQ |
encoding |
INT16 |
Band Key | Value |
---|---|
translatedfreq |
0 |
delaybias |
0 |
Skydel also supports the use of a text file as a metadata file (ex: my-waveform.iq.desc). This metadata file simply contains "Key-Value" pairs to describe the waveform. Here are the supported keys:
Key | Value | Unit | Requirement |
---|---|---|---|
CENTRAL-FREQUENCY |
1575420000 |
Hz |
MANDATORY |
SAMPLE-RATE |
12500000 |
Samples per sec |
MANDATORY |
The text file must contain 1 Key/value pair per line. For example:
-
CENTRAL-FREQUENCY=1575420000
-
SAMPLE-RATE=12500000
The waveform selected can have a lower sample rate then the RF output where it will be injected. If so, the waveform selected will be upsampled in real-time during the simulation. |
Power Level
The reference power level of the IQ-File signal is -130dBm, when the IQs of the file have a RMS value of 463.
For example, lets say that the IQ-File contains a CW waveform like this: I=463; Q=0; I=463; Q=0; I=463; Q=0; …
When this file is used as a "IQ-File interference", and the transmitter is set to -130dBm, the output power will be -130dBm. However, it is important to understand that by default, RF outputs of interferences have a gain +40dB. So the actual RF signal power at the radio’s connector will be -90dBm.
4.7.12.3. Multi-band Jammer
It is possible for a single transmitter to jam several bands. By default, all the signals added to a transmitter will jam the signal group defined in the transmitter general menu. To enable multi-band jamming, you have to uncheck "Use Default Group" in a signal "Add" or "Edit" dialog, then you can select the group you want the signal to jam.

In the following example, the transmitter is set to jam the group 1, so all its signals will, by default, jam the group 1, but this Chirp signal is set to jam the group 2.

4.7.13. Advanced Spoofing
A spoofing scenario usually looks like this:

To summarize and agree on terminology:
-
A receiver receives a truth signal, from which it determines its true position.
-
The receiver will also receive a spoofing signal from a device located at a spoofing transmitter position.
-
The spoofing signal is a GNSS signal as it would be perceived by a receiver located in a spoofed position.
To achieve advanced spoofing in Skydel, at least two instances are required:
-
The truth instance, which manages the truth signal, the true position and the spoofing transmitter position.
-
The spoofing instance, which manages the spoofing signal and the spoofed position.
4.7.13.1. Spoofing instance
To start a spoofing instance, search for the shortcut Skydel Spoofer on your operating system or start the application in a command line shell with the --spoofing argument.
This instance is almost the same as a regular instance, with the following exceptions:
-
There is only one type of output: Spoofer.
-
The Spoofer output is assigned to an interference group that will be used in the main instance.
-
Only GNSS signals can be configured, these are the definition of the spoofing signal.
-
The Vehicle section defines the spoofed position.

4.7.13.2. Truth instance
When the Advanced Spoofing feature is activated, you will see a new tab called Spoofers.

To add a spoofing transmitter, go into this tab and click on Add Spoofer… A spoofing transmitter is very close to a dynamic advanced jammer in its composition. We find the same General, Trajectory and Antenna sections.
In the Signal section, we have a summary of the spoofer’s status. Here we can see and edit the spoofing instance address. The default address can be changed in Skydel’s Preferences. Once connected, a table will show the spoofing signals detail.

When adding a spoofer in wavefront mode, the spoofing instance address must be visible from the nodes. |
In the Spoofers menu, next to the spoofer’s name, a LED is showing its status:
-
Red → Connection to the spoofing instance could not be established or no signal is configured.
-
Orange → Only some of the spoofer’s outputs are assigned to an output.
-
Green → Signals are all assigned to an output.
In the Settings menu, the LED next to the Spoofer submenu shows a global status:
-
Gray → The scenario does not contain any spoofers.
-
Red → At least one spoofer’s status LED is red.
-
Orange → At least one spoofer’s status LED is orange, none are red.
-
Green → All spoofer’s status LED are green.
4.7.13.3. Additional Jamming + Spoofing Resources
Here are some additional resources that can help you when working with Jammers and Spoofers:
4.7.14. Plug-in
With plug-ins, users can develop features and integrate them to the Skydel user interface and the real-time simulation engine. In Skydel’s context, a plug-in is a dynamic library (.so on Ubuntu and .dll on Windows).
For more information on how to develop a plug-in, see the documentation here. |
When the Plug-in feature is activated, the plug-in settings are located in the Settings - Plug-ins menu.

To instantiate a plug-in, click Add Plug-in….

A plug-in can be instantiated multiple times, since each plug-in instance is independent from the others and has its own memory allocation. |
At the launch of the software, Skydel searches once in the Skydel Data Folder /Plug-ins, resulting in a list of available plug-ins from which a plug-in instance can be instantiated.
A list of available plug-ins is created at Skydel’s launch from the shared libraries found in the Skydel’s "Plug-ins" folder.

The graphical user interface of a plug-in instance can be found in the plug-in instance Interface submenu.

Information about the plug-in instance can be found in the Info submenu:

Name |
Unique identifier of the plug-in instance. |
Type, Version, Description |
Plug-in name, version and description from the dynamic library metadata. |
Interfaces |
Roles implemented by the plug-in. |
Click Remove… to remove a plug-in instance.
When a plug-in instance is removed, the memory allocated by Skydel for this instance will be unassigned. Executing a redo (Ctrl+Shift+Z) for the deletion of a plug-in instance will create a completely new instance. |
In the Settings - Plug-ins menu, next to the plug-in’s name, a LED is showing its status:
-
Red → Plug-in instantiation failed.
-
Green → Plug-in instantiation succeeded.
In the Settings menu, the LED next to the Plug-ins submenu shows a global status:
-
Gray → The scenario does not contain any plug-ins.
-
Red → At least one plug-in’s status LED is red.
-
Green → All plug-in’s status LED are green.
4.7.14.1. Plug-in Roles
A description of the interfaces, or roles, that are implemented with plug-ins.
SkydelCoreInterface
The implementation of this role is mandatory, and provides access to multiple features:
-
A temporary logging folder created by Skydel.
-
A JSON object saved/loaded from Skydel configuration file.
-
The option to send a command to Skydel to change the state of the application to unsaved.
-
The option to send a command to Skydel to change different notification levels (info/warning/error).
-
A custom user interface integrated into Skydel’s user interface.
Use simple_plugin as a basic plug-in example.
SkydelRadioTimeObserverInterface
When implemented, this role enables the reception of information regarding the radio time at a rate of 1000 Hz. It’s also possible for the plug-in to update its user interface during the simulation.
SkydelPositionObserverInterface
When implemented, this role enables the reception of real-time Skydel vehicle position data at a rate of 1000 Hz. It’s also possible for the plug-in to update its user interface during the simulation. Use position_observer_plugin as an example.
SkydelRawDataInterface
When implemented, this role enables the reception of real-time Skydel raw data at a rate of 1 Hz. It’s also possible for the plug-in to update its user interface during the simulation.
SkydelHilObserverInterface
When implemented, this role enables the reception of position data received through the HIL interface by Skydel in real-time. The plug-in can also update its user interface during the simulation. Use hil_observer_plugin as an example.
SkydelLicensingInterface
When implemented, this role allows a plug-in to decide whether it can be instantiated or not. To identify itself, Skydel will send a serial number associated with the active license via an encrypted communication channel.
To use this role and have access to an example, contact Safran Trusted 4D Canada’s technical support. |
SkydelInstrumentationInterface
When implemented, this role provides useful instrumenting information about Skydel. The plugin will receive a graph illustrating the relationship between each module of Skydel’s engine. Also, during a simulation it will receive statistics to help identify which module is throttling the simulation. Use skydel_default_instrumentation_plugin as an example.
SkydelRapiInterface
When implemented, this role gives direct access to Skydel’s remote API. This allows the plug-in to send commands to Skydel without establishing a server/client connection with the traditional remote API in python/C++/C#. Use rapi_plugin as an example.
4.8. Receiver
You can access the Receiver tab by clicking this button:

Once your simulation is running, you can switch to the Receiver tab to look at the output of an NMEA receiver. Start by clicking the Connect button and choosing your receiver from the list of available ports. It is possible to modify the baud rate, data bits, parity, stop bits and flow control of the serial port used by the receiver.
Linux users must be in the “dialout” group to connect to the receiver. See Dialout Group section. |

Skydel is optimized for NMEA 0183 Version 4.1. Click on the Help button to get further information about which sentences can be decoded. Click OK to close the dialog box and connect with your GNSS receiver. You should then see a stream of NMEA data appear. The receiver’s NMEA data is decoded in real-time and Skydel will display the receiver time, position, DOP, sky view, and C/No for each satellite.

When Skydel is connected to a receiver, a new checkbox appears in the Constellation subtab enabling you to display the receiver. When this checkbox is checked, the Constellation subtab will split horizontally. The upper half of the subtab will display information about the receiver (as decoded from the NMEA feed): C/No bars and sky view. The lower half of the subtab displays the usual information about the simulator.
The C/No values are displayed for the selected constellation.
The simulator sky view (lower) and the receiver sky view (upper) are not always identical. For example, some satellites below the elevation mask will appear in the receiver sky view only when the receiver has decoded the almanac from the navigation message which can take several minutes.
The Deviation subtab will show traces only if the receiver has a navigation solution. If the receiver does not have a solution, or does not send GGA sentences, Skydel will not display the receiver deviation.
Controls to display the deviation graph are provided on the left-hand side of the subtab; deviation graph options can also be accessed by right-clicking the deviation graph to bring up a contextual menu.

The Display Settings let you change the receiver’s leap seconds. This parameter is very important for accurate calculation of deviations. Skydel runs with GPS time while the receiver sends NMEA data using UTC time. To align the receiver data with the simulated data, the value for the receiver’s leap seconds must match what the receiver is currently using. This value may require adjustment if a Leap Seconds Future (LSF) event occurs during the simulation.

4.9. Map
You can access the Map tab by clicking this button:

The Map tab contains the map on the left side and the information panel on the right side. It simultaneously displays the simulated position and the receiver’s position. If Skydel is not connected to a receiver, or if the receiver does not have a navigation solution, the receiver position will not appear. If the Advanced Jammer feature is enabled, the transmitters position are displayed as well. The information panel on the right uses accordion styling. You can click on an item to open or collapse the details.

Each item in the information panel has a target state button. When clicked, the corresponding position stays centered on the map. If you pan the map, the target button will reset automatically.

4.10. Automate
Skydel was built around the Command Design Pattern, which means that all actions (either from GUI or Remote control) are sent to the Engine using Commands. The commands are processed by the engine exactly the same way whether they come from the GUI or remote program. If your simulation is working via GUI, it will work exactly the same via the API.

You can access the Automate tab by clicking this button:

The Automate tab helps you get started using the Skydel API and writing your own scripts to control Skydel.
4.10.1. Application Programming Interface (API)
There are several reasons why you might want to use the Skydel API.
-
More control over the simulation while it runs, such as:
-
changing the value of pseudorange offsets during the simulation;
-
changing the power of interference during the simulation;
-
changing the power of satellites during the simulation;
-
changing the downlink data more frequently.
-
-
To control Skydel as part of an automated test system
-
no human interaction with Skydel is required when using the API
-
Skydel provides API clients in the following languages:
-
Python
-
C#
-
C++
The Skydel API is fully featured and provides complete control over the Skydel Engine. In fact, the Skydel GUI communicates with the Skydel Engine using this same API. Therefore, anything that can be done through the Skydel GUI can also be done via the Skydel API.
The Documentation.txt file in the Skydel-SDX/API folder provides a complete list of commands with a short description.
As you make changes to your configuration, a list of commands will be displayed in the Automate tab. For example, in the image below, the line highlighted in blue is for a message modification.

When double-clicking a line, additional information about the command will be displayed.

The JSON Object tab is the command interpreted by Skydel.

The Documentation tab describes each parameter for the command.
When you set the message modification in the GUI and click the Add button, the GUI sends a request as a JSON Object to the Skydel command engine to be executed and logged in the Automate page. In computer science, encapsulating a request as an object is called the command design pattern.
The Skydel API client is an external library that will enable you to send requests as JSON objects to Skydel through a TCP/IP connection. It doesn’t matter to Skydel whether a command comes from the GUI or via a remote program.
Some Skydel functionalities could not be implemented using the Command design pattern and will not appear in the Automate tab. For example, creating a vehicle trajectory or using the hardware-in-the-loop will not appear in the Automate list. But that doesn’t mean that you can’t use these functions through the API.
4.10.1.1. Python
When you install Skydel on a Linux system, the skydelsdx library is automatically installed. Python scripts can be run from anywhere.
For Windows users, the library can be found in the Skydel-SDX/API/Python/skydelsdx folder. You may run setup.py to make the library accessible from anywhere. If you choose not to do so, you should save your scripts in the parent folder and execute them from there. The Python interpreter will find the library in the skydelsdx sub-folder.
The Skydel Python API is open source and can be modified, copied, or reused any way that you want. However, Safran recommends using the API “as is” (as much as possible) so that migration to future releases of Skydel will be easier. Skydel is constantly evolving; Safran sometimes adds new functions or capabilities that require modifying existing features and the corresponding API. To mitigate impacts to your scripts, each Skydel version comes with release notes that include a list of modified, removed, and added API methods.
You will find several Python script examples in the Skydel-SDX/API/Python folder.
The “Export to Python” feature is, by far, the easiest way to learn how to automate Skydel.

When you click the Export to Python button, Skydel will generate a Python script that will replicate the content of the Automate list.
Before you export your Python script, you can delete any lines in the list that you don’t want exported to your script. |
The following is an example of a Python script generated by Skydel:

In the above example, sim
is an instance of the RemoteSimulator
class. This class offers a high-level API that converts simple function calls into JSON objects. The class handles the transmission of those JSON objects to Skydel and interprets the results for you.
Before you can transmit requests to Skydel, you must first connect. The connect()
method accepts 2 parameters: Skydel IP address and instance id. If no values are provided to the method, the defaults are “localhost” and “0”. Skydel is listening on port 4820 + id. If Skydel was started with instance id 2, it would be listening on port 4822. When connected, Skydel will display a robot emoji at the left end of the dashboard.

The connection is followed by a list of calls that you can easily recognize in the Automate list. The first call is to create a new configuration in Skydel.
sim.call(New(True))
The call
method is generic. It can send any command: New
, SetModulationTarget
, etc. The parameter is a command object. This line can be replaced by 2 lines. First you create the command, and then you execute the call.
cmd = New(True) sim.call(cmd)
It is sometimes useful to proceed this way so that you can interrogate the command object after the call returns. Some commands will be updated as a result of the call method. For example, if you add a message modification without providing a unique identifier, the result will contain a unique identifier assigned by Skydel that you can re-use to update the message modification in the future.
The call method is blocking. This means that it will stop the script execution until Skydel returns a result (pass or fail). This blocking mechanism is referred to as a synchronous call. There is another method called post which is not blocking and this calling mechanism is referred as asynchronous. When using the asynchronous strategy, it is important to synchronize from time to time with the wait method.
cmd = New(True) sim.post(cmd) # do something else… sim.wait(cmd)
Regardless of how the command was sent to Skydel (call or post), it will appear in the Automate tab.
When you run your script for the first time, or if you need to debug it, clear the command list in the Automate tab and monitor the command results. |
If you become a heavy API user, you may notice that it takes some time to process hundreds or thousands of commands to change the settings. The reason is that Skydel updates the user interface after every command and redraws the sky view and power bars above the sliders. To avoid this, you can instruct Skydel to hold off GUI updates while it updates the settings.
sim.call(LockGUI()) # Update many settings sim.call(UnlockGUI())
Skydel will display a message in the title bar to signal when the GUI is locked.

You are encouraged to look into the skydelsdx library to better understand how it works. Also, the examples provided with Skydel will demonstrate how you can define custom vehicle trajectories, send real-time trajectories (hardware-in-the-loop), control interferences, etc.
4.10.1.2. C++
The Skydel C++ API is located in Skydel-SDX/API/Cpp/sdx_api.
The C++ examples are located in the sdx_examples folder. To build the examples, use the CMakeLists.txt file in the parent folder.
The principles of the C++ library are the same as with the Python library. The syntax differences are minor and looking at the various examples should get you started quickly.
4.10.1.3. C#
The Skydel C# API is located in Skydel-SDX/API/CSharp/SdxApi.
The C# examples are located in the SdxExamples folder. To build the examples, use the SdxExamples.sln file in the parent folder.
The principles of the C# library are the same as with the Python library. The syntax differences are minor and looking at the examples should get you started quickly.
4.10.1.4. Vehicle Trajectory
Trajectories can be created through the API. You can create tracks as well as routes. They differ in that tracks are defined with time and position pairs, while routes are defined with speed and position pairs.
For detailed explanations about the geographic coordinate system used in Skydel, please consult the Six Degrees of Freedom section.
4.10.1.4.1. Track
To create a track with the API, use the following command sequence:
sim.call(SetVehicleTrajectory("Track")) sim.call(SetVehicleType("Ground / Water")) sim.beginTrackDefinition() # push time and position pairs sim.endTrackDefinition()
There are multiple methods that you can use to push time and position pairs:
-
pushTrackEcef
: push time and position in ECEF reference system; -
pushTrackEcefNed
: push time, position (ECEF), and attitude (relative to NED local frame); -
pushTrackLla
: push time, latitude, longitude and altitude (ellipsoid); -
pushTrackLlaNed
: push time, latitude, longitude, altitude, and attitude (relative to NED local frame).
Time is the number of milliseconds (ms) into the simulation (elapsed time). |
If the attitude is not provided, Skydel will automatically calculate it. The yaw (heading) will go along the route. The pitch will go up and down based on the altitude variation and the roll is fixed to 0°.
4.10.1.4.2. Route
To create a route with the API, use the following command sequence:
sim.call(SetVehicleTrajectory("Route")) sim.beginRouteDefinition() # push speed and position pairs sim.endRouteDefinition()
The route vehicle simulation supports only ground vehicles for the moment. Therefore, you don’t need to specify the vehicle type and you can’t specify the attitude either. The attitude is automatically calculated by Skydel. The yaw (heading) will go along the route. The pitch will go up and down based on the altitude variation and the roll is fixed to 0°.
To push speed and position pairs, you have the choice between two methods:
-
pushRouteEcef
-
pushRouteLla
The speed is expressed in meter per second (m/s).
4.10.1.5. Retrieve vehicle information
It is possible to retrieve information about the vehicle using the remote API. The available information are:
-
The position in the ECEF frame
-
The attitude (Yaw, Pitch, Roll)
-
The speed in km/h
-
The heading
-
The odometer
Please refer to the example_vehicle_info.py python script, the runExampleVehicleInfo C++ function or the RunExampleVehicleInfo C# function for a complete example.
4.10.2. Additional Resources
Here are some additional resources that can help you create and edit a trajectory:
4.10.3. Skydel Script
Sometimes you require a fast and simple way to automate tasks and you don’t want to use a programming language to do so. Skydel allows you to record commands as a Skydel script from within the GUI and to replay these commands. Let’s take an example to illustrate how it works.
- Step 1
-
Create a new configuration.
- Step 2
-
Switch to the Automate tab and clear the list
- Step 3
-
Switch to the Settings tab and make some changes to the settings such as:
-
Change the simulation start time.
-
Change the ionospheric model. If you switch back to the Automate tab, you should see the changes in the list.
If you switch back to the Automate tab, you should see the changes in the list.
-
- Step 4
-
Save the script as my_first_script or some other filename that you will remember.
By default, your script will be saved in the Skydel-SDX/Automate folder. The extension of the file is .sdxscript.
- Step 5
-
Quit Skydel and restart it. You can also simply create a new configuration and clear the Automate list once again.
- Step 6
-
Switch to the Automate tab and open the script that you just saved (my_first_script).
You will notice the Automate list is now showing the list of commands that you saved in my_first_script but the difference is in the Result column: it is empty. That’s because the script is loaded but never executed. At this point, your simulation start time and ionospheric model are unchanged.
- Step 7
-
Run the script
The script execution will only last a few milliseconds and you will see the Result column filled with “Success” mentions. You can now check that your simulation start time and ionospheric model are set according to your script.
Scripts can be more complex and can record commands while the simulation is running. Commands executed during the simulation are timestamped and will occur at the exact same time during replay. In the image below, you can see that timestamps are recorded after the simulation starts and continue to be recorded until it stops.
If you export this list as a Python script, you will see how commands are executed from a Python script while the simulation is running.
As an exercise, you can create a script where you change the satellite power during the simulation (move the power slider up and down). When you will replay this script, you will notice that the slider moves at the same moment.
4.11. Basic Interference
When the Advanced Jammer feature is enabled, the Basic Interference tab is hidden and replaced with the Interference submenu located in the Settings - Interference menu. For more information on the Advanced Jammer feature, read here. |
You can access the Interference tab by clicking this button:

You can use the Interference tab to add jamming waveforms to the simulation. These jamming signals will be generated and output by the same ports that output the GNSS signals. When saving a configuration, these interference waveforms will be retained in the saved configuration.
To add a waveform, click the Add button on the Interference tab. Select the type of waveform that you would like to add. For this example, we will use Continuous Wave.

You can adjust the settings in the dialog box that appears. The start and stop times are in the “hh:mm:ss” format and are relative to simulation time.

The power is relative to the nominal output power (-50 dBm at the TX port for the Ettus X300 SDR, -110 dBm after the 60 dB attenuators). This power level can be thought of as the “jammer to signal” ratio. But this is only true if the global signal level and code specific signal level are both 0 dB.
For example, if the signal levels are configured as shown below and the interference is set to 30 dB, the interference will be 30 dB stronger than the C/A signals, and 33 dB stronger than the P Code signals.

If you increase the Global Signal Level to +5 dB, the interference will be 25 dB stronger than the C/A signals. This is because the global offset increases the power level of the signals, but not of the interference.
Once you have added the interference, it will show up in the Interference list.

The State column indicates Not Running if the simulation is not running. During the simulation, there are a handful of states that can be indicated for each interference signal:
-
Inactive - The interference is off. The current time is not between the start and end times;
-
Active - The interference is on;
-
Out of Range - The interference is off. The signal doesn’t fit within any of the RF output frequency ranges. There are two options to fix this:
If everything is setup correctly, you should see the interference become active during the assigned times.
When you configure multiple outputs with the same Fc or with overlapping bands, and when the interference is enabled for that Fc, the interference is added to each RF output. When you combine the outputs with the RF combiner, you sum the interferences. The interference wavefronts are not necessarily aligned. |
4.12. SNMP Support
An SNMP agent and a MIB can be found on Learn Safran Navigation Timing’s Github. It is provided with an installation script for Ubuntu.
Thanks to this agent, you can probe and control Skydel through variables such as the isRunning variable. This variable is an integer equal to 1 if a Skydel simulation is currently running, 0 otherwise. Setting it to 1 will start the simulation while setting it to 0 will stop it.
More details can be found in the documentation provided with the agent. An application is also available detailing how to customize the sub agent for your specific needs.
Additional Resources |
4.13. Additional Skydel Resources
Here is a list of additional resources, articles, and application notes that can help you maximize Skydel’s potential in your GNSS simulation:
5. Hardware-In-the-Loop (HIL)
In a HIL setup involving the Skydel GNSS simulator, we often have the following elements (or concepts).

There are many possible variations. For example, the Autopilot could be a human interacting with a virtualized dashboard, but the concept often remains the same. The key principle is that the loop is often closed, and the true position is not known in advance. Instead, the true position of the vehicle is determined as the scenario progresses and fed in real-time to the Skydel GNSS Simulator.
In this setup, the Skydel GNSS Simulator receives the true vehicle trajectory in real-time and generates the GNSS RF signal accordingly. A GNSS receiver tracks the signal and computes its position. This position is sent to a navigation system, such as the autopilot in this example. The autopilot analyzes the position and sends commands to correct the vehicle trajectory. Those commands are processed by the HIL simulator, which emulates the effect of such commands on the true position.
For this setup to work properly, the integrator must carefully consider the following questions:
-
What is the acceptable latency between the HIL Simulator input (Autopilot Command) and the Skydel GNSS Simulator output (GNSS RF Signal)?
-
How is this latency budget shared between the HIL Simulator, the Skydel GNSS Simulator, and the link connecting them?
-
How are synchonization and the clock system handled?
-
Can the HIL Simulator and the Skydel GNSS Simulator use a common clock source?
-
At which rate can the HIL Simulator update the true position of the vehicle?
-
What position data will be available (time, position, velocity, attitude, angular velocity, etc.)?
Make sure the HIL option is included in your software license. |
5.1. Time Reference
The following drawing details the suggested integration of the HIL Simulator and Skydel Simulator.

Module | Description |
---|---|
SecureSync |
The network time server ensures the operating system on the HIL Simulator, and the Skydel Simulator are tightly synchronized within hundreds of microseconds. It also provides the 10MHz reference clock and PPS signal to the software-defined radios (SDRs). |
Linux OS |
Linux is recommended over Windows for real-time applications. Linux should be configured to use Precision Time Protocol (PTP) to synchronize the clock with the SecureSync. |
Skydel |
The GNSS simulation software receives the true position and generate the corresponding GNSS RF signal in real-time. Skydel adds a deterministic latency which is set in the software preferences. It may be required to change the settings in the preferences to achieve the desired latency. |
HIL Simulator Software |
The HIL Simulator is responsible for sending the true vehicle position to the Skydel simulator. The HIL Simulator must timestamp the data, hence the need to have a common clock source to minimize jitter and drift between the HIL Simulator and the Skydel Simulator. |
Skydel HIL Client |
The Skydel HIL Client is a library providing a simple API. It is highly recommended to use this library and not try to reimplement the communication protocol with Skydel. The Skydel HIL Client requires an Ethernet connection and uses a mix of TCP/IP for most commands and UDP for true position data. The Skydel HIL Client adds latency which is mainly defined by the Ethernet connection. The combination of the HIL Simulator and the Skydel HIL client is sometimes referred to as the HIL Client in this document. |
SDR |
The software defined radios must receive the PPS and 10MHz signals from the same time source, as Skydel will use their internal clock to drive the simulation. |
It is possible to deviate from the suggested integration, but investing in a common clock source to discipline all subcomponents will make the system easier to understand and easier to optimize.
5.2. HIL Sequence Diagram
The most critical part in any HIL system is to get the synchronization right. The following timing diagram shows the logical steps for precise control of the Skydel synchronization with an external PPS source.

There are 5 phases in the starting sequence:
- Arm the system
-
The ArmPPS command initializes the hardware. The execution may take a while and will vary depending on the hardware. Some radios take only a couple of seconds while others, like a Wavefront system, will take longer because it must perform a phase calibration.
- Choose a PPS reference (PPS zero)
-
The WaitAndResetPPS command does exactly what it says: it will wait for the next PPS, reset the PPS counter in Skydel to zero and return. When this command returns, you know that you are just a few microseconds or milliseconds after PPS zero.
If your setup is using a SecureSync to discipline your operating system clock as shown in the previous section, it should be aligned with the PPS. When the WaitAndResetPPS returns, you can read the precise system clock on Linux and round down to the previous second. This is the system time associated with PPS zero.
- Program the delayed start using PPS zero as the timing reference
-
The StartPPS command will start the GNSS RF signal stream at a precise time, always relative to the PPS zero. When multiple Skydel instances are controlled by a primary (master) Skydel instance, make sure the StartPPS is set in the future to cover at least 2 full PPS cycles which are required by Skydel to synchronize all the secondary (slave) instances. Multiple instances are used in many scenarios: multiple vehicles, spoofer, Wavefront nodes, etc.
The StartPPS command will return control to the caller a few milliseconds before the defined time. This will allow time to send the initial position before the simulation starts. Without the initial receiver position, Skydel can’t make the necessary calculations to determine the propagation delays from the GNSS satellites to the receiver position and will not start properly.
StartPPS uses the Streaming Buffer size defined in the Skydel preferences as the amount of time before the actual RF streaming starts. For example, with a streaming buffer of 200ms, the StartPPS function will return control to the caller 200ms before the RF starts streaming. It is not recommended to play with this preference.
- Push the initial position before it starts
-
The first position should be sent before the beginning of the simulation. For this reason, the StartPPS command returns before the specified time. When it returns, it is the right time to send the initial position. Skydel needs the starting position to initialize and compute pseudoranges, visible satellites, etc.
- Push all subsequent positions at regular intervals
-
Assuming the operating system clock is disciplined by the same clock source as the Skydel simulator, it is possible to use the system clock to determine when it is time to start the loop to send the vehicle position. The position should be sent at a high rate to minimize position errors between samples. A rate of 200-250 Hz is a typical compromise between extrapolation errors and available system resources.
Each position update, including the initial position, must include the elapsed time. The elapsed time is not relative to PPS zero, it is relative to the beginning of the RF signal transmission. In the timing sequence previously shown, the simulation starts at PPS 3. At that precise moment, the elapsed time is zero. All HIL positions pushed should include the elapsed time since that moment. The initial push should have the elapsed time set to zero. If the HIL push rate is 200Hz, new positions should be pushed at 5, 10, 15 ms and so on.
5.3. Code Example
To simplify the integration of Skydel in user programs, it is strongly recommended to use the libraries provided. These libraries are open source so they can be inspected by users. Although they are open source, these libraries are developed by Safran, and not by the open-source community. The libraries are available in Python, C and C#. For simplicity, the code provided as examples in this document are all in Python, but they can easily be translated into C or C# as the command names are the same.
In this example, the Python code will initialize the Skydel simulator to synchronize with a PPS source and steer the vehicle on a simple circular trajectory. It is assumed that the example program is running on a Linux computer and the system clock is disciplined by the same source as the Skydel simulator, as previously explained in the hardware setup.
We will skip some details, such as some function definitions, just to cover the main concepts. The complete Python source code, as well as a C++ and C# example, can be found in the API examples folder. |
The first step is to connect with the Skydel instance.
sim = skydelsdx.RemoteSimulator() sim.setVerbose(True) sim.connect("localhost")
The verbose option can be helpful to help diagnose potential issues. The “localhost” should be replaced with the IP address where Skydel is running. A local host can be used only if this Python script runs directly on the Skydel host computer.
sim.call(SetVehicleTrajectory("HIL")) Sim.call(SetHilTjoin(20)) sim.setHilStreamingCheckEnabled(True)
The script sets the vehicle trajectory to Hardware-In-the-Loop (“HIL”). It is assumed that Skydel scenario is already configured (signals selection, output selection, etc.). After setting the HIL trajectory, the Tjoin parameter must be set for the current scenario. The unit for Tjoin is in milliseconds. You will find below in this document a whole section dedicated to this parameter. Next, the script enables the streaming check. When enabled, the API will determine if Skydel stopped streaming unexpectedly and if so, will throw an exception. The check is done automatically once every second when the script starts pushing positions. This check does an API call, which adds a delay that can be unacceptable in some low-latency scenarios; in that case, the streaming check should be disabled.
sim.call(EnableMasterPps(True))
The EnableMasterPps command enables PPS synchronization.
sim.call(ArmPPS())
The ArmPPS command performs the hardware initialization. In the case of a Wavefront system, it will also perform the phase calibration. The call is blocking, but it is also possible to post the command and do some other work in parallel and wait later for the ArmPPS function to complete.
armPPS = sim.post(ArmPPS()) # do some time consuming work here sim.wait(armPPS)
Any call can be replaced with a post/wait. It is also possible to post several commands and wait after you posted all of them. It is also possible to wait only for the last post sent, but if an error occurred with a previous post, the script might miss an error message and the flow could lead to unexpected behavior.
sim.call(WaitAndResetPPS()) pps0TimestampMs = getLastPPSTimeMs()
The WaitAndResetPPS command returns immediately after the beginning of the next PPS. If the clock on your Linux computer is disciplined with the same PPS source, you can read the clock and round it to the nearest second. This value matches the time of PPS zero.
pps0TimestampMs = getClosestPpsTimeMs()
The getClosestPpsTimeMs command is a simple helper function to get the nearest second, but expressed in milliseconds.
If the computer time is not disciplined with the same clock source as the PPS, you can ask Skydel to provide the computer time corresponding to the PPS.
pps0TimestampMs = sim.call(GetComputerSystemTimeSinceEpochAtPps0()).milliseconds()
This technique works only if the HIL script is running on the same PC as Skydel (sharing the same computer clock).
sim.call(StartPPS(syncDurationMs))
The StartPPS returns a few milliseconds before Skydel starts transmitting the RF signal. The RF will start at the precise moment specified in the command with syncDurationMs (relative to PPS zero). So, the script must send the first position immediately after the StartPPS returns and before Skydel starts streaming RF.
sim.pushEcefNed(0.0, position, attitude, velocity, angularVelocity)
The first push must use zero as the elapsed time. Remember, the elapsed time is relative to the beginning of the RF streaming, and not relative to PPS zero. Also, the elapsed time is expressed in milliseconds and can be fractional (floating number).
After the first push, the script simply loops at the predefined frequency to push new positions.
try: # Send positions in real time for the desired duration while elapsedMs <= simDurationMs: # Wait for the next position's timestamp preciseSleepUntilMs(nextTimestampMs) nextTimestampMs += timeBetweenPosMs # Get the current elapsed time in milliseconds elapsedMs = getCurrentTimeMs() - simStartTimestampMs # Generate the position position, velocity = trajectory.generateEcefWithDynamics(elapsedMs) # Push the position to Skydel sim.pushEcefNed(elapsedMs, position, attitude, velocity, angularVelocity) finally: # Stop the simulation sim.stop() # Disconnect from Skydel sim.disconnect()
5.4. Latency
The HIL latency is the delay between the instance of an event on the true trajectory and the realization of this event on the RF signal. Different mechanisms like extrapolation can be implemented to predict these events, but they are only a way to mitigate the effects of latency. That is why it is crucial to minimize the latency of a system as much as possible. Several factors contribute to the latency:
-
The determination (or calculation) of the true trajectory in the HIL Simulator
-
The sampling rate of the true trajectory
-
The time it takes for those samples to reach Skydel
-
The time it takes for Skydel to process and generate a trajectory and create the RF signal corresponding to the trajectory. This factor is referred to as the Engine Latency in the following section.
Skydel supports two strategies to mitigate the effects of latency:
-
The HIL Simulator sends the current receiver position at regular intervals and Skydel can extrapolate the trajectory to eliminate the effects of latency. Skydel will estimate the future position of the receiver based on received samples.
-
The HIL Simulator sends the future receiver position at regular intervals. The position must be received enough time in advance to cover the latency. Skydel will interpolate the trajectory between the samples.
Although Skydel supports both strategies, the script provided in this manual only illustrates the first strategy which is simpler to integrate for the client side. This section explains how to use the second strategy.
5.4.1. Engine Latency
The Performance subtab is useful for insight on the system’s latency, performance, and stability. The right side of the Performance graph is a detailed view on the last second of simulation, while the left side graph is a summary of the last minute of simulation.
During a HIL simulation, the graph shows when the positions were received, relative to the RF time. This is useful to investigate issues with the network or the HIL client.

Before reading the next section, it is recommended to review your understanding of the Skydel engine latency fundamentals in the performance section.
5.4.2. HIL Latency
The data flow begins in the constellation worker (see previous section, Engine Latency). It is the entry point where the calculations begin. The constellation worker is computing data ahead of its transmission. Therefore, it is considered that the constellation worker time is in the future (prior to RF output).
The goal of the Skydel HIL engine is to estimate where the receiver will be (constellation time) using real-time data (system time) and minimize estimation errors (oscillation, resonance, jerk, etc.) in the receiver trajectory. The HIL client should not perceive significant discrepancies between its current position and the simulated position at the radio output.
The HIL client is only required to know the current position and optionally the dynamic (velocity, acceleration, and jerk) of the receiver. The HIL client does not transmit the continuous trajectory; instead, it is sampling the receiver position (and dynamic) at regular intervals. We will refer to this information as PVA, or PVA sample. Each sample is timestamped and corresponds to the time at which the sample was taken.
The HIL client sends PVA samples which are always in the past from the constellation worker point of view (constellation time vs system time). The constellation worker uses the latest PVA sample to extrapolate the receiver position in the future.

When a new sample cPVA@T1 is received in the constellation worker, this new sample is already in the past, but not as old as the cPVA@T0 sample used to compute the current position P.
The trajectory of the receiver is dynamic and the extrapolation of cPVA@T0 will not connect perfectly with cPVA@T1. To mitigate the discontinuity, the engine smooths the transition between the 2 extrapolated trajectories. The transition occurs over a period that is limited by the parameter Tjoin. That parameter defines when the actual trajectory catches up or joins the curve extrapolated with the latest PVA sample.

Before Skydel extrapolates to reach P2, it is expected that HIL client will send a new PVA sample such that a new trajectory converging to this new sample can be calculated and have a smooth transition.

In the event where no PVA sample is received after the constellation thread extrapolation reaches P2, the extrapolation will continue using only cPVA@T1 until the next sample is received. When cPVA@T2 is finally received, a new extrapolation curve is calculated to converge with the latest PVA sample. This may not be an issue in most cases, but this extrapolation is not perfectly deterministic as the new curve is calculated when the PVA sample arrives.

The Tjoin parameter can be set programmatically. As a rule of thumb, its value should be defined as the sum of the following parameters:
- Engine Latency
-
The maximum time the constellation worker is allowed to simulate ahead of the current system time. This parameter is defined in the Skydel preferences.
- HIL Interval
-
The time between two PVA samples (the inverse of the HIL update rate).
- Network Latency
-
The time it takes for the PVA sample to travel on the network
For example, if you optimize the engine latency to 5 ms, use an HIL update rate of 250 Hz (one sample every 4 ms) and the network latency is within 1 ms, the Tjoin could be set to 10 ms.
5.5. HIL Graph
5.5.1. How it works
Using the HIL feature can create undesired effects such as excessive jerk and error position. These effects are usually caused by simple mistakes which can easily be corrected once identified. The challenge is to make the proper diagnostic in the first place. The HIL graph is a powerful visualization tool that is designed to make precise diagnoses and give you the confidence the solution is working exactly as you expect.
The HIL graph is in the HIL subtab.

The graph on the right provides a detailed view of the last second, while the view on the left summarizes the last minute.
If we zoom in on the detailed view on the right, you can see that it is composed of multiple vertical bars.

Each vertical bar represents a PVA sample. The vertical axis is time. The bottom of the vertical bar corresponds to the PVA time reference, and the height of the bar is defined by the value of Tjoin. The zero on the vertical axis is the current system time. Because the PVA sample time reference is in the past, the bottom of the vertical line can be negative. A value of -5 means the sample was taken 5 milliseconds ago. Because Skydel uses a pipeline to compute chunks in advance, the constellation worker can be several milliseconds ahead of the system time. With an engine latency of 10ms and a Tjoin value of 17 ms, the first PVA sample bar can be illustrated like this:

The horizontal axis represents the system time as well. As the system time advance by chunk of 1 millisecond, the PVA sample gets older by 1 ms. A 1 ms step on the HIL graph can be illustrated like this:

When the system time progress by 1 ms, the constellation worker is allowed to work on the next chunk (#11).
As defined by Tjoin, the constellation worker will extrapolate the PVA sample up to chunk #17. The constellation worker expects a new PVA sample before it starts working on chunk #18. That new PVA sample could have a time reference of 5 ms. With a Tjoin value of 17 ms, that new sample can be extrapolated up to chunk #22.

As more PVA samples are added to the graph, it creates a characteristic saw tooth geometry with peaks and valleys. An optimal HIL integration will have regular peaks (same height, same interval). The valleys will be as close as possible (from top and bottom) to the dark green area.
A PVA sample doesn’t always arrive at the exact moment it is needed. If it arrives a couple of milliseconds earlier, it will appear in the HIL graph in blue. It means the sample is already received but queued to be used later.

When a PVA sample does not arrive when the constellation worker needs it, the worker will extrapolate beyond the limit defined by Tjoin. In this case, the chunk will be shown in yellow.

5.5.2. Common Patterns (Extrapolation)
As explained in the previous section, when the settings are optimal, the HIL graph has regular peaks and valleys. Depending on the settings and the HIL integration, you may observe different patterns. In this section we explain typical deviations to the optimal pattern, the reasons behind them, and the possible solutions to improve the performance.
Note that if you use a Tjoin value of zero, refer to Sending Positions in Advance section and the resulting common patterns.
5.5.2.1. Optimal

Observations:
-
The green valleys reach the Engine Latency and stay green; there is no blue, yellow or red. It means that HIL trajectory samples are received just in time, not too soon, not too late.
-
The gray valleys are close to the RF. It means the Tjoin value and the HIL trajectory sampling rate are well configured.
-
All peaks and valleys are very similar. It means the samples are received at fixed interval with little jitter.
5.5.2.2. Tjoin Value Too Large

Observations:
-
Excessive blue color in the graph means that HIL trajectory samples are queued and not used until later. At the same time, there is excessive gray color at the bottom which indicates the samples are used for a prolonged period. This is caused by a large Tjoin value.
-
Reducing Tjoin will make Skydel move to the next HIL trajectory sample sooner. You can reduce the Tjoin value until you start seeing yellow or red and then back off a little. If being perfectly deterministic in the extrapolated trajectory is more important, you prefer blue to yellow. If shorter latency is more important in your system, you can tolerate more yellow and less blue.
The following image focuses on the last second to show more details.

5.5.2.3. Tjoin Value Too Small


Observations:
-
Excessive yellow (or red) color in the graph means that Tjoin is too small. You can either increase Tjoin which also increases the system latency, or increase the sampling rate of the HIL trajectory, or reduce the engine latency. You can use the performance graph to determine if you can reduce the engine latency without risking underrun errors.
-
Another possible explanation is that you have a bias between the HIL simulator clock and the Skydel simulator clock. You can observe the timestamp offset with the Skydel clock in the performance subtab. The HIL dots (orange) should be very stable and near the 0.
5.5.2.4. Jitter


Observations:
-
The peaks are not at regular heights.
-
The peaks are not at regular intervals.
There are multiple possible reasons that can explain this pattern:
-
Irregular intervals are caused by the varying HIL trajectory samples rate of arrival. The HIL simulator could be sampling at an irregular interval, or the network could be congested.
-
Irregular height can be caused by poor precision or poor accuracy on the timestamps. This can be caused by unreliable timing functions or clock source on the HIL simulator. Or it can be the network interface that is not sending packets immediately.
-
When both heights and intervals are irregular, it can mean that multiple source of errors are present simultaneously.
Although everything is green or blue (no yellow, no red), this jitter might cause problems, especially if the timestamps are inaccurate. It is recommended to analyze the resulting receiver trajectory log for discontinuities or anomalies. Computing the first or second derivatives might also reveal insufficient precision in the HIL trajectory samples provided to Skydel.
The timestamp offset relative to the radio time of each HIL trajectory sample is also displayed in the performance subtab as shown in the image below.

5.5.2.5. Lost Sample
HIL is a time-sensitive application and for that reason Skydel uses the User Datagram Protocol (UDP) to transmit the trajectory samples. UDP does not recover lost packets. A lost packet can be visible in the HIL graph when the Tjoin value is not too large.

If you zoom in, you can see a packet seems to be missing because the interval between the samples is stable except for 1 gap which resulted in non-deterministic extrapolation (yellow) of an older trajectory sample.

5.5.2.6. Late Sample
Skydel will extrapolate a sample until the moment when the constellation worker reaches the time defined by the sample reference time plus the Tjoin time. At that moment, the worker will use the next queued sample; if there are no queued samples, Skydel has no other choice than to extrapolate the sample beyond the limit defined by Tjoin. This situation is illustrated in yellow in the HIL graph. If this situation lasts long enough and the next sample arrives when its reference time plus Tjoin is already in the past, Skydel will not try to smooth the transition and it will snap the trajectory on the newly received sample. This condition is shown in red.

5.5.2.7. Falling Behind / Catching Up
When the constellation worker is falling behind, you can see the effect in the performance graph as well as in the HIL graph as shown in the image below.

5.6. Sending Positions in Advance
In previous sections, we explain how the HIL simulator sends the current receiver position in real-time and at regular intervals. In that case, Skydel uses the provided samples to extrapolate the trajectory and compensate the effect of the latency. It is possible to use Skydel in a different way, where the client side (the HIL simulator) extrapolates the trajectory to provide position samples in advance (timestamp in the future) so that Skydel will interpolate the trajectory between the current position and the future position. This section explains how this can be done and the visible effects on the HIL graph common patterns.
The Skydel engine latency has a direct effect on the amount of time the HIL simulator has to send the samples in advance.
In the previous code example, the Python script plays the role of the HIL simulator and it sends the current position at regular intervals. To operate in interpolation mode instead of extrapolation, the HIL simulator must send the position for a time in the future instead of the current position. The time offset should be the sum of:
-
Engine Latency
-
HIL sampling interval
-
Estimated network latency
For example, with an engine latency of 10 ms, a HIL sampling rate of 200 Hz and a network latency of 1 ms, the offset should be 16 ms.
Sending the initial position with a timestamp of 0 ms, as shown in the code example, is still required, but when the simulation starts, instead of sending the current position, the HIL simulator must send the position for a time in the future. To do so, it must take the current elapsed time (relative to the moment when the simulation started) and add the time offset (16 ms in the example above) and extrapolate the position for that time.
The table below shows the samples sent to Skydel for the following example:
-
Engine Latency = 10 ms
-
HIL Sampling Rate = 200 Hz (one sample every 5 ms)
-
Network Latency = 1 ms
Scenario time when the sample is transmitted to Skydel | Timestamp of the sample |
---|---|
Before the simulation starts |
0 ms |
~0 ms |
16 ms |
~5 ms |
21 ms |
~10 ms |
26 ms |
~15 ms |
31 ms |
To reduce the system latency, it is not sufficient to simply increase the HIL sampling rate. It is also important to reduce the engine latency and the network latency. |
The Scenario time is relative to the real-time at the radio RF output. Be careful with the elapsed time notion: it can refer to the Constellation Worker time which is ahead of the Scenario time by as much as the value defined by Engine Latency. |
5.6.1. Common Patterns (Interpolation)
The common pattern for interpolation will differ from the patterns observed for extrapolation when Tjoin is greater than zero.
5.6.1.1. Optimal
Using the previous example:
-
Engine Latency = 10 ms
-
HIL Sampling Rate = 200 Hz (one sample every 5 ms)
-
Network Latency = < 1 ms
-
Resulting Time Offset = 16 ms
The HIL simulator sends the samples with a timestamp 16 ms in the future. You can observe the following optimal pattern:


Observations:
-
There is no gray color at the bottom. Because Tjoin is set to zero, Skydel will not use a sample with a timestamp in the past as long as there are available queued samples.
-
There is minimal blue color at the top. That means the samples arrive just when they are needed, and not before.
5.6.1.2. Time Offset Too Large
When the time offset is too large, the HIL simulator extrapolates too far in the future. Using the same conditions found in the optimal example above, but with a time offset of 25 ms instead of 16 ms, you can observe the following pattern:

Observations:
-
There is no gray color at the bottom. Because Tjoin is set to zero, Skydel will not use a sample with timestamp in the past as long as there are available queued samples.
-
There is excessive blue color at the top. That means the time offset for extrapolation on the HIL Simulator could be smaller.
-
If the HIL Simulator reduces the sampling rate, the samples will be used for a longer duration and there will be less queuing of samples (less blue). It is usually preferable to reduce the time offset and keep the sampling rate high. Note that a sampling rate higher than 1 kHz is useless because Skydel will take a maximum of sample per millisecond and ignore the other samples.
5.6.1.3. Time Offset Too Small (or Sampling Rate Too Low)
When the time offset is too small, the HIL simulator does not extrapolate far enough in the future. Using the same conditions found in the optimal example above, but with a time offset of only 13 ms instead of 16 ms, you can observe the following pattern:

Observations:
-
There is no gray color at the bottom. Because Tjoin is set to zero, Skydel will not use a sample with a timestamp in the past as long as there are available queued samples.
-
When the constellation worker time, which is ahead of the scenario time, reaches the last queued time stamp, it can no longer interpolate with the next point, so it continues by extrapolating the trajectory as shown in yellow in the graph. To solve this issue, the HIL simulator should either increase the time offset, the sampling rate, or both.
5.6.1.4. Jitter

Observations:
-
The peaks are not at regular heights.
-
The peaks are not at regular intervals.
There are multiple possible reasons that can explain this pattern. Refer to this section for explanations.
5.6.1.5. Lost Sample

Observation:
-
The peaks are at regular intervals, except for one gap which is not compensated by closer peaks following the gap.
For additional information on lost samples, read this section here.
5.7. Additional HIL Resources
Here are some additional resources that can help you when working with HIL.
6. Timing
While Skydel can be used with little knowledge of its internal working model, some simulation use cases will benefit from a deeper understanding of its operating principles. For example, if you want to:
-
synchronize RF with external PPS;
-
synchronize multiple simulators;
-
synchronize time with the live sky;
-
control a receiver’s trajectory in real-time (Hardware-in-the-loop);
-
or any combination of the above use cases.
The Skydel simulation engine can be controlled by the user interface (GUI) or a client API. To simplify the documentation, the diagrams in the following sections will refer to the API client setup as pictured below.
When synchronizing multiple instances of Skydel, we use a Master/Slave terminology. The client usually connects only to the Skydel Master, and the Skydel master connect to the Slave(s). In some circumstances, the client may want to connect to the Slave as well.
To better understand the timing diagrams in the following sections, it can be helpful to refer to the following Skydel state machine diagram.

6.1. Single Skydel Setup
This section describes use cases using hardware setups based on Ettus USRP X300 radios (and an OctoClock-G clock distribution module when appropriate).
6.1.1. Normal Start
Normal Start refers to a scenario where Skydel:
-
does not synchronize with other simulators;
-
does not synchronize the simulation’s start time with a timing receiver;
-
does not synchronize with an external PPS source (by setting Skydel as master instance).
The sequence starts when the client API sends the Start command, or when the user clicks the Start button in the Skydel GUI.
In this use case, Skydel ignores the external PPS. Instead, it uses its own internal PPS source. The PPS OUT connector on the radio is aligned with the internal PPS. The duration of the start command can change for each run, but the RF signal will always be aligned with a PPS rising edge.
The Start command is blocking until Skydel enters the Streaming RF state.
When Skydel enters the Streaming RF state, it doesn’t mean that it is transmitting RF at the exact same moment. The GNSS RF signal transmission only starts at the next PPS rising edge. |
6.1.2. Arm & Start
This use case is similar to Normal Start except that the client API arms the system before starting it. The Arm command returns when the hardware is initialized and ready to start. Once the initialization is completed, the Start command is executed with minimal delay.
Even if you were to arm the system before starting it, Skydel would wait for the next PPS rising edge. This means that even if the command returns after only a few milliseconds, the GNSS RF signal streaming may start up to 1 second later. |
6.1.3. HIL Start
This use case is similar to Normal Start except that the vehicle trajectory type is HIL. In this scenario, the client transmits the vehicle’s trajectory in real-time.
In this use case, the GNSS RF Signal and the PPS OUT are not synchronized. This is because the simulator starts as soon as it receives the first HIL position. To synchronize the GNSS RF Signal with a PPS while using HIL trajectory, refer to section Master/Slave Sync With PPS. |
6.1.4. Sync With External PPS
To synchronize Skydel with an external PPS source, refer to section Master/Slave Normal Start. The difference with Master/Slave scenario described in the other section is that this use case only has a master - there are no slaves. Make sure the setup is properly configured to use external 10 MHz and PPS sources and make sure the master checkbox is set.
6.2. Master/Slave Setup
This section describes use cases with hardware setups based on Ettus USRP X300 radios and an OctoClock-G. In all use cases, the Sync Time (Master) checkbox must be checked for the master and the Sync Time (Slave) checkbox must be checked for the Slave(s).
When checking a Sync Time checkbox (either for the master or the Slave), the Ettus X300 radio must use the external PPS signal source from the OctoClock-G; it should be connected to the PPS TRIG IN connector on the back of the X300.
When the USRP X300 radio is configured to use an external 10 MHz and PPS sources, the USRP PPS OUT is disabled and can not be used. |
6.2.1. Master/Slave Normal Start
This use case describes how to synchronize multiple simulators to commence on the same PPS rising edge. The master Skydel instance will automatically select which PPS to use. To manually select the PPS, refer to section Master/Slave Sync With PPS.
In the following timing diagram, the sequence is initiated by the client API when it sends the Start command to the master Skydel instance. This command is blocking until the master enters the Streaming RF state.
When the Master receives the Start command, it begins a process to initialize itself, as well as each of the Slaves. Once this initialization is completed, the Master monitors the PPS and selects one as the reference PPS. The Master also guarantees that all Slaves are using the same reference PPS. Once the reference PPS has been determined, the Master uses the PPS IN Delay value to program the GNSS RF signal start.
6.2.2. Master/Slave Sync With PPS
You can synchronize multiple simulators (one Master with one or more Slaves) with a specific PPS rising edge.
In the following timing diagram, the sequence is initiated by the client API when it sends the ArmPPS command to the master Skydel instance. This command is blocking until the master enter the Sync PPS Reset state.
When the master receives the ArmPPS command, it automatically forwards the command to the Slave(s) and each Skydel instance commences the hardware initialization process. The Master Skydel instance will complete its own initialization and wait for each of the Slaves to enter Sync state before entering the Sync PPS Reset state.
The initialization may take more or less time depending on the hardware being used. See note 1 in above diagram. |
Once the ArmPPS command returns, the client sends the WaitAndResetPPS command to the master Skydel instance. This command is blocking until the Master enters the Sync Start Time state.
When the Master receives the WaitAndResetPPS command (note 2), it waits for the next PPS rising edge (note 3). Immediately after this rising edge, Skydel knows that it has one full second to complete a time-critical process before the next rising edge. During that period of time, it will inform all Slaves to use the next PPS rising edge as the reference PPS. Each Skydel instance resets the PPS counter on the same PPS rising edge. Once that task is completed, the master Skydel instance enters the Sync Start Time state.
Once the WaitAndResetPPS command returns, the client sends the StartPPS command with a delay relative to the reference PPS. This delay is specified in milliseconds.
Between the WaitAndResetPPS command and the StartPPS command, it is possible to change the scenario start time using the SetPps0GpsTime. The start time sent will match the 0th PPS.
The StartPPS command returns 200 ms before the radios actually start transmitting the RF signal (note 4). The 200 ms is defined by the streaming buffer size in the general preferences. The RF signal containing the GNSS signals commences at the exact moment defined in StartPPS command (note 5).
The Master/Slave synchronization also works with HIL trajectories as illustrated in the timing diagram below:
The only difference is that when the StartPPS command returns, the client is expected to begin sending receiver positions for hardware-in-the-loop trajectories. It should start sending position for time=0s; this position corresponds to where the client tells the receiver to be at the precise moment that the RF streaming begins.
Sometimes we need to set the Master checkbox even if there is no Slave(s) connected. This is actually the only way to synchronize a GNSS RF Signal with an external PPS while using the HIL trajectory. |
6.3. Timing Receiver Setup
To synchronize with the actual current time, Skydel needs to be connected with a GPS timing receiver, such as the OctoClock-G.
The flow is similar to Master/Slave Normal Start. The difference is that Skydel will go through an additional state called Sync Start Time. In this state, Skydel will poll the timing receiver to retrieve the current time and set the simulation start time to align the GNSS RF Signal with the GPS timing receiver time.
The GPS timing reveiver must be configured in the preferences. |
6.4. Trigger (USRP X300 AUX I/O)
When using a X300, Skydel can take advantage of its GPIO to emit a trig signal. To do so, download the Safran GPIO trigger library that matches your operating system from the Skydel Driver/Firmware Page.
This library was made using Safran’s GPIO API. This API is available as an option, for more information contact simulationsupport@nav-timing.safrangroup.com. |
You then need to tell Skydel where to find the previously downloaded library in the preferences.

As long as this library is set here, the X300 radio will emit the following signals on its GPIO pins:
Pin 2 will stay high as long as RF is streaming and Pin 3 will be high only for 100ms.
The library source code is available and can be modified to control the pins with very accurate timing. It could be used to generate a 100 PPS signal of to trig event at specific moment during the simulation. The pins can be controlled in real-time or with a precise time stamp.
For pin numbering, refer to ettus documentation.
7. Hardware Selection
This section is for users that purchased the software-only version of Skydel. Users who purchased a turnkey solution automatically receive a properly configured and very powerful computer workstation, a Software-Defined Radio, and all required RF accessories.
There are 4 basic components to consider when building your simulator:
-
the Software-Defined Radio (SDR) model;
-
a Reference Clock and PPS generator (optional);
-
a computer.
If necessary, please contact simulationsupport@nav-timing.safrangroup.com for a detailed BOM to build your own simulator.
7.1. Software-Defined Radio
The first item to select is the Software-Defined Radio. The selection of other components will ultimately depend upon your choice of SDR.
The choice of an SDR model depends on your simulation requirements. Moreover, if you wish to repurpose your SDR for other uses, you should consider other characteristics such as central frequency range, output power level, community support, etc.
The SDR models currently supported by Skydel are as follows:
-
Ettus N310
-
Ettus X300/X310 or NI USRP-294xR/295XR
-
Dektec DTA-2115B
-
Dektec DTA-2116
Here’s a quick chart comparing Skydel-supported SDR:
Ettus N310 | Ettus X300/X310 NI USRP-294xR/295xR |
Dektec DTA-2115B | Dektec DTA-2116 | |
---|---|---|---|---|
Number of RF Outputs |
4 |
2 |
1 |
1 |
Frequency Range |
10 to 6000 MHz |
UBX: 10 to 6000 MHz |
32 to 2186 MHz |
32 to 3225 MHz |
Max Bandwidth per Output |
100 MHz |
160 MHz |
72 MHz |
100 MHz |
Reference Clock |
10 MHz |
10 MHz |
10 MHz |
10 MHz |
PPS Synchro |
Yes |
Yes |
Yes |
Yes |
MIMO Operation |
Yes |
Yes |
Yes |
Yes |
DAC Resolution |
14 bits |
16 bits |
14 bits |
16 bits |
Data Link |
10 GbE |
10 GbE |
PCIe 1x 3.0 |
PCIe gen3 x4 |
Operating System |
Linux / Windows |
Linux / Windows |
Linux / Windows |
Linux / Windows |
The frequency range specified here is for the Ettus SDR with UBX daughterboard. Other RF daughterboards have different frequency ranges. See the Ettus website for options and specifications www.ettus.com/product-categories/rf-daughterboards↗. |
Skydel limits the maximum bandwidth to provide 100% reliable streaming. SDR may be capable of higher bandwidth for other applications. |
7.1.1. Accessories
7.1.1.1. Requirements for Ettus N310
7.1.1.1.1. 10 GbE Cable
You will need to order a 10 GbE cable, as none are provided with the SDR.
When paired with Intel X520-DA2 PCIe card: the cable should be SFP+ terminated on both ends. See www.ettus.com/product/category/Cables↗.
When paired with Intel X550-T2 PCIe card: the cable should be RJ45 terminated on both ends. The cable must be Cat6A or better. A RJ45 to SPF+ adapter must be connected inside the n310 device. We recommend the 10Gtek ASF-10G-T model 10Gtek ASF-10G-T.
7.1.1.2. Requirements for Ettus X300/X310
7.1.1.2.1. Daughterboards
You will need to order 2 daughterboards for your SDR. Basically, the daughterboards contain the analog components of the SDR. We strongly recommended using Ettus UBX-160 daughterboards, as they include an RF shield and cover a larger range of frequencies. See the Ettus website www.ettus.com/product-categories/rf-daughterboards↗ for a complete list of daughterboards from Ettus.
7.1.1.2.2. 10 GbE Cable
You will need to order a 10 GbE cable, as none are provided with the SDR.
When paired with Intel X520-DA2 PCIe card: the cable should be SFP+ terminated on both ends. See www.ettus.com/product/category/Cables↗.
When paired with Intel X550-T2 PCIe card: the cable should be RJ45 terminated on both ends. The cable must be Cat6A or better. A RJ45 to SPF+ adapter must be connected inside the n310 device. We recommend the 10Gtek ASF-10G-T model 10Gtek ASF-10G-T.
7.1.1.3. Requirements for National Instruments USRP-294xR/USRP-295xR
When ordering SDR from National Instruments, you will receive a device with integrated daughterboards. You only need to order a 10 GbE cable, which is recommended and can be ordered from the National Instruments’ website.
7.1.1.4. Requirements for Dektec DTA-2115B and DTA-2116
IQ streaming option: "DTC-371-IQ" option is required.
7.2. Reference Clock and PPS generator
In order to execute an accurate GNSS simulation, your SDR requires a precise reference clock. This section review various timing options available depending on the SDR model in use. Note that if you require more than one SDR in your simulation scenario (MIMO operation), each SDR will need to share the same 10 MHz reference clock and have a common Pulse Per Second (PPS) signal in order to be synchronized.
Below is a list of external clocks that have been successfully tested with the various SDRs supported by Skydel.
Ettus OctoClock-G NI CDA-2990 | Safran CDM-5 | |
---|---|---|
![]() |
![]() |
|
Number of ports* |
8 |
5 |
10 MHz |
Yes |
Yes |
PPS |
Yes |
Yes |
Form Factor |
External |
PCIe card |
Manufacturer Website |
-
The number of ports lists the available channels, thus the total number of concurrent SDR in MIMO operation.
7.2.1. Ettus X300/X310; National Instruments USRP-294xR/USRP-295xR
- Option 1 - External Reference Clock
-
You can use any 10 MHz reference clock with a precision of 200 ppb or better. Simply connect it to the REF IN port of your SDR.
- Option 2 - Internal GPSDO
-
You can add an internal 10 MHz reference clock inside the device itself. This add-on board is called the GPSDO Kit and contains a 10 MHz OCXO reference oscillator. www.ettus.com/product/details/GPSDO-MINI↗
NI USRP-295xR devices come out of the box equipped with a GPSDO. However, you must consider option 3 for MIMO operations with this device. |
- Option 3 - External Clock with Multiple SDR
-
If your planned setup includes more than one SDR (MIMO operation), you will need an external reference clock with multiple ports, such as this model.
7.2.2. Ettus N310
- Option 1 - External Reference Clock
-
You can use any 10 MHz reference clock with a precision of 200 ppb or better. Simply connect it to the REF IN port of your SDR.
- Option 2 - Internal GPSDO
-
The Ettus N310 includes an internal GPSDO, which hosts a 10 MHz OCXO reference oscillator. www.ettus.com/product/details/GPSDO-MINI↗
- Option 3 - External Clock with Multiple SDR
-
If your planned setup includes more than one SDR (MIMO operation), you will need an external reference clock with multiple ports, such as this model.
7.2.3. Dektec cards (DTA-2115B or DTA-2116)
An external reference clock is required when using a single Dektec card: the onboard reference clock is not precise enough for GNSS simulation. Safran’s CDM-5 is a PCIe card that fits alongside a DTA-2115B or DTA-2116 in a PC. Consult the external reference clock table.
7.2.3.1. Multiple Dektec cards
If your planned setup includes more than one SDR (MIMO operation), you will need an external reference clock with multiple ports, such as this model.
7.3. RF Accessories
A handful of RF accessories are required in order to connect the SDR to your GNSS receiver (DUT). See Simulator Hardware Components for more information on how these accessories are connected.
7.3.1. Attenuators

The RF signal power level output by the SDR is much stronger than the real live sky signal would be when it reaches the GNSS receiver’s antenna. Consequently, Safran strongly recommends using attenuators between the SDR and the GNSS receiver to avoid damaging your GNSS receiver. |
Ettus N310 | Ettus X300/X310 NI USRP-294xR/295xR |
Dektec DTA-2115B | Dektec DTA-2116 | |
---|---|---|---|---|
Attenuation Required |
40 dB |
60 dB |
30 dB |
30 dB |
7.3.2. DC-Block

A DC-Block is a simple component that prevents the DC voltage from travelling back from the GNSS receiver to the SDR. Typically, GNSS receivers will provide DC voltage (5 V to 12 V) to the antenna in order to power the antenna’s amplifier. However, when using a simulator, this DC voltage is useless and could damage the SDR.
We strongly recommend using a DC-Block, even if your GNSS receiver can be configured to stop providing DC at the antenna. |
7.3.3. RF Signal Combiner

When your simulation setup has more than 1 RF output, a RF signal combiner is required to combine the RF signals into a single RF cable.
For a 2 RF outputs system, we recommend the ZAPD-2-272-S+ RF signal combiner from Mini-Circuits.
For a 4 RF outputs system, we recommend the ZN4PD-272+ RF signal combiner from Mini-Circuits.
7.4. Computer
While it is important to select a computer based on your GNSS simulation requirements, you may also want to acquire a computer for uses that go beyond the scope of this manual.
7.4.1. Minimal Computer Requirements
The components listed in the following table are required to run a basic simulation: 12 satellites with only a single GNSS signal each. While this kind of simulation scenario is enough to cover most use cases for most users, the following section offers a future-proof list of recommended components.
Component | Minimal Requirement |
---|---|
CPU |
Intel Core i5, 3rd generation |
RAM |
8 GB DDR3 |
Storage |
4 GB free space. We strongly recommend having at least 10% of free space on the O/S drive. |
GPU |
Nvidia GeForce, Quadro or Tesla |
Network Card 1 GbE |
Intel PRO/1000 CT Desktop Gigabit |
Network Card 10 GbE |
Intel X550-T2 |
7.4.2. Recommended Computer
The following configuration is recommended for 4-constellation, dual frequency simulation. If you have advanced simulation use cases such as RTK or multi-element antenna, please contact Safran Trusted 4D Canada support for detailed information on an appropriate setup.
Component | Recommended Manufacturer and Model |
---|---|
Motherboard |
ASUS Prime Z490-P |
CPU |
Intel Core i7 10700K or better |
RAM |
16 GB DDR4 |
Storage |
Samsung 970 Evo NVMe PCIe M.2 250 GB |
GPU |
Nvidia GeForce RTX 3070 |
Network Card 1 GbE |
Intel PRO/1000 CT Desktop Gigabit |
Network Card 10 GbE |
Intel X520-DA2 (E10G42BTDA) or Intel X550-T2 |
8. Simulator Hardware Components
This section is for users that purchased the software-only version of Skydel, and describes how to connect the different hardware components that compose a Skydel-based simulator. Different scenarios are shown below, depending upon the SDR available and the simulation’s requirements. For details on how to load FPGA firmware, see Firmware Programming.
8.1. Ettus N310
8.1.1. Single Radio: 1 to 4 RF Outputs

Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
Connect a 10 GbE cable (SFP+ terminated) between the computer’s Intel 10 GbE card (any port) and the SDR’s port 1 (do not use port 0).
-
Optionally, connect an external 10 MHz reference clock to the EXT REF port of the N310.
-
Connect the N310 ports “RF 0/1/2/3, TX/RX” to the 4:1 RF combiner with shielded RF cables.
-
Connect the combiner to the 40 dB attenuators with a shielded RF cable.
-
Connect the 40 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
Only one instance of Skydel can communicate with one N310 radio. It is not possible to have 2 Skydel instances communicating with one N310 radio. |
8.2. Ettus X300/X310; National Instruments USRP-294xR/USRP-295xR
8.2.1. Single Radio: 1 or 2 RF Outputs

Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
Connect a 10 GbE cable (SFP+ terminated) between the computer’s Intel 10 GbE card (any port) and the SDR’s port 1 (do not use port 0).
-
If your SDR does not have an internal GPSDO, connect an external 10 MHz reference clock to the EXT REF port of the SDR.
-
-
Connect the SDR port “RF A, TX/RX” to the 2:1 RF combiner with a shielded RF cable.
-
Connect the SDR port “RF B, TX/RX” to the 2:1 RF combiner with a shielded RF cable.
-
Connect the combiner to the 60 dB attenuators with a shielded RF cable.
-
Connect the 60 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
Only one instance of Skydel can communicate with one radio. It is not possible to have 2 Skydel instances communicating with one radio. |
8.2.2. Dual Radio: 4 RF Outputs

This simulator configuration is required when your GNSS signals combination is not possible on 2 RF Outputs (ex: Simulating GPS L1, L2 and L5).
Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
Connect the two 10 GbE cables (SFP+ terminated) between the computer’s Intel 10 GbE card and the SDR port 1 (do not use port 0).
-
For each SDR:
-
Connect one of the 10 MHz OUT ports of the OctoClock-G to the EXT REF port of the SDR.
-
Connect one of the PPS OUT ports of the OctoClock-G’s to the PPS IN port of the SDR.
-
Connect the SDR port “RF A, TX/RX” port to the 4:1 RF combiner, using a shielded RF cable.
-
Connect the SDR port “RF B, TX/RX” port to the 4:1 RF combiner, using a shielded RF cable.
-
-
Connect a shielded RF cable between the combiner and the 60 dB attenuators.
-
Connect the 60 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
8.2.3. Dual Radio - Multi-instance (RTK)

This simulator configuration is required when you want to synchronize the simulated GNSS signals for 2 different antennas connected to 2 different GNSS receivers. With this configuration, each antenna receives the RF signal from a single X300 (1 or 2 RF output) SDR.
Starting from the computer (PC):
-
For each computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
Connect a 10 GbE cable (SFP+ terminated) between the computer’s Intel 10 GbE card (any port) and the SDR’s port 1 (do not use port 0).
-
-
For each SDR:
-
Connect one of the 10 MHz OUT ports of the OctoClock-G’s to the REF IN port of the SDR.
-
Connect one of the PPS OUT ports of the OctoClock-G’s to the PPS TRIG IN port of the SDR.
-
Connect a shielded RF cable between the SDR port “RF A, TX/RX” port and a 2:1 RF combiner.
-
Optionally, for each SDR: connect a shielded RF cable between the SDR port “RF B, TX/RX” port and the 2:1 RF combiner.
-
-
-
For each GNSS receiver:
-
Connect a shielded RF cable between the combiner and the 60 dB attenuators.
-
Connect the 60 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
-
It is feasible to use a single computer to control both radios. With the multi-instance option activated, you can run 2 instances of Skydel, one for each radio. Depending on the number of simulated signals, using 2 computers may be necessary. |
8.3. GPS Timing Receiver
Skydel makes it possible to synchronize the simulation start time with the live GPS signal by using a GPS timing receiver. In general, this connection is required for users wishing to test anti-spoofing algorithms.
This feature is only available with Ettus or Dektec devices, because the simulation start must be synchronized with a hardware Pulse Per Second (PPS). |
8.3.1. OctoClock-G
The Ettus OctoClock-G timing reference and distribution system can be used as a GPS timing receiver.
-
Connect the GPS ANT INPUT of the OctoClock-G to your GNSS antenna. The GNSS antenna must be positioned to receive the live GPS signal from the sky (either outside, or very close to a window).
-
Connect the Ethernet port of the OctoClock-G to a 1GbE Ethernet port on the computer (PC).
-
For each SDR in your system, connect one PPS OUT port on the OctoClock-G to the PPS IN port of the SDR.
The firmware of the OctoClock-G must be recent enough to support Ethernet communication. See Ettus OctoClock and OctoClock-G Firmware to learn how to reprogram it. |
To establish the connection between Safran Skydel and the OctoClock-G, refer to the GPS Timing Receiver section. |
8.3.2. Generic GPS Timing Receiver
You can also use any other type of GPS timing receiver, as long as it can:
-
send a PPS pulse to each SDR in your system, and
-
send NMEA data on a serial port (required sentences are "$GPGGA" and "$GPRMC").
Connection steps:
-
Connect the serial port of the GPS timing receiver to a serial port on the computer (PC). Typically, you can also use a USB port if you have a serial-to-USB cable.
-
For each SDR in your system, connect the PPS OUT port of the GPS timing receiver to the PPS IN port of the SDR.
To establish the connection between Safran’s Skydel and your GPS timing receiver, refer to GPS Timing Receiver in the Using Skydel section. |
8.4. Dektec SDR Cards
This section applies to both supported Dektec cards: the DTA-2115B and the DTA-2116.
When using Dektec cards, please note that Skydel does not support using mixed Dektec models for the same simulation. For example, a DTA-2115B cannot be used alongside a DTA-2116. In the examples below using multiple Dektec cards, they must all be similar models per simulation. |
8.4.1. Single Radio: 1 RF Output

Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
Connect the reference clock:
-
Connect one of the 10 MHz OUT ports of the reference clock to the 10M port of the Dektec card.
-
Connect one of the PPS OUT ports of the reference clock to the 1pps port of the Dektec card.
-
-
Connect a shielded RF cable between the SDR port “RF” and 30 dB attenuator.
-
Connect the 30 dB attenuator to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
8.4.2. Multiple Radios: Multiple RF Outputs

This simulator configuration is required when your GNSS signals combination requires multiple RF Outputs in order to transmit at difference central frequencies (ex: Simulating GPS L1, L2 and L5).
Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
For each Dektec card:
-
Connect one of the 10 MHz OUT ports of the reference clock to the 10M port of the Dektec card.
-
Connect one of the PPS OUT ports of the reference clock to the 1pps port of the Dektec card.
-
Connect shielded RF cables between the Dektec’s port “RF” port and a RF combiner; connect a shielded RF cable between the combiner and the 30 dB attenuator.
-
-
Connect the 30 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
8.4.3. Multiple Radios - Multi-instance (RTK)

This simulator configuration is required when you want to synchronize the simulated GNSS signals for 2 different antennas connected to 2 different GNSS receivers. This configuration uses a single computer to control all radios. With the multi-instance option activated, you can run 2 instances of Skydel, one for each radio pair.
Starting from the computer (PC):
-
Connect the Safran USB license dongle to any USB port of the computer.
-
For each Dektec card:
-
Connect one of the 10 MHz OUT ports of the reference clock to the 10M port of the Dektec card.
-
Connect one of the PPS OUT ports of the reference clock to the 1pps port of the Dektec card.
-
Connect a shielded RF cable between the Dektec “RF” port and a combiner.
-
-
For each GNSS receiver:
-
Connect a shielded RF cable between the combiner and the 30 dB attenuator.
-
Connect the 30 dB attenuators to a DC-Block.
-
Connect the DC-Block to the antenna port of the GNSS receiver.
-
9. Software Installation
This section is for users that purchased the software-only version of Skydel. Users who purchased a turnkey solution will already have their software, OS, and drivers properly configured.
9.1. Firmware Programming
9.1.1. Ettus N310 Firmware (File system and FPGA image)
Safran Skydel requires a very specific version of the N310 file system and FPGA (UHD Version 3.13.1.0). Before using Skydel for the first time, you must update your N310 device with this version of File system and FPGA.
9.1.1.1. Programming Under Linux Ubuntu
Safran provides a zip package to prepare a N310 device to be used with Skydel. The instructions are written in a ReadMe file, contained in the install zip package. The package can be found in the users "drivers and firmwares" page under "N310 Setup" using the following link: users.skydelsolutions.com/drivers-and-firmwares↗.
9.1.2. Ettus X300/X310; NI USRP-294xR/295xR Firmware (FPGA image)
Safran Skydel requires a very specific version of the FPGA image for those devices. Before using Skydel for the first time with your device, you must burn this specific image into your device.
If you are not familiar with the reprogramming of this device, Safran provides a simple “FPGA programming tool” for Windows to perform this task.
Why does Safran Skydel require this specific version?
GNSS signal simulation has a very important requirement: the RF signal transmission must never be interrupted. The absence of a single I/Q sample will introduce error into the carrier phase, thus making the whole simulation too imprecise for GNSS receiver testing.
To achieve an uninterrupted RF signal, the SDR must have a buffer of I/Q samples. The buffer must be large enough to mitigate interruptions in the I/Q sample transmission between the software and the SDR. Interruptions can have many causes (e.g., O/S scheduler, hardware interrupts, communication link errors, etc.).
To ensure a steady stream of I/Q samples, Safran Skydel requires a special FPGA image from Ettus that uses the onboard DDR RAM as a streaming buffer; this flavor of FPGA image is called “HG” image. This FPGA image will only work with the corresponding UHD (aka USRP Hardware Driver) included with Skydel. If you want to use or compile this version of UHD on your own, please contact Safran Trusted 4D Canada at simulationsupport@nav-timing.safrangroup.com and we will gladly guide you through the compiling process.
9.1.2.1. Programming Under Windows
- Step 1
-
Download our "FPGA programming tool" from the Skydel Driver/Firmware Page.
Make sure to download the FPGA programming tool for your device. Using the X300 FPGA Tools for a X310 or the X310 FPGA Tools for a X300 will brick your device. |
- Step 2
-
Connect your X300 to the computer. You can use either a 1 GbE or 10 GbE Ethernet connection to burn the FPGA image.
-
1 GbE: Use the SFP adapter to connect a regular Ethernet cable between the device’s port 0 and your computer’s network card. Your network card should have a static IP Address of 192.168.10.1. Once connected, power on the SDR.
-
10 GbE: Connect a 10GbE cable (SFP+ terminated) between the SDR’s port 1 and your computer’s 10 GbE card. Your network card should have a static IP Address of 192.168.40.1. Once connected, power on the SDR.
-
- Step 4
-
Verify that you can ping your SDR. Typically, when connecting with 1 GbE, the IP address of the SDR is 192.168.10.2 and when connecting with 10 GbE, the IP address is 192.168.40.2. If you can’t ping your SDR, verify the static IP address of your network card and your cable connections.
C:\Users\Skydel\Downloads\X300-UHD-3.13.1.0>ping 192.168.40.2 -n 4 Pinging 192.168.40.2 with 32 bytes of data: Reply from 192.168.40.2: bytes=32 time=1ms TTL=32 Reply from 192.168.40.2: bytes=32 time<1ms TTL=32 Reply from 192.168.40.2: bytes=32 time=1ms TTL=32 Reply from 192.168.40.2: bytes=32 time=1ms TTL=32 Ping statistics for 192.168.40.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
- Step 5
-
Verify the IP address in the FPGA programming tool batch file: edit the file
update-x300-fpga.bat
file (or theupdate-x310-fpga.bat
file for a X310 model SDR). Make sure that line #2 has the correct IP address of your device. - Step 6
-
Execute the batch file. Either open a command prompt in the folder where you extracted the FPGA programming tool, or double-click on the
update-x300-fpga.bat
file. You should see the following:
C:\Users\Skydel\Downloads\X300-UHD-3.13.1.0>update-x300-fpga.bat Are you Ready to Update X300's FPGA at address: 192.168.40.2 ? Press any key to continue . . . WARNING: MAKE SURE YOUR DEVICE IS A ETTUS X300. WARNING: DO NOT CONTINUE IF YOUR DEVICE IS A ETTUS X310 or NI USRP-294x or USRP-295x. Press any key to continue . . . Win32; Microsoft Visual C++ version 12.0; Boost_105500; UHD_003.010.git-89-gb17b440d Unit: USRP X300 (310EE4A, 192.168.40.2) FPGA Image: C:\Users\Skydel\Downloads\X300-UHD-3.13.1.0\usrp_x300_fpga_HG.bit -- Initializing FPGA loading...successful. -- Loading HG FPGA image: 100% (87/87 sectors) -- Finalizing image load...successful. Press any key to continue . . .
Once the programming is complete, you will need to power-cycle your device to enable it to load the new FPGA image. |
9.1.2.2. Programming Under Linux Ubuntu
- Step 1
-
Download the FPGA image for Skydel from the Skydel Driver/Firmware Page.
Make sure to download the FPGA programming tool for your device. Using the X300 FPGA Tools for a X310 or the X310 FPGA Tools for a X300 will brick your device. The tools include libuhd.so.003.013, libuhd.so.003, libuhd.so, usrp_x3xx_fpga_burner and fpga_burner.sh. |
- Step 2
-
Connect your X300 to the computer. You can use either a 1 GbE or 10 GbE Ethernet connection to burn the FPGA image.
-
1 GbE: Use the SFP adapter to connect a regular Ethernet cable between the device’s port 0 and your computer’s network card. Your network card should have a static IP Address of 192.168.10.1. Once connected, power on the SDR.
-
10 GbE: Connect a 10GbE cable (SFP+ terminated) between the SDR’s port 1 and you computer’s 10 GbE card. Your network card should have a static IP Address of 192.168.40.1. Once connected, power on the SDR.
-
- Step 3
-
Verify that you can ping your SDR. Typically, when connecting with 1 GbE, the IP address of the SDR is 192.168.10.2; when connecting with 10 GbE, the IP address is 192.168.40.2. If you can’t ping the SDR, verify the static IP address of your network card and your cable connections.
serge@SKYDEL-PROTO-U16:~$ ping 192.168.40.2 -c 4 PING 192.168.40.2 (192.168.40.2) 56(84) bytes of data. 64 bytes from 192.168.40.2: icmp_seq=1 ttl=32 time=0.345 ms 64 bytes from 192.168.40.2: icmp_seq=2 ttl=32 time=1.26 ms 64 bytes from 192.168.40.2: icmp_seq=3 ttl=32 time=0.645 ms 64 bytes from 192.168.40.2: icmp_seq=4 ttl=32 time=0.378 ms - - - 192.168.40.2 ping statistics - - - 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.345/0.658/1.265/0.369 ms serge@SKYDEL-PROTO-U16:~$
- Step 4
-
Burn the FPGA image. Go to the folder where you have downloaded the FPGA image, and execute the command
sh fpga_burner.sh 192.168.40.2 usrp_x300_fpga_HG.bit
. You should see the following:
serge@SKYDEL-PROTO-U16:~$ cd Downloads/ serge@SKYDEL-PROTO-U16:~/Downloads$ sh fpga_burner.sh 192.168.40.2 usrp_x300_fpga_HG.bit linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.013.git-89-gb17b440d Attempting to find X3x0 with IP address: 192.168.40.2 Found X300 (HG). ************************************************************************************************ WARNING: This utility will be removed in an upcoming version of UHD. In the future, use this command: uhd_image_loader --args="type=x300,addr=192.168.40.2,fpga=HG" ************************************************************************************************ Burning image: usrp_x300_fpga_HG.bit Progress: 100% (87/87 sectors) Attempting to find device...found! Successfully burned FPGA image! Power-cycle the USRP X300 to use the new image. serge@SKYDEL-PROTO-U16:~/Downloads$
Once the programming is complete, power-cycle your device to load the new FPGA image. |
9.1.2.3. Unbricking Procedure
If you accidentally burn the wrong FPGA image to your device, or if the programming of the FPGA image was interrupted, the device will probably be “bricked”. At this point, it will probably be impossible to reprogram the FPGA image via the 1 GbE or 10 GbE connection.
Don’t panic! You can unbrick your device by reprogramming the FPGA image with the JTAG port. Here’s a simple procedure to unbrick your device under Windows.
- Step 1
-
Connect the device JTAG port to the PC with a USB Type B cable.
- Step 2
-
Download Digilent Adept System
adept/digilent.adept.system_v2.16.1.exe
from the Skydel Driver/Firmware Page. - Step 3
-
Download our "FPGA programming tool" from the Skydel Driver/Firmware Page.
Make sure to download the FPGA programming tool for your device. Using the X300 FPGA Tools for a X310 or the X310 FPGA Tools for a X300 will brick your device. Unzip the downloaded file. |
- Step 4
-
Install Digilent Adept System.
- Step 5
-
Start Digilent Adept System. You should see the following screen (example shown for the X300):

- Step 6
-
Select the FPGA image file to program into the FPGA. The FPGA image file is included in the folder downloaded in Step 3.
For Ettus X300 SDR use this file: For Ettus X310 SDR or NI USRP-294xR/295xR use this file: |
- Step 7
-
Click the Program button.
- Step 8
-
Ping the device. Make sure the device is connected to your PC with an Ethernet cable (1GbE on port 0, or 10GbE on port 1). Open a command prompt, and try to ping the device. Normally, the device should now respond.
For the 1 GbE (port 0), ping 192.168.10.2 For the 10 GbE (port 1), ping 192.168.40.2 |
- Step 9
-
At this point, the device is using the new FPGA image. However, we still need to write this new FPGA image to a flash memory of the device. In the unzipped FPGA programming tool, you will find a .bat file that you can use to write the image to the device flash memory. For the Ettus X300, execute the
update-x300-fpga.bat
file. For the Ettus X310 or NI USRP-294xR/295xR, execute theupdate-x310-fpga.bat
file.
9.1.3. Ettus OctoClock and OctoClock-G Firmware
The Ettus OctoClock is used for 2 different use cases within Safran Skydel:
-
As a common 10 MHz reference clock and PPS generator when using multiple SDR. In this case, any version of the OctoClock/OctoClock-G firmware can be used. This also means that there is no need to reprogram the OctoClock or OctoClock-G firmware for this use case.
-
As a GPS Timing receiver, in order to align the simulation’s start time with the live GPS signal. In this case, you absolutely need to use an OctoClock-G device. It is also necessary to install a firmware version that is able to communicate with the computer via Ethernet; only the latest versions of the firmware enable this. See section GPS Timing Receiver to learn how to configure Skydel to communicate with the OctoClock-G. In the case where your OctoClock-G cannot communicate with Skydel, you can find the bootloader/firmware update procedure on the Ettus website at files.ettus.com/manual/page_octoclock.html↗
With the OctoClock device (without an internal GPSDO), you will need to provide an external 10 MHz reference clock and an external PPS generator. Only the OctoClock-G is equipped with an internal GPSDO. |
The update procedure for the OctoClock-G will void its warranty. It requires the use of additional hardware (Pocket AVR Programmer) available from a variety of vendors. |
Here are a few tips to complete the procedure.
Get an AVR programmer. We recommend using the Sparkfun Pocket AVR programmer, model PGM-09825. |
Connect the AVR programmer to the OctoClock-G. Here’s how the Pocket AVR programmer connects to the OctoClock-G’s JTAG connector: ![]() |
Ensure that power is not being supplied from the Pocket AVR Programmer (make sure that the power DIP switch setting on the Pocket AVR Programmer is OFF). |
9.1.4. Computer BIOS
We strongly recommend that you modify the following settings in your BIOS:
-
disable Intel SpeedStep;
-
disable Intel Turbo Boost.
These settings need to be disabled in order to force the CPU to always run at the same frequency. Otherwise, it can cause the communication link between the computer and SDR to become unstable as the CPU frequency changes. This can, in turn, lead to interruptions in the GNSS signal transmission.
9.2. Software Configuration
9.2.1. Linux Ubuntu
Supported versions:
-
Ubuntu 18.04 LTS
-
Ubuntu 20.04 LTS
Only Ubuntu 18.04 and 20.04 LTS are supported. Do not update the Ubuntu Operating system to Ubuntu 22.04 LTS. |
You can perform Ubuntu 18.04 and 20.04 LTS package updates with the following commands. This will ensure you get the most recent Ubuntu security patches, and assure packages are upgraded in consisten maner: |
sudo apt update sudo apt dist-upgrade
9.2.1.1. General Parameters
- Screen Brightness & Lock
-
Set “Turn screen off when inactive for” to “Never”. This will avoid interrupting the simulation when there is no user interaction with the computer.

- Real-Time Priority of Threads
-
Safran Skydel uses processing threads that need to run at the “real-time” priority level. In order to use this priority level, the Linux user must have rights to change the thread priorities. With root rights, edit the file
/etc/security/limits.conf
, and add the following line:
<username> - rtprio 99
- Dialout Group
-
Skydel can be connected to a GNSS receiver through a serial port in order to get the NMEA data. To be able to access the serial port, the Linux user needs to be in the
dialout
Linux group. You can add the user to this group by executing this command in a terminal window:
usermod -a -G dialout $USER
9.2.1.2. Nvidia GPU Driver
The installed Nvidia graphics card driver must support CUDA Runtime API 11.6.2 or higher. The Nvidia driver version must be 510.47.03 or higher.
For Ubuntu 18.04 and 20.04, Safran recommends using the "Nvidia propietary driver", which can be installed from Ubuntu’s "Software & Updates." See below. |
9.2.1.2.1. Nvidia GPU Driver for Ubuntu 18.04 and 20.04 (Automatic)
- Step 1
-
Ensure that your Ubuntu system is connected to the Internet.
- Step 2
-
Add ppa:graphics-drivers/ppa repository to apt. Execute the following commands:
sudo apt-add-repository ppa:graphics-drivers/ppa sudo apt update
- Step 3
-
Open Ubuntu’s "Software & Updates" window from Ubuntu’s "System Settings". Click on the "Additional Drivers" tab.

- Step 4
-
Select "Using NVIDIA binary driver", and click "Apply changes". Once the installing is completed, reboot the computer such that the new driver is used by Ubuntu.
If you previously manually installed a Nvidia driver, you might be unable to select the "Using NVIDIA binary driver". In that case, you can execute the next alternate steps |
- Alternate Step 4a
-
Execute the following command:
sudo ubuntu-drivers devices
- Alternate Step 4b
-
From the output of the command, locate a line showing "driver : nvidia-xxx", where xxx is the Nvidia driver version. Then, execute the next command:
sudo apt-get install nvidia-xxx
- Alternate Step 4c
-
Reboot the computer. The nvidia-xxx driver will now be used.
Nvidia drivers are frequently updated. If the above procedure is not successful, please refer to the Skydel user forum. If you are still unable to find a solution, we encourage you to post your question/issue on the forum for a prompt response. |
Additional Resource |
9.2.1.3. Network Card Driver: 10 GbE Intel X520-DA2
Only required to operate Ettus X300/X310; NI USRP-294xR/295xR SDR.
- Update the Driver
-
For 18.04 and 20.04 LTS, the driver installed by default is perfectly functional; there is no need to update it.
- Configure Network Parameters
-
Open the Network Configuration Settings window and edit the settings of the network card connected to the USRP device:
-
set the “MTU” size to 9000;
-
in the IPv4 settings, set a static IP address: Address=192.168.40.1; Netmask=255.255.255.0; Gateway=0.0.0.0
-
the computer must be configured to use the maximum socket buffer size: With root rights, edit the /etc/sysctl.conf file, and add the following lines:
-
net.core.rmem_max=33554432 net.core.wmem_max=33554432
To ensure that changes are applied, perform a logoff/logon of the Ubuntu user. |
9.2.1.4. Dektec Drivers
You can find the Dektec drivers for the DTA-2115B and DTA-2116 on Dektec’s web site. www.dektec.com/downloads/SDK↗ The Dektec drivers are included in the "Linux SDK" package. Simply follow the instructions included with the download, in order to compile and install the driver.
Please note that if you update the Ubuntu kernel of your system, you will need to re-compile and re-install it again.
9.2.1.5. Safran Skydel Installation
Before installing Skydel, make sure you remove any previous version(s) by executing the following command:
sudo dpkg -r skydel-sdx
To install the new version of Skydel, execute the following commands (note: rename the .deb file name according to the version that you want to install):
sudo dpkg -i skydel-sdx-YY.MM.X-HHHHHHH.deb sudo apt-get install -f
The second command will install any missing dependencies required by Skydel. Usually, the missing dependencies are libboost, libblas-common, libblas3, libgfortran3, libgstreamer-plugins-base0.10-0, and libgstreamer0.10-0 liblapack3.
skydel-sdx will be installed in /usr/bin
.
All libraries will be installed in /usr/lib/skydel-sdx
.
After having started Skydel for the first time, you will find a Skydel-SDX folder inside your Documents folder. See the Skydel-SDX Folder section for a detailed explanation of each folder’s contents.
9.2.2. Microsoft Windows
Microsoft Windows supported versions:
-
Windows 10 Home and Pro.
9.2.2.1. General Parameters
- Power Plan
-
Open the Control Panel, Power Options, and click "Show additional plans".
-
Select the "High Performance" power plan.
-
Click on "Change plan settings", and set "Display turning off time" to "Never".
-
- Monitor
-
Always leave the monitor turned ON during a GNSS simulation. Windows is able to detect if a monitor is turned ON or OFF. When the monitor is turned OFF, Windows may reduce the GPU’s performance, which can lead to simulation errors (e.g., streaming buffer under-run).
- Registry key: FastSendDatagramThreshold
-
Only required to operate Ettus or NI SDR. Open the Windows Registry with the regedit tool:
-
add or modify the DWORD Registry Key FastSendDatagramThreshold under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AFD\Parameters\;
-
make sure the value is 9000 (decimal);
-
reboot, as this is required for changes to take effect.
-
- Notifications (Windows 10)
-
During GNSS simulation, it is strongly recommended to turn off all Windows notifications to avoid interruptions. To do so, open the Action Center, and turn on "Quiet hours".
9.2.2.2. Nvidia GPU Driver
The installed Nvidia graphics card driver must support CUDA Runtime API 11.6.2 or higher. Make sure your computer is using the latest WHQL-certified Nvidia GPU driver(511.65 or higher). You can download the latest version at the Nvidia website www.nvidia.com/drivers↗.
9.2.2.3. Network Card Driver: 10 GbE Intel X520-DA2
Only required to operate Ettus X300/X310; NI USRP-294xR/295xR SDR.
Download and install the latest version from Intel’s website.
- Jumbo Packets
-
Open the Control Panel, Networking and Sharing Center, then Change Adapter Settings. Right-click on the adapter connected to the SDR and select Properties. Click on Configure, and look for “Jumbo packets” in the Advanced tab:
-
Enable Jumbo packets, and set the size to the maximum value.
-

-
In the Performance options, set Transmit Buffers to the maximum value (16384).

- Static IP Address
-
Open the Control Panel, Networking and Sharing Center, Change Adapter Settings. Right-click on the adapter connected to the SDR and select Properties. Double-Click on Internet Protocol Version 4 (TCP/IPv4):
-
select the radio button "Use the following IP address";
-
IP Address: 192.168.40.1
-
subnet mask: 255.255.255.0
-
9.2.2.4. Dektec Driver
You can find the Dektec drivers for the DTA-2115B and DTA-2116 on Dektec’s web site. www.dektec.com/downloads/SDK↗ The Dektec drivers are included in the "Driver for DTA products" package. Simply follow the instructions included with the download.
9.2.2.5. Safran Skydel installation
Installing Skydel under Windows is relatively straightforward. Double-click the downloaded executable. This will start the installation program:
-
by default, the application will be installed in the folder
C:\Program Files\Skydel
; -
you may select the new Start Menu folder’s name;
-
you may choose to install a desktop icon.
9.2.2.6. Windows Firewall
Skydel needs an exception in Windows Firewall to allow remote computers to connect to it. This is required when Master and Slave are not on the same machine, or when an external software wants to control Skydel through the API.
The first time Skydel is started on a Windows computer, a Windows Security Alert popup should open:

Ensure that your network type is checked (usually Private) and then click Allow access.
If remote connection still doesn’t work, an exception has to be added manually in the firewall. Open the Windows Firewall with Advanced Security:

-
Click on New Rule….
-
On the Rule Type step, select Program.
-
On the Program step, select This program path and input Skydel path (by default
C:\Program Files\Skydel
). -
On the Action step, select Allow the connection.
-
On the Profile step, check the profiles that match your setup.
-
On the Name step, name this rule
skydel-sdx
and click Finish.
9.2.3. Skydel-SDX Folder
Once you have started Skydel for the first time, you will find a “Skydel-SDX” folder inside your Documents folder.
You can customize the location of the Skydel-SDX folder in the Preferences. |
Folder or File | Description |
---|---|
|
Safran Skydel root folder |
|
Remote API open-source libraries and examples |
|
Remote API in C++ |
|
Remote API in C# |
|
Remote API in Python |
|
Remote API documentation |
|
Folder where Skydel scripts (.sdxscript) files are stored |
|
Folder where Skydel configurations are stored |
|
Folder where raw data, NMEA and I/Q sample files are written by Skydel |
|
Folder where Skydel search in order to list all the available plug-ins |
|
Folder where default almanacs and ephemeris are read by Skydel |
|
The Skydel log file. Very useful when requesting assistance from Safran support. |
10. References
10.1. Safran Skydel Download Page
Contact Safran (simulationsupport@nav-timing.safrangroup.com) to get user name and password to access the Skydel download page.
URL |
10.2. Skydel Driver/Firmware Page
This page contains download links for drivers and firmware, which may be required for Skydel operation.
Contact Safran (simulationsupport@nav-timing.safrangroup.com) to get a user name and password for access. Note: This is the same user name and password as for the Safran Skydel Download Page.
URL |
11. Appendix A - Important changes introduced in version 21.3
There are important changes introduced in Skydel version 21.3. Users upgrading from 20.9 or older to 21.3 or newer should read this appendix carefully. |
Until version 20.9, PRN was used as primary key to identify a GNSS satellite. This is replaced in 21.3 with the space vehicle identifier, or SV ID. This method is more robust for several reasons:
-
The SV ID is constant, while the PRN may change.
-
Different signals from the same satellite may use different PRNs.
-
For testing purposes, you may need to assign the same PRN to different satellites which makes the PRN ambiguous.
In many situations, the SV ID and PRN values are the same by default. But for QZSS and SBAS they differ. For QZSS, it may even differ on a signal basis.
Constellation | SV ID | Default PRN |
---|---|---|
GPS |
1-32 |
1-32 |
GLONASS |
1-24 |
1-24 |
GALILEO |
1-36 |
1-36 |
BEIDOU |
1-63 |
1-63 |
SBAS |
1-39 |
120-158 |
QZSS L1S, L5S |
1-10 |
183-192 |
QZSS C/A, L1C, L5 |
1-10 |
193-202 |
NAVIC |
1-14 |
1-14 |
The SV ID used by Skydel is an index. It is not the same as the satellite numbering used in ICDs. For example, GPS will use satellite No. or SVN which has a different meaning. Skydel SV ID is relevant only within Skydel software. |
11.1. SV ID used in the GUI
The first noticeable changes in the GUI are in the settings pages such as GPS>Orbits and in the Constellations subtab as shown in the image below.

In this image, notice 3 important changes:
-
At the top of the screen, the SV ID spin control replaces the PRN spin control. The PRN itself is shown just beside the SV ID. Note the PRN and SV ID have the same value, which is typical for most constellations, but not all of them.
-
At the bottom left of the screen, the power sliders are identified with numbers; these are now SV IDs.
-
At the bottom right in the sky view, the satellites are also numbered with SV IDs but there is a dropdown list where you can switch from SV ID to PRN. Note that showing PRN instead of SV ID will affect only the sky view and not the rest of the GUI.
For GPS, SV ID and PRN use the same value by default. For other constellations, like QZSS, the changes are more consequential. The image below shows the same settings but for QZSS.

This time, we can see at the top of the screen that for SV ID 1, there are different PRNs used. In the sky view, when selecting the PRN in the dropdown list, the tooltip shows the PRN for all QZSS signals.
Another example, where SV ID is used instead of PRN, is where you can actually change the PRN being transmitted for each signal as shown in the following image.

As you can see, SV ID 14 uses different PRNs in this example. It uses PRN 18 for the C/A signal, 15 for L1C, and so on. The power slider still uses the SV ID. This demonstrates the need to use SV ID instead of PRN to avoid confusion.
These changes are visible in the user interface but more importantly, they affect many commands in the API.
11.2. SV ID used in the API
In version 21.3, certain commands were changed to replace PRN with SV ID as the primary key. Older commands are deprecated so they continue to work for backward compatibility, but they will eventually be removed from the API. For new projects, deprecated commands should be avoided.
At the same time that PRN was replaced with the SV ID, some other changes were introduced:
-
Ordering of the parameters was uniformized for better coherency between commands. For example, system always comes before signal and signal always comes before svID.
-
The naming convention also uses the suffix […]ForSV and […]ForEachSV where applicable.
Here are some examples of changes made to the API.
Satellite Power
SetSatellitePower(system, prn, powerOffset, otherSatsFollow) // deprecated SetPowerForSV(system, svId, powerOffset, otherSatsFollow) // new command
Changes:
-
The prn is replaced with svID
-
The name uses the […]ForSV suffix convention
Enable Signal
EnableSignal(prn, signal, enabled) // deprecated EnableSignalForSV(signal, svId, enabled) // new command
Changes:
-
The prn is replaced with svID
-
The name uses the […]ForSV suffix convention
-
The parameter signal comes before svID
Change the transmitted PRN
SetGpsCodePrn(satPrn, transmittedPrn) // deprecated SetTransmittedPrnForSV(svId, signalPrnDict) // new command
In this case, the changes are more significant. It is now possible to change the PRN per signal. The same GPS satellite could use different PRNs for C/A, L1C, L2C, etc.
Also, this command introduces a new parameter type: the dictionary. It is now possible to use multiple key/value pairs; you can set multiple signals with different PRNs using a single command.
Lastly, the word "GPS" was removed from the command name to generalize the concept to all constellations. Here’s an example of the command expressed as a JSON object:
{ "CmdName": "SetTransmittedPrnForSV", "CmdUuid": "{3c9af86c-23f7-4c9c-aab1-6ee4718c14b4}", "SvId": 7, "SignalPrnDict": { "L1C": 7, "L1CA": 8, "L2C": 8, "L5": 7 } }
It is no longer possible to identify a satellite using a PRN alone because it can be duplicated. However, if you want to retrieve the SV ID corresponding to a specific PRN, use the following commands:
GetPrnOfSVID(signal, svId) GetPrnForEachSV(signal)
The command GetPrnOfSVID returns the PRN for a specific signal and satellite, while GetPrnForEachSV returns a vector to return the same information for all satellites.
Skydel ™ Version 23.5.0
© 2023 by Safran Trusted 4D Canada Inc. All rights reserved.
Skydel and the logo of Skydel are trademarks of Safran.
All other company names and products are trademarks or registered trademarks of their respective companies.