First Results of a GNSS Signal Generator Using a PC and a Digital-to-Analog Converter

Transcription

1 First Results of a GNSS Signal Generator Using a PC and a Digital-to-Analog Converter Andrea Pósfay, Thomas Pany, Bernd Eissfeller Institute of Geodesy and Navigation, University FA F Munich, Germany BIOGRAPHY Andrea Pósfay has obtained her diploma in Geodesy and Cartography from the Slovak University of Technology Bratislava and joined the Institute of Geodesy and Navigation at the University of Federal Armed Forces Munich in 21 as Research Associate. She has worked in the field of high-precision GNSS positioning and GPS meteorology. She is currently involved in the design of a GPS/Galileo software simulator. Thomas Pany has a PhD in Geodesy from the Graz University of Technology and a MS in Physics from the Karl-Franzens University of Graz. Currently he is research associate at the Institute of Geodesy and Navigation at the University of Federal Armed Forces Munich. His major areas of interests include GPS/Galileo software receiver design, Galileo signal structure and GPS science. Bernd Eissfeller is Full Professor and Vice-Director of the Institute of Geodesy and Navigation at the University of the Federal Armed Forces Munich. He is responsible for teaching and research in the field of navigation and signal processing. He received the Habilitation (venia legendi) in Navigation and Physical Geodesy in ABSTRACT Since 24 at the Institute of Geodesy and Navigation of University FAF Munich a Global Navigation Satellite System (GNSS) signal simulator has been developed. Like in cases of other institutes our motivation was to create a highly flexible, reasonable prized and reliable source of simulated GNSS signals in order to analyze and develop new receiver algorithms and hereby speed up the receiver development for the Global Positioning System (GPS) as well as for the future Galileo system. We present the development of a cost-efficient GNSS signal simulator based on a conventional PC and a commercial digital-to-analogue conversion (DAC) card. The signal simulator is in principle able to simulate arbitrary GNSS signals on arbitrary frequencies. The signals are precomputed for an intermediate frequency (IF) or for baseband on the PC and streamed to the DAC card which converts them to an analogue signal. This signal will be up-converted to RF (e.g. L1 = GHz) in a future project. A GNSS signal simulator is a powerful device, which simulates the received GNSS signal for a given satellite system (e.g. GPS or Galileo) and for a given user antenna trajectory. Satellite system parameters can be changed as well as the signal propagation environment. The benefits of this GNSS IF software signal simulator are demonstrated by two different software simulator applications described in this paper: generation of Galileo signals to make possible interference investigations between GPS and the future Galileo system and of a new BPSK like signal structure (Castle BPSK) to test its properties. In both cases the generated IF signals could be successfully tracked by a software receiver. These experiments show the outstanding benefits of a software based signal simulator: especially its extremely high level of flexibility in contrast to a hardware based signal simulator. To expand the application areas of the software simulator a new chapter of simulation has been started: the conversion of the digital IF samples into an analog signal in order to emit the simulated GNSS signals. The first milestone on this way has been completed. A fullconstellation low-bandwidth analogue GPS C/A signal at IF was generated and its properties have been investigated by a spectrum analyzer. The signals could be successfully acquired by feeding it into the analog IF input of the software receiver. INTRODUCTION The developed simulator generates bit true IF or baseband samples, i.e. these are virtually identical to the once produced by a real front-end having the same parameters. The signal simulator has been written in C++. The signal modeling in the software is divided in 4 modules: satellite

