目錄

GNU Radio's class gr::basic_block is the abstract base class for all signal processing blocks, a bare abstraction of an entity that has a name and a set of inputs and outputs. It is never instantiated directly; rather, this is the abstract parent class of both gr::hier_block2 , which is a recursive container that adds or removes processing or hierarchical blocks to the internal graph, and gr::block

1. gr :: basic_block: 是所有訊號處理塊的抽象基類，是具有名稱和一組輸入和輸出的實體的抽象, 永遠不會直接被例項化;
2. gr :: hier_block2: gr :: basic_block是它的的抽象父類，它是一個遞迴容器，用於向內部圖形新增或刪除處理或分層塊;
3. gr :: block: 它是所有處理塊的抽象基類。

A signal processing flow is constructed by creating a tree of hierarchical blocks, which at any level may also contain terminal nodes that actually implement signal processing functions. 

Class gr::top_block is the top-level hierarchical block representing a flowgraph. It defines GNU Radio runtime functions used during the execution of the program: run(), start(), stop(), wait(), etc. A a subclass called GNSSBlockInterface is the common interface for all the GNSS-SDR modules. It defines pure virtual methods, that are required to be implemented by a derived class.
Subclassing GNSSBlockInterface, we defined interfaces for the GNSS receiver blocks depicted in the figure above. This hierarchy provides the definition of different algorithms and different implementations, which will be instantiated according to the configuration. This strategy allows multiple implementations sharing a common interface, achieving the objective of decoupling interfaces from implementations: it defines a family of algorithms, encapsulates each one, and makes them interchangeable. Hence, we let the algorithm vary independently from the program that uses it.

1. 通過建立分層塊樹來構造訊號處理流程，該分層塊樹在任何級別也可以包含實際實現訊號處理功能的終端節點;
2. gr :: top_block類是表示流程圖的頂級層次結構塊。它定義了在程式執行期間使用的GNU Radio執行時函式：run()，start()，stop()，wait()等;
3. GNSSBlockInterface子類是所有GNSS-SDR模組的通用介面。它定義了純虛方法，這些方法需要由派生類實現;
4. 對GNSSBlockInterface進行子類化，我們為上圖中描述的GNSS接收器塊定義了介面。此層次結構提供了不同演算法和不同實現的定義，這些演算法將根據配置進行例項化。該策略允許多個實現共享一個公共介面，實現了將介面與實現分離的目標：它定義了一系列演算法，封裝了每個演算法，並使它們可以互換。因此，我們讓演算法獨立於使用它的程式。                                    

1.6.1 Signal Source

The input of a software receiver are the raw bits that come out from the front-end's analog-to-digital converter (ADC). Those bits can be read from a file stored in the hard disk or directly in real-time from a hardware device through USB or Ethernet buses.
The Signal Source module is in charge of implementing the hardware driver, that is, the portion of the code that communicates with the RF front-end and receives the samples coming from the ADC. This communication is usually performed through USB or Ethernet buses. Since real-time processing requires a highly optimized implementation of the whole receiver, this module also allows to read samples from a file stored in a hard disk, and thus processing without time constraints. Relevant parameters of those samples are the intermediate frequency (or baseband I&Q components), the sampling rate and number of bits per sample, that must be specified by the user in the configuration file.
This module also performs bit-depth adaptation, since most of the existing RF front-ends provide samples quantized with 2 or 3 bits, while operations inside the processor are performed on 32- or 64-bit words, depending on its architecture. Although there are implementations of the most intensive computational processes (mainly correlation) that take advantage of specific data types and architectures for the sake of efficiency, the approach is processor-specific and hardly portable. We suggest to keep signal samples in standard data types and letting the compiler select the best library version (implemented using SIMD or any other processor-specific technology) of the required routines for a given processor.

訊號源模組:

1. 可以處理來自RF的資料,也可以讀取文字資料;
2. 這些取樣值的相關引數是中頻（或基帶I＆Q分量），取樣率和每個取樣點的位數，必須由使用者在配置檔案中指定;
3. 該模組還執行位深度自適應，因為大多數現有RF前端提供量化為2或3位的取樣，而處理器內部的操作則根據其體系結構在32位或64位字上執行。儘管為了提高效率，存在利用特定資料型別和體系結構的最密集計算過程（主要是相關操作）的實現，但該方法是特定於處理器的並且幾乎不可移植;
4. 我們建議將取樣訊號保留標準資料型別，並讓編譯器為給定處理器選擇所需例程的最佳庫版本（使用SIMD或任何其他特定於處理器的技術實現）。

1.6.2 Signal Conditioner

The signal conditioner is in charge of resampling the signal and delivering a reference sample rate to the down-stream processing blocks, acting as a facade between the signal source and the synchronization channels, providing a simplified interface to the input signal. In case of multiband front-ends, this module would be in charge of providing a separated data stream for each band.

訊號調理器模組:

