München, Univ. der Bundeswehr, Diss., 2000. / Erscheinungsjahr an der Haupttitelstelle: 2000. Computerdatei im Fernzugriff.

München, University der Bundeswehr, Diss., 2000. / Erscheinungsjahr an der Haupttitelstelle: 2000.

A 12 channel real-time GPS L1 C/A-code software receiver has been implemented on a Desktop with 1.84GHz Intel CPU. The software receiver has the capability to acquire new satellites coming in, keep tracking of satellites in view and give a user solution accuracy of 30 meters. This study also explores a real-time correlator for the GLONASS L1 signals. This software receiver is going to be used for scientific research and education. This work is a part of the ongoing effort to develop a low-cost, flexible, and capable GNSS receiver for use as a scientific instrument and for GNSS receiver technology development. The software receiver developed here makes use of a reconfigurable RF front end called the Universal Software Radio Peripheral (USRP) with a maximum real sampling frequency of 8MHz of complex samples. The USRP uses interchangeable daughter boards to down-convert and digitize RF signals in the range of DC to 2.9GHz, where each daughterboard covers an overlapping subset of this range. This RF front end was chosen for its flexibility and ease of use. The output of the RF front end is 8-bit complex I/Q samples output via a USB cable. The software receiver processing of the RF front-end outputs is accomplished by using bit-wise parallelism, as described in References [1] and [2]. In order to process the incoming RF data in this manner, the 8-bit complex I/Q samples are quantized to two bits. This is performed in the software receiver prior to signal correlation. In-phase and quadrature accumulations are computed using bit-wise parallel techniques, and these accumulations are used to drive code tracking delay-lock loops (DLLs) and carrier tracking phase-lock loops(PLLs). The computation of accumulations and the implementation of DLLs and PLLs for the GNSS ranging signals are detailed in the thesis. The software receiver is developed by C++. It consists of two parts: the software receiver core program and a simple interface. The current software receiver runs under Ubuntu Linux systems, but it is convenient to implement on other Linux systems. The software prerequisites for the software receiver are GNUradio and QT4.0. GNUradio is an open source program which provides the driver for the USRP board. The current version used by the software receiver is GNUradio-3.1.3. The user interface program is developed by using the classes provided by QT4.0. The hardware of the whole system consists of computer with intel 1.84 GHz CPU and 2GHz RAM, GPS and GLONASS antenna, USRP, and analogue signal generator. One problem with the USRP is that its on-board oscillator is not particularly stable in terms of frequency and phase. One solution to this problem is to use a high-quality external oscillator. An Agilent N5181A MXG Analog Signal Generator configured to output a 64MHz signal has been used as an external input clock to the USRP. This oscillator has a stated frequency error of 1 ppm/yr, has decent short-term frequency stability, and has a reasonably low phase noise at 64MHz. The outputs of the USRP board are 8 bits complex data with 4MHz sampling frequency with an intermediate frequency of zero. The input data are re-quantized and pack into 32-bit of integers. The total CPU usage of the software receiver is about 30 ~ 40% of the 1.84GHz CPU. The software receiver is started with a FFT based acquisition. The acquisition results are then used to initialize the receiver. The background search of satellites is accomplished by a serial search of PRN code replicas. The novelty of the the software receiver developed in this study is as follows: first, a reconfigurable RF front end is used which makes the software receiver extendable.Second, The software is developed with C++ in the general Linux system; This will make the software receiver easy to maintain and update. Third, the current software receiver also explores the process of GLONASS L1 signals with bit-wise parallel correlation. / Master of Science

