System for processing global navigation satellite system (GNSS) signals and method for processing GNSS signals in a GNSS receiver

Abstract

A system for processing GNSS signals, the system comprising: a memory for storing master code types of GNSS signals from one or more GNSS clusters GNSS SVs and storing one representation of master code polynomial data for generating master PRN codes of the GNSS signals; and a code generator coupled to the memory for receiving the master code types and the master code polynomial data, and using the master code types and the master code polynomial data to generate more than two master PRN code bits in a single clock cycle during acquisition and tracking of one of the GNSS signals.

Description

Prior Art

[0001] The present invention relates to the field of global navigation satellite systems (GNSS). More specifically, in one embodiment, the present invention relates to a GNSS receiver that uses a modern L5 signal in the L5 band. Numerous GNSS systems are available, including the US GPS (Global Positioning System), GLONASS, Galileo, BeiDou, and regional systems currently in use or that may be deployed in the future. The US GPS system was originally available only in the L1 band. Currently, the US GPS system includes GNSS signals in the L5 band, and the Galileo system includes modern GNSS signals in the L5 band centered at 1191.79 MHz (such as E5A and E5B). Modern GNSS signals in the L5 band offer several advantages over GNSS signals in the L1 band, some of which are discussed below. However, directly acquiring L5-band GNSS signals in a GNSS receiver without first acquiring L1 GNSS signals has been considered too difficult. Consequently, conventional GNSS receivers employ a technique that first acquires L1 GNSS signals. This acquisition provides information (such as time information and Doppler estimation) used to acquire GNSS signals in the E5 band. Consequently, conventional GNSS receivers supporting L5 GNSS signals use a single RF front-end that receives both L5 and L1 signals; this implies the presence of multiple RF components in these GNSS receivers. Furthermore, conventional receivers must store and use pseudo-random noise (PRN) codes for both L1 and L5 GNSS signals. Summary of the Invention

[0002] Various aspects described herein provide improvements that can allow a GNSS receiver to directly receive, acquire, process, and use only L5-band GNSS signals within the GNSS receiver with greater sensitivity and reliability than can be achieved through acquisition in the narrow L1 band. However, in some embodiments, these improvements can be used in conventional receivers to receive and process L5-band GNSS signals as well as one or more additional GNSS bands (such as the L1 GPS band). These aspects can be implemented in various embodiments, which can include a GNSS receiver or portions thereof, or a data processing system (such as a smartphone) containing such a receiver or portions thereof, and can include methods performed by such a device (e.g., a GNSS receiver, etc.), and can include non-transitory machine-readable media storing computer program instructions that, when executed by a data processing system, cause the data processing system to perform one or more of the methods described herein.

[0003] One aspect of the present invention relates to directly acquiring L5-band GNSS signals. In other words, in this aspect, a GNSS receiver directly acquires L5-band GNSS signals without attempting to acquire time and frequency information from L1-band GNSS signals. The terms "direct acquisition" and "directly acquiring" are intended to mean that a GNSS receiver receives L5-band GNSS signals and acquires them to obtain time and frequency information derived from them, rather than acquiring time and frequency information from L1-band GNSS signals. While cellular phone assistance data (time or frequency phase lock as described in the prior Rapid Tracking patent) can be used in a GNSS receiver, a GNSS receiver that does not acquire L1-band GNSS signals and does not use them for directly acquiring L5-band GNSS signals does so. Therefore, when a GNSS receiver directly acquires L5 band GNSS signals, the GNSS receiver acquires the L5 band GNSS signals to obtain time and frequency information from these signals without the benefit of previously acquiring L1 band GNSS signals and without the benefit of obtaining time or frequency information from the L1 band GNSS signals.

[0004] Another aspect of the present invention relates to sharing a cache memory between one or more application processors (APs) and a GNSS processing system (or sharing other memory between the GNSS processing system and other processors on a system-on-chip (SOC) or integrated circuit). This aspect provides a solution to the typically excessive memory requirements for acquiring L5 GNSS signals, specifically by utilizing discrete Fourier transform (DFT) calculations. The one or more APs (or other processors) and the GNSS processing system can be implemented together in a single monolithic integrated circuit (IC) on a single semiconductor substrate, and the cache memory can also be located on the same IC. This single monolithic IC on a single semiconductor substrate can be referred to as a system-on-chip (SOC). In this aspect, the AP (or other processor) shares its cache memory (or other memory) with at least one acquisition engine (AE) of the GNSS processing system. In one embodiment, this sharing may be limited to situations in which the acquisition engine initially acquires GNSS signals (for example, at the beginning, with or without assistance data from a cellular telephone network). During the acquisition phase, a portion of cache memory (which may be L1 (Level 1) or L2 (Level 2) SRAM cache of the one or more application processors or other memory used by other processing systems) may be allocated to the acquisition engine in response to a request for location data (such as latitude and longitude) from an application (such as a mapping application or other application). This allocation may be prioritized based on the location request, or not by the system's operating system (OS) or firmware on an IC. If the location request comes from a low-priority background resident application, allocation may be temporarily deferred until sufficient free memory is available in the cache. On the other hand, if the location request comes from a mapping application that is the foreground application (and therefore the device's display presents the mapping application's user interface to a user), allocation is prioritized. In one embodiment, the portion to be allocated can be identified by determining which pages in the cache have not been tampered with and are stored in a backing store, such as main DRAM or, more preferably, non-volatile memory, such as flash memory. These pages (e.g., tampered with and stored in a backing store) can be immediately cleared / deleted from the cache (or other memory) and then allocated to the AE for storing, for example, one or more of the hypothesis data or generated GNSS PRN codes and / or code spectra of the GNSS PRN codes generated from a DFT.

[0005] A method according to this common aspect may include the following operations implemented in a GNSS receiver: receiving a request from one or more application processors on an integrated circuit to generate position data using a GNSS processing system on the integrated circuit, the GNSS processing system including an acquisition engine (AE), the acquisition engine (AE) configured to acquire a plurality of GNSS signals, each of the GNSS signals being transmitted from one of a GNSS cluster space vehicle (SV); identifying a portion of a cache (or other memory) on the integrated circuit and allocating the portion to the acquisition engine for use in response to the request to generate position data, and allocating a remaining portion of the cache (or other memory) to the one or more application processors (or other processors), the allocation being performed by an operating system executing on the one or more application processors or by firmware on the IC; and storing, by the acquisition engine or the one or more application processors, data related to GNSS signal acquisition processing in the allocated portion. In one embodiment, the method may use static random access memory (SRAM) as a cache memory (or other memory) on the integrated circuit, and the acquisition engine may include ASIC (application specific integrated circuit) hardware logic for performing a fast Fourier transform (FFT) operation (such as a discrete Fourier transform (DFT) operation) using a time decimation method and also using a frequency decimation method. In one embodiment, the method may further include the following operations: after the GNSS processing system begins tracking GNSS signals acquired from at least three (3) GNSS SVs, de-allocating the allocated portion in response to acquiring GNSS signals from the at least three GNSS SVs before a tracking phase. In one embodiment, the GNSS processing system includes a dedicated memory that is separate from the cache memory (or other memory) and is dedicated to the GNSS processing system. In one embodiment, a memory controller coupled to a cache (or other memory) may include: a first port controller for controlling access to a portion allocated to an acquisition engine; and a second port controller for controlling access to the remaining portion of the cache (or other memory). In one embodiment, the acquisition engine performs acquisition of a GNSS signal from a GNSS SV and the acquisition includes determining a primary code phase and frequency of a received GNSS signal containing a pseudo random noise (PRN) code to enable tracking of the GNSS signal to generate a virtual range to the GNSS SV as a result of the tracking. In one embodiment of the method, the allocated portion is used to store one or more of: (1) a pseudo random noise code of the GNSS SV or (2) a hypothesis of an identity of a potentially acquired GNSS signal and a hypothesis of a frequency of the potentially acquired GNSS signal.In one embodiment of this method, the one or more application processors may generate GNSS PRN codes and / or code spectra of GNSS PRN codes from DFT for at least the GNSS SVs in view before an acquisition phase begins. In one implementation of this embodiment, these PRN codes and / or their code spectra from DFT may be generated and used immediately but not stored, or alternatively, these PRN codes and / or their code spectra from DFT may be generated and temporarily stored for use during the acquisition and tracking phases. In an alternative embodiment, the one or more application processors may generate GNSS PRN codes and store them in the system's DRAM memory, then copy them to cache (or other memory) before starting the acquisition phase or in response to a position request. In one embodiment, to conserve memory, the system may generate GNSS PRN codes and / or their code spectra from DFT only for healthy GNSS SVs in view.

[0006] In one embodiment, a system according to this shared aspect may include the following components: a set of one or more application processors configured to execute an operating system (OS) and one or more applications, the set of one or more application processors being implemented in an integrated circuit (IC); a set of one or more buses coupled to the set of one or more application processors, the one or more buses being located on the IC; a cache (or other memory) located on the IC and coupled to the set of one or more buses and to the set of one or more application processors for storing data for use by the operating system or for the one or more applications and other memory (such as high-bandwidth modem memory or other memory used by one or more processors that are not in the set of one or more application processors and that may also be located on the IC and coupled to the one or more buses); a bus interface coupled to the one or more buses, the bus interface coupling the one or more application processors to dynamic random access memory (DRAM) external to the integrated circuit; a GNSS processing system implemented on the integrated circuit, the GNSS processing system comprising an acquisition engine (AE) and a tracking engine (TE), the GNSS processing system coupled to the cache memory (or other memory) via the one or more buses; and a memory controller coupled to the cache memory (or other memory), the one or more application processors, and the GNSS processing system, the memory controller allocating a portion of the cache memory (or other memory) to the AE in response to one or more instructions from an operating system (or other software component) to enable acquisition of GNSS signals. In one embodiment, the cache memory may include static random access memory (SRAM), and the AE may include ASIC hardware logic to perform discrete Fourier transform operations using both a time decimation method and a frequency decimation method. In one embodiment, the memory controller may include a first port controller for controlling reads and writes to the portion used for the AE and a second port controller for controlling reads and writes to a remaining portion of the cache (or other memory). In one embodiment, the memory controller may deallocate the portion of the cache (or other memory) used by the AE before the GNSS processing system begins tracking GNSS signals acquired from at least three GNSS SVs (but before determining position data (e.g., latitude and longitude)).

[0007] Another aspect that can help reduce memory usage in an L5 band GNSS receiver is to generate code spectra for GNSS PRN codes and / or DFT-derived GNSS PRN codes, used to associate with received GNSS signals, on-demand during the acquisition phase. In one embodiment, this on-demand generation can generate code spectra for GNSS PRN codes and / or DFT-derived GNSS PRN codes during both the acquisition and tracking phases. For example, in one embodiment, these codes may be generated but not stored during both the acquisition and tracking phases. In an alternative embodiment, codes may be temporarily generated and stored on-demand during both the acquisition and tracking phases and no longer stored once a position is determined.

[0008] Another aspect of the present invention relates to an acquisition correlator using array processing. This array processing architecture can first arrange digitized GNSS sample data, for example, in rows in an array, where the rows are arranged in time in a baseband sample memory. A DFT operation performed on the data can generate an output that can then be processed by an inverse DFT operation without rotating, reformatting, reconfiguring, or transposing the data in the array before the inverse DFT operation. The data can be arranged so that each ALU in a set of multiple ALUs processes a row or column of the array, thereby dividing the processing into discrete segments that can be processed by each DFT ALU. This allows a single DFT ALU to calculate each row or column in one or a few processing clock cycles as an atomic processing operation. In one embodiment, the single DFT ALU performs multiple DFT operations upon receiving an instruction to do so. The baseband sample memory can be implemented as a circular buffer containing an array of sorted data. In one embodiment, the processing operation may be a DFT in-place computation such that a row (or column) of input data is retrieved from memory and processed (using a DFT), and then the output from this processing is stored back into the same memory locations as the input data (thus overwriting the input data in those memory locations).

[0009] In one embodiment in which an array processing architecture may be used, a system for processing GNSS signals may include the following components: a radio frequency analog-to-digital converter (ADC) for generating a digital representation of a received GNSS signal; and a baseband sample memory for storing the digital representation of the received GNSS signal as digitized GNSS sample data in N2 columns (e.g., 1024 columns) and N1 rows (e.g., 20 rows), the array being stored in the baseband sample memory in a column order, and the column order containing digitized GNSS sample data received during a time period (including a first time period and a second time period), such that a first column in the column order contains digitized GNSS sample data received during the first time period, and a second column in the column order subsequent to the first column contains digitized GNSS sample data received during the second time period that is temporally subsequent to the first time period, wherein the baseband sample memory is coupled to the RF analog-to-digital converter (ADC). An ADC is provided; and an arithmetic logic unit (ALU) configured to perform discrete Fourier transform (DFT) operations, the ALU being coupled to the baseband sample memory and configured to perform N1 DFTs in parallel and simultaneously, wherein each of the N1 DFTs contains N2 points in the DFT and the output of the N1 DFTs is stored in a portion of the sample array, and wherein the ALU is then configured to perform N2 DFTs, each of the N2 DFTs containing N1 points from the portion of the sample array, the N2 DFTs providing an output that is stored in a DFT result array arranged in row order. In one embodiment, the baseband sample memory is configured as a circular memory buffer for storing digitized GNSS sample data. In one embodiment, the N1 DFTs use the same operation and the same program control instructions to cause the ALUs to operate on different data. In one embodiment, the N2 DFTs are performed continuously over time. In one embodiment, the circular sample memory buffer stores one or more frames of a pseudo-random GNSS signal exceeding one millisecond. In one embodiment, the N1 DFTs and the N2 DFTs utilize a decimation-in-time method, and N1 is an integer value selected from 5, 10, 20, or 40. In another embodiment, N2 is set such that N1×N2=20480 (or N1×N2 is greater than 20480). In one embodiment, a change from column order to row order avoids a reordering or transposition algorithm, and the change is generated by a combination of N1 DFTs followed by N2 DFTs configured to generate the change. In one embodiment, a GNSS code generator is configured to generate a GNSS code spectrum, and the ALU performs a set of DFTs on the GNSS PRN code to provide code spectrum result data, which is stored in a code spectrum memory in row order.In one embodiment, the ALUs may be configured to multiply the code spectrum result data by the sample output stored in the DFT result array to generate a product array. In one embodiment, the ALUs may be configured to perform an inverse DFT on the product array using a frequency decimation method. In one embodiment, the inverse DFT may include: (1) in a first stage, N2 DFTs using conjugate inputs, each of the N2 DFTs having N1 points; and (2) in a second stage following the first stage, N1 DFTs, each of the N1 DFTs having N2 points. In one embodiment, the baseband sample memory may be a dual-port memory that allows different processors or programs to access different portions of the baseband sample memory simultaneously. In one embodiment, a GNSS code generator can repeatedly generate a pseudo-random noise code every millisecond for each GNSS SV in view during an acquisition phase when a pseudo-random noise code is needed. The generated pseudo-random noise code (and / or its code spectrum derived from the DFT) is not stored after use, and the generated pseudo-random noise code can be used to generate a GNSS code spectrum. In one embodiment, the GNSS code spectrum is aligned in both frequency and phase to an appropriate location in memory to match the code phase and frequency shift hypotheses associated with the received GNSS signal. In one embodiment, this alignment can be performed by CORDIC hardware.

[0010] One or more embodiments of the GNSS receiver described herein may implement one of the following methods using a series of DFTs. In one embodiment, a method may include the following operations: Receive GNSS signals; digitizing the received GNSS signal and providing an output of GNSS sample data from an analog-to-digital converter (ADC), the GNSS sample data comprising at least one of (1) GNSS sideband A sample data of the received GNSS signal and (2) GNSS sideband B sample data of the received GNSS signal; performing at least one of the following: (1) calculating a first set of DFTs on the GNSS sideband A sample data to provide a first set of results; and (2) calculating a second set of DFTs on the GNSS sideband B sample data to provide a second set of results; Perform at least one of the following: (1) calculating a third set of DFTs on the GNSS sideband A primary PRN code data, adjusting the GNSS sideband A primary PRN code data due to code Doppler and carrier Doppler before the third set of DFTs, the GNSS sideband A primary PRN code data including at least one of the two components in GNSS sideband A, the third set of DFTs providing a third set of results; and (2) calculating a fourth set of DFTs on the GNSS sideband B primary PRN code data, adjusting the GNSS sideband B primary PRN code data due to code Doppler and carrier Doppler before the fourth set of DFTs, the GNSS sideband B primary PRN code data including at least one of the two components in GNSS sideband B, the fourth set of DFTs providing a fourth set of results; performing at least one of the following: (1) calculating a first set of correlations using a DFT of the complex conjugate of a product of the first set of results and the complex conjugate of the third set of results to provide a fifth set of results; and (2) calculating a second set of correlations using a DFT of the complex conjugate of a product of the second set of results and the complex conjugate of the fourth set of results to provide a sixth set of results; and Integrating at least one of: (1) integrating the fifth set of results using at least one previous sum of the GNSS sideband A; and (2) integrating the sixth set of results using at least one previous sum of the GNSS sideband B, wherein the integrating comprises at least one of: (1) storing at least one new sum of the GNSS sideband A components in a single hypothesis memory and (2) storing at least one new sum of the GNSS sideband B components in the single hypothesis memory.

[0011] One implementation of this method can be summarized as follows ("Scenario 1"): 1. Calculate the FFT of the A sample on one side; 2. Calculate the FFT of the B samples; 3. Calculating the FFT of at least one sideband A-component main code adjusted by code Doppler and carrier Doppler (e.g., a range of potential Dopplers to be searched); 4. Calculate the FFT of at least one sideband B component main code adjusted by code Doppler and carrier Doppler; 5. Calculate the correlation by performing an inverse FFT (IFFT) on the product of (a) the FFT calculated from 1 (the FFT of the sideband A samples) and (b) the FFT calculated from 3 (the FFT of the sideband A components); 6. Calculate the correlation by performing an IFFT on the product of (a) the FFT calculated from 2 and (b) the FFT calculated from 4.

[0012] This implementation offers several advantages. For example, it can perform very few FFTs on received sideband samples and can reduce or eliminate the large data transfers typically required to move pre-computed GNSS sample spectra from memory (e.g., DRAM or non-volatile memory) to the frequency-domain correlation engine. The frequency-domain correlation engine can be highly efficient by reusing the engine at a reasonable clock rate while requiring a low or minimal memory footprint. For example, the frequency-domain correlation engine can calculate the master code and its spectrum live within the engine (e.g., in operations 3 and 4 of the summation in "Case 1" above) according to a pipeline architecture described herein. Furthermore, applying code Doppler and carrier Doppler to the live-generated code (e.g., in operations 3 and 4 of the summation in "Case 1" above) can reduce the input (received) sample FFTs and also improve code Doppler accuracy.

[0013] There are many combinations and permutations of this implementation for acquiring, for example, L5 GNSS signals. However, these combinations and permutations may not be as efficient as "Case 1" above because they require a faster processing clock and / or more memory (relative to "Case 1"), or because they have less acquisition sensitivity or take longer to acquire a signal to reach a given signal strength. The use of the six (6) operations in "Case 1" may be retained, but the arrangement is based on one or more of the following: (1) where and how the code compensation and carrier compensation are performed, for example: (a) carrier Doppler compensation may be performed by "erasing" the received GNSS samples or multiplying the locally generated (or pre-calculated) PRN code samples; or (b) code Doppler adjustment may be applied to the received GNSS samples ("input samples") or the locally generated (or pre-calculated) PRN code samples by performing a complex multiplication of the code spectrum (for example, see Appendix 3) or by correlating the compensated result and integrating it in memory (see Appendix 1); (2) based on the GNSS in view. SV instead of generating the code spectrum locally in the acquisition engine (AE), or pre-calculating the code spectrum and loading it into the AE; or (3) alternative hardware architecture (rather than performing time decimation FFT and frequency decimation FFT sequentially), such as parallel FFT cores or higher radix cores to reduce the number of processing clocks per FFT. The following six arrangements are examples of possible arrangements.

[0014] Case 2 (Switch code and carrier Doppler to samples: more input samples are needed for FFT) 1. Perform FFT on the sideband A adjusted for code Doppler and carrier Doppler 2. Perform FFT on the sideband B adjusted for code Doppler and carrier Doppler 3. Perform FFT on at least one A component main code 4. Perform FFT on at least one B component main code 5. Correlate by performing IFFT on 1 product and 3 products combined into a single hypothesis memory 6. Correlation is made by performing IFFT on 2 and 4 products integrated into a single hypothesis memory

[0015] Case 2B (same as 2, but with pre-calculated code spectrum: requires more memory and data bandwidth) 1. Perform FFT on the sideband A adjusted for code Doppler and carrier Doppler 2. Perform FFT on the sideband B adjusted for code Doppler and carrier Doppler 3. Obtain at least one pre-calculated FFT of the A component main code 4. Obtain the pre-calculated FFT of at least one B-component master code 5. Correlate the 1 product and 3 products integrated into a single hypothesis memory by performing IFFT 6. Correlate the 2 products and 4 products combined into a single hypothesis memory by performing IFFT

[0016] Case 3 (same as 2, correlation after code Doppler compensation) 1. Perform FFT on the sideband A adjusted for carrier Doppler 2. Perform FFT on the sideband B adjusted for carrier Doppler 3. Perform FFT on at least one A component main code 4. Perform FFT on at least one B component main code 5. Correlate the 1st and 3rd products combined into a single hypothesis memory and adjusted for code Doppler 6. Correlate the 2 products and 4 products combined into a single hypothesis memory and adjusted for code Doppler

[0017] Case 3B (same as 3, but with pre-calculated code spectrum) 1. Perform FFT on the sideband A adjusted for carrier Doppler 2. Perform FFT on the sideband B adjusted for carrier Doppler 3. Obtain at least one pre-calculated FFT of the A component main code 4. Obtain at least one pre-calculated FFT of the B component main code 5. Correlate 1 product and 3 products integrated into a single hypothesis memory and adjusted for code Doppler 6. Correlate the IFFT of the 2 products and 4 products combined into a single hypothesis memory and adjusted for code Doppler

[0018] The following set of scenarios uses the method described in Appendix 1, which computes the FFT of the input sample sideband samples every millisecond at several frequencies (0, 200, 400, 600, 800) and then roughly estimates the sample sideband A or B spectrum by selecting the closest sub-kHz FFT and then shifting by + / - N samples to obtain a super-kHz compensation. For example, 2450 Hz uses a 400 Hz FFT and shifts this FFT by +2 samples to obtain a combined 400 Hz + 2 kHz Doppler compensation.

[0019] Scenario 4 (similar to the method described in Appendix 1) 1. Select at least one FFT from a set of sideband A sample FFTs adjusted for carrier Doppler at a set of frequencies covering a 1 kHz range, the one FFT shifted by N samples to generate an approximate carrier Doppler 2. Select at least one FFT from a set of sideband B sample FFTs adjusted for carrier Doppler at a set of frequencies covering a 1 kHz range, the FFT being shifted by N samples to generate an approximate carrier Doppler 3. Perform FFT on at least one A-component main code adjusted for code Doppler 4. Perform FFT on at least one B-component main code adjusted for code Doppler 5. Correlate the 1 product and 3 products integrated into a single hypothesis memory by performing IFFT 6. Correlate the 2 products and 4 products combined into a single hypothesis memory by performing IFFT

[0020] Case 4A (similar to method 4, but with pre-calculation of code spectrum and code Doppler post-correlation) 1. Select at least one FFT from a set of sideband A sample FFTs adjusted for carrier Doppler at a set of frequencies covering a 1 kHz range, the one FFT shifted by N samples to generate an approximate carrier Doppler 2. Select at least one FFT from a set of sideband B sample FFTs adjusted for carrier Doppler at a set of frequencies covering a 1 kHz range, the one FFT shifted by N samples to generate an approximate carrier Doppler 3. Obtain at least one pre-calculated FFT of the A component main code 4. Obtain a pre-calculated FFT of at least one B-component main code 5. Correlate 1 product and 3 products integrated into a single hypothesis memory and adjusted for code Doppler 6. Correlate the IFFT of the 2 products and the 4 products integrated into a single hypothesis memory and adjusted for code Doppler

[0021] In some of the embodiments described herein, adjustments or compensation are made for one or both of code Doppler and carrier Doppler. As described herein, these adjustments can be performed independently and at different stages. Code Doppler adjustment is an adjustment made to a locally generated code (or a pre-calculated code) or to a received GNSS sample code to compensate for the Doppler effect of a code (such as a primary GNSS PRN code). For example, during a search or acquisition phase, multiple possible code Doppler adjustments can be made to the locally generated code or to the received GNSS sample code to search for and acquire a GNSS signal affected by the Doppler effect. Carrier Doppler adjustment is an adjustment made to compensate for the Doppler effect on a signal's carrier frequency. Carrier Doppler is the observed frequency offset from the transmit frequency due to relative motion between the satellite and receiver, and is a deviation from the nominal values of the satellite and receiver oscillators. Code Doppler is the time shift of the received code phase that is coherent with the carrier Doppler. At L5, there are 115 carrier cycles per code chip. Therefore, the code Doppler, expressed in chips / second, is the carrier Doppler divided by 115. Therefore, at a carrier Doppler of 4321 Hz, the received code phase will shift by 37.57 chips per second. To receive weak signals, the received signal must be correlated with the receiver's replica signal over multiple primary code frames. This requires shifting each incoming code phase hypothesis according to the carrier Doppler hypothesis. This shift is called the code Doppler.

