Baseband Hardware Design for Space-grade Multi- GNSS Receivers

Transcription

1 International Global Navigation Satellite Systems Society IGNSS Symposium 2011 University of New South Wales, Sydney, NSW, Australia November 2011 Baseband Hardware Design for Space-grade Multi- GNSS Receivers Nagaraj C Shivaramaiah University of New South Wales, Australia nagaraj@unsw.edu.au Peter J Mumford University of New South Wales, Australia p.mumford@unsw.edu.au Kevin Parkinson University of New South Wales, Australia kevin@dynamics.co.nz ABSTRACT This paper describes the design of a Field Programmable Gate Array (FPGA) based baseband hardware for UNSW s multi-gnss space-grade Namuru receiver. Apart from being multi-frequency, a significant shift in the proposed design compared to the previous generations of UNSW s FPGAbased baseband designs is the use of Actel FPGAs. Details of the baseband design are provided along with a real signal test result for the GPS L5 signal. A potential user of this baseband hardware is the Garada, a Synthetic Aperture Radar (SAR) satellite formation flying project. KEYWORDS: GNSS, baseband, FPGA, space-grade. 1. INTRODUCTION 1.1 System Overview The Garada prototype multi-gnss receiver in its final form plans to achieve the space grade positioning and navigation capability by receiving, processing and utilising four major open service GNSS signals: GPS L1 C/A, Galileo E1 (E1b and E1c), GPS L5 and Galileo E5 (E5a and E5b). The Garada prototype receiver which is the Namuru V3.3 will be based on the architecture of GPS L1 C/A capable predecessor Namuru V3.2 and uses some of the receiver

2 Multiband GNSS antenna Multichannel RF Frontend L1/E1 IF L5/E5a, E5b IF Baseband (FPGA) Correlation values Meas., status & command Processor (ARM) Mission Computer Interface components of Namuru V3.2. Figure 1 Planned GNSS receiver architecture for Garada The Namuru family is basically an FPGA based GNSS receiver platform (Engel et. al. 2004; Parkinson et.al. 2006; Mumford et.al. 2006) that mainly focuses on the research aspects of the GNSS user segment. In the Namuru receiver, the digitized IF signal is processed with the help of a FPGA based hardware. The current stable version Namuru v2 can process GPS L1 C/A and QZSS signals. The Namuru V3.2 which is under development, is a space grade GPS L1C/A and QZSS L1C/A receiver planned to fly on Cubesats. The focus of this paper is the baseband signal processing part within the FPGA, the interface between the FPGA and the microprocessor and the memory mapped interface specifications of the baseband for the next version, the Namuru V3.3 planned to be integrated into other components of the Garada SAR formation flying project. Fig. 1 provides an overview of the planned architecture of the Garada receiver prototype. While the Namuru V1 and V2 used Altera FPGAs and the NIOS-II processor from Altera, Namuru V3.2 uses Actel FPGA and an ARM processor (ARM Cortex M3) available within the SmartFusion FPGA device. The plan for Namuru V3.3 is to continue using the ARM family of processors (or a high-end processor based on ARM core). Actel s flash FPGAs provide higher level of immunity to the radiation in space compared to other commercial FPGAs that use SRAM technology. The Namuru V3.2 space-grade receiver employs two Actel FPGA devices, a SmartFusion device and a ProASIC3 device. The high density ProASIC3 device implements most part of the baseband digital logic. The low-density FPGA fabric in the SmartFusion device is used to interface the ProASIC3 device and to perform some of the baseband control operations. The ARM Cortex M3 processor core within the SmartFusion device implements the software to program the baseband. In Fig. 1, the RF signal in the L1 and L5 bands after down conversion and digitization is fed into the FPGA baseband. The FPGA implements correlation processing for several channels and the correlation values and the measurements are passed onto the ARM processor for further processing. The ARM processor interfaces with the mission computer to exchange the