Submitted by Haroudo Xavier Filho (haroudo.xavierfo@ufpe.br) on 2016-03-23T17:22:47Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissert_EmanoelGomes_vFinal (1).pdf: 3169112 bytes, checksum: 670b4efee57c1d0f5415070a594b6ca0 (MD5) / Made available in DSpace on 2016-03-23T17:22:47Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissert_EmanoelGomes_vFinal (1).pdf: 3169112 bytes, checksum: 670b4efee57c1d0f5415070a594b6ca0 (MD5) Previous issue date: 2015-03-06 / CAPES / O posicionamento geodésico atualmente é realizado em sua maioria a partir do GNSS. Dentre os sistemas disponíveis, o GPS ainda é o mais utilizado na atualidade, porém, o GLONASS está totalmente operacional, o que torna possível a aplicação de sistema multi-constelação no posicionamento geodésico. Os dois sistemas encontram-se em fase de modernização, o que permite estudos e pesquisas relacionadas à integração dos sinais GPS e GLONASS (GPS/GLONASS), seja para fins de posicionamento geodésico ou em outras atividades da comunidade usuária, dentro das engenharias e pesquisas científicas. Dentre os métodos de posicionamento, destaca-se o método PPP, o qual tem sido alvo de muitas investigações e melhoramentos nos últimos anos em função das melhorias nos produtos disponíveis pelos centros do IGS. O PPP em sua forma convencional requer o uso de medidas em duas frequências, órbitas e correções precisas dos erros dos relógios dos satélites, além da modelagem matemática para corrigir os diversos efeitos envolvidos com a propagação dos sinais GNSS e efeitos geodinâmicos afetando as estações terrestres. Uma vez que os diversos efeitos tenham sido corrigidos, espera-se precisão da ordem de poucos centímetros na estimativa de coordenadas no método PPP após algumas horas de coleta de dados. A integração GPS/GLONASS no PPP requer compatibilização entre sistemas de referência e sistemas de tempo. Espera-se que a utilização de dados GPS/GLONASS, forneça melhor geometria para estimativa dos parâmetros, além de proporcionar maior redundância para o ajustamento, o que gera maior confiabilidade (capacidade de detectar erros) nos resultados. Dentro deste contexto, esta pesquisa tem como objetivos investigar a modelagem matemática para a integração de dados GPS/GLONAS no método PPP, além de avaliar a acurácia do posicionamento para dados coletados no Brasil. Análises qualitativas foram realizadas para verificar o impacto da utilização das medidas GLONASS juntamente com medidas GPS no PPP considerando o caso de posicionamento estático e cinemático. A análise das precisões dos parâmetros foi realizada a priori com base na construção da matriz Jacobiana (matriz A), a qual não requer o uso de observações GNSS. A partir desta matriz se obtém a matriz N e sua inversa proporciona a Matriz de Covariância dos parâmetros. Esta tarefa é muito útil, por exemplo, no planejamento de redes Avaliação da qualidade do posicionamento GNSS com integração GPS/GLONASS Emanoel Gomes de Sousa Silva geodésicas e, no caso da integração GPS/GLONASS no método PPP observou-se melhorias nas estimativas das precisões das coordenadas em torno de 30%. A precisão da componente úmida da troposfera, no caso da análise a priori, foi de até 20% com observações em dias distintos de um ano. Para a análise de acurácia no caso de posicionamento cinemático, as coordenadas estimadas no método relativo foram adotadas como referência em relação ao PPP cinemático. No caso de análise de acurácia do PPP estático as coordenadas divulgadas das estações da RBMC e da rede SIRGAS-CON foram adotadas como referência. Foram processados no modo PPP estático dados de cinco estações distribuídas em diferentes latitudes no Brasil ao longo do ano de 2013 com a geração de séries temporais anuais de coordenadas. A melhoria em acurácia posicional ao utilizar integração GPS/GLONASS atingiu máximo de aproximadamente 25%. Além disto, observaram-se melhorias no tempo de convergência do PPP. / The geodetic positioning is currently accomplished in most of part by using GNSS. Among available systems, GPS is still the most widely used nowadays; however GLONASS is totally operational, what turns possible the application of multi-constellation system in the geodetic positioning. Both GPS and GLONASS (GPS/GLONASS) are under modernization process allowing studies about integration of signals either for geodetic positioning purposes or other activities in the engineering field and scientific researches. Among the geodetic positioning methods the PPP method (Precise Point Positioning) has been widely investigated in the last years and experienced many improvements, as for instance due to improvements in available products through IGS centers. The PPP in its conventional form requires the use of measures on two frequencies, precise orbits and correction of satellite clock error as well as adequate mathematical modeling to correct for several effects involved in the spread of GNSS signals and geodynamic effects affecting ground stations. Once the various effects have been corrected, it is expected coordinates accuracy of a few centimeters in the PPP method after a few hours of data collection. The Combined GPS/GLONASS in PPP requires compatibility between reference systems and time systems. It is expected that the use of GPS/GLONASS data, provide better geometry to estimate parameters and also provide increased redundancy for the adjustment, which generates higher reliability (ability to detect errors) in the results. Within this context, the aim of this research is to investigate the mathematical model for the Combined GPS/GLONASS data in the PPP method and evaluate the accuracy of positioning for data collected in Brazil. Qualitative analyzes were performed to verify the impact of using GLONASS together with GPS measurements in PPP considering static and kinematic positioning. Precision analysis of parameters was a priori performed based on the inverse of the matrix N. This task is very useful a for instance in geodetic network planning and for GPS/GLONASS integrations in PPP it was observed improvements of the order of 30% in the estimated precision. The parameter related with tropospheric wet delay was also a priori analyzed and improvements of up to 20% were observed at different days of a year. In the case of kinematic positioning, the coordinates estimated in the relative method were adopted as reference to compute Avaliação da qualidade do posicionamento GNSS com integração GPS/GLONASS Emanoel Gomes de Sousa Silva accuracy of kinematic PPP. Concerning the static positioning it was used as ground truth official coordinates of RBMC stations and SIRGAS-CON network. For the static PPP, it was processed data from five stations distributed in different latitudes along of Brazil in the year 2013 with generations of time series of coordinates. The Improvement in positional accuracy when applying GPS/GLONASS reached maximum value of 25%. Besides that, it was observed improvements in the PPP convergence time.