[0022] Another aspect of the present invention involves using the primary code and / or secondary code in the E5 GNSS signals from one GNSS SV to derive code phase information or time information based on those GNSS signals, and then using that information to estimate the code phases of other GNSS signals from other GNSS SVs to obtain the code phases of those other GNSS signals from those other GNSS SVs. In this aspect, a GNSS receiver may employ a processing period that may be less than and offset from a 1 ms GNSS PRN code period, and may use this processing to attempt to coherently integrate before acquiring the code phase of other GNSS signals. For example, a GNSS processing system in the GNSS receiver may retrieve a full 1 ms of digitized GNSS sample data from a circular memory buffer every 0.25 ms and perform a set of DFTs and inverse DFTs on the retrieved data to coherently integrate for each frequency band, and then repeat this VFFDC process in the next processing period, where each processing period is 0.25 ms or some other fraction of a code period (i.e., in one embodiment, 1 ms long). This allows the GNSS receiver to repeatedly use the 1 ms data from the circular buffer over multiple processing periods to attempt to coherently integrate the other GNSS signals using information obtained by pre-acquiring the primary or secondary code phase of at least one of the GNSS signals. In this example, the satellite code is searched based on an approximate time grid at which it is expected to be received, thereby reducing sub-millisecond coherence cancellation losses due to phase reversals associated with the secondary code. In another embodiment, the receiver clock may be sufficiently accurate (with an error of significantly less than 1 ms) and a preferred position may be sufficiently well known to allow processing of all GNSS signals in this precise time acquisition mode.

[0023] Another aspect of the present invention involves using only a subset of two or four components of a GNSS signal (a selected component) to first acquire that subset (e.g., only one of the four components) during coarse time acquisition, and then acquiring the remaining components. In one embodiment, the selected component is chosen based on the lowest probability of a signal change due to a sign or phase reversal due to the decoding scheme used in the selected component. In the case of Galileo's E5 GNSS signal, the E5BI component has the lowest probability of a signal change due to a sign or phase reversal and can therefore be used as the selected component to perform a coarse or fine time acquisition before attempting to acquire and / or track the remaining components of the Galileo GNSS signal. This use of only a subset of the components may be performed initially when starting an acquisition (such as a coarse time acquisition), or as a backup mode of operation after a conventional acquisition fails, or as a method of acquiring a stronger satellite more quickly as the number of associations decreases, to allow a portion of a GNSS acquisition engine to search a large frequency space of many SVs more quickly and with lower power than if more GNSS signal components were employed.

[0024] Another aspect of the present invention involves mitigating the effects of interference from known strong interference sources, such as aeronautical radio navigation (ARN) signals, which are often present around airports or military bases. ARN signals, such as those from a tactical air navigation system (DME / TACAN), are typically strong pulsed signals that are well above the noise floor, while GNSS signals are typically below the noise floor. Furthermore, ARN signals can interfere with GNSS signals operating in the L5 band. In one embodiment, this interference can be mitigated by detecting a signal source above the noise floor (for example, a signal above a predetermined threshold, which may be several dB above the noise floor) and then removing the signal in the frequency domain. The DFT array processing described herein can be used to identify the interfering signal during the signal acquisition phase and then processed through an FIR (finite impulse response) filter to remove the interfering signal before time-domain correlation processing. Alternatively, since the input sample spectrum is performed every millisecond and at each of the upper and lower sidebands, frequencies with strong interference may be observed in the input data spectrum.

[0025] Another aspect of the present invention relates to a method for reducing memory usage by outputting some DFT calculations but not storing them. This method can reduce the size of the integration or hypothesis memory by not storing selected outputs from the DFT calculation. In one embodiment, the outputs are evaluated to determine whether to save them. This approach can be used when performing correlation using a DFT method. In this case, the DFT generates correlation results using all code hypotheses within one millisecond. If the time period position uncertainty is much less than one millisecond (i.e., the full range), only a portion around the estimated position needs to be integrated and stored.

[0026] The aspects and embodiments described herein may include a non-transitory machine-readable medium storing executable computer program instructions that, when executed by one or more data processing systems, cause one or more data processing systems to perform the methods described herein. These instructions may be stored in non-volatile memory (such as flash memory) or volatile dynamic random access memory or other forms of memory.

[0027] The above summary of the invention does not include an exhaustive list of all embodiments of the present invention. All systems and methods can be practiced according to all suitable combinations of the various aspects and embodiments summarized above and according to the aspects and embodiments disclosed in the detailed description below. Simple diagram description

[0028] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

[0029] FIG1 is a block diagram showing an example of a data processing system including a GNSS processor and one or more application processors.

[0030] FIG. 2 is a block diagram illustrating an example of an embodiment including a GNSS processing system, one or more application processors, and a cache memory.

[0031] 3 is a flow chart illustrating a method for sharing a cache memory between one or more application processors and a GNSS processor according to one embodiment.

[0032] FIG4 shows an example of a front-end of a GNSS receiver that digitizes received GNSS signals according to an embodiment.

[0033] 5A and 5B show an example of a method using array processing with several DFTs according to an embodiment.

[0034] 6 is a block diagram illustrating a frequency domain correlator architecture using array processing according to an embodiment.

[0035] FIG. 7 illustrates, in block diagram form, an example of processing components for performing array processing according to one embodiment.

[0036] FIG. 8 illustrates, in block diagram form, an example of additional processing components for performing array processing according to one embodiment.

[0037] 9A , 9B, 9C, and 9D show one example of processing components and a method that may be used to generate a PRN code spectrum for use with the array processing architecture shown in FIG. 6 , FIG. 7 , and FIG. 8 .

[0038] FIG. 10 shows an example of components that may be used in an embodiment of a GNSS receiver.

[0039] FIG11 is a flow chart showing a method according to an embodiment.

[0040] FIG12 shows an example of a GNSS receiver including only the L5 WB band in block diagram form. Implementation Method

[0041] Various embodiments and aspects will be described with reference to the details discussed below, and the accompanying drawings illustrate various embodiments. The following description and drawings are illustrative and should not be construed as limiting. Numerous specific details are set forth to provide a thorough understanding of the various embodiments. However, in some instances, well-known or customary details are not set forth to provide a concise discussion of the embodiments.

[0042] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment. The phrase "in one embodiment" appearing throughout this specification does not necessarily refer to the same embodiment. Processing logic, including hardware (e.g., circuitry, dedicated logic, etc.), software, or a combination of both, implements the procedures illustrated in the following figures. Although the procedures are described below based on certain sequential operations, it should be understood that some of the described operations may be performed in a different order. Furthermore, some operations may be performed in parallel rather than sequentially.

[0043] One aspect of the embodiments described herein relates to sharing cache memory between one or more application processors and a GNSS processing system. Before describing these shared embodiments, a description of a prior art architecture will be provided with reference to FIG1 . FIG1 shows a system 10 including one or more application processors 12 and a GNSS processor 20 coupled via a bus 14. Bus 14 is also coupled to system main memory, which includes dynamic random access memory (DRAM) 24. System 10 includes one or more input / output (I / O) devices 26 (such as one or more touch screens, speakers, microphones) and one or more sensors (such as a camera, facial detection sensor, etc.). System 10 also includes a cellular modem and processor 16, which may include its own cache memory, such as SRAM 16A. Cellular phone modem and processor 16 is coupled to cellular phone RF components 17 to receive cellular phone signals via antenna 18. GNSS processor 20 is configured to receive and process GNSS signals in both the L1 and L5 bands. Furthermore, GNSS radio frequency (RF) components 21 are configured to receive GNSS signals in both the L1 and L5 bands via antennas 22A and 22B. GNSS RF components 21 include one or more RF mixers and RF-to-intermediate frequency downconverters, as well as an RF local oscillator. These GNSS signals are processed by GNSS processor 20, which includes its own dedicated processor memory as part of GNSS processor 20. The GNSS processor does not use cache 12A or shares cache 12A with one or more application processors 12, which utilize a cache using techniques known in the art. The GNSS processor receives and processes GNSS signals and provides position outputs (such as latitude and longitude outputs) to one or more application processors 12 via bus 14. The GNSS processor receives and processes GNSS signals without utilizing cache memory 12A and requires two separate GNSS antennas 22A and 22B and two separate GNSS RF paths originating from the two GNSS antennas 22A and 22B.

[0044] FIG2 shows an example of a system in which cache memory is shared between one or more application processors and a GNSS processing system. The system 50 shown in FIG2 includes a system-on-a-chip (SOC) 52 that includes one or more application processors 66, a cache memory 70, and a GNSS processing system 68. In one embodiment, the SOC 52 may be a single monolithic semiconductor device pre-positioned within the substrate of an integrated circuit that includes all of the components shown within the perimeter of the SOC 52 shown in FIG2. The SOC 52 may include a memory controller 72 that controls access to the cache memory 70 (or other memory), which is coupled to the one or more application processors 66 and to the GNSS processing system 68. Thus, the memory controller 72 can arbitrate the use of cache memory 70, allowing both the GNSS processing system 68 and the one or more application processors 66 to use the cache memory, which in one embodiment may be implemented as SRAM memory. In one embodiment, the memory controller 72 can allocate a portion of cache memory 70 for use by the GNSS processing system and allow the one or more application processors 66 to use the remaining portion of cache memory 70. In one embodiment, cache memory 70 can be used to store program code or program instructions and data operated on by the processing system. As further described below, when the acquisition engine of the GNSS processing system 68 acquires GNSS signals, the acquisition engine can use the cache memory to store hypotheses, such as those in a hypothesis memory, used during the acquisition phase, or can use cache memory 70 to store PRN codes (and / or their code spectra from a DFT) generated for the GNSS signals. The GNSS processing system 68 can be coupled to the one or more application processors 66 via a bus 74. The one or more application processors 66 and the GNSS processing system 68 may also be coupled to a cellular phone modem and processor 76 via a bus 74. In one embodiment, bus 74 is a bus on the SOC 52. The SOC 52 also includes a bus interface 78 that allows the SOC 52 to couple to a system bus 54 external to the SOC 52. Several other components exist external to the SOC 52, including the GNSS radio 63, which, in the example shown in FIG. 2 , is configured to operate only in the L5 wideband (WB) band to receive and process only L5 wideband (WB) GNSS signals in the embodiment shown in FIG.The term or phrase "L5 WB band" or "L5 WB signal" or "L5 WB GNSS" is intended to include or refer to modern GNSS signals and modern GNSS systems (e.g., SVs and receiver clusters) operating in a modern frequency band centered at 1191.795 MHz and having a chip rate of 10.23 MHz or a chip rate significantly higher than the original chip rate or GPS L1 of 1.023 MHz. These modern GNSS systems include, for example, the U.S. L5 GPS system, the European E5 Galileo system, the Chinese BeiDou / GuanXiang B2 system, GLONASS K2, and QZSS. A cellular phone modem and processor 76 is coupled to a cellular phone radio 64 for receiving cellular phone signals and transmitting cellular phone signals. DRAM 56 is coupled to bus 54 and can store user data and applications, as well as an operating system. In addition to DRAM 56, system 50 may also include non-volatile memory 57, such as flash memory. Non-volatile memory 57 can store user data, applications, and the operating system for system 50. System 50 may also include various input / output devices, which can interface with the rest of the system via one or more I / O controllers 58. The input / output devices may include one or more sensors 62 and other input / output devices 60. For example, the sensors may include one or more of the following: a three-axis accelerometer, a three-axis gyroscope, an ambient light sensor (ALS), a barometric pressure sensor, a magnetometer, one or more cameras, etc. Furthermore, system 50 may include other radio frequency components 62, such as Bluetooth, Wi-Fi, etc. A method for operating system 50 will now be provided with reference to FIG. 3.

[0045] In operation 101 (shown in FIG. 3 ), system 50 may receive a request from an application to determine a location. This request may come from a foreground application or a background application. For example, a map application in the foreground, displaying a map to a user, requests a location, and this request may cause GNSS processing system 68 to be activated. Alternatively, a resident background process may make a request for a location. The nature of the request may determine a priority for memory controller 72 to determine how and when to allocate a portion of cache 70 for use by GNSS processing system 68. For example, in some embodiments, a foreground application's request for a location may cause allocating a portion of cache 70 to GNSS processing system 68 to be a high-priority task, thereby allocating the portion as quickly as possible. Alternatively, a background application's request for a location may cause memory controller 72 to deferred its allocation of a portion of cache 70, giving memory controller 72 more time to allocate a portion of cache 70.

[0046] In operation 103, the GNSS processing system 68 may receive assistance data from, for example, a cellular telephone modem and processor 76. In one embodiment, a satellite almanac or other data source regarding satellites in view over a period of time may be received by the system 50 and stored for later use by the GNSS processing system 68. In operation 105, based on the satellites or space vehicles (SVs) in view (e.g., from a received satellite almanac), the GNSS processing system 68 may generate pseudo-random noise (PRN) codes for the GNSS SVs in view and / or generate code spectra of these pseudo-random noise codes from a DFT (e.g., see code spectrum memory 263 in FIG. 6 ). In one embodiment, the GNSS processing system 68 may generate these codes as needed and use them without storing them during the acquisition and tracking phases of processing GNSS signals. In another embodiment, during the acquisition and tracking phases of processing GNSS signals, the GNSS processing system 68 may generate such codes and / or code spectra of such codes from DFT (e.g., see code spectrum memory 263 in FIG. 6 ) as needed and use such codes and / or code spectra of such codes from DFT (e.g., see code spectrum memory 263 in FIG. 6 ) but also store such codes and / or their code spectra, but no longer store such codes once the tracking phase is completed. In one embodiment, a code spectrum may be generated (from the GNSS PRN codes of the GNSS SVs in view) but not stored (for more than about 1 millisecond), and the code spectrum may be repeatedly generated every millisecond (ms) of GNSS sample data received and stored (e.g., in a circular memory buffer); thus, in a first ms, a code spectrum is generated by applying a code Doppler (e.g., time shift) and a carrier frequency Doppler adjustment (e.g., see FIG. 6 and FIG. 9D ) to the generated GNSS master PRN code, then performing a DFT (e.g., by DFT ALU 261), and then generating a new code spectrum in a second ms (the next millisecond after the first ms). One benefit of applying code Doppler and carrier frequency adjustment before generating the code spectrum (e.g., via DFT ALU 261 in FIG. 6 ) is that, because the code Doppler rate of the E5 GNSS signal is high, the code spectrum cannot be pre-calculated or even used in subsequent milliseconds, and therefore the code Doppler should be shifted every millisecond interval to maintain high correlation. In one embodiment, if memory is available, the Doppler-shifted code spectrum can be stored for a short period of time to reduce computing resource usage. Generating these codes on demand (which continues until a position is determined) without long-term storage or without any storage can reduce the amount of memory used by the GNSS processing system 68. Similarly, sharing cache memory 70 with one or more application processors 66 can also reduce memory usage by the GNSS processing system 68.In operation 107, a portion of cache memory (such as SRAM memory) on the integrated circuit containing the GNSS processing system and one or more application processors may be allocated, for example, by the memory controller 72. This may then allow the acquisition engine in the GNSS processing system 68 to use the allocated portion, at least during the acquisition phase.

[0047] The acquisition phase typically involves determining the frequency and master code phase of the acquired PRN code, as well as the identity of the satellite that transmitted the acquired PRN code. When a correlation operation indicates a match between a locally generated PRN code and a received PRN code, the PRN code is acquired. In one embodiment, in operation 109, an acquisition engine in the GNSS processing system uses the allocated portion to store hypothesis data and / or GNSS PRN codes. Then, in operation 111, the acquisition engine acquires one or more GNSS signals to allow a tracking engine in the GNSS processing system to track the acquired GNSS signals, thereby determining a virtual range from the GNSS SV that transmitted the GNSS signal acquired by the acquisition engine. In one embodiment, in operation 113, after the tracking phase begins, the portion of cache memory may be de-allocated. For example, the memory controller 72 may deallocate the portion of the cache that already contains the hypothetical data, but if the GNSS PRN code and / or its code spectrum from the DFT (e.g., see the description of code spectrum memory 263 below) is already stored in the cache, then the GNSS PRN code and / or its code spectrum from the DFT is retained for tracking. In an embodiment where the PRN code and / or its code spectrum from the DFT is not stored but is temporarily generated during use (e.g., see the description of code spectrum memory 263 below), then deallocating the portion of the cache used by the acquisition engine may be a complete deallocation, thereby freeing the cache 70 for use by one or more application processors 66. In operation 115, the GNSS processing system 68 may then derive a virtual range and use the virtual range and the ephemeris data in the GNSS SV to determine position data for the system (e.g., system 50).

