Architecture
Last updated
Last updated
For existing GNSS signal generation, Skydel already knows all the signals specifications and how to generate the navigation message bits and the code chips. However, in order to generate a “custom signal”, users must provide information and compiled code to Skydel.
As shown in the diagram above, users needs to provide an XML file and a C++ shared library (.dll in Windows or .so in Linux) for each custom signal. Note that the same library can be shared by several custom signals.
For the legacy signals, Skydel automatically simulates the satellite visibility, signal dynamics and impairments (atmospheric delays, multipaths). The custom signal user must provide the signal data in the correct timeframe scheduled by the Skydel Engine.
A custom signal is composed of an arbitrary number of Subcarriers and Codes. The signal composition is described in an XML file. The codes' chips must be provided through a C++ shared library, as illustrated in the figure below.
The IQ samples are generated according to the following equation:
Where:
a constant (in ) multiplication factor
the number of codes
are the code chips value (-1 or 1) defined in the shared library (DLL)
the subcarriers defined as:
Where:
the number of subcarriers
are the subcarrier Real values defined in the XML file
Document interface version, current version is "1.0".
Optional Boolean. If missing, it will attempt to get a navigation message from the shared library. If set to True, it will generate an error if the navigation message is missing from the shared library.
The satellite constellation to which this custom signal will be attached.
Custom signal's central frequency, in Hertz.
Custom signal's bandwidth, in Hertz.
Path to the shared library, relative to the XML.
Default power offset to the constellation reference, in dB.
Optionnal parameter. 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 GLONASS Custom Signals.
Subcarrier identifier.
Subcarrier rate, in Hertz.
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 identifier. Can be used to distinguish different custom signals in the same shared library.
The real part of the multiplier applied to every sample.
The imaginary part of the multiplier applied to every sample.
The frequency offset in hertz between channels (SV IDs). This value will be multiplied by the given channel assignation for an SV ID.
Integer assignations for each channel. Requires as many channels as available SV IDs in the signal's constellation.
Your implementation constructor must take a reference to a constant CSInitData structure, containing various simulation start information.
Returns a pointer to the navigation message object or nullptr if this shared library does not define any.
Returns a pointer to the code object that matches the null-terminated identifier name or nullptr if this is not a recognized name.
Returns the code rate in chips per millisecond.
Copy your custom chips for elapsed time elapsed and PRN prn into the buffer chips. The buffer is guaranteed to be getNumberOfChipsPerMSec() + getExtraAllocSize() long.
Extra bytes to allocate for the chips buffer.
Returns the navigation message duration in milliseconds.
Called every getNavMsgDurationMs() with updated simulation data.
Returns the navigation message's offset to the constellation's Time Of Week.
With this approach, it is possible to generate several GNSS modulation types, such as BPSK(N), BOC(M,N) and MBOC(M,N,P). Some examples of legacy GNSS signals are provided in the . Tracking and accuracy of these signals have been validated using a GNSS receiver.
An evolution of the custom signal feature will bring even more genericity. The goal is to ensure the generation of all legacy signals using the custom signal feature. Description of these possible evolutions is given .