Navigationssysteme sollen nach Möglichkeit an jedem Ort und zu jeder Zeit funktionieren. Satellitennavigationssysteme unterliegen jedoch gewissen äußerlichen Einschränkungen, die die Positionierung erschweren oder erheblich verschlechtern. In einem urbanen Gebiet sind die Einflüsse auf die Positionierung mit Satellitensystemen durch die eingeschränkten räumlichen Verhältnisse besonders groß. Sowohl Mehrwege-Effekte wie auch die Verkleinerung des Sichtbereiches zu den Satelliten treten deutlich mehr auf. Mit der Verwendung von mehreren Satellitensystemen soll versucht werden, die Positionierung im urbanen Gebiet zu verbessern oder überhaupt erst möglich zu machen. Zur Untersuchung werden dafür die Eigenschaften Verfügbarkeit, Genauigkeit und Integrität für GPS, für GLONASS und für beide Systeme als ein Gesamtsystem genauer betrachtet.

International Telemetering Conference Proceedings / October 27-30, 1997 / Riviera Hotel and Convention Center, Las Vegas, Nevada / GLONASS is similar to GPS in many aspects such as system configuration, navigation mechanism, signal structure, etc.. There exists the possibility of receiving and processing GLONASS signals with GPS technology. The frequency plan of the GLONASS system is different from that of GPS. This makes the front-end of GLONASS receiver more complicated. The work here manifests our initial effort in GLONASS receiving. A design scheme is proposed of a C/A code GLONASS receiver.

International Telemetering Conference Proceedings / October 25-28, 1999 / Riviera Hotel and Convention Center, Las Vegas, Nevada / The coverage characteristics of the GLONASS constellation is analyzed. The almanac data of GLONASS navigation message are used in the computation according to the operation of the satellites. The ground traces of the GLONASS satellites are plotted. And the probability of visible satellite number is calculated under different latitude conditions. The results are analyzed to give descriptions of the GLONASS constellation. And they are compared with those of GPS's. The conclusion is verified that GLONASS constellation provides better coverage at high latitude.