[0048] In one embodiment, the GNSS processing system 68 may include a dedicated memory separate from the cache 70 and dedicated to the GNSS processing system. In one embodiment, the memory controller 72 may include a first port controller for controlling reads and writes to the portion of the cache 70 used by the acquisition engine, and a second port controller for controlling reads and writes to the remaining portion of the cache 70. In one embodiment, when position data is requested (e.g., based on information about the SV's health and information about the SVs in view), GNSS PRN code generation and / or code spectrum generation from DFT may be performed only for healthy GNSS SVs in view. This selective generation of GNSS PRN codes and / or code spectrum generation from DFT, without storing these codes after the tracking phase or during the acquisition and tracking phases (except for registers and buffers in the pipeline processing logic), reduces memory usage by the GNSS processing system. The pipeline processing logic may include registers and buffers that temporarily store codes and code spectra during one or more clock cycles. In one embodiment, the GNSS processing system 68 may use the array processing architecture described below (such as the architecture shown in Figures 6, 7, 8, and 9) to further reduce GNSS processing system memory usage by, for example, using an in-situ DFT algorithm.

[0049] In one embodiment, the operating system (or processor firmware) may allocate a portion of the cache to the GNSS processing system based on information about the data stored in the cache (which may be referred to as metadata). For example, the metadata may indicate whether the data stored in the cache was "tampered with" (e.g., modified while stored in the cache) or stored in a backup storage (such as non-volatile storage (e.g., flash memory) or even DRAM) before the portion of the cache was allocated for use by the acquisition engine. For example, if the cache was storing computer program instructions or code stored in non-volatile storage before the portion of the cache was allocated for use by the acquisition engine, and these computer program instructions had not been modified while in the cache, then the portion of the cache can be allocated to the acquisition engine without having to write the data in that portion out to DRAM or out to non-volatile storage. This allows the operating system (or processor firmware) to quickly clear a portion of the cache so that it can be quickly allocated for use by the GNSS processing system's acquisition engine. In the example shown in FIG2 , the GNSS processing system shares a memory (e.g., cache 70) with one or more application processors (APs); in an alternative embodiment, the GNSS processing system may share another memory with other processing systems on the IC (e.g., one or more other processors). In this alternative embodiment, the GNSS processing system shares another memory and does not use or shares the cache of the one or more APs. The other memory, the GNSS processing system, and the other processing systems may all be located on the same IC (e.g., a SOC that also includes one or more APs and their cache). The other processing systems may be one or more modem processors or graphics processors or code that uses another memory separate from the cache used by the one or more APs. This separate (on the same chip) other memory may also be a two-port ("dual-port") memory that supports high-frequency data access (read and write). As described herein, the memory controller can arbitrate access to the other memory when both the GNSS processing system and the other processing system attempt to access the other memory simultaneously. In one implementation of this alternative embodiment, the other memory can be processor-local memory of one or more of the other processing systems, and the one or more of the other processing systems uses the processor-local memory exclusively except when the GNSS processing system needs to use the processor-local memory.

[0050] Another aspect of the present invention involves using an array processing architecture with a DFT to acquire and track GNSS signals, such as from an E5 GNSS SV. This aspect is illustrated in Figures 4, 5A, 5B, 6, 7, 8, 9A-9D, and 10 and will now be described with reference thereto. Figure 4 shows an example of a portion 150 of a GNSS receiver that receives GNSS signals and stores them in a two-dimensional (2D) baseband sample array after performing analog-to-digital conversion. The GNSS receiver may include a GNSS radio frequency (RF) front end 153 that receives GNSS signals via an antenna 151 coupled to the GNSS RF front end 153. In one embodiment, the GNSS RF front end 153 receives only L5 WB GNSS signals.

[0051] Figure 12 shows an example of components and architecture that can be used in one embodiment of the GNSS RF front-end 153. As shown in Figure 12, the GNSS receiver includes an RF front-end module 701 and a digital front-end 703 located on an ASIC (which can be part of the SOC 52). The RF front-end module 701 can be separate from the ASIC containing the digital front-end 703. The RF front-end module 701 can be implemented in an RF integrated circuit (IC) coupled to a GNSS antenna 707 tuned to receive L5 WB GNSS signals. The GNSS antenna 707 is typically off-chip and therefore not located on the RF IC. The GNSS antenna 707 receives the GNSS signals and provides them to a bandpass filter 709. The bandpass filter 709 is configured to pass signals centered at 1192 MHz with a passband width of 51 MHz. Therefore, GNSS signals between approximately 1166.5 MHz and 1217.5 MHz pass through the bandpass filter 709. The output of bandpass filter 709 is coupled to LNA 711 to provide the bandpass-filtered GNSS signal to LNA 711. In one embodiment, GNSS antenna 707 is tuned to receive only L5 WB GNSS frequency signals. The RF front-end module may include a low-noise amplifier (LNA) 711 that is tuned and optimized for receiving only the L5 WB band. The GNSS receiver shown in FIG12 does not include other LNAs that receive other GNSS signals (e.g., L1 GPS). The output of LNA 711 may be filtered by a bandpass filter 713, and the output from filter 713 is amplified by amplifier 715 on the ASIC containing digital front end 703, and then an ADC 717 converter produces digitized GNSS sample data, which is then processed in one embodiment to produce two streams of digitized GNSS sample data: one GNSS sideband A and the other GNSS sideband B. A clock generation phase-locked loop 719 and clock dividers 723 and 725 generate clock signals that are used by ADC 717 and CIC decimators 721 and 729 to produce digitized GNSS sample data having up to four GNSS signal components (e.g., E5AI, E5AQ, E5BI, and E5BQ). The down-converter 727 separates the I signal from the Q signal, and the sideband splitting down-converter 731 separates the upper sideband from the lower sideband to provide GNSS sample data for storage in a baseband sample memory (such as the baseband sample memory 253 in FIG. 6 ).In one embodiment of a GNSS receiver shown in FIG12 , the GNSS receiver has a direct connection from an LNA (e.g., LNA 711) through one or more filters (e.g., bandpass filter 713) and / or one or more gain stages (e.g., amplifier 715) to an analog-to-digital converter (ADC 717). This GNSS receiver does not have an RF mixer, and therefore, no RF mixer is present in RF front-end module 701 and no RF mixer is present in digital front-end 703. Furthermore, this GNSS receiver does not have an RF reference local oscillator (e.g., a phase-locked loop) and does not perform frequency downconversion in the RF signal path before the ADC (e.g., ADC 717). In conventional GNSS receivers, an RF reference local oscillator and one or more RF mixers are used to implement RF frequency downconversion in the RF signal path before the ADC.

[0052] Referring back to FIG. 4 , the output from the GNSS RF front-end 153 may be provided to a radio frequency (RF) analog-to-digital converter (ADC) 155, which may generate digitized GNSS sample data from the digitized GNSS signal. In one embodiment, the output from the RF ADC 155 may be stored in a baseband sample array, such as baseband sample array 157 shown in FIG. In one embodiment, baseband sample array 157 may have N2 or more rows and N1 rows to provide an N2×N1 array (N2×N1). The number of samples in the array may be configured to meet the Nyquist criterion for providing a sufficient number of samples. If, in one embodiment, N1 = 20 and N2 = 1024, there are 20,480 samples over time (e.g., 1 millisecond or slightly more than 1 ms, such as 1.05 ms), which may meet the Nyquist criterion. RF ADC 155 is configured to repeatedly receive analog samples from GNSS RF front-end 153 over time and convert them into digitized GNSS samples for storage in array 157. For example, RF ADC may repeatedly convert samples of GNSS signals and store them in array 157. In one embodiment, array 157 may be implemented as a circular memory buffer that stores digitized samples. As is known in the art, a circular memory buffer may use a write pointer to indicate the next write location in the array and a read pointer to indicate the next read location. The write pointer is used when ADC 155 provides an output to be stored in the circular buffer, and the read pointer is used when the ALU reads the next set of inputs for processing. Array 157 may provide data to an arithmetic logic unit (ALU) 159, which is configured to perform DFT and inverse DFT to acquire and, in one embodiment, track GNSS signals. Figures 6, 7, 8, and 9 illustrate one embodiment of ALU 159. Before describing these ALUs 159, a method of using this array processing architecture will now be provided with reference to Figures 5A and 5B. The method shown in Figures 5A and 5B can use the array processing architecture shown in Figure 6.

[0053] In operation 201 shown in FIG5A , digitized GNSS sample data is stored in a two-dimensional memory array, which can be a circular buffer (such as memory 253 in FIG6 ) containing GNSS signal data slightly larger than a 1-millisecond frame (such as 1.05 or 1.25-millisecond GNSS signal data). One frame of E5 GNSS PRN code data in a GNSS signal is 1.0 millisecond long. The amount of additional memory beyond 1 millisecond can be determined based on the time required to calculate the spectrum of the input data (via a DFT) before it is overwritten. Therefore, a faster DFT means that a shorter additional time beyond 1 millisecond is sufficient. In one embodiment, the data in the memory array is formatted so that consecutive rows contain samples of consecutive time periods. For example, the first row may contain samples from time period t1 to t20, and the second row may contain samples from time period t21 to t40. Array 157 shown in FIG4 illustrates an example of such an array, which, in one embodiment, may be stored in baseband sample memory 253 in FIG6 . In one embodiment, the goal of these optimizations is to minimize the number of clocks required to perform a correlation procedure implemented using frequency-domain operations: namely, the inverse DFT of the product of the DFT of the input samples multiplied by the complex conjugate of the code samples adjusted for carrier frequency generates a correlation of the input samples under all possible code hypotheses under the carrier frequency hypothesis. This single step, defined herein, is referred to as very fast frequency-domain correlation (VFFDC), a form of frequency-domain correlation (FDC). Optimizing the data stream through these operations reduces the number of clock cycles required to perform the correlation. The advantage is that for a given system clock, the number of carrier frequency estimates or hypotheses that can be checked within 1 millisecond increases. Furthermore, reducing the clock means that system timing requirements can be relaxed, allowing for a more reliable chip design or a design that can operate at a lower voltage to reduce power consumption or at a faster clock to achieve greater throughput. Alternatively, a method for performing FDC that requires more clocks but at a higher clock frequency can be employed. The clocks required to perform FDC can be reduced using a matrix configuration (such as array 157), whereby the outputs of the sample and code spectrum are sorted so that the clocks required to perform the IDFT of the complex conjugate of the product can be reduced. Then, in operation 203, a GNSS processing system (such as the GNSS processing system shown in FIG. 6 or the GNSS processing system 68 shown in FIG. 2 ) can retrieve the GNSS baseband data from the two-dimensional memory array and load the retrieved GNSS baseband data into a set of DFT ALUs. For example, the set of DFT ALUs can be a set of four ASIC hardware DFT ALUs in an acquisition engine, each of which can perform 20 parallel DFT operations in response to a single program instruction. In one embodiment, the set of DFT ALUs can be the DFT ALU 255 shown in FIG. 6 .In operation 205, the GNSS processing system may generate PRN code data (or alternatively retrieve such PRN code data from storage) and / or generate a code spectrum for the PRN code data from a DFT for each expected GNSS signal source (e.g., each set of E5, L5, or B2 GNSS SVs known to be in view). Once the PRN code data is generated, it may be time-shifted and frequency-shifted, and sample interpolation may also be added (e.g., by adding a zero to pad the last bit in the code) to generate code data, which is then operated on by a set of DFTs (e.g., using the DFT ALU 261 in FIG. 6 ) to generate code spectrum data, which may be stored in a code spectrum array (e.g., the code spectrum memory 263 shown in FIG. 6 ). In one embodiment, the code generator 259 may perform operation 205 to generate code array data, and then the DFT ALU 261 shown in FIG6 may process the code array data to generate a code spectrum array (in row order), which is temporarily stored in the code spectrum memory 263.

[0054] It should be noted that the code Doppler on E5 band signals is much faster than that in the L1 band. This code Doppler is a carrier Doppler scaled by the ratio of carrier cycles to chips. In L1, there are 1540 carrier cycles per chip. In L5, for example, there are 116 carrier cycles per chip. Therefore, the number of chips in L5 is 13.28 times faster, which means that correlation in the E5 band requires faster code phase updates to accommodate consistent correlation within consecutive frames of the PRN code. This means that it is generally impossible to pre-calculate this effect. An alternative solution is to apply the code Doppler effect to the correlation results before adding a hypothesis memory. The storage address can be shifted to offset the code Doppler, but this results in some loss when the shift is quantized into the number of hypotheses, typically approximately 2 hypotheses per chip. Therefore, it is better to apply code Doppler to the generated code before generating the code spectrum. Another optimization scheme is to Doppler-multiply the carrier onto the generated code to match the carrier information in the input samples. This way, the DFT of the input samples only needs to be performed once per millisecond for each sideband and / or centerband, and the same input spectrum can be used for all correlations performed within that millisecond.

[0055] In operation 207, a set of DFT ALUs (such as DFT ALU 255 shown in FIG6 ) can simultaneously perform multiple DFTs on the loaded GNSS baseband data using a time decimation method and store the results in a frequency-domain result memory (such as memory 257 shown in FIG6 ). In the example shown in FIG6 , operation 207 performed by DFT ALU 255 generates an array, which is arranged in a row order and stored in memory 257. The data in memory 257 can be retrieved to provide an output 258 shown in FIG6 . Output 258 in operation 209 can be multiplied by the code spectrum stored in a code spectrum memory (such as code spectrum memory 263); in the example shown in FIG6 , multiplier 265 performs this multiplication in operation 209 and generates a product array of data. Then, in operation 211, a set of inverse DFTs may be performed on the data in the product array using a frequency decimation method, and these DFTs may use conjugate inputs to generate the inverse DFTs. In one embodiment, the inverse DFT ALU 267 shown in FIG. 6 may perform operation 211, and the output from the inverse DFT ALU 267 may be processed in a correlation post-processing operator 269 shown in FIG. 6 and then stored in a memory, which may be referred to as an integration memory (such as memory 271 shown in FIG. 6), in operation 213. In one embodiment, the integration memory may store hypothesis data during the acquisition phase. In one embodiment, the integration memory may be in a portion of a cache (e.g., cache 70) allocated for use by the acquisition engine of the GNSS processing system, which includes the array correlator of FIG. 6. The GNSS processing system can then perform operation 215 by determining the frequency of the acquired PRN codes, which identify the GNSS SV that transmitted them. Once it is confirmed that a GNSS signal has been acquired from a particular GNSS SV, operation 217 can then be performed for each acquired GNSS SV's signal by entering a tracking mode for the acquired GNSS signals. In one embodiment, the tracking mode can use a conventional correlator or other techniques such as DFT to determine the virtual distances to the acquired and tracked GNSS SVs. This is shown as operation 219 in FIG. 5B . The GNSS processing system can then use the determined virtual distances to derive a position of the GNSS receiver, i.e., by using the virtual distances of the tracked GNSS SVs (with ephemeris data) to derive a position (e.g., a latitude and a longitude of the GNSS receiver), as is known in the art.

[0056] FIG6 illustrates an example of a fast frequency domain correlator architecture that can implement the method shown in FIG5A and FIG5B. Memory 253 can be a circular buffer memory that stores N2×N1 samples of digitized GNSS signals. In one embodiment, memory 253 can be two circular memory buffers that store GNSS sample data of 1.05 or 1.25 ms; one of these circular memory buffers can store GNSS Sideband A sample data, and the other can store GNSS Sideband B sample data. The two different sidebands can be separated and then stored using the following method. To obtain the upper sideband (e.g., E5B or B2B), the GNSS sample data is digitally down-carrier shifted (for a sampler centered at 1191.795 MHz) by, for example, 15.345 MHz (and thus will now represent information in sample data that was originally 1207.14 MHz), and then filtered by a low-pass filter to extract a data bandwidth of + / - 10.23 MHz, and then the filtered sample data is down-sampled from a wideband sample to a lower sampling rate for processing in the pipeline shown in FIG6 . To obtain the lower sideband (e.g., E5A, B2A, L5, or QZSS), the GNSS sample data is digitally up-shifted (for samples centered at 1191.795 MHz) by, for example, 15.345 MHz (and thus now represents information in sample data originally at 1176.45 MHz). The shifted data is then filtered by a low-pass filter (LPF) to extract a data bandwidth of + / - 10.23 Hz. The filtered data is then downsampled from a wideband sample to a lower sampling rate for processing in the pipeline shown in FIG6 . DFT ALU 255 retrieves data from memory 253 and performs a set of DFTs within DFT ALU 255; FIG7 shows an example of the components within DFT ALU 255. In the example shown in FIG7 , there are two DFT stages. The first stage uses N1 DFTs, each of which operates on 1024 points based on inputs including a phase factor input from array 301 and data from memory 253, which may be similar to the data shown in array 157 in FIG4 . The input to this array may be, for example, input 251 provided by an analog-to-digital converter (such as RF ADC 155 shown in FIG4 ). FIG7 shows a set of 20 DFT operations, three of which are shown as operations 303, 304, and 306. The results of these operations may be stored in a partial result sample array 308, which in turn provides an output that serves as an input to the second stage, in which there are N2 DFTs; these N2 DFT operations include the two operations 313 and 315 shown in FIG7 .One of the inputs to these N2 DFTs is a set of phase factors from an array 311. The outputs of these DFT operations from the second stage shown in FIG7 are stored in an FFT result array 257, with the data stored in a row order that is the reverse of the column order in which the data is stored in memory 253. This reversal allows the data to be prepared for inverse DFT operations, such as those performed by inverse DFT ALU 267, without having to transpose or otherwise reformat the data.

[0057] FIG8 shows one embodiment of inverse DFT ALU 267. In the example shown in FIG8 , the inverse DFT ALU may include two DFT operation stages that receive data from the product array from multiplier 265. The first stage may include N2 DFT operations, which use data from the product array generated by multiplier 265 (with conjugate inputs) and phase factors from a phase factor array 351 to produce outputs, which may be stored in a first-stage sample array 361. Each of the N2 DFT operations in FIG8 is performed on 20 data points. FIG8 shows two of the total N2 DFT operations: DFT operations 355 and 357. In the example shown in FIG8 , the second stage of DFT operations uses N1 DFT operations, each of which operates on N2 points. FIG8 shows three of these operations, 363, 365, and 367, each of which receives a row of data from the first-stage sample array 361. These second-stage DFT operations also receive a phase factor input from the phase factor array 353 and generate 20 outputs that can be post-processed in the post-processor 371 shown in FIG8 . The results of the post-processing can be stored in the integration array 373, which can be the same as the integration memory 271 shown in FIG6 . The phase factors from arrays 301 and 311 (in FIG7 ) and arrays 351 and 353 (in FIG8 ) specify the required phase shift for each radix (20 / 16 / 8 DFT at each stage of the FFT). In one embodiment, these phase shifts are used to decompose a 20,480-point DFT into multiple radix stages—20 / 16 / 8 DFTs, which is an FFT implementation based on a DFT. The phase factors are also called "rotation factors" for an FFT.

[0058] Figures 9A, 9B, 9C, and 9D illustrate an example of a spectral code generator (and portions thereof) that can generate spectral codes that are stored in a code spectrum memory (such as code spectrum memory 263 in Figures 6 and 8). In one embodiment, as the GNSS processing system acquires and tracks GNSS SVs in view, the generator 259 and DFT ALU 261 shown in Figure 9D can only generate PRN codes and / or code spectra of DFT-generated PRN codes on-demand and temporarily for these GNSS SVs, but do not store (except briefly in registers and buffers within the processing pipeline for a few clock cycles) the generated PRN codes and / or their code spectra from DFT. This can improve memory usage by the GNSS processing system by reducing the amount of memory required to operate the GNSS processing system. In an alternative embodiment, the code generator may generate PRN codes and / or code spectra of PRN codes from DFTs only on demand for GNSS SVs in view, but store these codes during the acquisition and tracking phases until one or more positions (such as one or more latitude and longitude values) are determined. Thereafter, the PRN codes and / or their code spectra from DFTs may be deleted from storage to allow the storage to be used for other purposes. In one embodiment, as shown in FIG9D , the code spectrum generator 259 may use a polynomial generator 402 (shown in FIG9A ) to generate PRN codes from a code seed 401 for each GNSS SV in view. The generated PRN code can then be time-shifted in time shifter 404 using a set of programmable coefficients (based on these coefficients), and the generated and time-shifted PRN code can then be frequency-shifted by a frequency shifter that can use CORDIC phase rotations, three of which are shown as CORDIC phase rotations 408, 410, and 412. The phase rotations can be based on a programmable phase-divided input 406. Another set of CORDIC phase rotations (including phase rotations 417, 419, and 421) can then generate an output that is then processed by a DFT operation (in one embodiment, performed by DFT ALU 261 in FIG. 6 ) that is similar to the DFT operation performed on the digitized GNSS sample data. The results of the DFT operation (in one embodiment, performed by DFT ALU 261 in FIG. 6 ) are then, in one embodiment, stored in a code spectrum memory, such as code spectrum memory 263 shown in FIG. 6 .

[0059] FIG9A shows an embodiment of a polynomial-type generator 402. This embodiment can be used to implement the methods shown in FIG9B and FIG9C. If pre-calculated, this generator 402 includes two calculated (or pre-calculated) code shift matrices 501 and 502, retrieved, for example, from a lookup table. For example, for each of the four components of the Galileo E5A and E5B signals, there is a corresponding code type and master code polynomial information; this information is well known in the art and published in the ICD of the source of the GNSS constellation. Generator 402 can generate more than two of the master PRN code bits within a single clock cycle by using the calculated code shift matrices 501 and 502; see operations 955 and 957 in FIG9B. As shown in FIG. 9A , the calculated code shift matrix 501 includes a first input that receives a generator polynomial 503 that may serve as master code polynomial data for a given GNSS cluster and a given GNSS signal component, a second input that receives a value fed back from a register 515, and an output that is directed to a first input of a multiplexer (MUX) 511. A second input 507 to MUX 511 is a constant initial value of all 1s (14 bits, each of which is set to a value of 1 in one embodiment); this second input 507 is only used on the initial output from register 515, and thereafter MUX 511 selects the first input (to MUX 511) as the output from MUX 511 and stores that output in register 515 (which may be a clock-controlled register) so that on the next clock cycle the final output from MUX 511 is fed back to the second input of code advance matrix 501 and is also provided as a first input to XOR logic gate 519. The output from MUX 511 fed back to the second input (of code-advancing matrix 501) is multiplied by a constant value in code-advancing matrix 501 (derived from generator polynomial 503) to produce the next output from code-advancing matrix 501. This next output is passed through MUX 511 and stored in register 515. This process of feeding back the output from register 515 and performing a matrix multiplication of this output with the constant value in code-advancing matrix 501 is repeated on each clock cycle (or alternatively, on a set of several clock cycles) to generate N bits of the primary PRN code for a given GNSS cluster (e.g., Galileo E5) and a given GNSS signal component (e.g., E5AI) on each clock cycle. In one embodiment, N may be greater than 2, such as 10 or 14 bits. Therefore, the generator 402 can quickly generate a plurality of (eg, N) bits of the master GNSS PRN code within one clock cycle or a few clock cycles.In the example shown in FIG9A , 14 bits are generated at the output from register 515, but only the last 10 bits are used by XOR logic gate 519 (which performs an exclusive OR logic operation). Code shift matrix 502 is used in a manner similar to code shift matrix 501. Code shift matrix 501 and code shift matrix 502 (in one embodiment) are pre-calculated to generate, for a given GNSS cluster and GNSS signal component, and a given species for a GNSS SV in the given cluster, N bits below the primary GNSS PRN code (a "shift" of N bits) for the GNSS signal component from the GNSS SV (at the output of XOR logic gate 519) based on the values in the matrices and the previous outputs from registers 515 and 517. The Matlab Appendix includes an example of a code generator 402 that can form and use these pre-calculated code shift matrices, in the form of well-known Matlab code. In one embodiment, a pre-computed code shift matrix can be pre-computed (or calculated on the fly) by multiplying an original matrix containing master polynomial data N times to provide N shifted bits in the PRN code during each clock cycle. For example, if a shift of N=3 is desired, the original matrix ("A") is multiplied three times (A*A*A) to provide a code shift matrix for N=3 bits of output for the next three bits in the PRN code. As shown in FIG9A , the calculated code shift matrix 502 includes a first input that receives generator polynomial 505, which may be the master code polynomial data for a given GNSS cluster and a given GNSS signal component; a second input that receives a value fed back from register 517; and an output that is directed to a first input of MUX 513. A second input 509 to MUX 513 is a seed value for a corresponding GNSS SV in a given GNSS cluster. This seed value is used only for the initial output from multiplexer 513 and from register 517. Thereafter, MUX 513 selects the first input (towards MUX 513) as the output of MUX 513, and this output is stored in register 517 (which may be a clock-controlled register). This allows the final output from MUX 513 to be fed back to the second input of code advance matrix 502 on the next clock cycle and also provided as a second input to XOR logic gate 519. The output from MUX 513 fed back to the second input (of the code-shifting matrix 502) is multiplied (in a matrix multiplication operation) by the pre-calculated value in the code-shifting matrix 502 to produce the next output from the code-shifting matrix 502, and the next output is passed through MUX 513 and stored in register 517.On each clock cycle, an exclusive OR operation is performed on the outputs from registers 515 and 517 by XOR logic gate 519 to produce 10 new bits (i.e., a 10-bit shift of the PRN code). The 14-bit output is truncated during the current clock cycle to produce the 10 new bits. Code shift by 10 bits 524 can optionally be truncated. Then, an exclusive OR operation is performed on the output from XOR logic gate 519 and the secondary code bits 523 from a given GNSS signal component of a given GNSS SV to "erase" or "remove" the secondary code from the code generated at the output of XOR logic gate 519. Left shift logic 527, add sampling logic block 529, and left shift logic 533, along with registers 526 and 531, further process the generated primary PRN code to provide code samples that can be "aligned" with received GNSS samples at a specific sampling rate, ensuring that the sampling rates match and are aligned. The shift logic can be used to shift or move to different parts of the PRN code. The output from left shift logic 533 is provided to time shifter 404 in the code spectrum processing pipeline shown in FIG9D .

[0060] FIG9B and FIG9C illustrate a method for operating code generator 402. In operation 951, a GNSS processing system determines the GNSS SV in view, for example based on conventional assistance data (such as a recently downloaded version of a GNSS satellite almanac) or based on ephemeris data in the form of an equation. In one embodiment, the GNSS SVs in view may be limited to L5 WB GNSS SVs, such as one or more of the Galileo E5 GNSS constellation, the US L5 GNSS constellation, and the Chinese BeiDou / Compass B2 constellation. Then, in operation 953, the GNSS processing system may determine a code type and a code generator polynomial (which may be a set of known coefficients for the signal component) for each GNSS signal component from a GNSS SV in view (e.g., the E5AI and E5BI of a Galileo E5 GNSS SV) to generate a primary PRN code for the GNSS signal component. Then, in operation 955, a G1 code shift matrix is calculated (or pre-calculated and retrieved from a lookup table in non-volatile memory), and in operation 957, a G2 code shift matrix is calculated (or pre-calculated and retrieved from a lookup table in non-volatile memory). In one embodiment, each of the G1 code shift matrix and the G2 code shift matrix is pre-calculated by multiplying an original matrix of the master code polynomial data N times, where N represents the desired number of code bits to be generated. For example, if the code "shift" amount is 10 bits of the master PRN code data, the original matrix is multiplied (by itself) ten times to form a 10-bit code shift matrix. In one embodiment, the code "shift" amount is the number of bits of the master PRN code data generated within one clock cycle. Therefore, if N = 10, the code generator generates 10 new bits of the master PRN code data per clock cycle. After retrieving (if pre-calculated) or calculating the G1 code shift matrix and the G2 code shift matrix, the method can then continue in operation 959. In operation 959, the system uses the initial vector (all ones) to provide the first G1 output (thus, the first G1 output is the initial vector of all ones) and the system uses the code seed to provide the first G2 output (thus, the first G2 output is the code seed). In operation 961, the system performs an exclusive OR operation on the first G1 output and the first G2 output to provide the first set of N-bit PRN code data. After operation 961, the first set of N-bit PRN code data is processed in operations 969, 971, and 973 (as processing continues through 9X (from operation 961 to operation 969 shown in Figures 9B and 9C)), and all subsequent sets of N-bit PRN code shifts are generated in a loop of operations 963, 965, 967, 969, 971, 973, and 975.In operation 963, the G1 output (e.g., from register 515 in FIG. 9A ) is fed back into the G1 code forward matrix, and the G2 output (e.g., from register 517 in FIG. 9A ) is fed back into the G2 code forward matrix. Then, in operation 965, the last G1 output (e.g., from register 515) is multiplied by the G1 code forward matrix to produce the next G1 output, and the last G2 output (e.g., from register 517) is multiplied by the G2 code forward matrix to produce the next G2 output. In operation 967, an exclusive OR operation is performed on the G1 and G2 outputs (e.g., in XOR logic gate 519 in FIG. 9A ). In operation 969, an exclusive OR operation is performed on the code output from XOR logic gate 519 (e.g., in XOR logic gate 521) and the expected secondary code bit (e.g., secondary code bit 523) to erase or remove the secondary code from the code output. Then, in operations 971 and 973, code samples are generated and provided to the remaining code spectrum processing pipeline. These operations prepare the code samples so that their sampling rate matches the sampling rate of the received GNSS sample data. Operation 975 determines whether to continue generating GNSS primary PRN code data. In one embodiment, PRN code data generation can be terminated when tracking of all required GNSS signals is complete, but if such tracking is required, the process continues in a loop from operations 963 to 975.

[0061] FIG10 illustrates an example of a GNSS processing system that can be used to implement the methods or systems described herein. GNSS processing system 450 can be implemented on its own integrated circuit (e.g., a navigation chip 451) or as part of a system-on-a-chip architecture that is part of a larger system, such as a smartphone or tablet. GNSS processing system 450 can include processing logic, such as an ARM processor 466, which uses ARM program and data memory 467 to control the operation of GNSS processing system 450. GNSS processing system 450 can also include an RF ADC 465, which can be similar to RF ADC 155 shown in FIG4. GNSS processing system 450 can also include clock phase-locked loop (PLL) generation and gating circuitry 464 to use the PLL and generate clocks for other operations within GNSS processing system 450. GNSS processing system 450 may include both logic modules and memory to perform the acquisition and tracking procedures described herein. For example, logic module 457 may include an acquisition engine 458, which may include a set of DFT and inverse DFT processors or ALUs to perform the DFT operations described herein. Additionally, logic module 457 may include a digital front end 460, which may be located in all digital E5 GNSS front ends to provide processing before and after RF ADC 465. Logic module 457 may also include a plurality of satellite signal generators (such as satellite signal generator 459), which generate GNSS PRN codes for GNSS satellites (SVs) in view based on assistance data received, for example, from a cellular data communication network. Logic module 457 may also include a timing and control module 461 and a memory interface and bus control module 462 to allow the GNSS processing system to be coupled to one or more application processors. Logic module 457 may be coupled to one or more memories for storing various data in various data structures. For example, the one or more memories include baseband sample memory 468, acquisition engine command memory 469, FFT program memory 470, FFT constant memory 471, FFT variable memory 472, FFT result memory 473, code spectrum generation memory 474, coherent integration memory 475, IFFT memory 476, IFFT memory 477, IFFT variable memory 478, and non-coherent integration memory 479. These memories may be used in conjunction with logic module 457 to perform the operations described herein. It will be appreciated that alternative architectures may utilize processor and memory configurations different from those shown in FIG. 10 .

[0062] In another embodiment, the clock frequency required to perform the DFT calculation is reduced by executing multiple cores in parallel. For example, if the sampling rate is chosen to be 2^N (e.g., N=14), a radix-4 core with seven stages can be used to perform the DFT. Each step of each stage processes four samples in real time. Assuming only dual-port memory, with one read and write per cycle, the clock frequency required per stage is 4*4096, and seven stages require 114,688 clocks. The VFFDC shown in Figure 6 can perform a DFT in approximately 4096 clocks. To achieve similar performance, 32 cores can be implemented in parallel, completing one stage in 512 clocks, and seven stages in 3584 clocks. However, this approach requires the ability to process 32 input samples in parallel. Therefore, the advantage of VFFDC is that it can achieve a low clock rate while only reading 10 memories in parallel. Another embodiment uses a 4x higher clock rate and only requires 8 cores in parallel, reducing the parallel memory read requirement to 8 I / Os per clock. The advantage of VFFDC is that it maintains both a low clock rate and a low parallel memory read / write configuration. This optimization should allow for low power consumption, as the system can operate at a low clock speed and achieve reliable timing at low voltage.

[0063] In one embodiment, VFFDC implements a processing chain with minimal memory requirements. Every millisecond, two DFTs are performed on the input samples, one for each of the upper and lower sidebands of E5. Then, a DFT is performed on each component of each satellite signal (4 for E5, 2 for L5, and 4 for B2 in the future), including code Doppler and carrier frequency effects, eliminating the need to apply a different DFT to the input samples to remove the carrier frequency assumption. Another DFT is then performed to perform the inverse DFT on the product of the input and the code spectrum. Therefore, the total number of DFTs per millisecond is 2 + 2*N channels * M components, where the first 2 are the original input DFTs and the second 2 are the IDFTs of the product of the code spectrum and spectrum. For up to 22 channels with 4 components per channel, this results in 2 + 2*(22*4) = 178 DFTs per millisecond. If the code spectrum DFT is pre-computed, the input samples must be unique for each frequency of each PRN. In this case, the number of DFTs is (2*M*N) = 176, where M=4 and N=22. However, this requires memory to store the code spectrum. After each IFFT and before updating the hypothesis memory, this system would also require a method to generate the code Doppler. Therefore, even if the alternative approach uses a nearly identical number of DFTs, it still requires additional memory and may incur higher power consumption per millisecond to move the code spectrum DFT to the AE. For example, using 20,480 hypotheses per millisecond, the required bus rate would be 22 channels * 4 components * 2 bytes of I and Q code spectrum * 20,480 hypotheses * 8 bits / byte (28 Mbits / millisecond) = 28 Gbits / second. This configuration would be nearly impossible to implement. Therefore, on-site computing power makes this system feasible.

[0064] Another optimization approach to reducing system memory is to allow all four components of the E5 band signal (such as Galileo E5) and the future B2 to be processed into a single hypothetical memory for long-term integration. This overcomes weak signals due to high system losses in cellular phones and / or high losses due to attenuation of the signal by foliage or the user's body. The public domain interface control file for B2 only describes the lower sideband, but other technical papers suggest that the upper sideband signal structure will be available by the end of 2019 or later. Therefore, GPS L5, which has only one sideband, will have only two components, while E5 and B2 will have four components: two in each of the upper and lower sidebands.

[0065] The primary challenge in coherently integrating the sum of each millisecond code correlation is to reduce cancellation loss due to phase reversals at 1 ms intervals. If the primary code phase of the received signal can be estimated to be approximately 0.5 ms or less, the received signal spectrum can be at least partially aligned in time with the estimated code phase to avoid sub-millisecond cancellation. Figure 11 shows an embodiment that can provide precise time-coherent integration.

[0066] In one embodiment, estimating the expected partial primary (ms-long) code phase of a candidate signal requires knowledge of both precise time and initial position. As is known in the art, precise time can be derived from the secondary code phase of a first received signal or from a fine time source. This estimation can be performed as operation 601 in FIG11 .

[0067] Once the primary code phase uncertainty is reduced to well below 1 ms, the sub-millisecond cancellation problem can be solved by at least partially aligning the period of the received 1 ms signal with the time at which the code is expected to be received from each SV. This means that multiple received signal spectra must be calculated every millisecond, staggered in time to match the primary code spectrum, and thus reducing the extent of sub-millisecond coherence cancellation.

[0068] The search order determines which SVs, their signal components, and Doppler bins are searched for at each fractional phase offset. This is shown as operation 603 in Figure 11. Because long coherent integration yields greater sensitivity, the E5Aq and E5Bq pilot signals can be used preferentially because they have 100 ms-long secondary codes and no data bit reversals. In one embodiment, E5Ai and E5Bi can also be used if the navigation message symbols are predicted and removed, thereby eliminating or reducing their respective coherent cancellation losses. It should be noted that while the primary code phases of all signals are expected to be unevenly distributed across a millisecond, it is possible that the only processing slots available for a given signal are suboptimal. Regardless, the worst-case scenario where the first 1 / 2 ms of a signal cancels the second 1 / 2 ms in the case of a secondary code bit reversal is always avoided.

[0069] In one embodiment of the present invention, M 1ms signal spectra are calculated every millisecond, with each spectrum offset by 1 / M ms. For example, if M=4, then every 0.25 ms, a full 1 ms (or more than 1 ms) of received and digitized GNSS sample data is processed by FFT correlation (e.g., using the VFFDC architecture shown in FIG. 6 ). Therefore, in this case, the processing periods are separated and offset (one from the next) by 0.25 ms, and the received GNSS sample data is also offset by 0.25 ms. In this example, a first processing period at relative time 0.0 ms performs an FFT correlation on the 1 ms of GNSS sample data generated in operation 605. These correlations are shown as operation 607 in FIG. 11 . A second processing period at a relative time of 0.25 ms will process the FFT correlation (operation 607) using the 1 ms of GNSS sample data ending at the relative time of 0.25 (operation 605) and offset by 0.25 ms from the previous 1 ms of GNSS sample data. A third processing period at a relative time of 0.5 ms will process the FFT correlation (607) using the 1 ms of GNSS sample data ending at the relative time of 0.5 ms (operation 605) and offset by 0.25 ms from the previous 1 ms. Thus, operations 605, 607, and 609 are repeated four times during a 1 ms time interval. In an alternative, more sensitive embodiment, the signal spectrum is calculated to align as closely as possible with each expected satellite code phase.

[0070] In the case of coarse time mode, candidate signal codes (received GNSS sample data) and their associated spectra must be generated and aligned every millisecond and correlated with the signal spectrum using VFFDC or similar FFT-based methods.

[0071] When these resulting correlations are generated, they must be summed in a coherence hypothesis memory dedicated to each SV band and segment, removing the phase reversal associated with the secondary code. This is shown as operation 607. This process requires computing the full 1 ms correlation, but the code phase uncertainty is much less than 1 ms. However, only the portion of the full PN code that is likely to contain a correlation peak must be stored in the hypothesis memory.

[0072] At the subcode period boundary, or more often in some cases, the coherent hypothesis memory must be non-coherently summed into a non-coherent hypothesis memory that mirrors the coherent hypothesis memory but contains only magnitude information and thus preserves half of the memory. This is shown as operation 611.

[0073] The process in FIG. 11 continues in operation 613 (by returning to operation 605) until a correlation peak rises above the noise floor. Once the correlation peak rises above the noise floor with sufficient confidence, the search result is reported and the acquisition search for the particular SV of interest can be terminated, with the search proceeding to the next SV in the order to obtain its partial code phase. The search can also time out after a predetermined time interval and a search failure can be reported.

[0074] FIG11 shows an example of a method for searching for satellite codes aligned with an approximate time grid in which the satellite codes are expected to be received so that sub-millisecond coherence cancellation losses due to phase reversals can be reduced. This search can be performed based on a set of initial information, which in one embodiment can include at least two of the following: (1) a code phase of a primary or secondary code signal received from at least one GNSS SV; (2) a GNSS time estimated based on one or more time sources, the estimated GNSS time uncertainty being estimated (e.g., based on the known accuracy of the source) or known to be within + / - 0.5 milliseconds of the actual GNSS time; and (3) an approximate position of the GNSS receiver. Using this initial set, operation 601 of FIG11 can be performed. In effect, this initial set gives the system an estimate of GNSS time to enable acquisition using GNSS time.

[0075] A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read-only memory ("ROM"), random-access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory devices, etc.

[0076] An article of manufacture may be used to store program code. An article of manufacture storing program code may be embodied in, but not limited to, one or more memories (e.g., one or more flash memories, random access memories (SRAM, DRAM, or other random access memories)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards, or other types of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) via a data signal embodied in a transmission medium (e.g., via a communication link (e.g., a network connection)).

[0077] In the foregoing description, specific exemplary embodiments have been described. It will be apparent that various modifications may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the following claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. [appendix] [] The following appendix provides further information regarding some embodiments. These embodiments are non-limiting examples of GNSS receivers, portions of GNSS receivers, methods for operating such receivers or portions, and non-transitory machine-readable media that enable execution of such methods. Also included is a Matlab code appendix that provides examples of implementations of various components described herein in the form of well-known Matlab code. Appendix 1 appendix This appendix provides further information about various embodiments and aspects of the present invention and is not intended to limit the scope of any claims in the accompanying application body. A fully digital receiver architecture for commercially viable modern GNSS signal tracking Inventors: Paul Conflitti, Paul McBurney, Mark Moeglein, and Greg Turetzky [background] [] SnapTrack's development of Assisted-GPS between 1995 and 1999 (see, for example, U.S. Patents 5,663,734 and 5,812,087) brought GNSS tracking to mobile phones worldwide. At the time, GPS was the only operational GNSS constellation, and the L1 C / A signal was the only signal available for civilian use. The simplicity of the L1 C / A signal (with a 1 MHz chip rate and 50 BPS navigation messages) and the CDMA2000 cellular system architecture combined to create a two-receiver strategy suitable for mobile phones. They share a common oscillator, and the synchronous nature of the network enables time and frequency to be transmitted from base stations to mobile devices with great accuracy. This also enables the provision of assistance data to mobile devices, eliminating the need to read this assistance data directly from satellites, thereby saving significant time and processing power and significantly improving sensitivity. These same factors also enable Advanced Forward Link Trilateration (AFLT), effectively forming a virtual satellite network from synchronized CDMA2000 cellular base stations. The complexity of modern cellular networks (including 4G and 5G) and modern GNSS systems has continued to grow with the proliferation of a GNSS constellation encompassing Galileo (Europe), BeiDou / Compass (China), and a modernized GPS. These three constellations all intersect and share spectrum in the L5 band. GPS L5 is a 10.23 MHz extended bandwidth signal centered at 1176.45 MHz. Both Galileo and BeiDou use an altBOC code to spread the signal energy into two sidebands. Galileo's two sidebands (A and B) are centered at 1176.45 MHz and 1207.14 MHz, ±15.345 MHz from its center frequency (1191.795 MHz). It is similarly modulated using a 10.23 MHz code. Ultimately, Beidou has a signal on virtually the same frequency as Galileo, with the same spreading code length. India and Japan also have regional systems developed and transmitting in this band. The Japanese system, QZSS, uses a signal very similar to GPS. The Indian system has BOC modulation and a regular center frequency, but it also has a narrowband signal centered at 1176.45 MHz. Therefore, GPS, Beidou, Galileo, QZSS, and IRNSS all have signals in the 1176.45 MHz L5A band. Furthermore, Galileo and Beidou have similar signals centered at 1207.14 MHz, which will be referred to as the L5B band. GLONASS also has similar proposed signals at 1176.45 MHz and 1202.025 MHz. In practice, there are two sets of modern signals that share some common properties: some at L1, such as E1B and E1C, and some at L5, such as E5 and B2. Their main differences are in chip rate and code length. Here are some key advantages of these modern wideband GNSS signals under L5 compared to legacy signals or signals in other frequency bands: 1. Compared to GPS L1 C / A, the code length has been increased by a factor of 10 to further mitigate cross-correlation, and the up to four different signals broadcast by each SV are designed to be orthogonal to each other. Unfortunately, most of these signals use the same 10,230-chip code length and 10.23 MHz chip rate, so cross-correlation is still possible when one signal is directly received and another is relatively weak / indirect. 2. All signals are in the same frequency band, making it possible to track all signals using a single RF front end. 3. The pilot code enables enhanced sensitivity for tracking in blocked signal environments. 4. The AltBOC (15,10) signals of Galileo and BeiDou provide transmit diversity to improve fading resistance and multipath resistance. 5. The data and the guidance channel are orthogonal. This produces the following advantages: a. When combining signals (specifically, combining signals incoherently), the SNR is improved. b. Ability to coherently track the pilot channel limited primarily by oscillator stability and user dynamics. c. A pure PLL can be used for tracking instead of a Costas loop. This avoids the square loss of removing data bit inversion and allows the use of the full discriminator range of + / -180 degrees. 6. Advanced decoding of data on the data path to reduce the bit error rate. This allows data to be extracted at a lower SNR, thereby improving the ability to determine fine time using weak signals. 7. The secondary code with overlapping codes modifies the primary code frame. This reduces cross-correlation between codes by removing the constant phase sequence. Secondary coding also allows precise determination of GNSS time from the secondary code phase and, when the receiver clock uncertainty is less than the duration of the secondary code, the clock can be set with great absolute accuracy. 8. High chip rate: A higher chip rate narrows the correlation peak to reduce multipath and cross-correlation. 9. Codes completed in under 1 millisecond. This allows for faster acquisition and a feasible FFT method using circular convolution. This enables commercially viable modern-only GNSSS receivers (COVIMOGR). The longer the code, the greater the acquisition cost. Modern codes at L1 are typically longer and therefore more difficult to directly acquire. The key advantages of these modern GNSS signals (extended codes and higher chip rates) also present greater challenges for receivers than in the past, but modern correlator hardware can easily meet these challenges, as will be demonstrated in another example herein. Receiver manufacturers plan to first acquire L1 band signals (GPS C / A codes, Galileo E1, BeiDou B1 or B1C, or GLONASS FDMA) and then transition to L5 tracking, as the computational burden of tracking longer codes can be daunting when the timing uncertainty is around 1 ms. Some have proposed frequency domain correlation to solve this problem of directly acquiring the broadband 10.23 MHz signal. However, strategies for doing so rely on substantial FFT hardware, which contains far more memory than is commercially viable for consumer applications such as cell phones, wristbands, and even car navigation. While the embodiments described herein are suitable for standalone GNSS receivers, it is recognized that the most important market for GNSS receivers is as components of larger mobile devices, such as cellular phones. The complexity and data-carrying capacity of mobile networks have increased substantially, but the reliably available time and even frequency synchronization associated with Qualcomm's 2G and 3G technologies, while still supported, is no longer guaranteed for 4G and 5G systems. As a result, Qualcomm's AFLT technology for base station ranging is generally no longer supported, and has been replaced to some extent by multi-cluster GNSS tracking. Furthermore, at the time of this writing, fine timing assistance, used to help synchronize these networks, is not yet widely available. Therefore, any commercially viable direct L5 acquisition strategy (i.e., without L1 GPS) must allow for significant time uncertainty and even frequency uncertainty, and also accommodate the possibility that fine time and frequency assistance will be unavailable. Where cellular data (e.g., the internet) is available, time transfer protocols such as NTP and SNTP typically limit this time uncertainty. The limiting frequency uncertainty is the cellular carrier frequency, which itself is subject to availability and variations depending on the network type and implementation. Therefore, any modern AGNSS-capable design must accommodate varying initial time and frequency uncertainties. The benefits of direct L5A only track certain key benefits of L5 over transitioning from L1 to L5, including: 1. Eliminate one RF front end, including expensive antenna, LNA and SAW filter. This also substantially reduces the difficulty of integration. 2. A signal with improved sensitivity and resistance to fading can be obtained. 3. Substantially reduce the problem of far-remote correlation acquisition. 4. Reduce congestion and susceptibility to disruption. Some disadvantages include: 1. Currently, there are relatively few SVs supporting modern signaling. This gap is expected to narrow rapidly in the coming years. 2. Increased complexity, especially during acquisition. [decline] [] Pf L1 is defined as the probability of a frequency on L1 being large enough to cause a carrier tracking loss, and Pf L5 is defined as the probability of a carrier tracking loss on L5. Pf L1 and Pf L5 are related by the signal path, but are independent of the different expected C / No. Typically, when the data and pilot energy at L5 are synchronously combined, the L5 signal is expected to be enhanced by 3dB, so that Pf L5 <p fl1。 在一衰落環境中在l1處獲取信號本質上將係不可靠的,因此若接收器天線處於一局部零位中,則無法在l5處獲取信號,更不用無法進行追蹤。 在任何給定時刻,p acq變成1-p fl1。ptrack在其後,最初且用於重新獲取(1-p fl1)*(1-p fl5)。 在直接獲取情形中,p acq僅為(1-p fl5)。然而,就信號處理及記憶體兩方面而言,直接獲取大約要複雜一個數量級,且在無l1載波輔助之情況下維持載波追蹤也同樣可能會更加困難。 因此,在所有rician及rayleigh衰落場景中,直接獲取可靠性皆明顯變大,對於具有實質性主體阻塞、線性天線及混亂環境之消費型應用而言尤其如此。然而,在最惡劣環境中追蹤l1及l5信號會產生傳輸分集增益。然而,考慮到l5下之碼追蹤相對不準確及l1信號弱,損耗並不明顯,尤其是在主gnss集群之l5頻帶信號達到完全可操作性之後。 與在l5下追蹤複數個可分離信號相關聯之分集增益亦使得l1追蹤不太重要。雖然自額外載波獲得某些效能增益,但其實質上小於在l5下自額外載波獲得之增益。 以具有複數個可分離波瓣之伽利略e5 altboc信號為例。若一接收器僅追蹤e5 a及e5 b,但只需要一者或另一者來保持其載波平滑及增量位置解之連續性,則可將p slipe5ab定義為p slipe5a*p slipe5b。在例如p slipe5a="P" slipe5b="0.001之情形中,P" slipe5ab將係0.000001。雖然追蹤e1確實可提供更大載波追蹤可靠性,但藉由限制對e1的獲取及再次獲取以及e1處較弱信號以及較低精確性碼,該增益在某種程度上會無效。e5信號包含比兩個主波瓣低大約10db之3個額外波瓣,從而提供進一步使得不需要獲取或追蹤e1之一額外分集形式。 顯然,對於l5-i及l5-q信號而言,可用傳輸分集較少,且因此l1及l2c追蹤仍可十分有意義,尤其在支援l5之衛星集群擴大之前。此亦可使得沿著射線路徑更好地局部量測電離層tec。長遠來看,具有預期可用b2b信號之北斗更類似於伽利略。 本發明實施例之說明 下圖闡述根據本文中所闡述的本發明之一方面之一項實施例之一個可能數位信號處理前端。 天線–>Filter -> LNA -> RF downconverter (from 1189MHz to DC with + / -54MHz bandwidth). Sampling at 108MHz generates in-phase (realC = cosine) and quadrature (imagC – sine) samples. The bandwidth extends from + / -54MHz around the L5 center frequency of 1191.795MHz. GNSS receiver front-end signal processing flow chart Sideband A is centered downward at 15*1.023 MHz, and sideband B is centered upward at 15*1.023 MHz. This generates a 15*1.023 MHz digital local oscillator, which is called the sideband SB. By performing a frequency shift, the sideband A below -15*1.023 MHz is shifted to DC: Ai = real * cos(SB) – imag * sin(SB) Aq = imag * cos(SB) + real * sin (SB) The signal is then low-pass filtered and decimated from 100 MHz to 16.384 MHz using a clock divider. Similarly, the upper sideband B of 15*1.023 MHz is shifted to DC by performing a frequency shift: Bi = real * cos(SB) + imag * sin(SB) Bq = imag * cos(SB) - real * sin (SB) The signal is then low pass filtered and decimated from 108 MHz to 20.46 MHz using a clock divider. The decimator is simply a clock divider that generates 20,460 clocks from 108,000 samples in one millisecond. A commercially viable direct-acquisition wideband GNSS receiver should efficiently utilize its limited resources, depending on the state of the acquisition and tracking process. Applications without minimal data connectivity must utilize the "air search" mode, but the more interesting scenario is when assistance data is available and does not need to be derived from satellite signals. These pieces of assistance information can be broadly categorized as receiver clock settings (time), oscillator training (frequency), initial position, satellite position, and satellite clock information (ephemeris). Based on the quality of all these forms of assistance, in various embodiments, the commercially viable modern unique GNSS receiver (COVIMOGR) described herein should be able to acquire signals and derive the required assistance information as quickly as possible. To this end, three different acquisition modes are described: 1. Air Search: A key auxiliary component described above is effectively missing, and the receiver must therefore "air search" for all signals from all known clusters. This is the least attractive scenario, as its use cases have diminished in a connected world. In this sense, it is a slowed-down, widened version of Mode 2. 2. Coarse Time: The receiver clock time is known to within a few seconds but less than 0.5 ms (the more accurate the better) and a moderately accurate initial position is available. Direct acquisition in this mode is challenging because most signals under L5 are wideband, with millisecond codes an order of magnitude longer than those under L1-C / A. For COVIMOGR, attempting to directly correlate with these signals using a time-domain correlator library is computationally infeasible, especially for receivers that must acquire in obstructed environments and have suboptimal antennas, typically for commercial applications. 3. Precise Time: Once a first satellite signal is acquired or fine time assistance is received, the uncertainty of the millisecond code phase for each satellite can typically be reduced to approximately 100 microseconds or less, provided sufficiently accurate assistance information is available. In this case, signal processing is performed in a precise time mode to achieve maximum sensitivity and minimize resource allocation. The precise time source can be the initial signal or signals that have been acquired and / or tracked, or it can be based on network assistance, or a combination thereof. Once a signal is acquired from each SV, it is passed to a tracking engine that reads the navigation message data and provides ongoing virtual range, Doppler, and carrier phase measurements. Additionally, it can read the phase of the secondary code, allowing millisecond code phase to be extended to the virtual range of all SVs, a key benefit for precise time acquisition mode. Signal Processing in Coarse Time Mode: For the most complex case, this article will describe the acquisition of the Galileo E5 dual-sideband altBOC code. Alternative approaches for processing single-band BeiDou and GPS signals will also be described. Each SV supporting altBOC now has 20,460 samples per millisecond, one for each of the A and B sidebands, for both I and Q. By using E5 (a 1 PPM oscillator) and acquiring auxiliary information, it is expected that 1 PPM = 1191 Hz, for example, an oscillator frequency uncertainty of 1200 Hz, can be covered. Because the modernized signal is re-decoded on both the data and pilot channels, in one embodiment, only non-coherent integration is used with coarse timing. A longer coherent integration would observe phase reversals, thus canceling the integrated energy over a millisecond. For a 1 millisecond integration, a 500 Hz frequency step would result in a 2 dB sinX / X loss. Furthermore, after shifting to the low IF, the codes on the A-band and B-band are misaligned by 116.5 carrier cycles per chip. Therefore, this misalignment must be corrected for long-term correlation. Typically, the integration time is limited by the time it takes to integrate 1 / 2 a time / frequency search unit, where the frequency error is half the frequency search step size. Integrating longer than this means that energy is dragged from one code search grid to the next, limiting the effectiveness of the integration. Code ambiguity = Carrier frequency error / Carrier cycles per chip / Cells per chip * dt (seconds) Resolving the frequency error required to recover a certain number of dB for a given dt and limiting the smear to ½ cell gives 250 milliseconds. Frequency error = ½ * carrier cycles per chip / 20460 cells / 10230 chips / dt = ½ * 116.5 * 10230 / 20460 / 0.25 = 116.5 Hz [Note: Math reworked using 20460 cells instead of the old 16384 assumption] The frequency step size is then programmed to be twice the frequency error, so the frequency step size is approximately 233 Hz. To cover + / -1 PPM = 1191*2 = 2383 Hz with a step size of ~233 Hz, approximately 10 frequency bins are required. For the purposes of this example, it is assumed that the frequency uncertainty associated with unknown user motion, user position, or user clock is negligible. Note: The term mixer is used to denote a channel that effectively performs time-domain correlation of the input signals. Each modern satellite being searched has up to four codes. Correlation is performed using FFT. Correlation = inverse FFT (sample FFT * complex conjugate of code FFT). The amplitude of each correlation hypothesis is integrated in the hypothesis memory. This mixing is done to cover the entire frequency uncertainty range. To search for all SVs in the field of view within 1 second implies ~24 * 10 frequencies, with an integration time of 0.25 seconds per frequency. This would require 60 discrete mixers. This number is considered too high for at least some embodiments. Therefore, in one embodiment, the integration time can be reduced to 0.1 seconds. This only requires 24 mixers. However, each mixer must mix each of the four components of the E5 signal. This means, in one embodiment, 96 FFTs must be performed in parallel. Each FFT must nominally have 20480 (cells) * 16 bits (I or Q word size) * 2 (for each I, Q) = 0.625 megabits. Multiplying by 96 gives 60 megabits = 7.5 megabytes. In addition to the FFT memory, each mixer requires memory for integrating the incoherent or coherent code hypothesis memory. In one embodiment, a very compact representation of 8 bits per cell is assumed. In one embodiment, this requires a method to shift out the linearly increasing noise floor average associated with the incoherent integration of the amplitude every millisecond. Conveniently, the power of all four codes for the 20,460 cell hypotheses at each mixer can be integrated into the same memory for the incoherent integration. Therefore, each mixer requires 20,460 bytes, and the total hypothesis memory can be: hypothesis memory = 20,460 cells / mixer * 24 mixers * 8 bits / cell = 3.74 megabits = 0.468 megabytes. In one embodiment, which will be referred to as a double buffer, the sampled data is copied into each mixer every millisecond and processed in two stages, as shown below. Top-level time series image In another embodiment, a circular buffer can be used to reduce the signal buffer memory by nearly a factor of 2. However, substantially faster signal processing will be required than completing it in just 1 MS. The preferred embodiment of the present invention uses FFT to perform correlation, where correlation = inverse FFT (sample FFT * complex conjugate of code FFT). The amplitude of each correlation hypothesis is integrated into the hypothesis memory. In Phase 1 of the first embodiment described above, the FFTs of the samples are calculated. These FFTs can be used in all mixers. Because a reduced number of FFTs are being run at this time, power can be saved in Phase 1. In practice, the channels are not active in Phase 1, although some of their FFT resources are borrowed to generate the FFTs of the samples. Typically, eight FFTs are performed in Phase 1: one FFT for each of the 0 Hz, 250 Hz, 500 Hz, and 750 Hz carrier-erased versions of the input samples for both Channel A and Channel B. In Phase 2, the sample FFT (the FFT of the received GNSS sample data) is complex multiplied by the code FFFT (the FFT of the locally generated GNSS SV PRN code), and then an inverse FFT (IFFT) is performed. The IFFT is effectively equivalent to an FFT. The code FFT is temporarily calculated during the setup period, or pre-calculated and stored in non-volatile RAM or ROM. To minimize computations, the following improvements may be used in certain embodiments. 1) First, samples are carrier-erased at three incremental frequencies: 250 Hz, 500 Hz, and 750 Hz, generating four sets of samples, including the original sample at 0 Hz. These four sample sequences are then subjected to an FFT to generate four FFTs. In stage 2, when a specific Doppler must be applied to the sample sequence to eliminate the Doppler, an FFT technique is employed. Specifically, the FFT is shifted by + / -N bins to obtain another incremental frequency shift of + / -N*1 kHz. For example, to achieve a search frequency of 4321 Hz, two incremental frequency methods are combined to approximate the desired Doppler. The 250 Hz FFT is first selected because it is closest to the sub-kHz frequency band. This FFT is then shifted by 4 bins to obtain a total shift of 4250 Hz. A negative frequency of -4321 is constructed using a 750 Hz shift of -5 bins: -5000 + 750 = -4250. This way, all mixers do not need to calculate the FFT of a specific Doppler at the frequency mix in stage 1. Since the number of mixers is high, this reduces the total number of FFTs by almost half. a. In another method, the FFTs of 250 Hz and 750 Hz Doppler are interpolated from the FFTs of 0 Hz and 500 Hz. 2) Precompute the code FFT before the long integration or from memory. These codes can be used throughout the long non-coherent integration process. Generate the code by starting with a zero code phase offset. Generate a divisor to produce 10230 code pulses in 20360 sample pulses. The sample code remains constant between code pulse changes. To compensate for a code Doppler rate equal to the carrier Doppler divided by 116.5 cycles (when sidebands A and B are shifted to center at 1191.795 Hz), there are several options: a. The simplest is the code cell integrator, which is related to the number of chips moved multiplied by the ratio of the number of code hypotheses to chips per millisecond (for example, 20460 / 10230 = 2). Thus, every millisecond, the target hypothesis memory address shifts by that rate of integration. For example, if the Doppler frequency is 4321 Hz, the number of cells in 100 milliseconds is (4321 / 116.5) * (20460 / 10230) * 0.1 = 7.418 cells. This means that the offset between correlation and integration over one millisecond will vary from zero to approximately 7.5 cells, evenly distributed over 100 milliseconds. Furthermore, the same code zero-phase FFT is used each time. b. The worst case is to re-run the 20360 code sequence every millisecond, where the start code phase of the 20360 to 10230 code clock divider has a steadily increasing phase. Then update the code FFT every millisecond. c. Another relatively simple method uses another FFT property, where a time shift T in the time domain is equivalent to multiplying a zero-phase FFT by the complex exponential e(-jwT), where w is the frequency per grid cell and T is the time shift converted to chips per second by dividing by the number of chips per second. This complex multiplication can be reduced to a multiplication step of the sample FFT by the complex conjugate of the code FFT. d. Another method uses the fractional code offset of the first method to interpolate adjacent amplitudes to offset the code offsets between code offsets that change by integer values. Even with these improvements, the number of clocks required to execute a 16384- or 20480-sample FFT remains high. Even with dual-port memory, an efficient implementation may still require approximately 115,000 clocks, which is more than the approximately 100,000 clocks per millisecond for a 100 MHz initial sampling clock. Without acceleration, this would require 96 FFTs to run in parallel, requiring a significant amount of memory and potentially making it difficult for COVIMOGR to handle. Generally, the lower limit of an instruction is the number of clocks per stage multiplied by the number of stages. For a radix-N FFT, the number of clocks per stage is the sample size divided by N. The number of stages is the logarithm of the sample size to the base N. For example, for radix-2 and a sample size of 16384, the number of clocks per stage is 8192 and the number of stages is 14. Therefore, the minimum clocks is 14*8182 = 114666. For radix-4, the number of clocks per stage is 4096 and the number of stages is 7, for a total of 28672. This lower bound also assumes that the radix operation itself (which involves multiplying a complex combination of memory elements by a set of complex twiddle factors) can be cascaded into a single instruction. This is a reasonable assumption, as integrated circuits can perform several operations in a single clock cycle due to the speed of transistors and the predictability of propagation at certain voltages and clock rates. Therefore, increasing the radix can reduce clock speeds. However, this limitation is the fetch and write capabilities of the memory addressing circuitry. For a fairly common dual-port memory, a radix-4 implementation cannot fetch four complex elements in parallel, requiring four clock cycles. In a sense, the advantages of a higher radix are lost. To achieve a practicable design where modernized acquisition of only modernized signals can compete with previous acquisition methods, certain embodiments may utilize the following breakthroughs: 1) Implementing FFT-based methods is memory-intensive. a. Consider using system memory rather than dedicated memory. This way, the memory is no longer a sunk cost, as it can be allocated for acquisition and then reused for other purposes when acquisition is complete or when the GNSS receiver is not in operation. Therefore, a memory is shared between a GNSS processing system and another system that may be located on the same integrated circuit (IC), such that the shared memory, the GNSS receiver, and the other system are all located on the same IC, which may be a system-on-chip (SOC). b. Consider methods for efficiently pipeline processing FFT data to reduce memory usage. This is discussed in the Very Fast Frequency Domain Correlation (VFFDC) section below. 2) In one embodiment, recognizing that a high number of effective FFTs is required to achieve fast acquisition in mass-market GNSS receivers with high system loss (due to high NF, high antenna loss, signal fading, or blockage), a fast FFT engine can be reused multiple times within a millisecond, and general-purpose system memory can be used to minimize memory requirements by requiring only a low number of physical FFT engines. This fast FFT is restructured from a general-purpose FFT architecture, allowing the FFT to be further parallelized, with each parallel sub-FFT being updated using its own memory. a. Alternatively, a custom memory design can be used that can fetch a high number of words in parallel. This allows several radixes to be performed in parallel. For example, assume 32 I / Q sets can be fetched within a single clock cycle. This allows the 8-radix-4 calculation to be parallelized. Thus, the clock per stage is divided by 8. Therefore, in total, 20,460 FFTs can be performed within 4,096 (clocks / stage) / 8 (parallel radix-4) * 7 (stages) = 3,584 clocks. With a 100 MHz system clock, there are 100,000 clocks per millisecond, allowing the FFT to be reused 27 times within a millisecond. If a mixer requires 88 FFTs, only 4 physical FFTs will be required. Note that this low clock rate allows for a low-power system, as the maximum memory and DSP clocks are quite low by today's standards. b. Alternatively, a higher clock can be used. A 4x higher clock would reduce the number of FFTs to a single one. This has the disadvantage of mixing clock rates in the design and thus adding the overhead of buffering and staging. c. Finally, a pipelined VFFDC design can be used (this is the preferred embodiment), which minimizes the need for replication and maximizes parallel operations at each stage. 3) Although FFT memory can be reduced and reused, the remaining assumed memory dominates the rest of the design. a. Although the full E5 signal is over 6dB stronger than the conventional L1 CA signal, noncoherent integration is the most effective way to improve SNR without resorting to multiple assumptions about sub-coding and data bits, which generate random phase reversals every millisecond. In contrast, L1 C / A exhibits similar random phase reversals due to the data bits, but at significantly longer intervals (20 milliseconds). This feature achieves a faster SNR improvement by coherently integrating the L1 C / A signal. In some mass-market devices, simply noncoherently integrating the conventional signal is insufficient because it is practically impossible to integrate for a long enough time. i. Consider a target device that needs a 16dB improvement in SNR to overcome system losses. 1. Using E5, the four components of the combined signal—A-data (Ai), A-pilot (Aq), B-data (Bi), and B-pilot (Bq)—are almost 6.5 dB stronger than L1 C / A within 1 ms. Integrating non-coherently over 100 ms with a 1 ms integration yields a gain (over 1 ms C / A) of 6.5 dB + 1.5 dB*log(100,base2) = 6.5 + (1.5*6.64) = 10 dB + 6.5 = 16.5 dB. Considering the approximately 1 dB loss due to some phase reversals within the 1 ms sample buffer, the gain is 16.5 dB - 1 dB = 15.5 dB relative to the 1 ms GPS L1-C / A. ((There is some loss associated with σ phase and <2 dB phase reversals within the 1 ms sample buffer)) Combining means maintaining a separate sample buffer for the A and B sidebands, since adding them together would double the noise and erase the 3dB gain associated with each sideband. This calculation does not take into account the transmit diversity advantage provided by the dual-sideband signal. In typical Rayleigh fading environments found indoors and in urban canyons, this transmit diversity can improve fading resistance by approximately 10dB or more, particularly for the direct signal path, making signal acquisition, tracking, and reading of the navigation data symbol stream substantially more reliable. 2. For L1 C / A, typical acquisition using coarse timing means the longest coherence interval is close to 10 ms (half of the 20 ms data bit interval). In this case, a 10 ms sample can completely avoid phase reversal, while adjacent 10 ms samples may have their phase alignment nearly lost in the worst case. a. With 10 ms coherence, the frequency step size is now reduced to almost 50 Hz. To reduce frequency loss to the same level as described for the E5 method, a 25 Hz step size is used. This means that the number of frequencies required to cover the same + / - 1 PPM per SV is 2 * 1575 / 25 + 1 = 127. Note that E5 only requires 9 (the difference is 10 times the integration time, i.e., 10 = 10 ms / 1 ms, and there is a factor of 1.3 = 1575 / 1192, which makes E5's frequency lower). b. To achieve the same 16dB sensitivity after loss, the sensitivity gain model for an L1 C / A search with a 10ms coherence window is 10dB for the first 10ms, followed by a sensitivity increase of 1.5 for each doubling of the non-coherent integration over these 10ms. Maintaining the integration time at 100ms means doubling the integration time to 20, 40, 80, and then 20 / 160 = 0.125. The number of doublings is 5.56, and the non-coherent gain is 1.5 * 3.125 = 4.69dB, resulting in a total SNR gain of 10dB + 4.49 – 1.5dB (for a phase reversal loss in one of the 10ms windows, an average loss of 2dB) = 13.2dB, similar to but less than the E5 case. c. This suggests that the belief that L1 C / A is more sensitive to coherent integration is incorrect, as simpler non-coherent methods and acquiring the entire signal can have equal or better sensitivity. d. Now let's examine the size of the hypothesis memory and how it compares between E5 and L1 C / A. With E5, 24 channels are running in parallel. Therefore, the size of the hypothesis memory at two samples per chip is 20 * 20460 * 8 bits = 3.12 Mbits. Note that all four components of E5 are integrated into the same hypothesis memory because they all have the same code phase assumption. i. Note: As the signal travels through space, there is phase dispersion between Sideband A and Sideband B due to the fact that the number of carrier cycles per chip is different (115 cycles at A, 118 cycles at B, and 116.5 cycles at the center corresponding to 1191.795 MHz). The relative phase difference between the chips is 1. delChips = codeDoppler B – codeDoppler A = (Satellite Doppler) *dt * [1 / 115 – 1 / 118] = Doppler * dt * (118 – 115) / (115*118) = 3*Doppler*dt / 13570. Note that there is also a small relative ionospheric dispersion, approximately one carrier cycle. 2. Since the average travel time is about 80 milliseconds and the maximum Doppler due to satellite motion is 5 kHz, the incremental code chips are: delChips = 3*5000*0.08 / 13570=0.088 chips 3. Therefore, when the codeDoppler of A is greater than that of B, assuming that the code mapping from 1 millisecond amplitude to amplitude sum in memory can impose a specific offset of 14 cells on channel A (assuming 16384 cells per 10230 code chips). 4. Since both sidebands are shifted to the center, they have the same code rate during the processing time dt. 5. Note: If the oscillator offset is very high, the Doppler can be larger. In this case, the difference between the two sidebands in the travel time is larger and needs to be compensated. a. One solution is to compensate the oscillator in the hardware. A hardware-based table is maintained where the receiver knows the offset constant over temperature. Errors in velocity fixes can be measured, similar to how time offsets are known in position fixes. In this case, the frequency offset can be removed using hardware-based frequency shifting to remove the frequency error from the sample data. This way, only the satellite Doppler is observed in the code Doppler difference between the two sidebands. 6. Note: If the two sidebands are generated using separate IFs, the code Doppler difference is not common for time integration to be used for SNR improvement. In this case, compensation for the code Doppler difference is required. ii. Now let's discuss the hypothetical memory of L1 C / A: if the same search power is achieved, this means there are 127 frequencies per SV, and with the same 24 satellites in one second, this means 3048 frequency segments per second. Assuming each frequency is also searched for 100 milliseconds, this means 305 concurrent frequencies are being searched. Assuming typical sampling is close to twice the chip rate, and therefore approximately 2046 samples per millisecond. Therefore, the assumed total is 2046 * 305, and 8 bits = 4.875 megabits, which is actually higher than the E5 case. This number can be reduced in several ways. First, consider the same code cell to chip ratio. This reduces the sample clock to 1.6384 MHz instead of 2.046 MHz. This reduces the assumed memory to 3.904 megabits, which is still relatively large. The next step is to reduce the frequency step size from 25 Hz to 50 Hz, accepting another 1.5 dB loss in frequency step size, to 13.2 - 1.5 = 11.7 dB. This cuts the memory in half. Using the original 2.046 MHz sampling clock at 50 Hz yields half the frequency and, therefore, 2.4375 megabits, which is now slightly less than the 2.816 megabits of E5. L1 C / A sensitivity is reduced by almost 5 dB (16.5 - 11.7 = 4.8 dB). This does not take into account the additional advantage of Galileo signal transmit diversity, resulting in signals acquired using E5 A + B being substantially more resistant to fading. Conservatively estimating this improvement at 6 dB, COVIMOGR offers at least an 11 dB advantage over L1 coarse acquisition code in coarse acquisition mode. COVIMOGR's advantage is further extended in fine time acquisition mode, where coherent integration further improves tracking sensitivity for modern signals. iii. This example shows that even in a coarse time acquisition scenario, the E5 with a very efficient FFT engine can have higher sensitivity than an L1 C / A based receiver with similar memory assumptions. Preferred Embodiment – VFFDC Coarse Time Acquisition Processing Timeline Accurate time acquisition processing timeline The pipeline-oriented architecture illustrated in the figure above significantly accelerates FFT throughput and reduces memory usage in both working memory and signal memory, making the hypothetical memory the single largest memory footprint. In practice, as illustrated in the figure above, the process differs slightly between coarse-time and fine-time acquisition modes. Compared to typical FFT techniques, VFFDC's performance acceleration and memory reduction come from a combination of appropriate phasing, attention to detail in memory management, and application of recent "decimation in time" (DIT) FFT and "decimation in frequency" (DIF) FFT. The following figure shows a high-level view of the Very Fast Frequency Domain Correlator (VFFDC) architecture. Several of the blocks in this figure will be described in more detail. Very Fast Frequency Domain Correlator (VFFDC) Architecture FFT Processor Architecture (Four parallel IVFFT operations) Inverse FFT processor architecture (Four parallel IVFFT operations) The following diagram provides a detailed end-to-end timeline view of the Get Correlator process. Get the associator array processing diagram VFFDC Process The following figure further illustrates the GNSS code generator. The preferred embodiment generates each code from its underlying polynomial representation, shifts and shapes it appropriately, and then transforms it to the frequency domain every millisecond. However, several possible implementations can achieve many of the memory reduction goals without resorting to completely regenerating the code spectrum every millisecond. For example, the time-domain code can be generated only once per tracking session. In another example, the code spectrum memory can be stored and slightly adjusted as needed. In another embodiment, such caching methods can be used when storage resources are available, but otherwise unnecessary. FFT Processor Architecture (Four parallel FFT operations) Note: To generate the code spectrum, four GNSS code generators are used instead of the baseband sample memory. VFFT N2×N1 program flow Inverse FFT processor architecture NOTE: During the detailed design process, the interconnect network is defined, along with the algorithms mapped to the hardware and the instruction set definition for each block. Inverse VFFT N2×N1 algorithm Note that in this embodiment, FFTs are temporarily performed on both signal and code data in two working memory buffers that are reused by all mixers. Storing signal data in a circular buffer with a duration greater than 1 ms allows the FFT process to be performed before the buffer's write pointer catches up with the FFT's read pointer, resulting in a nearly twofold reduction in baseband sample memory compared to the previously described double-buffered embodiment. Furthermore, in this embodiment, GNSS codes are generated temporarily, resulting in approximately a 100-fold reduction in memory for pre-stored GNSS code spectra. These 10,230-bit codes can be stored compactly in the time domain, but once converted to the frequency domain, their size expands to encompass a complex non-binary representation. Note that there are actually four codes per SV. While some of these codes can be stored simply, they are most simply stored as polynomial representations. Therefore, this is the preferred embodiment for memory efficiency. While the required per-millisecond conversion of each code essentially increases the FFT throughput by almost a factor of two (only the in-phase branch of the code spectrum undergoes the first stage of FFT processing), this is worthwhile in this embodiment to reduce inherent memory and I / O. Further gains are achieved when a DIF conjugate FFT is used for the inverse FFT, allowing the inverse DIF process to be performed in column order using the same buffer that stores the results of the multiplication process (time domain data is stored in column order and frequency domain data is stored in row order). Note that, according to the Nyquist criterion, it is recommended to perform these FFTs on N = 20,460 samples, decomposing them into a set of N1 = 20 first-stage DFTs. (10 or 40 could also be used for N1; the choice of 20 was a design decision.) This leaves the next stage of N2 = 1024-point DIT / DIF FFTs, which can be implemented at high speed in another three stages using integer arithmetic (two radix-8 and one final radix-16). Because of the pipelined nature of this processing, it can easily be completed in 50 microseconds for all SVs in view at a frequency of 100 MHz using a processing clock just slightly faster than the sampling clock, which means that the circular buffer only needs to be about 1.05 milliseconds long (21483 samples, stored as 4 bits of I and 4 bits of q), saving power and most importantly, saving on-chip RAM. VFFT Details of One Embodiment: a. Decomposing an N-point DFT into an N1-point DFT and N1 parallel FFTs for N2 points. i. The total number of FFT points is N = N1*N2, where N1<<N2. ii. The N-point VFFT-DFT algorithm architecture is speed-optimized by decomposing the FFT processing into a combined stage of N1 parallel FFTs for N2 points followed by an N1-point DFT. Array processing techniques are used to execute N1 parallel FFTs simultaneously, accelerating FFT processing time by a factor of N1. iii. The N-point VFFT-DFT algorithm architecture is speed-optimized by decomposing the FFT processing into a first stage with an N1-point DFT followed by N1 parallel FFTs for N2 points. Array processing techniques are used to execute N1 parallel FFTs concurrently, accelerating FFT processing time by a factor of N1. iv. An inverse VFFT-DIF operation can be performed by conjugating the input array before the VFFT and conjugating the output array after the VFFT. b. Array processing is used to simultaneously process N1 parallel FFTs. All FFTs perform the same processing, using the same program control instructions but using a different data set (a vector) from the array. c. A DFT can be performed on a non-power-of-2 number of points during the reassembly / decomposition stage. This DFT is performed in one instruction cycle using N1 parallel constant-cross multipliers and adders. Therefore, N2 cycles are required to complete the first / last stage of the VFFT. d. An N2-point FFT is performed using three stages, two of which are radix-8 and the first / last stages are radix-16. i. The radix-16 stage does not require a WN phase shift, which reduces complexity and balances the time of the preceding / following VFFT operations. ii. Phase shift factors are only required for the radix-8 stage. Since the firmware selects only one element from memory per instruction cycle, only one hardware phase shifter is required for each N²-point FFT. Since there are N² parallel FFTs operating simultaneously, N² phase shifters are required in hardware, all sharing the same phase shift amount. iii. Each FFT stage requires N² cycles to complete, so three stages require 3*N² cycles. iv. The processing rate at each stage is limited by the read and write accesses to the dual-port variable memory. Each processing cycle includes a read and write access, allowing firmware cycles of 8 or 16 instructions for the radix-8 or radix-16 stages, respectively. This design utilizes nearly 100% of the available read and write memory bandwidth and is therefore likely the most efficient given practical hardware limitations. v. Dual-port memory is often available in ASIC libraries, but higher-port memory is not. Therefore, for design portability, this embodiment uses single-port and dual-port memories and does not currently require byte access capabilities (which are not always supported in every ASIC library).e. Associative post-processing operations are performed in real time, without requiring storage, and can be pipelined in a few additional processing cycles, but there are no additional cycles within the firmware loop. These operations are performed on the full column vector in one instruction cycle. f. Variable memory may be reduced in precision during the final stages of the VFFT. Associative post-processing operations can then be performed at higher precision in the processor's registers. The results can be reduced back to lower precision before being stored in the hypothesis memory. Therefore, variable memory does not require high precision (targeting 8-bit / I / Q components). g. Block floating point can be used for the integrated magnitude, reducing precision to unsigned 8 bits. Magnitude compression can also include subtracting the minimum value in the block before applying the block floating point conversion. h. In at least some embodiments, Cordic-based phase shifters can be used throughout the design instead of complex multipliers and sin / cos tables. i. Cordic hardware is approximately one-quarter the area (and cost) of a complex multiplier, and Cordic phase tables are generally less accurate than sin / cosine tables. ii. The Cordic algorithm generates several small phase modulation spurs (PM) near the noise floor, rather than the one or two dominant amplitude modulation harmonic spurs (AM) used by the quantized sin / cosine table approach. Cordic's spurious-free dynamic range is significantly increased, allowing for reduced signal accuracy while maintaining the same performance. iii. The only drawback of Cordic hardware is the long propagation delay through the serial stages. Due to the conditional logic within each stage, arithmetic logic optimization across stages is not possible. Excessive delays that exceed the timing budget may need to be handled by register pipeline stages, and any additional group delay must be incorporated into the signal processing algorithm. Note that while this design assumes data is read in column order to optimize addressing, data can easily be read in row order with similar results. Reduced complexity correlator for lower power acquisition of stronger signals. While using both components of E5's two sidebands allows for an SNR increase of up to 6dB compared to a single sideband component (I or Q), in some cases it's preferable to use a lower power configuration that can acquire a stronger signal in a reasonable amount of time. In another scenario, a receiver may need to read some information from a navigation message that is only available from a subset of signal components. This information could be, for example, a weekly timestamp or a specific phase change interpreted as a time marker for fractional synchronization. Or it could be integrity information. For example, it could be almanac or ephemeris information or differential correction information. In situations where certain information needs to be read to accelerate further acquisition and tracking, those signals that are likely to provide this information the fastest are prioritized. Consider the following acquisition scenario: When a receiver is powered on while inside a parking garage, all signals are blocked. The receiver is unaware of the garage's conditions and will likely initiate a search strategy based on the very weak signal. This strategy requires integrating all signal components for a longer period of time and provides maximum sensitivity. While this approach is beneficial for acquiring weak signals, it is slower to recover stronger signals when the receiver eventually leaves the garage because it spends more time searching each frequency. In this situation, it would be beneficial to have a second, parallel search engine, or to allocate some search resources to use a shorter integration period to find stronger signals. This allows each frequency band to be searched more quickly, allowing the receiver to cover more frequencies in a shorter period of time. Furthermore, consider acquiring unknown time. Typical Network Time Protocol (NTP) accuracy on the internet ranges from approximately 5 ms to 100 ms. In some cases, frame synchronization of only a selected GNSS signal component is sufficient to provide precise time. In such cases, searching for that signal component will be the highest initial priority until the signal is tracked and the clock is confidently established. Once the clock is confidently set, the signal may be de-prioritized in favor of one of the signal components that contains less data and therefore has higher tracking sensitivity. A flexible correlation method can be used to acquire strong signals as quickly as possible. First, correlation resources can be configurable, allowing a channel to search for one to four signal components. If a single channel fails to release unused resources, resources will remain idle, extending acquisition time. For example, if a channel is configured to search for four components and only a single component is used, the other three resources will be unavailable. Therefore, the first step in this embodiment is to identify the association of a signal component, such as E5BI, with the basic search unit. For frequency-domain methods, this means performing an FFT of the samples, an FFT of the code, a multiplication of the sample spectrum with the complex conjugate of the code spectrum, and an IFFT of the product. The total number of associations is the number of times the VFFDC resource can be reused within the code frame length (nominally 1ms). The channel concept then includes the ability to select up to four components to match the four-component E5 and B2 signals. In this case, the number of channels should match the hardware's ability to perform the number of associations within a frame (in this case, 1ms). For example, if it is possible to perform 88 full correlations in one millisecond, then the maximum number of channels should be 88 if only one component is used per channel. For example, if only 22 channels are defined with up to 4 components, then only a single component is used, leaving 3 components unused. The second part of this embodiment is to select the component with the lowest search loss. For a modern signal with a 1 millisecond frame length and 4 to 100 milliseconds of overlapping codes or subcodes (whose bits change synchronously with the frame), each frame can experience a sign change from 1 to -1 or from -1 to 1. Generally, these overlapping codes experience phase reversals at a rate of approximately 50%. For two consecutive frames without phase reversals, when the frame point or period or frame restart occurs, performing a one-millisecond period of non-coherent integration synchronized with a random millisecond input sample is lossless. In contrast, if the frame period is centered within a millisecond and a phase reversal occurs, cancellation occurs, resulting in very little correlation within that millisecond. Using FFT-based correlation, it is impossible to separate the millisecond correlation into two parts: the part before the potential phase reversal period and the part after the period. The receiver operates on a full millisecond of received signals with an arbitrarily selected start time. At this stage of the acquisition process, each satellite signal has a distinct and unknown phase. This is because the millisecond samples are correlated with a full millisecond code sample starting at zero phase, and separation based on other phases is not possible. In contrast, using traditional time-domain correlation methods, different input sample combinations are selected for different code phase estimates, causing the period to occur at the edge of the millisecond buffer. This ensures that the in-phase and quadratic sums have the same phase during integration. However, for modern signals, this approach of performing separate correlations for each code phase hypothesis is commercially unfeasible because it either requires excessive hardware, increasing power consumption and size, or is too slow when hardware is reduced. Therefore, the price of non-coherent integration of a millisecond correlation is a loss in millisecond samples related to the time period phase. This loss is small when the phase is near the millisecond edge or when the overlapping codes do not have phase reversals. The loss is higher when the phase is near the center of the millisecond and a phase reversal occurs. In the latter case, the loss is effectively infinite. In the former case, the loss is smaller. Generally speaking, when integrating over the duration of the overlapping codes, the worst-case loss is less than 3 dB. This is because the probability of phase reversal is approximately 50%, resulting in the loss of half the correlation, but the remaining correlations do not suffer from this phase loss. Losing half the power means losing 3 dB. It has been discovered that data channel E5BI has an overlapping code of 0001. The sub-code repeats every 4 frames, every 4 milliseconds. Data symbols undergo additional phase reversals at the boundaries of the overlapping code. Therefore, consider a 5-bit alternating data symbol sequence of 0, 1, 0, 1, 0. The combination of the overlapping code and data symbols generates the following overlapping code phase sequence, where 0 represents phase 0 and 1 represents phase 180 degrees. 0001 1110 0001 1110 0001 Now let's focus on the phase reversal, which is the derivative of the sequence: 0001 0001 0001 0001 0001 There are only 5 phase reversals on 20 symbols, so the probability of a phase reversal is 25%. In contrast, consider the B2AI data channel on BeiDou. Its overlapping code is 00010. Or perhaps a diagram with phase transitions specified by 00010 can be provided. Now consider the same five data bits, 01010. The resulting combination of overlapping codes and data symbols generates this sequence: 00010 11101 00010 11101 00010 Now let's look at the phase reversal, which is the derivative 00011 10011 10011 10011 10011 There are 15 phase reversals in 25 bits. The probability of this change is 15 / 25 = 60%. Therefore, the maximum loss in dB of B2AI is 3dB & 0.6 = 1.8dB. However, the maximum loss in dB for E5BI is 3dB * 0.25 = 0.75dB, which in comparison limits the loss to 1.05dB. Therefore, to improve the actual acquisition time with a fixed amount of search resources, one embodiment can implement a single component search (searching only a single component by attempting to acquire only that single component over a period of time) and select the component with the lowest phase reversal probability on each system. For Galileo E5, the optimal component is E5BI. [Shared Memory] [] COVIMOGR = Commercially Viable Modernized GNSS Receiver Another approach to achieving a commercially viable modern GNSS-only receiver (COVIMOGR) is to reduce dedicated memory by reusing system memory. Consider integrating the COVIMOGR into a system-on-a-chip (SoC), which already has large SRAM and DRAM components along with other processing systems. The COVIMOGR SOC components include but are not limited to the digital front end (DFE), the acquisition engine (AE) using frequency domain correlation, the tracking engine (TE) using time domain, the re-acquisition engine (RE) using time domain, and the minimum CPU / RAM / ROM required to control the AE, TE, and RE. The amount of memory required for an AE depends on its efficiency relative to the frame period, which is typically 1 millisecond for modern signals in the L5 band. For example, if 88 complete clocks (mixers) are required and a correlation engine requires 4,500 clock cycles, with 108,000 clock cycles available per millisecond, each correlation engine can be used 24 times per millisecond. This means at least four correlation engines are required in an AE. In this case, memory for four engines is required. Generally, this memory must be dedicated to the AE, as it must be available on every clock cycle and is slowed down by any memory arbitration. The SOC architecture may include the following items: 1. A set of application processors (APs), such as four. These typically have variable speeds. 2. A general-purpose IO, an input / output interface to external systems, and IO used for on-chip communication. 3. A hardware abstraction layer that contains hardware controls, the operating system (OS), and an arbitration communication bus so that all blocks can be configured and communicate through the OS. This block contains its own CPU or runs on an AP in the system. 4. A set of functions that are placed on the SOC and each of these functions can be performed by a processing system that includes a local processing memory that can be shared with a GNSS processing system. 5. A GNSS processing system (e.g., COVIMOGR), which is another function in itself. It may have an acquisition engine, a tracking engine, a re-acquisition engine, a digital front end, a minimal CPU, a minimal SRAM, and a minimal NV-ROM. 6. A large SRAM block that is available to the system via the communications bus and also used for one or more other functions, in this case connected to the COVIMOGR. 7. A DRAM, which is a general-purpose non-volatile memory. Consider the system-on-a-chip (SOC) shown below. This can be a single monolithic die or a system of multiple dies. Here, all components except the DRAM are located on the same die, and the DRAM is connected to a second die via a communication bus. To reduce the size of the COVIMOGR and, in particular, the size of the AE's SRAM, a combination of dedicated memory in the AE and the SOC's SRAM can be used. In a preferred embodiment, the hypothetical memory for non-coherent integration and / or coherent integration is shared with the SOC via a direct bus, allowing the COVIMOGR to address certain portions of the SOC's SRAM without slowing down. 1. The AP receives a request from an application to determine a GNSS position. 2. The HAL identifies a specific portion of SRAM and allocates it to the COVIMOGR. The allocated memory must have a read / write controller that can operate independently of the other memory slices so that it can be used by the AE without frequent contention / arbitration. 3. When the GNSS receiver is active, COVIMOGR uses the memory located in AE. 4. The application requesting GNSS is terminated or idle 5. OS signals HAL to turn off GNSS. 6. HAL notifies COVIMOGR to shut down. 7. Return the slice (e.g., page) of SRAM allocated to COVIMOGR to the system. This reduces the total SRAM required by the COVIMOGR because the memory required by the AE is shared rather than dedicated to the AE for exclusive use. To further reduce memory in the AE, at least some of the memory in the AE or in the GNSS processing system can be shared with other processing systems on the SOC. Another option is to store the GNSS code spectrum in the SOC DRAM as a set of pre-calculated tables, and then program these pre-calculated tables into the DRAM when the system is updated. Another option is that a program in the AP or even on the COVIMOGR can calculate the codes and / or code spectrum in the background or even at the beginning of a GNSS operation phase. For reference, the number of codes for L5 is 63, E5 is 50, and B2 is 63. QZSS contains 2 and EGNOS contains 2. This is 180 PRNs. However, L5 has two codes / PRNs, E5 has four codes / PRNs, and B2 has four codes / PRNs. Therefore, the total number of codes is 586. Each code consists of 10230 bits. Storing all codes requires 5,994,780 bits, which is approximately 734 kilobytes. When the code spectrum is stored as real codes, the storage depends on the sampling rate used by the AE. Because each component is searched independently, the code is real for each component. The DFT of this code is a symmetric complex conjugate. This means that pairs of complex numbers reflected near the midpoint of the DFT have the same real value, but the imaginary value is negative. The total value required after reading the memory is 2N, but N / 2 is a symmetric complex conjugate. Therefore, N unique values are required, and the HW can construct all values from these N unique values. Assuming the number of bits required is further reduced with minimal loss, in a preferred embodiment, 8 bits or 1 byte are used to store the real part and 8 bits are used to store the imaginary part. For a sampling rate of 20,480,000 (at 10,230,000 chips per millisecond, with only two samples per chip), the number of bytes required to store all pre-calculated code spectra is approximately twice the number of code bits. Therefore, 586 codes * 20,480 bytes / code = 11,632,640 bytes = 11.360 megabytes. This number can be reduced in several ways: Applications can periodically assess which codes are currently active in healthy satellites in space. This can then significantly reduce the number of stored codes or code spectrum. For example, there are more than 50 active PRNs per satellite per system. However, at any given time, there are typically no more than 30, and more likely only 24, allocated PRNs in space. This would allow the memory to be reduced by more than half. In another approach, the pre-computed code spectrum is moved to a sector of SRAM when GNSS is active, such that: 1. The AP receives a request from an application to determine a GNSS position. 2. The HAL identifies a set portion of SRAM to store the code spectrum and allocates it to the COVIMOGR. The allocated memory must have a read / write controller that can operate independently of other memory slices so that it can be used by the AE without frequent contention / arbitration. 3. The HAL copies the codes into the SRAM allocated for the code spectrum and gives COVIMOGR the base address of the pre-calculated code spectrum as well as the systematic, PRN and components of each code. 4. When the GNSS receiver is active, COVIMOGR extracts the code spectrum from the AE and uses the code spectrum in the step of multiplying the sample spectrum by the complex conjugate of the code spectrum. 5. Request GNSS application termination 6. OS signals HAL to turn off GNSS. 7. HAL notifies COVIMOGR to shut down. 8. Return the SRAM slice allocated to COVIMOGR to the system. In another embodiment, a background application running on the SOC AP is used to calculate the effective code spectrum based on the current PRN in space. 1. A background application periodically calculates the effective PRN of all systems and stores it in DRAM. 2. The AP receives a request from an application to determine a GNSS position. 3. The HAL identifies a set portion of the SRAM for storing the code spectrum and allocates this portion to the COVIMOGR. 4. The HAL copies the codes into the SRAM allocated for the code spectrum and gives COVIMOGR the base address of the pre-calculated code spectrum as well as the systematic, PRN and components of each code. 5. When the GNSS receiver is active, COVIMOGR extracts the code spectrum from the SRAM in the AE and uses it in the step of multiplying the sample spectrum by the complex conjugate of the code spectrum. 6. Request GNSS application termination 7. OS signals HAL to turn off GNSS. 8. HAL notifies COVIMOGR to shut down. 9. Return the SRAM slice allocated to COVIMOGR to the system. In one embodiment, one way to further reduce COVIMOGR's cost is to compute as much GNSS functionality as possible on the AP. The CPU / RAM / ROM allocated to COVIMOGR can be minimized to allow full control of the various hardware engines / components: AE, TE, RE, and DFE. These systems will require a reliable method for sending control settings, requesting services, and reading results. For example, the AE will have an interface to request a search for a specific PRN in the system. Results can be obtained as quickly as every millisecond. However, the system is designed to internally buffer its results to allow for a lower interrupt rate, such as once per block in 20 milliseconds. The tracking engine can operate at a similar update rate: periodically writing and reading each satellite approximately every 20 milliseconds. In this embodiment, the job of the COVIMOGR is to service these interrupts, write the next update and then format and send the data to the assigned AP. In one embodiment, the process may be: 1. The AP receives a request from an application to determine a GNSS position. 2. HAL identifies an AP to run COVIMOGR's high-level software. 3. Copy the COVIMOGR GNSS application code from DRAM to an execution memory block, which may be SRAM. 4. HAL identifies other SRAM chips used for AE 5. HAL identifies the code spectrum and copies the code spectrum to the SRAM chip used for AE 6. The application enables COVIMOGR and indicates the memory information used for AE. 7. The application tells the COVIMOGR CPU which satellites to search for. 8. COVIMOGR controls AE to start searching. 9. COVIMOGR CPU serves AE search results. 10. The signal has been found and TE tracking has begun. 11. Retrieve lost signals in TE in TE or RE based on the time since the last trace. Re-search recently lost confidential data in RE. 12. COVIMOGR detects the confidence trace and aggregates the code and frequency information within a configurable measurement interval (e.g., one second) to enable accurate measurement results to be sent to the COVIMOGR SW running on the AP. 13. COVIMOGR erases data bits to track the data, buffers the data with a configurable buffer size of 50 to 100 bits, and then sends the data to COVIMOGR SW running on the AP. 14. The exact time is known from the decoded symbols which are converted into time stamp and ephemeris data. 15. Use COVIMOGR SW on the AP to determine position / velocity clock offset and drift. 16. Refine the search data, update the observable PRN and its expected code phase and frequency, and send the data to the CPU on COVIMGR. 17. SW on COVIMOGR removed the satellite from AE and switched to searching in TE for a low power maintenance mode. 18. If COVIMOGR loses a satellite due to a signal blocking condition, repeat the reacquisition or initial acquisition to find the satellite immediately after any blocking condition is removed. 19. Termination of GNSS-requesting applications 20. OS signals HAL to turn off GNSS. 21. HAL notifies COVIMOGR to shut down. 22. Return the SRAM slice allocated to COVIMOGR to the system. It should be noted that in another embodiment of power and SRAM conservation, the COVIMOGR can also release a portion of the SOC SRAM back to the SOC if it is not needed for continued operation after the initial acquisition and clock setting. In this case, if the signal is lost and the clock setting is reduced by approximately 100 microseconds, the COVIMOGR can request to reacquire the required SRAM block, up to the full amount initially acquired. Carrier and Code Generation Options: In one embodiment, the following components can be used to increase the sensitivity of a COVIMOGR: 1. Combine all components of the modernized signal in a way that achieves the best SNR. a. Sidebands A and B should be processed in separate channels rather than combined. It's tempting to combine sidebands to minimize the number of input samples in the FFT. However, consider a PRN on one sideband with a received SNR. If combined with another sideband, the SNR will drop by almost 3dB, negating the benefit of using all components. b. Data from a particular sideband can be correlated with the pilot channel from the same channel in two different ways: separately or coherently. Separate correlation means multiplying the real-valued (i.e., not composite) code with the in-phase and quadrature signal input components, and in this way searching for the pilot and data codes in parallel. Coherent correlation means multiplying the composite code with the data channel code in the real part and the pilot channel code in the imaginary part. However, due to the unknown relative phase of the pilot and data channels, a second hypothesis must be tested when the two codes are out of phase. This can be done by changing the sign of one of the components. There are actually four possibilities, but only two exist if the correlation result is squared over a frame. In practice, either the strongest power (or amplitude) is selected in each code hypothesis, or the two are summed. For stronger signals, the coherent method offers some benefits, but it requires computing both hypotheses simultaneously and comparing them before integrating them into the hypothesis memory. For weaker signals, the advantage is smaller because it is difficult to select the correct hypothesis, and the procedure increases noise by selecting a larger estimate. c. When pre-calculating the code, the coherent method is more expensive because the coherent code is not as complex and symmetric as the real code, so it needs to be stored twice. d. A preferred embodiment is to mix the data and the pilot code as two sideband real code words and combine them after squaring a frame. 2. Use coherent integration up to the frame length of the primary code sequence, and then integrate the power (or amplitude) non-coherently over multiple frames so that the SNR grows almost linearly under each code hypothesis. a. This process allows for precise handling of code conversions due to carrier frequency alignment, referred to herein as code Doppler. During propagation from the satellite to the receiver, the code Doppler for each sideband differs depending on the relationship between the carrier frequency and the chip rate. For sidebands below 1176.45 MHz, there are 16 cycles per chip. For sidebands above 1207.14 MHz, there are 118 cycles per chip. The preferred embodiment shifts each sideband to a common center frequency of 1191.795 MHz. A Sideband A channel is found by shifting a baseband signal centered at this original center frequency by 15 * 1.023 MHz (BOC frequency = 14.345 MHz), applying a low-pass filter, and then decimating to a bandwidth of approximately 20.48 MHz, which contains the main lobe of Sideband A. A Sideband B channel is found using a similar procedure, but shifted down by 15.345 MHz. b. By shifting the sidebands to a common frequency, the individual codes are switched relative to each other at a rate of 116.5 carrier cycles / chip. c. Separately address the effects of code Doppler during transmission and during integration. An estimate of the transmission time (approximately 75 milliseconds on average) (determined by calculating the actual transmission time from the satellite to a known receiver position after fixation) is multiplied by the code Doppler (which is the negative of the carrier Doppler divided by the carrier cycle / chip) to approximate the transmission portion. Depending on the cycle / chip difference, there will be a difference in the arriving code phases of the two channels. However, the effect is small and negligible when searching with a large step size (e.g., ½ chip). For a Doppler of 5 kHz based on satellite motion and a transmission time of 80 milliseconds, the worst-case difference is approximately 0.08 chip. In many cases, a fairly accurate range estimate for each SV can be pre-calculated based on an approximate receiver time and position, making this compensation even more accurate. d. Using 116.5 carrier cycles / chips for both sidebands, the code Doppler effect during the integration period can be calculated exactly as the Doppler estimate multiplied by the integration time. e. This compensation can be done in several ways: i. The code samples can be time-shifted before the DFT so that the integrated amplitude at the beginning of the integration period corresponds to the code hypothesis. This shift is calculated as dt * carrier Doppler / 116.5. The shift is decomposed into integer and fractional code chips. This shift becomes the initial phase for the code generator, which generates a code estimate at a sample time of one millisecond from the input sample. This method is called the shifted code sample method. This method is only possible if the code spectrum is calculated every millisecond. ii. Generate code samples with an initial phase of zero and then modify the code spectrum by multiplying the spectrum by a frequency-dependent complex sequence. This method exploits the property that the FFT of a time-shifted sequence is equal to the FFT of the unshifted sequence multiplied by a frequency-dependent complex exponential and an argument of e^(jwT), where w is the angular frequency at each element of the FFT and T is the fixed amount of time shift. This is known as the modified zero-phase spectrum method. This method works well for both precomputed and temporarily computed code spectra based on a zero initial phase code sequence. iii. Code Doppler shift can be compensated after correlation. The correlation target hypothesis generated under a zero initial phase code spectrum is shifted to compensate. A coarse method and a fine method can be used. 1. In a coarse method, the code Doppler shift of a chip is converted into a code hypothesis by multiplying the number of input samples in one millisecond by the number of chips in one millisecond. For example, at a sample rate of 20480, a code shift of 1.5 chips is converted into a hypothesis shift of 1.5 * 20480 / 1020 = 3.0 cells. Therefore, when the carrier Doppler is negative, the current correlation result at zero phase is added to the third code hypothesis; when the Doppler is positive, the current correlation result is added to the final hypothesis minus 3 cells. 2. In a refined approach, the same method as above is used to identify integer code hypothesis offsets. Fractional shifts are then used to scale two similar results for zero initial phase correlation. For example, if the fractional phase is 0.5 chips, the correlation value added to the hypothesis memory under hypothesis zero is half the value of the zero initial phase correlation at cells 3 and 4. The other updates are shifted equally. f. As a method of minimizing the hypothesis memory, all components are integrated into a single memory. A simple shift (e.g., code Doppler applied to the correlation result) can be used before adding to the hypothesis memory to compensate for the offset between sidebands that occurred during transmission. g. Since the two sidebands are shifted to a common center frequency, each sideband experiences the code Doppler effect during the integration period. 3. Apply carrier Doppler with minimal frequency offset. In this scenario, correlation is performed using a frequency-domain method using three DFT steps to generate Correlation = IFFT [FFTsamples * FFTcode'], where FFTsamples is the DFT of the input samples, FFTcode' is the complex conjugate of the DFT of the code samples, and IFFT is the inverse DFT of the product of two FFTs. The IFFT is essentially an FFT followed by a division by the number of samples in the IFFT. FFT stands for Fast Fourier Transform, an efficient method for implementing the Discrete Fourier Transform (DFT). The VFFDC method combines three FFTs, performing multiplication and complex conjugation, in a manner that exploits the symmetry of the FFT and IFFT processes. VFFDC can also offset the effects of sideband processing on individual carrier frequencies by processing the signal input samples or code samples sidebands, an effect known as carrier Doppler. The selection affects the total number of DFT operations. a. The range of deviations of the received frequency from the nominal value for each satellite due to the motion of the satellite relative to the receiver is approximately + / - 5 kHz plus the oscillator's frequency offset. If the oscillator's frequency offset versus temperature curve is known, a frequency shift can be applied to the input samples before correlation to eliminate most of its effects. However, even though the remaining satellite motion-dependent frequency offsets can generally be precalculated, they do not have a common value for all satellites, and a specific range of values must be searched for each satellite based on the receiver's time and position uncertainties. b. This satellite-specific Doppler frequency can be handled in essentially one of two ways: i. Doppler is removed from the input samples using a frequency difference operation, resulting in samples with zero frequency offset. These modified samples are then correlated with code samples that also have zero frequency offset. This method is known as the Down-Shifted Input Sample Method (DISM). A down-shift of the complex sequence A is performed using triangulation with frequency source B: sin(ab) = sinA cosB - cosA sinB, and cos(ab) = cosA cosB + sinA sinB, where A represents the frequency of the input sample and B represents the carrier frequency to be removed. Sin and cos represent the imaginary and real components, respectively. a. This method requires a unique set of input samples for each frequency being searched. This increases the number of FFTs by the number of unique frequencies. When using two sideband components, two DFTs must be formed for the sideband input samples, which also doubles the number of FFTs. Certain optimizations can be performed here. i. Perform the DFT of both sidebands with a discrete frequency step size equal to the integration time. A longer integration time requires a smaller step size, while a shorter time allows for a larger step size. For a longer integration time, set the step size such that the maximum frequency error between two steps equals half the code Doppler error of the sample clock. For example, if the integration time is 100 milliseconds to achieve a desired SNR improvement of 10 dB for a weak signal, the frequency error of a sample clock of 20,480,000 is ½ = df / 116.5 * 0.1 * 20,480 / 10,230. Df = 0.5 * 116.5 / 0.1 * 10,230 / 20,480 = 291 Hz. Therefore, the search step size can be doubled, since the maximum error between steps of 582 Hz is 291 Hz. For a short integration time, the step size is chosen to minimize the loss associated with the sinX / X error of the maximum frequency error between two steps. For a 1 millisecond integration, sinX / X is 0.63 at X=500 Hz with a loss of 4 dB, and 0.9 at X=250 Hz with a loss of 0.9 dB. ii. To reduce the number of samples in the FFT, a set of carrier-down-shifted input samples is generated with a frequency step size related to the integration time. 1. For a 10 millisecond integration time for fast searches for strong satellites, sinX / X sets the step size. In this case, two frequencies, 0 and 500 Hz, are selected to limit the frequency error to 250 Hz. Then, there are 4-sample FFTs: 2 for A and 2 for B. For example, if a channel requires a 2200 Hz Doppler, the 0 Hz FFT is selected, and the resulting FFT is shifted by 2 grids to generate a 2 kHz frequency shift. The frequency error is limited to 200 Hz, which has a loss of less than 0.9 dB. This is because a 1 millisecond integration has a loss at 0 Hz, 200 Hz, 400 Hz, 600 Hz, and 800 Hz. 2. For an integration time of 250 milliseconds, which yields 11.5 dB, the df of the maximum code Doppler error for a ½-sample clock is 116 Hz. Therefore, the step size is rounded to almost double, 250 Hz. A method of down-shifting the input samples is used to generate input samples with 0, 250 Hz, 500 Hz, and 750 Hz removed. In this case, there are now 8 sample FFTs: 4 for A and 4 for B. For a channel with a desired carrier frequency of 2200 Hz, a 250 Hz FFT is selected and shifted by 2 divisions to generate a carrier erasure of 2250 Hz. ii. Doppler is added to the code samples using a frequency addition operation so that the resulting code samples have the same frequency as the expected satellite Doppler frequency. This method is called the Up-Channel Shifted Code Sample Method (UCSM). It uses triangulation to perform an up-frequency shift on the complex sequence A using frequency generator B: sin(a+b) = sinA cosB + cosA sinB, cos(a+b) = cosA cosB - sinA sinB, where A represents the frequency of the code sample and B represents the carrier frequency to be added. Sin and cos represent the imaginary and real parts, respectively. Note that when addressing code Doppler by shifting the resulting code spectrum, the code samples can start at zero phase, or when addressing code Doppler in the time domain, the code samples can start at a non-zero initial phase. Summarize the possibilities of performing frequency domain correlation using 22 channels, where each channel can process 4 components: 2 for sideband A and 2 for sideband B: Option 1: Apply carrier Doppler to the input samples and code Doppler to the code samples using a downshifting method: Correlation = IFFT[FFT(samples*Doppler)*FFT(code samples with non-zero phase)']. When all components are used, each channel has 2-sample FFT, for A and B 4 code FFTs, one for each code 4 IFFTs, one for each code Total = 10 / Frequency For all channels: 22 * 10 = 220 FFTs / ms Option 2: Apply carrier Doppler using up-shifting and apply code Doppler to the code samples with non-zero initial conditions: Correlation = IFFT [FFT (samples) * FFT (code samples with non-zero phase due to carrier Doppler up-shifting)]. Now the sample FFT is common to all channels. So put this in a separate pool. When all components are used, each channel has 4 code FFTs, one for each code 4 IFFTs, one for each code Total = 8 / frequency For all channels: 22 * 8 + 2-sample FFTs for A and B = 178 FFTs / ms Option 3: Use a down-shifting method to apply carrier Doppler to a set of input samples at a preset carrier Doppler frequency, using a pre-calculated code spectrum and applying a frequency-domain code Doppler method. Correlation = IFFT [FFT (samples * Doppler) * FFT (code samples with zero phase) * e^(jwT)]. Assume that the maximum integration time requires a Doppler step size of 200 Hz. Therefore, there are 10 sample FFTs for A and B, with step sizes of 0 Hz, 200 Hz, 400 Hz, 600 Hz, and 800 Hz. When all components are used, each channel has Read 4 pre-calculated code spectra, one for each code 4 IFFTs, one for each code Total = 4 / Frequency For all channels: 22 * 4 + 10 = 98 FFTs / ms The difficulty with Option 3 is that the correlation engine must access the precomputed code spectrum very quickly. It must read 22 * 4 * 20480 bytes / ms = 1.76 million bytes / ms. This motivates the use of Option 2, which trades off code spectrum computational power against system complexity to retrieve the precomputed code spectrum at speeds approaching 2 Gbytes / s. Real-time Code Spectrum Generator (Preferred Embodiment, Option 2) 3. Real-time code spectrum generator a. Perform a VFFT on each code sequence immediately before acquiring each correlator channel during the previous processing cycle (note that a VFFT can be performed on a code sequence in ~40 us with a 108 MHz clock) b. The code generator generates 10 chips / cycle based on the 14-bit code of the GNSS satellite of interest. i. There are 10 pairs of polynomials for the code generator. ii. The code generator polynomial is programmable to allow for changes in future GNSS signals. c. Applying a polyphase pulse-shaped filter to the code sequence to achieve an adjustable time shift with a resolution within a fraction of the chip period. i. The bipolar (+|-1) modulation code sequence allows for a simple implementation to achieve higher pulse shape accuracy. Furthermore, the bipolar modulation code sequence is noise-free, allowing for higher accuracy and a greater number of terms in the pulse shaping filter coefficients. The coefficients can also be programmed to accommodate any changes in the pulse response in the digital front end. ii. Higher interpolation accuracy can be achieved using a simple implementation. Increasing the sampling rate (Nu) allows for finer precision in effective time shifting. For example, with Nu = 8, there is a 1 / 8 chip resolution with 2 samples / chip; this is achieved with a 4-phase filter. Higher values of Nu are easier to implement. iii. Time shifting of an integer number of chips is implemented in the pulse shaper hardware iv. The time advance for each millisecond is calculated and applied in hardware based on the Doppler time shift assumption of the channel. v. An alternative approach is to apply a time shift in the frequency domain at the VFFT output with a phase shift across the frequency band before storing it in code spectrum memory. This approach may require an additional 20-point complex phase shifter in hardware as an additional processing pipeline stage after the VFFT 20-point phase shifter and the 20-point DFT; thus, there are a total of three processing pipeline operations in the final firmware loop. Because the code spectra for the upper and lower sidebands of the BOC (15,10) signal are generated separately and independently in real time, a different time shift can be applied to each code spectrum every millisecond within the dwell duration (the dwell duration is the integration time). This design capability allows correction for different time shifts in the upper and lower sidebands due to unequal Doppler time shifts, ionospheric divergence, and antenna phase instabilities. These time shift differences can be more closely aligned when the code spectra are generated, which then allows constructive combining during the coherent addition of the upper and lower sidebands in post-correlation processing. d. Apply frequency shift to the shaped code sequence before VFFT i. Frequency shifter provides a wider frequency range and any frequency step size without the need for rotation and interpolation of frequency band values after FFT. This provides maximum flexibility for satellite search strategies ii. The input from the pulse shape filter is noise-free and relatively low precision; therefore, an ideal location for a frequency shifter. iii. Frequency shifter with Cordic-based phase rotators and a common phase accumulator for 20 samples / cycle in parallel; each of the 20 phase rotators applies a different phase offset iv. It should be possible to combine the phase shift values of the frequency shifter with the phase shift values of the first stage of the VFFT-DIT. This will allow a Cordic phase shifter to perform phase shift summation. v. Calculate and apply a phase advance every millisecond in hardware to maintain phase continuity over a dwell duration of a few milliseconds. e. Perform a 20480-point VFFT-DIT on the time and frequency shift code sequence i. Performed by the same processor as the baseband sample VFFT. ii. The N=20480 frequency bands of the code spectrum and baseband spectrum can be truncated to a smaller amount with band symmetry to achieve the final "brick wall" filtering of the code spectrum (1 kHz transition band without aliasing). 1. One of the programmable options of 20k, 18k, 16k, and 14k is available, enabling different options for samples / chip, associated pulse width, and assumed memory word size. iii. The digital front end and baseband sample memory can be designed to achieve a 20,480 kHz sampling rate and full-load processing, enabling simpler and more accurate processing of GNSS signals. No brick-wall type nonlinear filters are required. iv. Only 25% more VFFT variable memory is required, which is a small portion of the total core area. The coarse time acquisition mode depicted above is intended for situations where the code phase uncertainty of each SV to be acquired is > + / = 0.5ms. The final reporting step may report code phase and Doppler instead of code phase and carrier phase. The figure below shows the Cordic phase rotation that will occur in the code spectrum generation process to align the code spectrum with the continuous 1ms sample buffer over time. Once the primary and secondary millisecond code phases are known, the acquisition process can achieve greater sensitivity by determining the secondary code phase and shifting to coherent integration. However, this can be done in the tracking loop using techniques generally known in the art and is beyond the scope of this invention. However, it should be noted that in this case, the secondary code phase boundaries of all tracked SVs are fed back into the acquisition engine to assist in acquiring subsequent satellites in precise time mode. PAUL MCBURNEY 8 Coherent Integration Hypothesis Memory Organization in Precise Time Acquisition Mode: The following table shows the known subcode lengths for all GPS, Beidou, and Galileo signal components at L5. Generally speaking, sensitivity improves by 3dB per doubling with coherent integration and by 1.5dB per doubling with non-coherent integration. Therefore, the following table shows the theoretical gain associated with coherent integration, synchronized with the subcode of each individual signal component, relative to non-coherent integration. [Cluster] [Signal] [Sub-code length] [During the main code period] [(5log10(] [length] [))] [Internal theoretical coherence gain] Galileo E5Ai 20 6.5dB Galileo E5A 100 10dB Galileo E5 4 3dB Galileo E5B 100 10dB GPS I5 10 5dB GPS Q5 20 6.5dB Beidou B2a Information 5 3.5dB Beidou B2a Introduction 100 10dB Once the receiver clock is effectively synchronized with the 100 ms Galileo E5 and BeiDou B2a secondary pilot codes, coherent integration of these signal components can be extended to up to 100 ms, provided the oscillator phase stability permits. (This does not imply that absolute GNSS time is known, but rather that the sub-100 ms secondary code phase is known.) While it is possible to predict and estimate the navigation data for each channel, this example assumes that such prediction is unavailable. In precise time acquisition mode, these theoretical gains are therefore those to be approximated in a COVIMOGR. It should also be understood that oscillator phase stability will affect the theoretical coherent integration gain. In practice, for example, when navigation messages are modeled and predicted in advance, L1 C / A receivers typically use 40 to 80 ms of coherent integration, as further coherent integration significantly narrows the effective Doppler grid and leads to diminishing returns due to oscillator phase instability. Direct acquisition of wideband GNSS signals faces similar concerns. In an alternative embodiment, where the expected primary ms code phase of a signal being searched is well defined but the secondary code phase is unknown, multiple coherent integration buffers are formed, one for each millisecond of ambiguity in the secondary code of each respective signal component. Note that if the secondary code phase is unknown, the average of three clusters containing a 100 ms secondary code pilot channel will be approximately 45 1 ms time ambiguity bins. Therefore, this may not be practical for Galileo and BeiDou 100 ms secondary codes, but may be feasible for code phase uncertainty limited to approximately 10 microseconds. However, only a portion of the complete PN cycle associated with the narrowed code phase window for each SV is stored in the hypothesis memory. In this case, the I and Q, and A and B sidebands must be stored and can be combined or integrated separately for later optimal gain combining. Note that all 100 1-ms ambiguities must generally be considered to reliably coherently integrate the Galileo and BeiDou pilot channels. Although the GPS pilot channel does not have such a high potential coherence gain, compared with the Beidou and Galileo pilot channels, its secondary code is shorter, and its assumed memory usage will be only 1 / 5 of the latter. Due to the level of time and Doppler uncertainty, it is commercially impractical to perform a full 1 ms PN rolling coherent integration of all SVs during coarse time acquisition. However, once a first SV is found, given the relatively low initial position uncertainty, the first SV signal can be used to help estimate the code phase of the continuous signal, limiting the timing error to twice the bilateral position uncertainty, and typically less. The typical average code uncertainty associated with the position uncertainty will be only the bilateral position uncertainty. In one embodiment (shown in FIG. 11 of the present disclosure), the sub-code phase is estimated in the time-domain tracking engine and fed back to the acquisition engine for precise time-coherent integration of the signals that have not yet been acquired. If, for example, the receiver's initial position uncertainty is 1500 meters, the associated time uncertainty will average approximately 3000 meters / speed of light = 10 microseconds, or less, which is <= 1% of the full 1MS PN roll. Given that the average total time ambiguity is approximately 45 ms, it can be seen that the CIM can be balanced with the NIM, perhaps being larger in cases where dynamic Doppler uncertainty is high, and smaller in static cases. Once a reference signal is known, a simple equation can be used to set the actual two-sided SV specific time uncertainty window size. , where 𝜎 p is the one-sided initial position uncertainty and and are the individual unit pointing vectors from the estimated position to the nth SV and the reference SV, respectively. Similarly, the expected ms code phase of the i-th SV (at the center of the window) will be 𝜑 ei = 𝜑 γ + 1000 ∗ m𝑜𝑑(R i – R γ,𝐶 / 1000) / 𝐶, where 𝜑 γ is the known fractional phase of the reference channel master code (0 to 1), R is the calculated range between an initial position and the satellite, and C is the speed of light. In this case, the modulus will be + / - 0.5 ms. Similarly, when a subcode phase is known, the appropriate subcode fractional phase for each signal component less than or equal to the length of the maximum known subcode can be determined. In most cases, the 100 ms code phase will be easy to determine, so the equation is shown here: 𝜑′ ei=𝜑′ γ+ 10 ∗ m𝑜𝑑(𝑅 i- 𝑅 γ,𝐶 / 10) / 𝐶, where 𝜑′ is the secondary code phase. Note that in the case where a longer coherent integration is applied to both the pilot and data channels, each with a shorter secondary code, each with a different Doppler width and expected sensitivity. In this case, in a practical E5 coherent integration method for acquisition, the preferred embodiment uses only the E5 AQ and BQ pilot signals and discards the AI and AQ when in precise time acquisition mode. Since its coherent integration is limited to the length of its relatively short secondary code, this method maintains the fading robustness of tracking the A and B sidebands while sacrificing the relatively low sensitivity of the data channel. Some gain can still be gained by using the data channel, especially if its navigation messages are well predicted and erasures are eliminated, but for simplicity, tracking the pilot channel in this mode is the preferred embodiment. In another embodiment, all four codes can be coherently integrated up to the length of their respective sub-codes. In this case, their respective VFFDC outputs will be appropriately summed with a greater weight given to the pilot channel. Note that in this case, the effective Doppler grid widths of the data and pilot components can differ in size by a factor of up to 25. When summed across each coherent integration memory cell associated with the pilot channel, the wider Doppler grid size of the data channel can be simply mapped onto the richer Doppler grid of the pilot channel. In another embodiment, a prediction of the navigation message data of the data channel may be used to remove its individual bit transitions and thereby extend the coherent integral of the data channel to match the coherent integral of the pilot channel. Above: Precise time-coherent and non-coherent integration processing. Note that the reporting block can report code phase and Doppler instead of code and carrier phase for transfer to the tracking engine. The figure below illustrates an exemplary embodiment of a shared, general-purpose non-coherent hypothesis (integrate / accumulate) memory, organized into ~20KB buffers. The non-coherent buffers each contain a single mixer result, based on the code phase uncertainty window for each SV of interest. The coherent memory map (on the same reusable buffer) contains a mix of in-phase and quadrature, multiple Doppler bins, and multiple SVs per bin. Assume memory is configured for non-coherent integration in coarse time mode (initial configuration is 100 ms search) – organized into 24 – 20460 byte buffers The figure below illustrates an exemplary embodiment of a shared hypothetical memory in precise time-coherent integration mode during a first integration period. Note that in this case, complex data must be stored but with narrowed code phase uncertainty; each Doppler must only store a portion of a full PN cycle. In this embodiment, the two pilot signal components are stored in separate buffers. In another embodiment, they can be combined. In yet another embodiment, the shorter coherent integration time of the data channel can be integrated with appropriate weighting to become its respective pilot counterpart (AI becomes AQ and BI becomes BQ), or the predicted navigation message data can be used across sub-code boundaries to erase the data before coherent integration. This approach would require an additional buffer for the I component so that it can be added to the Q component at the end of its respective sub-code period. Given that each data Doppler has multiple pilot Dopplers and that the data and pilot components can be combined in the case of predicted and erased navigation message data, this does not significantly impact memory usage in the hybrid approach. Assuming the memory is configured for coherent integration in exact time mode (configurable time slots) Summing can improve acquisition sensitivity by one or more of the following means (in one or more embodiments): 1. Direct broadband signal acquisition. 2. Separate the sidebands to avoid raising the noise level from the original level of each sideband. 3. Mix all components in coarse time acquisition to get maximum fade-resistant SNR. 4. Determine at least one pilot channel sub-code phase in the tracking engine and feed it back into the acquisition engine when transitioning into precise time acquisition mode. 5. When in fine time acquisition mode, all frequency diversity pilot channels are mixed to obtain maximum fade-resistant SNR. 6. Integrate the correlation results into a single hypothesis memory, where the results of each ms are compensated for code Doppler 7. Using one of the three methods described above to handle Code Doppler, increase the signal power only at the hypothetical memory location with the strongest signal, rather than smearing the signal at multiple locations if Code Doppler is not properly accounted for. 8. 20,360 chip-code correlation based on FFT. 9. In the precise time acquisition mode, the coherent integral is at least partially aligned with the expected master code phase. To keep the cost (memory, power, silicon area, RF chain) reasonable, one or more embodiments may use: 1. Only direct broadband signal can obtain L5 broadband signal. 2. The VFFDC architecture achieves working memory reuse and minimum signal input buffer size. 3. Temporary code spectrum generation minimizes code spectrum storage and I / O. Combining and carefully managing non-coherent and coherent assumption memory buffers also reduces memory usage. Matlab Appendix This Matlab supplement contains copyrighted material. The owner, oneNav, reserves all rights, including copyright, in this material. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Copyright oneNav. Part 1 The following Matlab code provides an implementation in Matlab of a GNSS code generator using the embodiments shown in FIG. 9A to FIG. 9D . function [code_array] = gnss_code_gen(code_bits_per_row, code_gen_poly_set, code_gen_seed) % Generates an array of code bits for all wideband GNSS signals % % Component State Var Length Shorten Code Gen Poly Exponents % L5I|Q 13 x1=>8190 [9,10,12,13] % x2=>full [1,3,4,6,7,8,12,13] % E5AI|Q 14 x1=>full [1,6,8,14] % x2=>full [4,5,7,8,12,14] % E5BI|Q 14 x1=>full [4,11,13,14] % x2=>full [2,5,8,9,12,14] % B2AI (data) 13 x1=>8190 [1,5,11,13] % x2=>full [3,5,9,11,12,13] % B2AQ (pilot) 13 x1=>8190 [3,6,7,13] % x2=>full [1,5,7,8,12,13] % Code generator seed must be length 14, even for L5 & B2 with poly order 13. % Append an extra zero bit if needed, and transpose into a column vector. if (length(code_gen_seed) == 13), code_gen_seed = [code_gen_seed 0]'; elseif (length(code_gen_seed) == 14), code_gen_seed = code_gen_seed'; end % Code generation polynomials in vector format g1_L5IQ = [0 0 0 0 0 0 0 0 1 1 0 1 1]; % [9,10,12,13] g2_L5IQ = [1 0 1 1 0 1 1 1 0 0 0 1 1]; % [1,3,4,6,7,8,12,13] g1_E5AIQ = [1 0 0 0 0 1 0 1 0 0 0 0 0 1]; % [1,6,8,14] g2_E5AIQ = [0 0 0 1 1 0 1 1 0 0 0 1 0 1]; % [4,5,7,8,12,14] g1_E5BIQ = [0 0 0 1 0 0 0 0 0 0 1 0 1 1]; % [4,11,13,14] g2_E5BIQ = [0 1 0 0 1 0 0 1 1 0 0 1 0 1]; % [2,5,8,9,12,14] g1_B2AI = [1 0 0 0 1 0 0 0 0 0 1 0 1]; % [1,5,11,13] g2_B2AI = [0 0 1 0 1 0 0 0 1 0 1 1 1]; % [3,5,9,11,12,13] g1_B2AQ = [0 0 1 0 0 1 1 0 0 0 0 0 1]; % [3,6,7,13] g2_B2AQ = [1 0 0 0 1 0 1 1 0 0 0 1 1]; % [1,5,7,8,12,13] % Add B2B and Glonass when available. Offer 3 programmable options for future % Select the configuration parameters for the code generator switch (code_gen_poly_set) case 'L5IQ' g1_poly = g1_L5IQ; g2_poly = g2_L5IQ; poly_order = 13; x1_code_length = 8190; case 'E5AIQ' g1_poly = g1_E5AIQ; g2_poly = g2_E5AIQ; poly_order = 14; x1_code_length = 10230; case 'E5BIQ' g1_poly = g1_E5BIQ; g2_poly = g2_E5BIQ; poly_order = 14; x1_code_length = 10230; case 'B2AI' g1_poly = g1_B2AI; g2_poly = g2_B2AI; poly_order = 13; x1_code_length = 8190; case 'B2AQ' g1_poly = g1_B2AQ; g2_poly = g2_B2AQ; poly_order = 13; x1_code_length = 8190; otherwise disp('Unsupported Code Generator Mode') end % switch % Form the generator polynomial vector into a 14 by 14 state transition matrix with an identity sub-matrix % The identity matrix behaves like a shift register. if (poly_order == 14) G1 = [g1_poly ; eye(13,14)]; G2 = [g2_poly ; eye(13,14)]; elseif (poly_order = = 13) % Append 1 zero row and column to fill 14x14 array G1 = [g1_poly ; eye(12,13) ; zeros(1,13)]; G2 = [g2_poly ; eye(12,13) ; zeros(1,13)]; G1 = [G1 zeros(14,1)]; G2 = [G2 zeros(14,1)]; end % if % Set the iteration where the G1*X1 code generator state must be re- initialized to all ones. x1_state_init_k = x1_code_length / code_bits_per_row; % Initialize the X1 and X2 state variable vectors and the output array X1 = ones(14,1); X2 = code_gen_seed; code_array = zeros(10230 / code_bits_per_row, code_bits_per_row); % Code generation with one code bit per iteration if (code_bits_per_row == 1) for k = 1:10230 code_array(k) = xor(X1(poly_order), X2(poly_order)); X2 = mod(G2 * X2, 2); if (k == x1_state_init_k), X1 = ones(14,1); else, X1 = mod(G1 * X1, 2); end end % for % Code generation with ten code bits per iteration elseif (code_bits_per_row == 10) % Multiple the state transition matrix by 10 times to form a new matrix % that advances the state by 10 code bits on each iteration. G1_10 = mod(G1^10, 2); G2_10 = mod(G2^10, 2); % Define generator output range for state variable bits in reverse order out_index = uint8(poly_order:-1:(poly_order-9)); for k = 1:1023 code_array(k,:) = xor(X1(out_index), X2(out_index)); X2 = mod(G2_10 * X2, 2); if (k == x1_state_init_k), X1 = ones(14,1); else, X1 = mod(G1_10 * X1, 2); end end % for end % if % Print state transition matrix % G1 = uint8(G1) % G2 = uint8(G2) % G1_10 = uint8(G1_10) % G2_10 = uint8(G2_10) end % function % Example of code seed values for first 2 SVs in each constellation % Seed value vector order =>[s21, s22, s23, ... s2r], where r is state variable size % First code bits output are ordered as c1, c2, c3 .., with c1 as MSB % Because g1 is initialized to all 1s, the first code bit vector is inverted and bit-reversed from the seed vector % % Component Initial State Seed First code bits output % L5I sv1,I = 1010100011011 0010011101010 % L5Q sv1,Q = 0110100110011 0011001101001 % L5I sv2,I = 0011111001010 1010110000011 % L5Q sv2,Q = 1011100001001 0110111100010 % E5AI sv1,AI= 10100011000011 3CEA9D % E5AQ sv1,AQ= 01010101110101 515537 % E5BI sv1,BI= 00001001011100 C5BEA1 % E5BQ<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv1,BQ=<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 10011011011000<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> E49AF0<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> E5AI<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv2,AI=<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 00111001000110<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 9D8CF1<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> E5AQ<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv2,AQ=<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 01000110010100<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> D67539<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> E5BI<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv2,BI=<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 11100100001101<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 4F6248<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> E5BQ<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv2,BQ=<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 11000110001100<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> CE701F<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> B2AI<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv1,I =<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 1000000100101<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 26771056<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> B2AQ<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv1,Q =<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 1000000100101<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 26772435<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> %<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> B2AI<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> sv2,I =<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr"> 1000000110100<h2 style=";text-align:left;direction:ltr"> 64771737 % B2AQ sv2,Q = 1000000110100 64771100 % Notes: % L5 seed values are inverted, and first code bits are bit-reversed from ICD % E5 seed values are bit reversed from ICD % B2 is correct in ICD % secondary code - pilot % L5 at 1 kHz rate => nh20(t) = 0 0 0 0 0 1 0 0 1 1 0 1 0 1 0 0 1 1 1 0 Part 2 The following Matlab code provides an implementation in Matlab of a GNSS code sample generation script using the embodiment shown in FIG. 9A to FIG. 9D . clear sc_cmd.code_gen_poly_set = 'E5AIQ'; sc_cmd.code_gen_seed = [1 0 1 0 0 0 1 1 0 0 0 0 1 1]; sc_cmd.freq_shift = -20480; sc_cmd.freq_shift_phase = 0; sc_cmd.code_advance = 11.125; sc_cmd.code_phase_step = 0.01; sc_cmd.second_code_length = 20; sc_cmd.second_code_seq = ones(sc_cmd.second_code_length, 1); sc_cmd.second_code_phase = 0; ms_nr = 1; % function [code_sample_array, csg_state_var] = code_sample_gen(ms_nr, sc_cmd, csg_state_var) % Code Sample Generator - Generate GNSS code, secondary code, shift code phase, upsample, filter and shift frequency % First unpack the command and state variable structures % and translate values for the hardware operations % --- Commands that are fixed for dwell duration --- % Frequency shift is specified in Hz and converted to a signed fraction of the sample rate. freq_gen_shift = sc_cmd.freq_shift / 20480000; % Code generator polynomial set selection and initial state variable (seed) code_gen_poly_set = sc_cmd.code_gen_poly_set; code_gen_seed = sc_cmd.code_gen_seed; % Frequency shifter phase step per ms is defined as signed fraction of cycles advanced / declined per ms. freq_gen_phase_step_ms = rem(sc_cmd.freq_shift / 1000, 1); % Code phase step per ms is defined as signed fraction of the code- bit period advanced / declined per ms. code_gen_phase_step_ms = sc_cmd.code_phase_step; % --- Variables set to command values on first ms, and updated every ms over dwell duration --- if (ms_nr == 1) % Initial phase of freq gen is specified in degrees and converted to positive fraction of a cycle freq_gen_phase = mod(sc_cmd.freq_shift_phase, 360) / 360; % Initial phase of code gen is specified in positive code-bit periods with 0.125 resolution, 0 to 63.875 range code_gen_phase = sc_cmd.code_advance; else % When not first ms, load state variables from last ms freq_gen_phase = csg_state_var.freq_gen_phase; code_gen_phase = csg_state_var.code_gen_phase; end % Update and save state variables for the next ms time when this function is called again csg_state_var.freq_gen_phase = freq_gen_phase + freq_gen_phase_step_ms; csg_state_var.code_gen_phase = code_gen_phase + code_gen_phase_step_ms; % Factor the code phase advance into tens, ones and 1 / 8th fractions of code bits. % Hardware will apply these in 3 separate stages of cycle advancing and shifting. code_advance_rnd = round(8*code_gen_phase) / 8; % round to 1 / 8 resolution code_advance_tens = uint32(floor(code_advance_rnd / 10)); code_advance_ones = uint32(floor(code_advance_rnd / 1)) - 10*code_advance_tens; code_advance_frac = uint32(8*rem(code_advance_rnd,1)); % Secondary Code-bit Selection second_code_bit = sc_cmd.second_code_seq( mod((sc_cmd.second_code_phase+ms_nr-1), sc_cmd.second_code_length) +1); % --- Now generate 20480 samples for the code sequence % Generate a length 10230 code sequence for a GNSS satellite signal component. % Reshape into a column vector for easier math in subsequent lines, % although hardware will process 10 bits in parallel per cycle code_array = gnss_code_gen(10, code_gen_poly_set, code_gen_seed); code_vector = reshape(code_array', [10230 1]); % Apply the secondary code to the primary code sequence second_code_vector = xor(code_vector, second_code_bit*ones(10230,1)); % not exactly right! another secondary code bit is needed on extension % Extend the code sequence by 20 code bits by appending the first 20 code bits to the end of the sequence. % Advance the code phase in increments of 10 code bits % (like the hardware will do in multiple clock cycles) code_ext_adv10 = [second_code_vector((10*code_advance_tens+1) : 10230) ; second_code_vector(1 : (10*code_advance_tens+20))]; % Advance the code phase by 0 to 9 code bits. Append NaN to fill vector to same size code_adv1 = [code_ext_adv10(code_advance_ones+1 : length(code_ext_adv10)) ; NaN(code_advance_ones, 1)]; % Upsample 8x by stretching each code-bit value over 8 consecutive samples code_sample_8x = reshape([code_adv1 code_adv1 code_adv1 code_adv1 code_adv1 code_adv1 code_adv1 code_adv1]', [8*length(code_adv1), 1]); % Further advance the code phase with 1 / 8 th chip resolution. Append NaN to fill vector to same size code_adv_frac = [code_sample_8x(code_advance_frac+1 : length(code_sample_8x)) ; NaN(code_advance_frac, 1)]; % Reshape into array of 1025 rows by 80 columns in column-order (just for easy sample insertion) % Insert repeated sample at the Nr row index in each of the 80 columns. % Reshape back into 1 column vector code_sample_array = reshape(code_adv_frac, [1025 80]); Nr = 512; code_insert_array = [code_sample_array(1:Nr, 1:80) ; code_sample_array(Nr, 1:80) ; code_sample_array((Nr+1):1025, 1:80)]; code_upsample = reshape(code_insert_array, [80*1026, 1]); % Lowpass filter and decimating by 4 to 80*1024 sample vector h_aa = 1 / 64 * [5 -2 -4 -3 -1 5 9 15 16 15 9 5 -1 -3 -4 -2 5]; % plot(h_aa) Ni = length(h_aa) - 1; lpf = zeros(20480, 1); for n = 1:20480 lpf(n) = sum(h_aa' .* code_upsample(4*n-3 : 4*n-3+Ni)); end % Frequency shifter (typical range less than + / - 10 kHz). Complex output % Set phase accumulator to initial phase command, then advance by frequency shift command % Limit to 1024 phase shifts / cycle to match with capabilites of the CORDIC in 1st stage of 20 by 1024-point FFTs freq_gen_phase_accum = zeros(20480, 1); freq_gen_phase_accum(1) = freq_gen_phase; for n = 2:20480 freq_gen_phase_accum(n) = rem((freq_gen_phase_accum(n-1) + freq_gen_shift), 1); end freq_gen_phase_1024 = round(freq_gen_phase_accum * 1024) / 1024; code_sample_vector = lpf.* exp(1j*2*pi * freq_gen_phase_1024); % Reshape sample vector into array of 1024 rows by 20 columns in row order. code_sample_array = reshape(code_sample_vector, [20 1024])'; % end % Alt method % Lowpass filter and decimating by 4 % Sum 8 consecutive 1-bit code values and step 4 samples every iteration. % Equivalent to h = [1 1 1 1 1 1 1 1] with post decimation by 4 % y1 = zeros(20480+2, 1); % for k = 1:(20480+2) % y1(k) = sum(code_upsample(4*k-3 : 4*k+4)) - 4; % end % Equalization filter for sinc shape LPF spectrum (try 3-tap or may need 5-tap) % Note, LPF+EQ combined filtering has an effective group delay of 8 samples => 1024 / 1023 chip periods % c = 0.3; h_eq = [1-c 1 1-c]; % Just place holder!!!! % y2 = zeros(20480, 1); % for k = 1:20480 % y2(k) = sum(h_eq' .* y1(k : k+2)); % end Part 3 The following Matlab code provides an implementation of the GNSS signal acquisition engine in Matlab using the embodiment shown in FIG6 . % Acquisition Engine Signal Processing % Frequency Plan fs_adc = 432000; % Plan A rf_upsample_rate = 8; fs_rf = rf_upsample_rate * fs_adc; fs_if = fs_adc / 4; % Satellite Parameters ssg_param.sample_rate = 432000; % kHz ssg_param.sv_type = 'E5'; ssg_param.sv_number = 1; ssg_param.doppler_freq = 200; % Hz time shift per ms = -freq_shift / 116500 ssg_param.snr = 0; % dB ssg_param.chip_code_phase = 0; % apply as decline ssg_param.pilot_code_phase = 0; % % Digital Front End Commands dfe_cmd.first_if_upconv = 1; % Upconv neg IF, downconv pos IF dfe_cmd.gain_step = 1; % - 3dB steps dfe_cmd.ifd2_init_phase = 0; dfe_cmd.ifd2_freq_shift = -3795 / fs_if; dfe_cmd.ab_init_phase = 0; dfe_cmd.ab_freq_shift = 15345 / fs_if; dfe_cmd.int_dec_rate = floor(fs_if / 20480); dfe_cmd.frd_init_phase = 0; dfe_cmd.frac_dec_phase_step = fs_if / (dfe_cmd.int_dec_rate*20480) - 1; % AE Channel Commands for 4 sub-channels, 1 channel only dwell_duration = 10; % ms integration_mode = 'Non_Coh'; comp_combining_mode =