2 constellation, signal parameters, navigation message and front end. All of these components can be configured via dialog windows of the graphical user interface. There is no limitation in the number of channels. Homogenous (only one satellite system) and also mixed data can be simulated. The GPS signal simulation is based on the GPS-ICD-2 document. Because the Galileo system settings haven t been fully available yet we had to take assumptions to simulate the Galileo signal. The full satellite constellation can be modeled easily with a RINEX file or with an institute own geometry file of pseudoranges. This allows also modeling of the Galileo system constellation. Currently only the GPS C/A code navigation message can be simulated, however the data rate of this message can be chosen by the user. The simulated C/A code navigation message includes the preamble, the Z-count, parity calculation and the GPS week, in order to allow the receiver to determine the signal emission epoch in an absolute sense. Subframes 1, 2 and 3 are fully implemented (they contain real data), subframes 4 and 5 containing almanac information are still implemented as random messages. The signal can be specified by the user by setting the following parameters: code rate, carrier frequency, signal power, modulation, used navigation message and used pseudoranges. The program loads the PRN codes from an ASCII file. Different modulation schemes like BPSK (Binary Phase Shift Keying) and BOC (Binary Offset Carrier) can be simulated by the software. The parameters of the front end included in the simulator are: Antenna temperature, noise figure, local oscillator frequency, front-end total gain, signals and navigation messages to include. Finally the simulation parameters must be defined. Here the user can set the start time of the simulation, the GPS week, duration of simulation and the sample rate. The chosen configuration is visualized in the software making a quick check of the simulation modules possible. The simulator is now extended by using a commercial DAC converter to play-back the stored GNSS signal samples on the hard-disc. The DAC converter is connected to the PC via the PCI66 bus. Maximum realistic transfer rate of the PCI66 bus is about 4 MByte/s. The transfer rate limits the signal bandwidth of the simulated signals read from hard disk, as the Nyquist criterion must be fulfilled. By using the hard disk, very long simulation times of several minutes can be achieved. The output of the DAC converter is a real signal at IF level. In a follow up project the analogue output will be fed into an upconverter which brings the signal from baseband to the selected carrier frequency. Synchronization signals of 1 MHz are also available form the DAC card. The analogue output of the DAC card is fed into the IF input of a GNSS receiver. For example, the software receiver developed at the Institute of Geodesy and Navigation, has an IF input (it is the IF input of the ADC card). Connecting a PC-based signal generator and a software receiver via an analogue connection represents a first step towards developing the RF chain. In this paper we will present first results obtained simulating the GPS C/A code on L1. As test receiver, we use primarily the software receiver as this setup provides the most versatile analysis possibilities. We expect that the concept of a PC-based GNSS signal simulator will gain increasing importance in the next years. Computational power is still increasing, such that real-time computation of the signals will become feasible in due time. Eventually they will allow generating even signals of highest bandwidths (e.g. Galileo E5a+E5b signal) or multi frequency signals. The first part of this paper describes the current status of the GNSS IF signal simulator: Graphical user interface, main modules as well as configuration options and settings. The next part deals with applications: different scenarios will be presented where using a software receiver the simulated data are processed. The first application is about Galileo-GPS interference investigation and the second about a new signal structure implementation and development (castle BPSK signal). At the end of this paper the first tests and results with the DAC card will be introduced. CURRENT STATUS OF THE GNSS IF SOFTWARE SIMULATOR Figure 1. Part of the Graphical User Interface of the software the main window screen shot. All configured modules with some of their configuration parameters are showed during the simulation in the main window. Red lines match the corresponding modules. The signal simulator has 4 main modules: Message, Geometry, Signal and Front End. These were already introduced in [3]. Therefore just a short overview is given here whereas the new options are underlined. Each module has a dialog window to configure their parameters.