<p>Vid användning av nätverks-RTK behöver driftcentralen kommunicera med användarens GNSS-mottagare på ett effektivt sätt oberoende av fabrikat. Av den anledningen finns ett standardiserat format för överföring av data som är utvecklat av RTCM (The Radio Technical Commission for Maritime Services). 2006 publicerades version 3.1 som stödjer utsändning av s.k. nätverksmeddelande som innebär att komprimerade observationsdata skickas till mottagaren för beräkning av korrektioner. För att bestämma GNSS-mottagarens position används i dagsläget till största delen VRS-tekniken (Virtual Reference Station). Denna teknik används bland annat av SWEPOS som driver en nätverks-RTK-tjänst i Sverige. VRS-tekniken kräver att mottagarens position ska skickas till driftcentralen, där huvuddelen av beräkningarna sker. Nätverksmeddelande har inte funnits i tidigare versioner av RTCM-standarden, men införandet av dem innebär bland annat att korrektioner kan skickas med envägskommunikation och att större delen av beräkningarna kan göras i mottagaren.</p><p>Syftet med studien är att göra jämförelser mellan VRS och RTCM 3.1 nätverksmeddelande, med avseende på bland annat mätkvalitet och initialiseringstider. I studien ingick även att undersöka behovet av nätverksmeddelande och hur tekniken fungerar under förflyttning. I studien användes GNSS-mottagare från Leica och Trimble för att göra upprepade mätningar med dels VRS och dels RTCM 3.1 nätverksmeddelande med s.k. automatisk respektive statisk konfiguration. Statisk konfiguration användes i två olika nät, ett där SWEPOS-stationen Gävle och ett där SWEPOS-stationen Leksand användes som s.k. masterstation. Totalt 1200 mätningar utfördes på tre väl inmätta punkter under 12 dagar. Vid varje mätning registrerades tiden till fixlösning och mätt position. Resultaten bearbetades därefter och analyserades med statistiska metoder.</p><p>Resultaten visade bland annat att initialiseringstiden för nätverksmeddelande är något längre än för VRS och att det inte finns någon större skillnad i kvalitetstalen mellan VRS och nätverksmeddelande. Inte heller mellan det automatiska nätet och de statiska näten finns någon större skillnad. 95:e percentilens avvikelser var i plan 25 mm och i höjd 45 mm. De enda resultaten som skiljde sig nämnvärt från övriga var mätningarna med Leica i det statiska nätet med Leksand som masterstation, där Leica hade problem med att få fixlösning.</p> / <p>When using network RTK the control centre needs to communicate with the user's GNSS receivers in an efficient manner regardless of the brand of equipment. For this reason, a standardized format for transmission of data has been developed by RTCM (the Radio Technical Commission for Maritime Services). In 2006 the version 3.1 was released which supports broadcasting of network RTK messages which means that the compressed observation data are sent to the rover for calculation of corrections. Today the most used concept to determine the position of the rover is VRS (Virtual Reference Station). SWEPOS, which provides a network RTK service in Sweden, is based on the VRS concept. The concept requires that the position of the rover should be sent to the control centre, where most of the calculations are made. Network RTK messages have not been found in earlier versions of the RTCM standard, but their introduction means that corrections can be sent with one-way communication and that most of the calculations can be made in the rover.</p><p>The purpose of the study is to make comparisons between the VRS and RTCM 3.1 network RTK messages regarding the measurement quality and the time for initialization. The study also included to examine the need for network RTK messages and how the technology works while continuously moving the rover. The study used GNSS receivers from Leica and Trimble to make repeated measurements with VRS and with RTCM 3.1 with automatic and static configurations. Static configuration was used in two different networks, one in which the SWEPOS station Gävle and one in which the SWEPOS station Leksand was used as master station. Totally 1200 measurements were carried out on three known points in 12 days. At each measurement the time for initialization and the measured position was registered. The results were then processed and analysed using statistical methods.</p><p>The results showed that the times for initialization regarding network RTK messages are slightly longer than for VRS and that there is no obvious difference in quality between the VRS and network RTK messages. The difference between the automatic network and the static network is not noticeable either. 95th percentile discrepancies were 25 mm horizontally and 45 mm vertically. The only results that clearly differed from the rest of the measurements were those with Leica in the static network with Leksand as master station, where Leica had problems to resolve the ambiguities.</p>