[0022] ; % 4

[0022] [1 1 1 1] sc1_cmd.sideband_select = 'ASB'; % ASB or BSB sc2_cmd.sideband_select = 'ASB'; sc3_cmd.sideband_select = 'BSB'; sc4_cmd.sideband_select = 'BSB'; sc1_cmd.freq_shift = 200; % Hz sc2_cmd.freq_shift = 200; sc3_cmd.freq_shift = 200; sc4_cmd.freq_shift = 200; sc1_cmd.freq_shift_phase = 0; % Degrees sc2_cmd.freq_shift_phase = 90; sc3_cmd.freq_shift_phase = 0; sc4_cmd.freq_shift_phase = 90; sc1_cmd.code_advance = 11.125; % Code sequence start position (1 / 8 chip resolution) sc2_cmd.code_advance = 11.125; sc3_cmd.code_advance = 11.125; sc4_cmd.code_advance = 11.125; sc1_cmd.code_phase_step = 0.01; % added / subtracted from code phase every ms sc2_cmd.code_phase_step = 0.01; % set to -freq_shift / 116500 sc3_cmd.code_phase_step = 0.01; sc4_cmd.code_phase_step = 0.01; sc1_cmd.code_gen_poly_set = 'E5AIQ'; sc2_cmd.code_gen_poly_set = 'E5AIQ'; sc3_cmd.code_gen_poly_set = 'E5BIQ'; sc4_cmd.code_gen_poly_set = 'E5BIQ'; sc1_cmd.code_gen_seed = [1 0 1 0 0 0 1 1 0 0 0 0 1 1]; % for Galileo SV #1 sc2_cmd.code_gen_seed = [0 1 0 1 0 1 0 1 1 1 0 1 0 1]; sc3_cmd.code_gen_seed = [0 0 0 0 1 0 0 1 0 1 1 1 0 0]; sc4_cmd.code_gen_seed = [1 0 0 1 1 0 1 1 0 1 1 0 0 0]; sc1_cmd.second_code_length = 20; % L5 => 10,20 ; E5 => 4,20,100 ; B2 => 5, 100 sc2_cmd.second_code_length = 100; sc3_cmd.second_code_length = 4; sc4_cmd.second_code_length = 100; sc1_cmd.second_code_seq = zeros(sc1_cmd.second_code_length, 1); % create function based on SV number and type sc2_cmd.second_code_seq = zeros(sc2_cmd.second_code_length, 1); % or just write down first 2 SV of each GNSS sc3_cmd.second_code_seq = zeros(sc3_cmd.second_code_length, 1); sc4_cmd.second_code_seq = zeros(sc4_cmd.second_code_length, 1); sc1_cmd.second_code_phase = 0; % Index offset advance of first code bit within sequence at start of dwell. sc2_cmd.second_code_phase = 0; % All secondary codes have 1 ms bit period sc3_cmd.second_code_phase = 0; sc4_cmd.second_code_phase = 0; % Dwell Loop for 1 channel with up to 4 sub-channels for ms_nr = 1 : dwell_duration % GNSS Satellite Signal Generator => Length 432,000 column vector, Load / save state variables every ms [ssg_signal, ssg_state_var] = gnss_signal_gen(ms_nr, ssg_param, ssg_state_var); % Digital Front End => 1024 by 20 in row order, Load / save state variables every ms [ASB_sample, BSB_sample, dfe_state_var] = dig_front_end(ms_nr, ssg_signal, dfe_cmd, dfe_state_var); % GNSS Code Sample Generators => 1024 by 20 in row order [code_sample_1, csg1_state_var] = code_sample_gen(ms_nr, sc1_cmd, csg1_state_var); [code_sample_2, csg2_state_var] = code_sample_gen(ms_nr, sc2_cmd, csg2_state_var); [code_sample_3, csg3_state_var] = code_sample_gen(ms_nr, sc3_cmd, csg3_state_var); [code_sample_4, csg4_state_var] = code_sample_gen(ms_nr, sc4_cmd, csg4_state_var); % Sideband Signal Spectrum Transform => 1024 by 20 in column order ASB_spec = vfft_dit(ASB_sample); BSB_spec = vfft_dit(BSB_sample); % Select Sideband Spectrum for each Sub-channel if (sc1_cmd.sideband_select == 'ASB'), sc1_SB = ASB_spec; else, sc1_SB = BSB_spec; end if (sc2_cmd.sideband_select == 'ASB'), sc2_SB = ASB_spec; else, sc2_SB = BSB_spec; end if (sc3_cmd.sideband_select == 'ASB'), sc3_SB = ASB_spec; else, sc3_SB = BSB_spec; end if (sc4_cmd.sideband_select == 'ASB'), sc4_SB = ASB_spec; else, sc4_SB = BSB_spec; end % Code Spectrum Transform => 1024 by 20 in column order code_spec_1 = vfft_dit(code_sample_1); code_spec_2 = vfft_dit(code_sample_2); code_spec_3 = vfft_dit(code_sample_3); code_spec_4 = vfft_dit(code_sample_4); % Signal and Code Spectrum Multiple => Conjugate the code spectrum and result before IFFT mult_spec_1 = conj(sc1_SB .* conj(code_spec_1)); mult_spec_2 = conj(sc2_SB .* conj(code_spec_2)); mult_spec_3 = conj(sc3_SB .* conj(code_spec_3)); mult_spec_4 = conj(sc4_SB .* conj(code_spec_4)); % Correlation (Inverse) Fourier Transform => 1024 by 20 in row order corr_result_1 = vfft_dif(mult_spec_1); corr_result_2 = vfft_dif(mult_spec_2); corr_result_3 = vfft_dif(mult_spec_3); corr_result_4 = vfft_dif(mult_spec_4); % Correlation Post Processing % Integration % Correlation Plot-update every ms % Print out status % Save results to file end % ms_nr loop Part 4 The following Matlab code provides an implementation of a GNSS signal acquisition engine in Matlab. In the embodiment shown in FIG6 , the GNSS signal acquisition engine uses DFT and time decimation. function [Y] = vfft_dit(X) % Very Fast Fourier Transform by Decimation in Time Algorithm % % X is the time domain input array of N2 rows by N1 columns with array % elements in row order. % % Y is the frequency domain output array of N2 rows by N1 columns with array % elements in column order. % % The N-point VFFT-DIT algorithm-architecture is speed optimized by decomposing % the FFT processing into N1 parallel FFTs of N2-points, followed by a % combining stage with N1-point DFTs. The N1 parallel FFTs are performed % concurrently using array processing to speed up FFT processing time by a % factor of N1 times. % The total number of FFT points is N = N1 * N2, with N1 << N2 % An inverse VFFT-DIT can be done by conjugating the input and output arrays. % Find the dimensions for the X array input [N2, N1] = size(X); % Total number of FFT points N = N1 * N2; % Calculate N2-point FFTs for all columns of X array H = fft(X, N2, 1); % Define an N2 by N1 array of n2*k1 exponent values for the WN phase shift factors P = [0:1:(N2-1)]' * [0:1:(N1-1)]; % Define the N2 by N1 array of WN phase shift factors WN = exp(-1j*2*pi / N * P); % Array element multiply of the N2-point FFT results and the WN phase shift factors H_WN = H .* WN; % Calculate N1-point DFTs on all rows Y = fft(H_WN, N1, 2); end Part 5 The following Matlab code provides an example of an implementation of a GNSS signal acquisition engine in Matlab, which uses a DFT with frequency decimation in the embodiment shown in FIG6 . function [Y] = vfft_dif(X) % Very Fast Fourier Transform by Decimation in Frequency Algorithm % % X is the time domain input array of N2 rows by N1 columns with array % elements in column order. % % Y is the frequency domain output array of N2 rows by N1 columns with array % elements in row order. % % The N-point VFFT-DIF algorithm-architecture is speed optimized by decomposing % the FFT processing into a first stage with N1-point DFTs, followed by % N1 parallel FFTs of N2-points. The N1 parallel FFTs are performed concurrently % using array processing to speed up FFT processing time by a factor of N1 times. % The total number of FFT points is N = N1 * N2, with N1 << N2 % An inverse VFFT-DIF can be done by conjugating the input and output arrays. % Find the dimensions for the X array input [N2, N1] = size(X); % Total number of FFT points N = N1 * N2; % Calculate N1-point DFTs on all rows of X G = fft(X, N1, 2); % Define an N2 by N1 array of n2*k1 exponent values for the WN phase shift factors P = [0:1:(N2-1)]' * [0:1:(N1-1)]; % Define the N2 by N1 array of WN phase shift factors WN = exp(-1j*2*pi / N * P); % Array element multiply of the first stage DFT results and the WN phase shift factors G_WN = G .* WN; % Calculate N2-point FFTs for all columns of G .* WN Y = fft(G_WN, N2, 1); End Appendix 3 [Background of using frequency domain Doppler compensation] [GNSS] [Signal Acquisition:] GNSS (Global Navigation Satellite System) signals typically incorporate a pseudo-randomly modulated (PRN) waveform to achieve precise time-of-arrival measurement at the receiving terminal. A PRN waveform typically incorporates a repetitive code whose duration is called the frame length. Signal processing structures (such as a correlator, matched filter, etc.) are used to process the received waveform. The present invention focuses on acquiring GNSS signals based on the use of a fast Fourier transform (FFT) method, which effectively implements a matched filter corresponding to the received signal. This approach is particularly attractive when the spreading ratio (SR) of the PRN waveform is large (i.e., the ratio of signal bandwidth to frame length is large). In many modern GNSS systems, this spreading ratio can exceed 10,000. The FFT is a very efficient algorithm for computing a discrete Fourier transform (DFT), and even though the term "FFT" is used throughout this document, by FFT we mean any method for computing a DFT, including various FFT algorithms, including the Cooley-Tukey algorithm, the prime factor algorithm, the frequency-modulated z-transform algorithm, etc. Acquiring a GNSS signal with a high SR is difficult because the signal arrival time must be within a large set of times (e.g., over 10,000 in the example above) and tested at a large set of potential frequency offsets from a nominal hypothetical carrier frequency due to the Doppler effect and local clock errors. Furthermore, testing must be performed on a set of possible satellite signals. This set of times, frequency offsets, and number of satellite signals is called a "hypothesis." As can be seen above, acquiring a GNSS signal requires searching a large three-dimensional hypothesis space. The use of the FFT method allows for very efficient time hypothesis searching because it can process each possible time hypothesis in parallel within the frame length. The FFT method performs a matched filter operation on a set of incoming time samples by (1) performing a forward FFT on the set of incoming time samples to generate a set of "signal frequency samples," (2) multiplying the signal frequency samples by the frequency samples of a PRN reference signal (called "reference frequency samples"), and (3) performing an inverse FFT on the result. This set of output samples is then further accumulated with the previous sets of outputs to perform "coherence processing," or detecting output samples (usually by magnitude or magnitude square operations) and accumulating them with similarly processed previous data sets. The accumulated processed data sets are observed to determine if a large peak appears above the background noise samples, where the peak indicates the arrival time of the incoming signal. As indicated above, during the acquisition process, the incoming signal may have a carrier frequency offset associated with it, which is also determined. Conventional methods for making this determination involve assuming a Doppler frequency, compensating for Doppler in the time domain by multiplying the incoming samples by a complex cosine to remove the Doppler component, and then proceeding with the above three steps. This process is performed for each of a set of assumed Doppler frequencies. A problem with this approach, which utilizes FFTs, is that a forward FFT and an inverse FFT are required for each Doppler frequency hypothesis. In many cases, a search must be performed within a set of 20 or more such hypothetical frequencies. The present invention reduces the number of FFTs to approximately half of that required in the above prior art methods, thereby reducing overall processing time by nearly half. [invention] [] In the following discussion, frequency uncertainty is referred to as "Doppler," but frequency uncertainty can also be due to local oscillator frequency errors. For simplicity, frequency uncertainty is referred to as "Doppler," but this term actually refers to any source of frequency uncertainty, perhaps including errors on the part of a GNSS transmitter. Furthermore, for simplicity, the following discussion ignores the multiplication of the forward FFT data with the frequency reference (discussed above), although this multiplication is normally performed. After a forward FFT, if the FFT output is considered a vector, rotating the vector by m positions is equivalent to a frequency shift equal to m × grid spacing, where the grid spacing is equal to the sampling rate divided by the number of samples / FFT. Here, m is an integer that can be positive for positive shifts and negative for negative shifts. If the input signal is positively Doppler-shifted, the vector is typically rotated negatively to compensate, and vice versa. This has the effect of shifting the signal to near zero frequency or some other desired frequency. The advantage of this method is that after a forward FFT, Doppler multiplicity can be tested using a series of inverse FFTs, each of which is followed by a frequency shift performed by a rotate-by-1 operation. For example, if 20 Doppler frequencies were tested in this way, only one forward FFT would be required, and 20 inverse FFTs would be required, one for each Doppler frequency to be tested. In this example, only 21 FFT operations need to be performed, while 40 are required in the standard method. In many cases, testing the Doppler uncertainty at increments of integer grid spacing is coarse, resulting in a worst-case loss of (0.5) or 3.9 dB. To reduce this loss, it is desirable to perform a rotation of the above vector by ½ grid spacing, that is, to test it for a Doppler frequency offset equal to m + ½ grids. This rotation can be performed in one of three ways. In the first method, two forward FFTs are performed, one without modification and the second with a frequency shift equal to half the grid spacing, that is, a frequency offset of the sampling rate / (2×no_FFT_samples). This frequency shift is performed in the time domain by multiplying by a complex cosine in the usual way (or using an equivalent algorithm such as CORDIC rotation). Each of these forward FFTs is stored. To test for Doppler error at an integer number of grids, the first forward FFT vector is rotated by the desired number of grids. To test for Doppler error incorporating half-grid spacing, the second forward FFT vector is selected and rotated by an appropriate integer number of grids. For example, if one wants to test for Doppler error at m+1 / 2 grids (m and integer), that is, one desires a total compensation shift of -m-1 / 2 grids, This will rotate the second forward FFT vector by -m-1 positions. Note that the second FFT data set incorporates a shift of (assumingly) +1 / 2 divisions, resulting in a total shift of -m-1 + 1 / 2 = -m-1 / 2. Of course, the above technique also works if the data used is first frequency-shifted by -1 / 2 divisions, or indeed by 1 / 2 divisions plus a positive or negative integer multiple of divisions, before the second forward FFT. In this case, the data vector will need to be rotated by an appropriate integer amount after the second forward FFT to achieve the overall desired Doppler compensation. The first method above is very accurate, but of course the number of forward FFT operations is doubled. In the previous example, a total of 22 forward FFTs were required, while the standard method required 40 FFTs, still a significant saving. However, another disadvantage is that twice as many forward FFT vectors need to be retained, which can be a significant cost, especially when several parallel FFTs are required to achieve a desired overall acquisition time. A second method for achieving an offset that incorporates half-grid spacing uses an interpolation technique on the forward FFT samples in the frequency domain to determine the intermediate samples at half-grid spacing from each of the original frequency samples. This vector of intermediate samples then replaces the second forward FFT discussed above. This vector of intermediate samples is then rotated by the required number of positions to implement a Doppler shift of half-grid spacing plus the required number of integer grids. A variety of different interpolation functions can be used to determine the intermediate samples, depending on the desired complexity and accuracy. For example, a sinc interpolator (sin(2πf) / (2πf), where f is in units of grid spacing) can be used. Alternatives include polynomial interpolators, spline functions, and others. Generally, the most appropriate interpolator can be determined empirically, as it depends on the frequency response of the time samples and the maximum complexity of the interpolator. When achieving half-grid spacing using either method, the worst-case loss due to Doppler error is -0.91 dB. This does not include any additional implementation errors (such as interpolation error). In yet another third method, interpolation is performed, but not in the frequency domain. The input data sample set is appended with additional frequency samples with a value of zero, either at the beginning or at the end of the sample set. If the set of zero-valued samples is equal to the value of the original sample set, the resulting FFT of the appended sample set now has an FFT with a grid spacing of ½, relative to the FFT of the non-appended set. Thus, a simple rotation of the FFT vector now provides a frequency translation in either the positive or negative direction, similar to that discussed above. Spacing less than ½ grid can be achieved by appending the original set with more zero-valued samples (e.g., adding twice as many zero-valued samples to provide a 1 / 3 grid spacing, etc.). For testing Doppler with m+1 / 2 grid spacing, choosing the first or second method depends on the memory requirements of the first method due to the complexity of the interpolation. In terms of computational speed, the interpolator method is expected to use fewer operations per frequency sample than the FFT. Although it would appear that an interpolation process could be more computationally efficient, further examination indicates otherwise. In terms of operations per data sample, the FFT operation is very efficient. An FFT of length N requires only approximately 2 log2(N) real multiplications per data sample. For example, an FFT of size 1024 requires only approximately 20 real multiplications per data sample. An interpolator of equivalent complexity would have an interpolation filter length (number of points) equal to 10, since two real multiplications are required per frequency sample. Since frequency data is often very noisy, it is unclear whether this short length would be sufficient to achieve the required accuracy. The above method can be further generalized to offsets other than m+1 / 2 grid spacing to m+e grid spacing, where e is any number between 0 and 1. After frequency conversion, an additional forward FFT of the input data can be calculated by a quantity corresponding to e grids and stored for later use, where this vector is used with an appropriate number of vector position shifts. Alternatively, an interpolation method can be used to determine the middle sample from any of a set of pre-computed FFT data (e.g., a set with a frequency offset of 0 and a 1 / 2 grid offset). Again, there is a trade-off between the need for more forward FFTs and increased indirect storage and the computational complexity of an acceptable interpolation method. The disadvantage of the third method discussed above is that it requires an FFT twice as large or larger and requires twice the storage to achieve the performance of this process. This may not be as efficient as methods 1 and 2, but it can be competitive in some cases, especially for relatively small FFT sizes. It should be clear from the above discussion that the three methods discussed above can be combined in various ways. For example, the third method can be combined with the second method to achieve a very small grid spacing without requiring a large FFT size. In another aspect of the present invention, a set of Doppler frequencies can be tested for more than one PRN corresponding to more than one received GNSS satellite signal without performing additional forward FFTs. That is, in the previous discussion, one or several forward FFTs are performed on the data, followed by a set of inverse FFTs to test various Doppler shifts, all corresponding to a specific satellite signal, i.e., a specific PRN. As indicated above, as part of the overall processing, the frequency samples are multiplied by the frequency samples of a PRN reference signal. This occurs after the Doppler shift operation described above. This is because the PRN frequency samples are assumed to have zero frequency offset. A similar set of inverse FFTs can be performed on other PRNs using their corresponding frequency samples, and additional Doppler frequencies can again be tested without having to perform another forward FFT corresponding to these additional PRNs. In another aspect of the present invention, rather than rotating or shifting the vector of frequency samples provided by the forward FFT of the signal samples, a similar operation can be performed on the frequency samples of the PRN reference signal. That is, Doppler compensation is performed on the PRN frequency samples rather than the signal frequency samples. A problem with this approach is that even when the Doppler is assumed to be exactly correlated with the signal, the product of the signal frequency samples and the Doppler-compensated PRN samples will no longer be zero frequency. Therefore, the inverse FFT will contain a frequency offset. However, applying the magnitude of the inverse FFT will remove the frequency component. Therefore, this approach is effective for applications that only perform incoherent summations of these inverse FFT vectors. An advantage of this approach is that the Doppler-shifted PRN frequency samples can be pre-calculated, thus eliminating the need for any additional forward FFT of the signal data, as indicated by the previously mentioned approach (using Doppler-shifted signal frequency samples).

