Architecture
Architecture
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 it is shown on the diagram, the user needs to provide an XML file and a C++ shared library (.dll in Windows or .so in Linux) for each custom signal. Nevertheless, the same library can be shared by several custom signals.
As for the legacy signals, Skydel Engine automatically simulates the satellite visibility, signal dynamics and impairments (atmospheric delays, multipaths). The custom signal user just has to 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 on 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
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 Annex A. Tracking and accuracy of these signals have been validated on a GNSS receiver.
An evolution of the custom signal feature is already plan that will bring even more genericity. The objective is to have the possibility to generate (at least) all the legacy signals thanks to the custom signal feature. Description of these possible evolutions is given in Annex B.
XML file
CustomSignal
Version
Document interface version, curent version is "1.0".
NavMsg
Optional Boolean. If missing, it will try 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.
Constellation
The satellite constellation to which this custom signal will be attached to.
CentralFreq
Custom signal's central frequency, in Hertz.
Bandwidth
Custom signal's bandwidth, in Hertz.
DLLPath
Path to the shared library, relative to the XML.
SignalLevel
Default power offset to the constellation reference, in dB.
Subcarrier
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
Id
Code identifier. Can be used to distinguish different custom signals in the same shared library.
ModulationCoef
Real
The real part of the multiplier applied to every samples.
Imag
The imaginary part of the multiplier applied to every samples.
Shared library
ICustomSignal
Constructor
Your implementation constructor must take a reference to a constant CSInitData structure, containing various simulation start information.
getNavMsg
Returns a pointer to the navigation message object or nullptr if this shared library does not define any.
getCode
Returns a pointer to the code object that match the null-terminated identifier name or nullptr if this is not a recognized name.
ICustomSignalCode
getNumberOfChipsPerMSec
Returns the code rate in chips per millisecond.
getChips
Copy your custom chips for elapsed time elapsed and PRN prn into the buffer chips. The buffer is guaranteed to be getNumberOfChipsPerMSec() + getExtraAllocSize() long.
getExtraAllocSize
Extra bytes to allocate for the chips buffer.
ICustomSignalNavMsg
getNavMsgDurationMs
Returns the navigation message duration in milliseconds.
buildNavMsg
Called every getNavMsgDurationMs() with updated simulation data.
getTOWOffset
Returns the navigation message's offset to the constellation's Time Of Week.
Last updated