3 measurement and position solution information. The shaded portion is the main focus of the discussion in this paper. 2. OVERVIEW OF THE FPGA BASEBAND MODULE Fig. 2 provides the functional details of the FPGA baseband module. The functionality is divided into three sub modules, the correlator, the correlator controller and the interface controller. The correlator module comprises of the carrier and code mixers and accumulators for all the signals GPS L1, Galileo E1b and E1c, GPS L5 and Galileo E5a and E5b. The correlator controller implements the carrier NCO, carrier, code NCO, code and timing control signals for the correlator and interface controller blocks. The interface controller manages the memory mapped interface to the processor. The functional architecture depicted in Fig. 2 is slightly different to the other baseband descriptions available elsewhere in the literature. Usually, for a single channel of correlator, all the blocks viz, carrier NCO, carrier, carrier mixer, code NCO, code, code mixer and accumulators are put together and the channel block is instantiated (replicated) for as many channels as desired. However, in the architecture presented in Fig. 2, the correlation computation logic is separated from the logic responsible for the generation of local reference signals. The proposed modification is because of two reasons. First, in the context of multi-gnss baseband processing, especially the complex wideband signals, the correlation computation logic is not simple. Second, the commonality of several parameters in the generation of local reference signals can be exploited if the reference signal generation blocks of different signals are grouped together. Baseband (FPGA) Correlators (x Number of channels) Interface controller L1/E1 IF L5/E5a, E5b IF L1 correlator E1 correlator L5 correlator E5 correlator Correlation values Multiplexer To Processor Clock Correlator Controller Code Carrier Timing and Control logic Meas., status & command Mux / Demux Figure 2 Functional details of the baseband module

4 One advantage of separating the local reference signal blocks from the correlation computation blocks is the better controllability of the intra-system aiding. For e.g. the local carrier generation process, mainly the carrier NCO used for L1 C/A signal and the L5 signal f (for the same GPS satellite) can aid each other depending on the algorithm used during the acquisition and tracking. This sort of intra-system aiding is best realised if the two NCO blocks are grouped together, which is the case with the architecture shown in Fig. 2. The correlation computation block and the correlator controller block are instantiated for the required number of channels. The interface controller implements a memory mapped interface to the ARM processor and comprises of multiplexers/ de-multiplexers and the baseband wrapper for all the four signals. 3. DETAILS OF THE BASEBAND SUB-MODULES 3.1 Correlation computation module The correlation computation block accepts the IF signal samples and the local reference signals as the input and produces the correlation values. The correlation computation block is again divided into two sub modules, the sample correlator and the accumulator as shown in Fig. 3. Correlator L1/E1 IF L5/E5a, E5b IF Sample correlator L1C/A logic E1 logic L5 logic E5 logic L1C/A accumulators E1b/c accumulators L5I/Q accumulators E5 ai/aq/bi/bq accumulators Correlation values Local carrier and Latch and clear code+subcarrier bits (from controller) Figure 3 Details of the correlation computation block Sample correlator The sample correlator produces correlation values for one sample of the input IF signal and one sample of the local reference signal. Since these inputs are obtained at the sample clock rate, the sample correlation is computed before the next sample clock edge, generally implementing the computation as a combinational logic. Often the sample correlation block is implemented as a look-up-table (Shivaramaiah & Dempster, 2010). It should be noted that the

5 propagation delay of this combinational block is important when it comes to the wideband signals that require the computation of complex correlation. This propagation delay should be less than the sample clock period (less any setup time). Accumulator bank The accumulator accumulates the sample correlation values for a specified duration of time. The accumulator values are latched and the accumulator is reset on a control signal from the correlator controller. The accumulator block consists of a bank of accumulators to cater to the in phase and quadrature phase versions of the Early, Prompt and Late local reference signals. The correlation values of the signal components within a signal (i.e. the pilot and data for the Galileo E1 and GPS L5, Galileo E5a and Galileo E5b signals) go through individual accumulators. This sort of design allows the processor to have flexibility in combining the correlation values from the components of the signals depending on the algorithm used. Thus for the four signal case, a total of 54 accumulators are required (six for GPS L1 C/A, twelve each for Galileo E1 and GPS L5, twenty four for Galileo E5) for each channel. 3.2 Correlator controller module Fig. 4 shows the details of the correlator controller block for a single channel. As mentioned earlier in the paper, the correlator controller module comprises of the carrier and code generation blocks and the control signals generation block. The processor programs the PRN number, carrier frequency, code delay and the integration duration for each channel of the baseband module. The correlator controller module provides the measurement output upon a measurement latch request from the processor. To correlator Correlator Controller To correlator L1 carrier L1 C/A code E1 carrier E1b/c code memory & subcar L5 carrier L1 carrier NCO L5 I/Q code L1 code NCO E5a/b carrier E1 carrier NCO E5 ai/aq/bi/bq, code & subcar E1 code NCO Meas., status & command Clock L5 carrier NCO L5 code NCO E5 carrier NCOs E5 code NCOs Control signals generation logic and timing Latch and clear (to accumulators) Figure 4 Details of the correlator controller module The correlator controller blocks for the different signals differ mainly in the way the local code (or code + subcarrier) is generated. Details of the L1/E1 code generation correlator are explained in Shivaramaiah & Dempster (2009) and that of the E5 correlator in Shivaramaiah (2011). Fig. 5 shows the code generation logic for the GPS L5 signal. Whenever a new PRN is programmed or the code is reset, the initial states of the XBI and XBQ registers are read from the internal FPGA RAM and the XA register is initialized to all 1 s. Further the