[0078] 10: System 12: Application Processor 12A: Cache memory 14: Bus 16: Processor 16A: Static Random Access Memory 17: Cellular phone RF components 18: Antenna 20: Global Navigation Satellite System Processor 21: GNSS RF components 22A: Antenna / Global Navigation Satellite System Antenna 22B: Antenna / Global Navigation Satellite System Antenna 24: Dynamic Random Access Memory 26: Input / Output Devices 50: System / Operating System 52: System on Chip 54: System bus / bus 56: Dynamic Random Access Memory 57: Non-volatile memory 58: Input / Output Controller 60: Input / output device 62:Sensor / RF components 63: GNSS RF components 64: Cellular phone radio frequency components 66: Application Processor 68: Global Navigation Satellite System Processing System 70: Cache memory 72:Memory Controller 74: Bus 76: Processor 78: Bus Interface 101: Operation 103: Operation 105: Operation 107: Operation 109: Operation 111: Operation 113: Operation 115: Operation 150: Part 151: Antenna 153: GNSS RF Front End 155: RF Analog-to-Digital Converter 157: Base frequency sample array / array 159: Arithmetic Logic Unit 201: Operation 203: Operation 205: Operation 207: Operation 209: Operation 211: Operation 213: Operation 215: Operation 217: Operation 219: Operation 251: Input 253: Base frequency sample memory / memory 255: Discrete Fourier Transform Arithmetic Logic Unit 257:Memory / Fast Fourier Transform Result Array 258: Output 259: Code Generator 261: Discrete Fourier Transform Arithmetic Logic Unit 263: Code spectrum memory 265:Multiplier 267: Inverse Discrete Fourier Transform Arithmetic Logic Unit 269: Associated post-processing operator 271:Memory / Integral Memory 301: Array 303: Operation 304: Operation 306: Operation 308: Partial result sample array 311: Array 313: Operation 315: Operation 351: Phase Factor Array 353: Phase Factor Array / Array 355: Discrete Fourier Transform Operation 357: Discrete Fourier Transform Operation 361: First level sample array 363: Operation 365: Operation 367: Operation 371: Post-processor 373: Integral Array 401: Code 402: Polynomial Generator 404:Time Shifter 406: Programmable phase split input 408:CORDIC Phase Rotation 410:CORDIC phase rotation 412:CORDIC Phase Rotation 415:CORDIC Phase Diagram 417: Phase Rotation 419: Phase Rotation 421: Phase Rotation 450:Global Navigation Satellite System Processing System 451:Navigation chip 453: GNSS receiver code 457:Logic Module 458: Get Engine 459: Satellite signal generator 460:Digital Front End 461:Time base and control module 462: Bus Control Module 463:Tracking Engine 464: PLL Generation and Gate Control Circuit System 465: RF Analog-to-Digital Converter 466:ARM processor 467:ARM program and data memory 468: Baseband sample memory 469: Get engine command memory 470: Fast Fourier Transform Program Memory 471: Fast Fourier Transform Constant Memory 472: Fast Fourier Transform Variable Memory 473: Fast Fourier transform result memory 474: Code spectrum generation memory 475: Synchronous Integral Memory 476: Inverse Fast Fourier Transform Memory 477: Inverse Fast Fourier Transform Memory 478: Inverse Fast Fourier Transform Variable Memory 479: Non-coherent integral memory 501: Code forward matrix 502: Code forward matrix 503: Generator polynomial 505: Generator polynomial 507: Second input 509: Second input 511: Multiplexer 515: register 517: register 519:XOR logic gate 521:XOR logic gate 523: secondary code bit 524: Move the code forward by ten digits 526: register 527: Left shift logic 529: Add sampling logic block 531: register 533: Left shift logic 601: Operation 603: Operation 605: Operation 607: Operation 609: Operation 611: Operation 613: Operation 701: RF front-end module 703: Digital Front End 707: GNSS Antenna 709: Bandpass filter 711: Low Noise Amplifier 713: Bandpass filter 715:Amplifier 717:Analog-to-digital converter 719: Clock Generation Phase-Locked Loop 721:CIC Extractor 723:Clock divider 725:Clock divider 727: Down Converter 729:CIC Extractor 731: Sideband Splitting Down Converter 951: Operation 953: Operation 955: Operation 957: Operation 959: Operation 961: Operation 963: Operation 965: Operation 967: Operation 969: Operation 971: Operation 973: Operation 975: Operation