3 Message Module The user can choose from three options in the message module: No message C/A navigation message CNAV message So far the classical C/A navigation message is implemented in the software. As well known this message structure consists of 25 frames and each frame is built up from 5 subframes. The first subframe includes satellite clock corrections, health indicators and the age of data. The second and third one includes satellite ephemeris parameters. The fourth one contains the ionosphere mode parameters, UTC data, and almanac and health status data for satellites numbered 25 and higher. The fifth contains almanac and health status data for satellites numbered 1-24 [6]. The first 3 subframes in the simulator contain real data which are loaded from a special ASCII file. This includes the Kepler elements of each simulated satellite. After the file has been read, the data are converted in binary format and filled to the by ICD-GPS-2C document defined position. Subframes 4 and 5 are still random messages. Just the special message (text) on the page 17, subframe 4 is already implemented. The user can define the bit rate of the message which is currently the only chance in the simulator to mimic a Galileo navigation message. By this way the C/A navigation message is tuned to the Galileo signal structure as the Galileo navigation message is not available yet. The tuned message parameters for the Galileo are shown in Table 1. GPS Galileo Bit Rate [bps] 5 25 Z Count [s] Navigation Message [s] [zc] Frame [s] [zc] Subframe [s] [zc] Table 1. Parameters of the Galileo navigation message which is based on the GPS navigation message and tuned to the Galileo signal characteristics. By increasing the bit rate to 25 bit/s the navigation message duration is 2.5 min. The z count duration is adapted to this bit rate therefore the navigation message, frame and subframe duration in units of z counts (zc) remain the same as for the GPS C/A code. If the No message option is chosen, a data less signal is going to be generated for this message module. The CNAV message option is not implemented yet. Geometry Module This module deals with the satellite constellation: as an input either an institute own simulated pseudorange file or a RINEX file can be loaded. The simulated file contains: GPS sec Satellite PRN number Pseudorange [m] Rate [m/s] Received Power [dbw] Satellite Elevation [deg] Satellite Azimuth [deg] Ionospheric Delay at L1 [m] An institute own raw data generator can simulate separate pseudorange files for GPS and Galileo system. For the GPS simulation the YUMA almanac is applied for Galileo currently the Walker(27,3,1) constellation. This contains 27 satellites in 3 orbits with following main parameters: eccentricity, inclination 56, mean anomaly 13.33, semi-major axis 29, km. The data simulation rate is.1s. To shorten this interval and make the data more frequent for the simulations the polynomial interpolation is used. Signal Module Via this module the user configures the signal. First the modulation scheme has to be chosen: Standard BPSK(n) Castle BPSK(n) BOC(m,n) Any kind of BOC modulation can be applied. In addition a new option has been implemented: the castle BPSK signal (this will be described later on in this paper). Each code is loaded from an ASCII file. The user sets the path to this file, the code rate, carrier frequency, phase shift and the ID of navigation message and geometry which have to be applied on the signal. To neglect the received power loaded from the geometry file the user can set the received power of the signal: a constant value for all satellites of the signal will be used. If the simulated signal power has to be used, the polynomial interpolation is applied in order to get data for each epoch defined by the chosen sample rate (i.e. 1/sample rate). Signal power reduction can be applied on the read data as well. This allows an arbitrary combination of orthogonal signals sent simultaneously by a satellite like the Galileo or GPS L5 signal in his current status. This consists of 2 orthogonal signals and both together carry the final signal power. Front End Module This module s parameters are the antenna temperature, noise figure, local oscillator frequency, number of bits in

4 ADC, total antenna gain, signal and navigation message ID to be applied in the front end. At the end the simulation has to be configured. This dialog window includes start time of the simulation in GPS seconds, GPS week, duration of the simulation in seconds, sample rate and the ID of the used front end. The configured modules as well as the connection between them are visualized on the main frame of the software (Figure 1). APPLICATIONS The validation of the generated data has been already shown in [3]. Now we are focusing on some applications of the simulated data. Before moving on to processing the data for each new signal the power spectral density computation was carried out in order to check if the signal has been generated correctly. Galileo Signal Simulation - Interference Investigation The first application is about interference investigation between GPS and Galileo on L1. Three signals have been generated: GPS, Galileo pilot and Galileo data bearing channel. The configuration is shown in Table 3 for the GPS signal and in Table 2 for Galileo channels. A fixed position in Munich, Germany (WGS 84 position: Longitude = , Latitude = , Height =.m) was simulated. Galileo Signal Settings Pilot channel Data bearing channel Center frequency [GHz] Received Signal Power Individual for Individual for each SV each SV Modulation Scheme BOC(1,1) BOC(1,1) Secondary code length 25 bits - Code length [bits] 492 * Code chipping rate [Mcps] Navigation message GPS C/A GPS C/A Data bit rate [bps] No data 25 Code type L1C L1B Constellation Walker(27,3,1) Walker(27,3,1) Table 2. Simulated Galileo signal characteristics. Main Walker(27,3,1) constellation characteristics: Eccentricity, inclination 56, mean anomaly 13.33, 27 satellites in 3 orbits, semi-major axis km. For each GPS and Galileo satellite an individual received signal power was set. For Galileo the current pilot and data bearing open service channel on L1 have been simulated; in our implementation this two channels share the final power of the Galileo open service signal. The data less pilot channel is equipped with a secondary code of 25 chips. The primary code is convoluted by this secondary code. By this way the code length of the data less channel increases to 12,3 chips. In BOC(1,1) modulation each chip contains 2 subchips. The data bearing channel has a code length of 492 chips and no secondary code. The navigation message of C/A code has been applied as already described above. For GPS the usual settings and the C/A code navigation message have been used described in ICD-GPS-2C. GPS Signal Settings GPS Center frequency [GHz] Received Signal Power Individual for each satellite Modulation Scheme BPSK(1) Code type C/A Code length 123 Code chipping rate [Mcps] 1.23 [Mcps] Navigation message GPS C/A Data bit rate [bps] 5 Constellation YUMA Table 3. Simulated GPS signal characteristics. Power Spectral Density [db/hz] GPS + Galileo GPS IF = 4.92MHz Frequency [Hz] x 1 6 Figure 2. Power spectral density of the generated signals. The red line corresponds to the pure GPS signal and the blue one to the mixed GPS+Galileo signal. The power spectral density graph of the IF samples can be used as verification of the software signal simulator. As expected the BOC(1,1) signal (for Galileo) has no effect on the signal power of the peak but makes the GPS+Galileo spectral density curve edges less steep. The brown line in the middle represents the IF frequency (4.92MHz). Figure 2 shows the power spectral density once of GPS signal (red line) and once of the GPS Galileo mixed signal (blue line). The brown line in the middle represents the IF frequency (4.92MHz). The BOC(1,1) signal s