1. 負責訊號的重取樣並將重取樣資料傳送到後續的處理塊，充當訊號源和同步通道之間的介面，為輸入訊號提供簡化的介面。
2. 在多頻帶前端的情況下，該模組將負責為每個頻帶提供分離的資料流。

1.6.3 Channel

A channel encapsulates all signal processing devoted to a single satellite. Thus, it is a large composite object which encapsulates the Acquisition, Tracking and Decoding of the navigation message modules. As a composite object, it can be treated as a single entity, meaning that it can be easily replicated. Since the number of channels is selectable by the user in the configuration file, this approach helps improving the scalability and maintainability of the receiver.

This module is also in charge of managing the interplay between acquisition and tracking. Acquisition can be initialized in several ways, depending on the prior information available (called cold start when the receiver has no information about its position nor the satellites almanac; warm start when a rough location and the approximate time of day are available, and the receiver has a recently recorded almanac broadcast; or hot start when the receiver was tracking a satellite and the signal line of sight broke for a short period of time, but the ephemeris and almanac data is still valid, or this information is provided by other means), and an acquisition process can finish deciding that the satellite is not present, that longer integration is needed in order to confirm the presence of the satellite, or declaring the satellite present. In the latter case, acquisition process should stop and trigger the tracking module with coarse estimations of the synchronization parameters. The mathematical abstraction used to design this logic is known as finite state machine (FSM), that is a behavior model composed of a finite number of states, transitions between those states, and actions. For the implementation, we used the Boost.Statechart library, which provides desirable features such as support for asynchronous state machines, multi-threading, type-safety, error handling and compile-time validation. 

The abstract class ChannelInterface represents an interface to a channel GNSS block. Check Channel for an actual implementation.

通道模組:

1. 通道模組是一個大型複合物件，封裝了每顆衛星的所有訊號處理模組, 包括捕獲，跟蹤和電文解碼模組;
2. 通道模組作為一個複合物件，它可以被視為一個單獨的實體，這意味著它可以很容易地複製;
3. 由於使用者可以在配置檔案中選擇通道數，因此該方法有助於提高接收器的可擴充套件性和可維護性;
4. 該模組還負責捕獲和跟蹤之間的通訊。
5. 可以通過多種方式初始化捕獲，具體取決於可用的先驗資訊（冷啟動/溫啟動/熱啟動）並且捕獲過程決定衛星是否不存在，或需要更長的積分時間來確認衛星的存在或者宣告衛星存在。
6. 當確認衛星訊號存在,捕獲過程應該停止並通過對同步引數的粗略估計來觸發跟蹤模組。
7. 用於設計該邏輯的數學抽象被稱為有限狀態機（FSM），它是由有限數量的狀態組成，這些狀態之間的轉換和動作組成的行為模型。
8. 為了實現FSM，我們使用了Boost.Statechart庫，它提供了所需的功能，例如支援非同步狀態機，多執行緒，型別安全，錯誤處理和編譯時驗證。
9. 抽象類ChannelInterface表示通道GNSS塊的介面, Channel給出了具體的實現.

(1) 捕獲:

The first task of a GNSS receiver is to detect the presence or absence of in-view satellites. This is done by the acquisition system process, which also provides a coarse estimation of two signal parameters: the frequency shift with respect to the nominal IF frequency, and a delay term which allows the receiver to create a local code aligned with the incoming code. AcquisitionInterface is the common interface for all the acquisition algorithms and their corresponding implementations. Algorithms' interface, that may vary depending on the use of information external to the receiver, such as in Assisted GNSS, is defined in classes referred to as adapters. These adapters wrap the GNU Radio blocks interface into a compatible interface expected by AcquisitionInterface. This allows the use of existing GNU Radio blocks derived from gr::block , and ensures that newly developed implementations will also be reusable in other GNU Radio-based applications. Moreover, it adds still another layer of abstraction, since each given acquisition algorithm can have different implementations (for instance using different numerical libraries). In such a way, implementations can be continuously improved without having any impact neither on the algorithm interface nor the general acquisition interface.

1. GNSS接收機首先檢測可檢視內衛星的存在與否, 通過捕獲過程完成，該過程還提供兩個訊號引數的粗略估計：多普勒頻移和碼相位延遲;
2.  AcquisitionInterface是所有捕獲演算法及其相應實現的通用介面。
3. 捕獲演算法的介面可以根據接收機外部資訊的使用而變化，例如在輔助GNSS中，在被稱為調節器的類中定義。這些調節器將GNU Radio的塊介面封裝到AcquisitionInterface所期望的相容介面中。這允許使用從gr :: block派生的現有GNU Radio塊，並確保新開發的實現也可以在其他基於GNU Radio的應用程式中重用。
4. 此外，在AcquisitionInterface和演算法介面之間增加了另一層抽象，因為每個給定的捕獲演算法可以有不同的實現（例如使用不同的數值庫）。
5. 以這種方式，可以不斷地改進具體的實現，而不會對演算法介面和通用獲取介面產生任何影響。