Claims

1. A method for processing GNSS signals in a GNSS receiver, the method comprising: Determine a set of initial information comprising at least two of the following: (a) a code phase of a primary code signal or a secondary code signal received from at least one GNSS space vehicle (SV); (b) an estimated GNSS time based on one or more time sources, the estimated GNSS time being estimated or known to be within + / - 0.5 milliseconds of the actual GNSS time; and (c) the approximate location of one of the GNSS receivers; estimate the expected fractional primary code phase of one of the GNSS signals to be received based on the set of initial information; perform a first DFT correlation using at least a first full primary code period of digitized GNSS sample data received within a time period, the time period being comparable to a time period of a code period of the GNSS signals, the correlation based on the first DFT using digitized GNSS sample data starting at a first time; A second DFT correlation is performed using at least one second full code period of received digitized GNSS sample data, the received digitized GNSS sample data being included in at least some of the GNSS sample data received in the first full code period, the second DFT correlation using digitized GNSS sample data starting at a second time, the second time being after the first time and deviating from the first time by less than the time period of the code period; a subcode is removed from the result of the first DFT correlation and the second DFT correlation to provide input for a coherence integration operation; at least one of these inputs is integrated into a coherence hypothesis memory; the magnitude of the result is squared from the coherence hypothesis memory or the magnitude of the result is taken to obtain a GNSS signal from at least one GNSS SV.