Vid användning av nätverks-RTK behöver driftcentralen kommunicera med användarens GNSS-mottagare på ett effektivt sätt oberoende av fabrikat. Av den anledningen finns ett standardiserat format för överföring av data som är utvecklat av RTCM (The Radio Technical Commission for Maritime Services). 2006 publicerades version 3.1 som stödjer utsändning av s.k. nätverksmeddelande som innebär att komprimerade observationsdata skickas till mottagaren för beräkning av korrektioner. För att bestämma GNSS-mottagarens position används i dagsläget till största delen VRS-tekniken (Virtual Reference Station). Denna teknik används bland annat av SWEPOS som driver en nätverks-RTK-tjänst i Sverige. VRS-tekniken kräver att mottagarens position ska skickas till driftcentralen, där huvuddelen av beräkningarna sker. Nätverksmeddelande har inte funnits i tidigare versioner av RTCM-standarden, men införandet av dem innebär bland annat att korrektioner kan skickas med envägskommunikation och att större delen av beräkningarna kan göras i mottagaren. Syftet med studien är att göra jämförelser mellan VRS och RTCM 3.1 nätverksmeddelande, med avseende på bland annat mätkvalitet och initialiseringstider. I studien ingick även att undersöka behovet av nätverksmeddelande och hur tekniken fungerar under förflyttning. I studien användes GNSS-mottagare från Leica och Trimble för att göra upprepade mätningar med dels VRS och dels RTCM 3.1 nätverksmeddelande med s.k. automatisk respektive statisk konfiguration. Statisk konfiguration användes i två olika nät, ett där SWEPOS-stationen Gävle och ett där SWEPOS-stationen Leksand användes som s.k. masterstation. Totalt 1200 mätningar utfördes på tre väl inmätta punkter under 12 dagar. Vid varje mätning registrerades tiden till fixlösning och mätt position. Resultaten bearbetades därefter och analyserades med statistiska metoder. Resultaten visade bland annat att initialiseringstiden för nätverksmeddelande är något längre än för VRS och att det inte finns någon större skillnad i kvalitetstalen mellan VRS och nätverksmeddelande. Inte heller mellan det automatiska nätet och de statiska näten finns någon större skillnad. 95:e percentilens avvikelser var i plan 25 mm och i höjd 45 mm. De enda resultaten som skiljde sig nämnvärt från övriga var mätningarna med Leica i det statiska nätet med Leksand som masterstation, där Leica hade problem med att få fixlösning. / When using network RTK the control centre needs to communicate with the user's GNSS receivers in an efficient manner regardless of the brand of equipment. For this reason, a standardized format for transmission of data has been developed by RTCM (the Radio Technical Commission for Maritime Services). In 2006 the version 3.1 was released which supports broadcasting of network RTK messages which means that the compressed observation data are sent to the rover for calculation of corrections. Today the most used concept to determine the position of the rover is VRS (Virtual Reference Station). SWEPOS, which provides a network RTK service in Sweden, is based on the VRS concept. The concept requires that the position of the rover should be sent to the control centre, where most of the calculations are made. Network RTK messages have not been found in earlier versions of the RTCM standard, but their introduction means that corrections can be sent with one-way communication and that most of the calculations can be made in the rover. The purpose of the study is to make comparisons between the VRS and RTCM 3.1 network RTK messages regarding the measurement quality and the time for initialization. The study also included to examine the need for network RTK messages and how the technology works while continuously moving the rover. The study used GNSS receivers from Leica and Trimble to make repeated measurements with VRS and with RTCM 3.1 with automatic and static configurations. Static configuration was used in two different networks, one in which the SWEPOS station Gävle and one in which the SWEPOS station Leksand was used as master station. Totally 1200 measurements were carried out on three known points in 12 days. At each measurement the time for initialization and the measured position was registered. The results were then processed and analysed using statistical methods. The results showed that the times for initialization regarding network RTK messages are slightly longer than for VRS and that there is no obvious difference in quality between the VRS and network RTK messages. The difference between the automatic network and the static network is not noticeable either. 95th percentile discrepancies were 25 mm horizontally and 45 mm vertically. The only results that clearly differed from the rest of the measurements were those with Leica in the static network with Leksand as master station, where Leica had problems to resolve the ambiguities.

This diploma thesis deals with a comparison of the measured data using various GNSS apparatures. In the theoretical part, the general structure of navigation systems is described and the comprehensive overview of navigation systems in the world is elaborated here. The next chapters are devoted to regional and augmentation navigation systems. The last chapter in the theoretical part is focused on point field in the Czech Republic.In the practical part of this thesis, the experimental measurement using various GNSS apparatuses was carried out in cadastre unit Kokořov. Subsequently, the measured data were transformed into S-JTSK and compared with each other. In the end, using various GNSS for the purpose of registration changes in landuse was evaluated.