捕獲演算法的所有原始碼在以下目錄中:

• |-gnss-sdr
• |---src
• |-----algorithms
• |-------acquisition
• |---------adapters             <- Adapters of the processing blocks to an AcquisitionInterface
• |---------gnuradio_blocks <- Signal processing blocks implementation
   

(2) 跟蹤:

When a satellite is declared present, the parameters estimated by the acquisition module are then fed to the receiver tracking module, which represents the second stage of the signal processing unit, aiming to perform a local search for accurate estimates of code delay and carrier phase, and following their eventual variations. Again, a class hierarchy consisting of a TrackingInterface class and subclasses implementing algorithms provides a way of testing different approaches, with full access to their parameters.

1. 當一顆衛星被捕獲到時,轉入跟蹤階段,執行精確的載波相位和碼相位跟蹤;
2. 同樣，由TrackingInterface類和實現演算法的子類組成的類層次結構提供了一種測試不同方法的方法，可以完全訪問它們的引數。

跟蹤演算法的所有原始碼在以下目錄中:

• |-gnss-sdr
• |---src
• |-----algorithms
• |-------tracking
• |---------adapters             <- Adapters of the processing blocks to a TrackingInterface
• |---------gnuradio_blocks <- Signal processing blocks implementation
• |---------libs                      <- libraries of tracking objects (e.g. correlators, discriminators, and so on)

(3) 電文解碼

Most of GNSS signal links are modulated by a navigation message containing the time the message was transmitted, orbital parameters of satellites (also known as ephemeris) and an almanac (information about the general system health, rough orbits of all satellites in the network as well as data related to error correction). Navigation data bits are structured in words, pages, subframes, frames and superframes. Sometimes, bits corresponding to a single parameter are spread over different words, and values extracted from different frames are required for proper decoding. Some words are for synchronization purposes, others for error control and others contain actual information. There are also error control mechanisms, from parity checks to forward error correction (FEC) encoding and interleaving, depending on the system. All this decoding complexity is managed by a finite state machine implemented with the Boost.Statechart library. The common interface is TelemetryDecoderInterface.

1. 大多數GNSS訊號鏈路由導航電文調製，包含: 電文傳輸的時間，衛星的軌道引數（星曆）和曆書（關於一般系統健康的資訊，以及網路中所有衛星的粗略軌道和誤差修正引數）。
2. 導航資料bit 以字，頁，子幀，幀和超幀結構來組織。
3. 有的引數的bit分佈在不同的字上，並且從不同的幀提取。
4. 字用於同步/錯誤控制/實際資訊。
5. 還有糾錯控制機制，根據不同系統包含奇偶校驗/前向糾錯（FEC）編碼和交織等。
6. 所有這些解碼的複雜性由使用Boost.Statechart庫實現的有限狀態機管理。
7. 通用介面是TelemetryDecoderInterface。

1.6.4 Observables

GNSS systems provide different kinds of observations. The most commonly used are the code observations, also called pseudoranges. The pseudo comes from the fact that on the receiver side the clock error is unknown and thus the measurement is not a pure range observation. High accuracy applications also use the carrier phase observations, which are based on measuring the difference between the carrier phase transmitted by the GNSS satellites and the phase of the carrier generated in the receiver. Both observables are computed from the outputs of the tracking module and the decoding of the navigation message. This module collects all the data provided by every tracked channel, aligns all received data into a coherent set, and computes the observables. The common interface is ObservablesInterface.

1. GNSS系統提供不同型別的觀測值: 最常用的有偽距和載波相位等等;
2.  觀測模組收集每個跟蹤通道提供的所有觀測資料，將所有接收的資料對齊到一個連貫的集合(翻譯得不好,就是各個通道資料都扔到觀測模組中,並進行時間對齊處理,同一觀測時刻嘛)中，並計算觀測值。
3. 通用介面是ObservablesInterface。

1.6.5 Computation of Position, Velocity and Time

Although data processing for obtaining high-accuracy PVT solutions is out of the scope of GNSS-SDR, we provide a module that can compute a simple least square solution and leaves room for more sophisticated positioning methods. The integration with libraries and software tools that are able to deal with multi-constellation data such as GPSTk or gLAB appears as a viable solution for high performance, completely customizable GNSS receivers. The common interface is PvtInterface.

1. 雖然用於獲取高精度PVT解決方案的資料處理超出了GNSS-SDR的範圍;
2. GNSS-SDR提供的模組可以計算簡單的最小二乘解決方案，併為更復雜的定位方法留出空間;
3. 可與能處理多星座資料（如GPSTk或gLAB）的庫和軟體工具的進行整合,提供一個高效能,完全可定製的GNSS接收機方案； 
4. 通用介面是PvtInterface。