2. The method of request 1, wherein the I data and Q data are summed in each of the first full code time period and the second full code time period.

3. The method of request item 1, further comprising: The summation of such squared results is performed in the nonhomogeneous hypothesis memory, wherein such summation of such squared results occurs a few milliseconds after the first time.

4. The method of request item 1, wherein the method further includes: A search order is established for GNSS signals from GNSS SV, which is at least partially based on the expected fractional primary code phase.

5. The method of request item 1, wherein the method further includes: Select one subgroup of the associated hypotheses within one of the windows containing the expected digital phase to store it in the homology hypothesis memory.

6. The method of request item 1, wherein the method further includes: Each SV is assigned to an input sample offset group based on several factors, including the expected primary key phase of each SV.

7. The method of claim 6, wherein the method further includes: Assign one SV to one estimated code period and another SV to another estimated code period, wherein each SV is assigned to a code period that is temporally closer to the other SV.

8. A system for processing GNSS signals, the system comprising: A memory for storing primary seeds of GNSS signals from one or more GNSS clusters GNSS SVs and storing one representation of primary polynomial data for generating primary PRN codes of the GNSS signals; a code generator coupled to the memory to receive the primary seeds and the primary polynomial data, and using the primary seeds and the primary polynomial data to generate more than two primary PRN code bits in a single clock cycle during acquisition and tracking of one of the GNSS signals.