6 XA register is reset after 8190 cycles which is shown as the reset logic in Fig. 5. Reset logic L5 I/Q code XA shift reg XI prn, phase init RAM XBI Init states RAM XBI shift reg clock XBQ Init states XBQ shift reg XQ Figure 5 L5 code generation block 3.3 Interface controller Fig. 6 shows the baseband module address map as seen from the processor. This is an extension of the existing Namuru receiver address map (Namuru data sheet, 2007). The offset address ranges from 0x0000 to 0x04FF with each signal occupying 256 locations. The address map has the redundancy built-in, i.e. the address map has the provision to independently use all the signals though some parameters are common between the signals from the same satellite (GPS L1 C/A and GPS L5 for example) and only one signal channel needs to be programmed for those parameters. The control registers for each channel have an information bit to indicate if that particular channel needs to derive the correlator parameters from another channel implementing its signal counterpart. The address map assumes 32-bit words for the interface. In the expanded address map for the three signals in Fig. 6, 16-bit correlation values for the pilot and the data channel are concatenated to fit into a 32-bit word. It is planned to change the interface to 16-bit half words and in that case the measurements span two half words (two locations) and the correlation values will not be concatenated (i.e. each correlation value will occupy one location). The 16- bit interface has been implemented but yet to be integrated with the processor subsystem. For the wideband signals especially GPS L5 and the Galileo E5, the correlation values require accumulators with more than 16-bit width for longer integration durations. In this case, the accumulators automatically latch the values at the end of one millisecond (i.e. after accumulating the number of samples in one millisecond), reset the contents to zero and start afresh. These one millisecond correlation values are further accumulated for the total integration duration within the processor. This method avoids the usage of different width accumulators for different signals. The processor in this case is interrupted at a rate slightly higher than one millisecond to access the intermediate correlation values.

7 Address Map (Offset Address) 0x000 0x0FF GPS L1 C/A 0x000 0x00F GPSL1_Channel_0 0x010 0x01F GPSL1_Channel_1 0x0B0 0x0BF GPSL1_Channel_11 0x0C0 0x0CF Spare 0x0D0 0x0DF Spare 0x0E0 0x0EF GPSL1_Status 0x0F0 0x0FF GPSL1_Control 0x100 0x1FF Galileo E1b/c 0x100 0x10F GALE1_Channel_0 0x110 0x11F GALE1_Channel_1 0x1B0 0x1BF GALE1_Channel_11 0x1C0 0x1CF Spare 0x1D0 0x1DF Spare 0x1E0 0x1EF GALE1_Status 0x1F0 0x1FF GALE1_Control 0x200 0x2FF GPS L5 0x200 0x20F GPSL5_Channel_0 0x210 0x21F GPSL5_Channel_1 0x2B0 0x2BF GPSL5_Channel_11 0x2C0 0x2CF Spare 0x2D0 0x2DF Spare 0x2E0 0x2EF GPSL5_Status 0x2F0 0x2FF GPSL5_Control 0x300 0x4FF GAL E5a/b 0x300 0x30F GALE5a_Channel_0 0x310 0x31F GALE5a_Channel_1 0x3B0 0x3BF GALE5a_Channel_11 0x3C0 0x3CF Spare 0x3D0 0x3DF Spare 0x3E0 0x3EF GALE5a_Status 0x3F0 0x3FF GALE5a_Control 0x400 0x40F GALE5b_Channel_0 0x410 0x41F GALE5b_Channel_1 0x4B0 0x4BF GALE5b_Channel_11 0x4C0 0x4CF Spare 0x4D0 0x4DF Spare 0x4E0 0x4EF GALE5b_Status 0x4F0 0x4FF GALE5b_Control GPS L1 C/A Channel n 0x0n0 prn_key (write) 0x0n1 carrier_nco (write) 0x0n2 code_nco (write) 0x0n3 code_slew (write) 0x0n4 I_early (read) 0x0n5 Q_early (read) 0x0n6 I_prompt (read) 0x0n7 Q_prompt (read) 0x0n8 I_late (read) 0x0n9 Q_late (read) 0x0nA carrier_val (read) 0x0nB code_val (read) 0x0nC epoch (read) 0x0nD epoch_check (read) 0x0nE-F spare GAL E1b/c Channel n 0x1n0 prn_key (write) 0x1n1 carrier_nco (write) 0x1n2 code_nco (write) 0x1n3 code_slew (write) 0x1n4 [I_early_b, I_early_c] (read) 0x1n5 [Q_early_b, Q_early_c] (read) 0x1n6 [I_prompt_b, I_prompt_c] (read) 0x1n7 [Q_prompt_b, Q_prompt_c] (read) 0x1n8 [I_late_b, I_late_c] (read) 0x1n9 [Q_late_b, Q_late_c] (read) 0x1nA carrier_val (read) 0x1nB code_val (read) 0x1nC epoch (read) 0x1nD epoch_check (read) 0x1nE-F spare GPS L5p/d Channel n 0x2n0 prn_key (write) 0x2n1 carrier_nco (write) 0x2n2 code_nco (write) 0x2n3 code_slew (write) 0x2n4 [I_early_p, I_early_d] (read) 0x2n5 [Q_early_p, Q_early_d] (read) 0x2n6 [I_prompt_p, I_prompt_d] (read) 0x2n7 [Q_prompt_p, Q_prompt_d] (read) 0x2n8 [I_late_p, I_late_d] (read) 0x2n9 [Q_late_p, Q_late_d] (read) 0x2nA carrier_val (read) 0x2nB code_val (read) 0x2nC epoch (read) 0x2nD epoch_check (read) 0x2nE-F spare GAL E5 a(m=3)/b(m=4) Channel n 0xmn0 prn_key (write) 0xmn1 carrier_nco (write) 0xmn2 code_nco (write) 0xmn3 code_slew (write) 0xmn4 [I_early_p, I_early_d] (read) 0xmn5 [Q_early_p, Q_early_d] (read) 0xmn6 [I_prompt_p, I_prompt_d] (read) 0xmn7 [Q_prompt_p, Q_prompt_d] (read) 0xmn8 [I_late_p, I_late_d] (read) 0xmn9 [Q_late_p, Q_late_d] (read) 0xmnA carrier_val (read) 0xmnB code_val (read) 0xmnC epoch (read) 0xmnD epoch_check (read) 0xmnE-F spare Figure 6 Address map of the baseband module as seen from the processor

