Custom Signal

This section explains the integration the Custom Signals Plug-in feature in Skydel.

If you're still using the legacy architecture and haven't yet migrated to plug-ins, please refer to Migration.

The plug-in SDK provides functions that allow users to create their own custom signals and attach them to GNSS satellites so they are streamed alongside standard GNSS signals. It serves as a powerful tool for advanced users looking to design GNSS or non-GNSS signals (such as those from LEO constellations) and evaluate their performance.

The goal of the plug-in SDK is to eliminate the complex task of developing an engine that simulates satellite dynamics, vehicle motion, and associated environmental effects (such as atmospheric delays, multipath, jamming, and spoofing). This allows users to focus entirely on the design and architecture of their custom signal.

The following sections provide essential information on how to integrate custom signals into Skydel, guiding users through the development process. For more details on the specific Custom Signal Factory Role, refer to the dedicated section.

Design

A custom signal is composed of an arbitrary number of subcarriers and codes, with its composition defined in an accompanying XML file. The chips for each code must be supplied by the custom signal plug-in, as illustrated in the figure below. Once the codes are provided, Skydel handles the rest of the signal generation chain.

Custom signal plug-in code chips transmission to Skydel

The IQ samples are generated according to the following equation :

$$sample(t)=A× ∏^C_{i=1}C_i(t)×SC(t)$$

where :

• $A$ a constant (in $ℂ$) multiplication factor

• $C$ the number of codes

• $C_i(t)$ are the code chips value (-1 or 1) defined in the plug-in

• $SC(t)$ the subcarriers defined as:

where :

$$SC(t)=1 \space if \space S=0, \space ∑^S_{j=1}SCj(t) \space otherwise$$

• $S$ the number of subcarriers

• $SC_j(t)$ are the subcarrier Real values defined in the XML file

With this approach, it is possible to generate various GNSS modulation types, such as BPSK(N), BOC(M,N), and MBOC(M,N,P). The example repository contains a set of legacy GNSS signals that demonstrate this capability. These examples use a recording of the Skydel downlink to replay the navigation message and generate the signal chips. Each example is valid for a specific time range, based on the content of the downlink file. You can replace the downlink file to test different configurations. The tracking performance and signal accuracy have been validated using a GNSS receiver.

XML File

As explained in the Design section, the XML file contains configuration information that defines part of the custom signal’s behavior. Below are the details of the information that must be provided in the XML file for Skydel to properly import and interpret the custom signal.

Here's the high level representation of the XML file.

Custom signal XML format

For array types in the XML file, both , and | can be used as delimiter characters.

Custom Signals

This element is mandatory, defines the root of the XML file and will include all the custom signals definition associated with the plug-in.

Multiple custom signals can be defined within the same XML file, provided they are all handled by the same plug-in. For example, the Galileo E1 signal includes two custom signal definitions in a single XML file: one for the E1b component and another for the E1c component.

CustomSignal

This element can appear multiple times, with each instance representing a distinct custom signal. It contains the essential information needed to define the signal’s behavior and properties, allowing it to be added to Skydel’s signal selection.

Below are the mandatory sub-elements that must be specified for each CustomSignal instance.

Parameter	Definition
Name	Custom signal unique identifier, will be used in Skydel GUI and RAPI as a key.
Version	Document interface version, current version is “1.0”.
Constellation	The constellation of the custom signal All constellations are supported except SBAS.
CentralFreq	The central frequency of the custom signal in Hertz.
Bandwidth	The bandwidth of the custom signal in Hertz.

Below are the optional sub-elements that must be specified for each CustomSignal instance.

Parameter	Definition
NavMsg	If missing, it will attempt to get a navigation message from the plug-in. If set to True, it will generate an error if the navigation message is missing from the plug-in.
SignalLevel	Default power offset relative the constellation reference power in dB.
SignalTimeDelays	An array of real numbers representing the delay to be added to a signal in nanoseconds. The size of the array is equal to the number of satellites in the Custom Signal Constellation. For example, For a GPS Custom Signal, if the TGD of a satellite is 5.12 ns, and you want to set an ISC for your Custom Signal of -2.36 ns for this satellite, you need to set the Signal Time Delay of the satellite to TGD - ISC = 7.48 ns. This parameter is not configurable for custom signal on the Glonass constellation.

Subcarrier

The Subcarrier element is optional. As an example, see Galileo E1.

Parameter	Definition
Id	Subcarrier identifier.
Rate	Subcarrier rate in Hertz.
Coef	An array of real numbers representing the subcarrier chip values. For example, a BOC would have the [-1, 1] coefficients. A CosBOC at half power would have the [-0.5, 0.5, 0.5, -0.5] coefficients.

Code

The Code element is optional. As an example, see GPS CA.

Parameter	Definition
Id	Code identifier, can be used to distinguish different custom signals in the same plug-in.

ModulationCoef

The ModulationCoef element is optional. As an example, see Galileo E1.

Parameter	Definition
Real	The real part of the multiplier applied to every sample.
Imag	The imaginary part of the multiplier applied to every sample.

FDMA

The FDMA element is optional. As an example, see Glonass G1.

Parameter	Definition
ChannelOffset	The frequency offset in hertz between channels (SV IDs). This value will be multiplied by the given channel assignation for an SV ID.
Channels	Integer assignations for each channel. Requires as many channels as available SV IDs in the signal's constellation.

GPS CA Example

Here's a digest of the GPS CA custom signal example XML file.

Parameter	Value	Explanation
Name	CustomCa	The custom signal unique name, making sure it's not allready used by Skydel.
Version	1	The current document version.
NavMsg	True	Since the custom signal has a navigation message.
Constellation	GPS	The custom signal is a GPS CA clone, it runs on the GPS constellation.
CentralFreq	1575420000	It's the central frequency of the GPS CA signal.
Bandwidth	2046000	It's the bandwidth necessary to properly generate the signal.
ModulationCoef	Real = 0, Img = 1	Default configuration for the GPS CA signal.
Codes	Id = L1CA	If the plug-in code ever need to know what is the code.

Usage in Skydel

Once your custom signal has been compiled as a plug-in and its corresponding XML file is defined, it is ready to be imported into Skydel. To do so, simply place the compiled plug-in and its associated XML file in the plug-in discovery folder, located at Skydel-SDX / Plug-ins.

If you're using a custom signal example that relies on a downlink file, make sure to also copy the required downlink file into the same folder, alongside the plug-in and XML file.

It's important that the custom signal plug-in and the XML file have the same name. For example, if the plug-in is named custom_e1.dll (on Windows) or libcustom_e1.so (on Ubuntu), the XML file should be named custom_e1.xml.

After restarting Skydel, you can enable your custom signal plug-in like any other plug-in via the Help / Plug-ins... menu. Once enabled, your custom signal will appear in the Settings / Custom Signals / Your Custom Signal Name page, where you’ll have access to its basic configuration options. It will also be available for assignment to an output.

That’s it, you’re now ready to run simulations using your custom signal!

Implementation

Refer to Custom Signal Factory for details on how to implement a custom signal plug-in.