9. The system of claim 8, wherein the code generator calculates more than two primary PRN code bits in a single clock cycle by using one of a computed code shift matrix, the computed code shift matrix being derived from a primary code polynomial matrix of a given GNSS cluster multiplied by a factor of N with one of the GNSS signal components in that GNSS cluster, where N represents the number of primary PRN code bits generated in a clock cycle.

10. The system of claim 9, wherein the system generates the master PRN code bits but does not store the master PRN code bits after tracing is completed or after the DFT transformation of the present master code period is completed.

11. The system of claim 9, wherein the computed code shift matrix is ​​pre-computed and stored in the memory before the acquisition begins, and wherein N represents the code shift amount provided by the code generator between clock cycles.

12. The system of claim 9, further comprising: A GNSS processing system coupled to the code generator, the GNSS processing system being used to obtain at least two of the four GNSS signal components by nonhomologically integrating at least two of the four GNSS signal components in an array processing system within a time period, the array processing system receiving GNSS sample data from a baseband memory and the GNSS sample data being formatted into a column and row array having a plurality of columns and rows.

13. The system of claim 12, wherein the generation of GNSS PRN codes by the code generator is performed dynamically based on GNSS SV in the field of view during the acquisition and tracking of GNSS signals.

14. The system of claim 13, wherein a GNSS master PRN code from one of the outputs of the code generator is frequency-shifted and time-shifted to generate a code spectrum for use in the DFT, thereby obtaining the frequency result of the DFT of the received GNSS signal.

Images