8 Correlation Value Correlation Value 4. EXAMPLE RESULT Figures 7 and 8 provide the L5 acquisition and tracking results as an example output from the correlator. The correlation values from the baseband are transferred to a file and the plotted using Matlab. 6 x x Sample Number x Sample Number Figure 7 L5 pilot signal acquisition result from SVN Carrier doppler (Hz) 0.5 Carrier phase error (cycles) Code phase error (chips) Code doppler (Hz) x 105 Early, Prompt and Late Correlation values Time (ms) Figure 8 L5 pilot signal tracking result from SVN49

9 5. CONCLUSIONS This paper described the L1/E1/L5/E5 baseband development for the Garada prototype receiver. The focus was on the details of the functional units within the FPGA baseband. The processor interface address map details were provided by extending the address map of the UNSW s existing Namuru GPS L1 C/A receiver. An example acquisition and tracking result for the GPS L5 signal was provided. Future work involves integrating this baseband design with the processor subsystem driving the complete firmware and testing on the Namuru V3.3 Garada receiver board. ACKNOWLEDGEMENTS This research work is funded by the ASRP SAR Formation Flying project and the Biarri project. REFERENCES F. Engel, G. Heiser, P. J. Mumford, K. J. Parkinson, and C. Rizos (2004) "An Open GNSS Receiver Platform Architecture," in GNSS 2004, Sydney. Namuru Datasheet (2007) Namuru FPGA GPS tracking module Issue 1.3 January 2007, K. J. Parkinson, A. G. Dempster, P. J. Mumford, and C. Rizos, (2006) "FPGA based GPS receiver design considerations," Journal of Global Positioning Systems, vol. 5, pp P. J. Mumford, K. J. Parkinson, and A. G. Dempster, (2006) "The Namuru Open GNSS Research Receiver," in 19'th Int. Tech. Meeting of the Satellite Division of the U.S. Inst. of Navigation Fort Worth, TX, pp Shivaramaiah, N. C. & Dempster, A. G. (2009). Design challenges of a Galileo E1 correlator on the Namuru platform, IGNSS Symp, Gold Coast, Australia. Shivaramaiah, N. C. & Dempster, A. G. (2010). On the baseband hardware complexity ofmodernized GNSS receivers, IEEE ISCAS, pp Shivaramaiah, N. C. (2011). Enhanced Receiver Techniques for Galileo E5 AltBOC Processing, PhD thesis, School of Surveying and Spatial Information Systems, University of New South Wales, Sydney, Australia.