5 spectral density curve has two peaks situated symmetrically around the IF frequency. That effects that the mixed signal spectral density curve is less steep then the one of the GPS signal and the peak remains uninfluenced. To find out the interference between GPS and Galileo signals two sets of data have been generated: once pure GPS and once mixed GPS and Galileo. About 5s of IF samples have been simulated, saved in a binary file and processed by a GPS C/A code only software receiver. The method of epoch-per-epoch single point positioning was used to process the data and to compute the user position. Then, this computed position was compared with the simulated (known) one. Based on these differences statistical characteristics like bias and standard deviation were determined. The position output rate specifies how many positions in a second will be computed and compared. Longitude Error [m] GPS GPS+Galileo Latitude Error [m] Figure 3. Error in horizontal position estimated via standard GPS C/A code receiver (scenario 1, Table 4), Epoch-per-epoch single point positioning results from the software GNSS simulator generated IF samples: GPS versus GPS+Galileo. The positioning error is 7.6m for mixed signal and 7.5m for pure GPS signal. For mode details see Table 6. Two processing scenarios were applied for both data sets: once a standard (normal) GPS C/A code only receiver was used once a precise. The main difference is due to the correlation spacing of the used discriminator function. The standard receiver uses wide whereas the precise the narrow correlator peak sampling. The standard receiver doesn t use carrier aiding whereas the precise does. The Delay Lock Loop (DLL) bandwidth for the precise receiver was set to 1 Hz and for standard receiver to 1 Hz. The processing scenarios are shown in Table 4. For more details about the correlation functions used in ipexsr software receiver see [4]. Processing Scenarios Scenario 1 Scenario 2 Simulated signals GPS GPS GPS+Galileo GPS+Galileo Simulation Length 48 s 45 s Receiver settings Receiver Standard Precise Correlation spacing 1.1 Carrier Aiding No On Position Output rate.1 s.1 s DLL BW [Hz] 1 1 Table 4. Receiver scenarios for processing the simulated homogenous GPS and mixed GPS+Galieo signals. Longitude Error [m] GPS GPS+Galileo Latitude Error [m] Figure 4. Error in horizontal position estimated via precise GPS C/A code receiver (scenario 2, Table 4). Positioning method: Epoch-per-epoch single point positioning. From the software GNSS simulator generated IF samples: GPS versus GPS+Galileo. A high precision software receiver was used. The positioning error is.455 m for the mixed signal and.461 m for pure GPS signal. For more details see Table 7. DRMS Scenario 1 Standard receiver Scenario 2 Precise Receiver GPS m.455 m GPS+Galileo m.461 m Positioning.144±.1 db.69±.1 db interference Table 5. DRMS values and the effective positioning interference for the processing scenarios from simulated data. The processing results characteristics like bias and standard deviation (std) for standard (first scenario) and precise (second scenario) receiver are shown in Table 6 and Table 7 respectively. No significant difference in precision between the homogenous and mixed system can be observed. The horizontal positioning errors are shown in Figure 3 and Figure 4. The precise (for geodetic purposes) receiver shows a substantial improvement in accuracy as expected. In Table 5 there is a summary of

6 horizontal (distance) RMS precision values for both scenarios and systems: this is about 7.5m for standard receiver and.5m for the precise receiver. These values serve as input for the effective positioning interference: computation form introduced in [5]: I 2log DRMS inter = 1 DRMSnormal DRMS inter Distance RMS for positioning via GPS DRMS normal Distance RMS for positioning using simultaneously GPS and Galileo signals The effective positioning interference for the standard receiver is.144 ±.1 db and for the precise receiver.69 ±.1 db (Table 5). Lon Lat. H. Bias Std System [m] [m] GPS GPS+Galileo GPS GPS+Galileo GPS GPS+Galileo Table 6. Error values for the position determination via standard GPS C/A code receiver (scenario 1) from simulated homogenous GPS and mixed GPS+Galileo data. receiver has been designed and produced (let say fixed receiver) there is no way to make it capable to track completely new signals without hardware update. The satellite navigation community is traditionally spirited in looking for new methods to improve positioning accuracy. Hence the user segment is not easy to modify, the research is focusing on looking for signals which offers higher accuracy but requires no receiver hardware update. In finding such signals the better device is a software signal simulator. As the new signal is implemented, its test can be started to find out its benefits and if it is suitable for the given fixed receiver. In the future Galileo system the final signal optimization will utilize this concept in a similar way using a fixed prototype receiver. Various signal options are currently being developed and can be tested with the software signal simulator. The use of fixed prototype receivers is necessary as it is virtually impossible to develop for each single optimized signal a dedicated receiver. Other applications can be the use of modified signals in pseudolites in order to improve tracking accuracy. Lon Lat. H. Bias Std System [m] [m] GPS..37 GPS+Galileo.1.37 GPS.1.27 GPS+Galileo..28 GPS GPS+Galileo Table 7. Error values for the position determination via precise GPS C/A code receiver (scenario 2) from simulated homogenous GPS and mixed GPS+Galileo data. Implementation new signals - Castle BPSK signal For a successful satellite positioning and navigation we need in absolute simplified way said two components: signals (space segment) and receivers (user segment). It means, in order to modify positioning accuracy either the emitted signals or the receiver must be modified. If a Figure 5. Castle BPSK(1) signal and its generation: each chip of the standard BPSK(1) signal includes 1 castle BPSK(1) chips where the very first and the very last castle chip is +1 or -1 (castle tower) whereas the castle chips between are +1/8 or -1/8 (castle wall). This castle signal has been implemented in the software signal simulator. One example for an optimized signal is the castle BPSK signal which is derived from the standard BPSK signal itself and shows as studied here good tracking features by an existing fixed receiver. The castle BPSK signal is derived from the standard BPSK signal by dividing the standard BPSK chip into certain parts. The very first and very last subchip remains the value of the standard BPSK chip and will be called tower whereas the subchips between the towers get a

7 new value and will be called wall. In the signal simulator the castle BPSK(1) signal has been implemented. It contains 1 subchips and the wall value is 1/8 (see Figure 5). Scenario 1 Scenario 2 Simulated signals St. BPSK(1) St. BPSK(1) Castle BPSK Castle BPSK Simulation Length 2 s 15 s Receiver settings Receiver Standard Precise Correlation spacing 1.1 Carrier Aiding No On Position Output Rate.2 s.2 s DLL BW [Hz] 1 1 Table 8. Comparison of standard (St.) BPSK(1) and castle BPSK(1) signals by simulated data scenario definition. As a consequence of the low wall the castle signal power which can be used by a GPS C/A code receiver is lower as the one of the standard BPSK signal (Figure 7 shows the power spectral density of the simulated standard BPSK(1) and castle BPSK(1) signal) but the castle BPSK signal has better tracking features: The simple narrow code discriminator designed for standard BPSK tracking can easily track the castle BPSK signal as well, but has a steeper slope at zero which makes the tracking more precise. In addition the correlation function returns to near zero which assures a good mutlipath performance. Figure 6 shows the tracking monitor of the ipexsr software receiver for both signals: on the right hand side there is the discriminator output of castle BPSK(1) and on the left hand side for the standard BPSK(1) signal. C/A code, black one for castle BPSK(1)) is shown in Figure 7. The yellow line at 4.92 MHz signs the intermediate frequency. Power Spectral Density [db/hz] IF = 4.92 MHz Standard BPSK Castle BPSK Frequency [Hz] x 1 6 Figure 7. Power spectral density of the standard BPSK(1) and castle BPSK(1) signals. The Castle signal bears less power. The generated signals have been processed by ipexsr in two modes: once by a standard receiver and once by a precise receiver. The receiver settings were the same when processing the data for the interference investigation and are shown in Table 8. Longitude Error [m] Castle BPSK(1) Standasr BPSK(1) Latitude Error [m] Figure 8. Horizontal positioning error of standard receiver (scenario 1, Table 8). The positioning error (DRMS) is 14.1 m for castle BPSK(1) signal and 6.82 m for the standard BPSK(1) signal. For more details see Table 9. Figure 6. Tracking of the castle BPSK(1) signal screen shot of the ipexsr tracking monitor. On the right side the discriminator output of castle BPSK(1) and on the left side for the standard BPSK(1) signal. Two sets of data less IF signals have been simulated in order to study the castle BPSK signal: once a standard BPSK(1) and once a castle BPSK(1) signal. The power spectral density of simulated signals (red one for GPS The simulation time was about 2 s. Again, the epochper-epoch single point positioning of the ipexsr was used to determine the user position. Figure 8 and Figure 9 shows the horizontal position errors for the standard and precise receiver respectively. Figure 1 shows the error in the height determination for the precise receiver. Table 9 and Table 1 contain the position errors for standard and precise receiver respectively. The standard receiver wasn t able to benefit from the castle BPSK(1) signal

8 performance. However the precise receiver shows an improvement in dm size. The horizontal accuracy values are listed in Table 11. Longitude Error [m] Castle BPSK(1) Standard BPSK(1) Latitude Error [m] Figure 9. Horizontal positioning error of precise receiver (scenario 2, Table 8). The positioning error (DRMS) is.28m for castle BPSK(1) signal and.45m for standard BPSK(1) signal. For more details see Table 1. Lon Lat. H. Bias Std System [m] [m] St. BPSK(1) Castle BPSK(1) St.BPSK(1) Castle BPSK(1) St. BPSK(1) Castle BPSK(1) Table 9. Error values for the position determination via standard receiver (scenario 1) from simulated standard BPSK(1) and castle BPSK(1) data. (For simulation settings see Table 8). Lon Lat. H. Bias Std System [m] [m] St. BPSK(1) Castle BPSK(1) St. BPSK(1) Castle BPSK(1).2.18 St. BPSK(1) Castle BPSK(1) Table 1. Error values for the position determination via precise receiver (scenario 2) from simulated standard BPSK(1) and castle BPSK(1) data. (For simulation settings see Table 8). DRMS Scenario 1 Standard receiver Scenario 2 Precise receiver St. BPSK(1) 14.1 m.44 m Castle BPSK(1) 6.82 m.28 m Table 11. Comparison of distance RMS of position solution from standard BPSK(1) and castle BPSK(1) signals via standard and precise receiver. Height Error [m] BPSK(1) Castle BPSK(1) Time [s] Figure 1. Error in height determination of precise receiver for standard BPSK(1) (blue signs) and castle BPSK(1) (red signs). The castle BPSK(1) signal shows better accuracy. Table 9 gives more information about statistical characteristics. ANALOG REAL-TIME OUTPUT The design goal of the software simulator is to provide finally an authentic RF signal which can be feed into an arbitrary GNSS receiver. To accomplish this goal two basic steps have to be completed: (a) analog output of the simulated IF signal by means of a DAC board and (b) upconversion to RF. The first step is currently under development. The second one will be done using a commercial up-converter and later, a dedicated upconverter optimized for GNSS frequencies will be built. A block diagram of the final GNSS simulator is shown in Figure 11. This system will provide three types of output signals (software, IF and RF) and will thus provide many research options. Figure 11. Envisaged scheme of GNSS simulator.

9 Real Time IF Output with a DAC Card A commercial DAC card (ICS-572B) is the core interface between software simulated signals and real signals. The features, relevant for the simulator, include two DAC outputs, one clock output, a maximum DAC sample rate of 24.8 MHz and a fast connection to the controlling PC via a 64bit/66 MHz PCI connector. A block-diagram of the card is shown in Figure 12. According to the specifications the maximum signal bandwidth is 5 MHz and thus even the high bandwidth Galileo E5 signal could be output. bandwidth of the spectrum analyzer is higher than the simulated signal bandwidth, we can verify that above 3.2 MHz virtually no (simulated) signal is present. This is a consequence of using the linear interpolator of the DAC board. The generation of noise is itself an interesting question. Two possible options can be envisaged. The first one is to generate also the noise in software (as it is done now) and to output the signal at a level such that the inevitable hardware noise does not cause any distortions. The second method would be to generate only the signal in software and reduce its power after DAC conversion and up-conversion to its nominal value of about -16 dbw using attenuators. Thermal noise adds to this signal naturally. At the moment it is not clear which method provides advantages 5 4 Figure 12. Scheme of the used 2-Channel DAC Board. Power Spectral Density [db/hz] Simulated noise True noise However, practical experience showed that highly sophisticated software needs to be developed in order to transfer the data continuously and in real-time from the hard disc to the DAC board. Currently only generation of a low-bandwidth GPS C/A code signal has been tested. First Results The first test run with the DAC board is based on a simulated data set of a low-bandwidth GPS C/A code signal. The sampling rate of the simulated signal was 6.4 MHz, thus its bandwidth equals to 3.2 MHz. The IF was chosen to be 1.42 MHz. The signal includes the GPS C/A code signals from 8 satellites as well as simulated noise. The data was read from hard disc and completely stored in the computers main memory in order to avoid hard disc data transfer problems during the first test run. During the next phase, data will be continuously read from hard disc. The DAC board works with a fixed sampling rate of 24.8 MHz. The input data is linearly interpolated in hardware by a 32 point interpolator. The output signal is band limited by 5 khz to 9 MHz (.1 db) since a transformer is used to output the generated signal. The output signal is then analyzed by an oscilloscope and a spectrum analyzer. For example in Figure 13 the power spectral density of the generated signal is shown. One nicely sees the 3 key features: main lobe of the GPS C/A code, simulated noise and system (true) noise. As the GPS C/A code main lobe Frequency [Hz] x 1 6 Figure 13. Spectrum of analogue GPS code signal. The generated signal is been fed into the ADC card which is connected to the ipexsr software receiver. By doing so, the receiver was able to acquire signals as shown in Figure 14. Tracking is also possible, but since only a short signal is generated in this first test run, no results are presented here. Figure 14. Acquisition result for analogue signal for 3 PRN codes.

10 To conclude this paper we would like to express our opinion that the conversion of the simulated signal into an RF or IF signal is a well defined task, which however has to be done with much care and skill. Once it is completed it can be used for all possible GNSS signals. On contrast the software will be continuously updated and in fact each new signal requires development of new software modules the software is the core of the system. Thus the GNSS software signal simulator represents a good example of utilizing the software defined radio concept. ACKNOWLEDGMENTS Part of this work (signal and noise generation) was support by the German Research Foundation (DFG) under contract number EI 255/3. The development of the realtime output was supported by the German Aerospace Center (DLR) under contract number 5NA52. Special thanks to our college Dr. J.-H. Won for his co-operation on the DAC card integration. REFERENCES [1] Kaniuth, R., A. Pósfay, Th. Pany, B. Eissfeller, "Positioning with a Software Receiver under weak tracking conditions with software simulated IF-Signals", Proc. ION-GNSS 24, Long Beach [2] Pany, Th., B. Eissfeller, G.W. Hein, S.W. Moon, and D. Sanroma, "ipexsr: A PC Based Software GNSS Receiver Completely Developed in Europe," Proc. ENC- GNSS 24, Rotterdam. [3] Eissfeller, B., G.W. Hein, R. Kaniuth, A. Pósfay and Th. Pany, "Implementation and Simulation of a Mass-Market GPS/Galileo Single Point Positioning Receiver", Proc. ION-NTM 25, San Diego [4] Pany, Th., M. Irsigler, B. Eissfeller, and K. Fürlinger, "Performance Assessment of an Under Sampling SWC Receiver for Simulated High-Bandwidth GPS/Galileo Signals and Real Signals," Proc. ION-GPS/GNSS 23, Portland, pp [5] Wallner, S., G.W. Hein, Th. Pany, J.A. Avila- Rodriguez, A. Pósfay, "Interference Computations between GPS and GALILEO" Proc. ION-GNSS 25, Long-Beach. [6] Misra, P., P. Enge, "Global Positioning System, Signals, Measurements, and Performance"; Ganga- Jamuna Press, 21, Lincoln, Massachusetts