Metody szybka statyczna RS (Rapid Static) - pozyskiwanie i przetwarzanie danych z odbiornika AzusRTN

[El Geodetos]

Na początek pytania i opisy problemów, które chce przekuć w sukces.

1. W załączniku przesyłam zarejestrowaną bazę VRS w odbiorniku AzusRTN (ReachView v2.22.3) zgodnie z instrukcją  https://geodigitalgp.nazwa.pl/publikacje/Instrukcja_AzusRTN_wersja_1-2-8.pdf  punkt 4.3.3.1 rejestrowana była w formacie RINEX 2.11. Mam jednak problem z wczytaniem jej w programie GNSS Solutions.

[IWING]

Witam, przekonwertowałem do Rinex 3.03 oraz dodałem brakujące dane nav. U mnie teraz dane się wczytują.

Sprawdziłem także dane pod kątem poprawności (ostatnio mamy jakiś dziwny problem z przeskakującym VRS z ASG, logują się dane z kilku pozycji, a w nagłówku rinex jest oczywiście tylko ta ostatnia, w komentarzach rinex także nic nie ma), tutaj pozycja jest stała i zgadza się z nagłówkiem.

[RYSZARD PAŻUS]

To pytanie dotyczące pozyskiwania danych.

Tutaj dla tego przykładu mam takie uwagi:

1) Jeśli program do postprocessingu odrzuca plik RINEX jako niepoprawny to najprościej wykonać jego sprawdzenie, tzn. kontrolę jakości (qc = quality checking). Jest do tego kilka sposobów, chyba tutaj najprościej skorzystać z programu teqc.exe 

2)  https://www.unavco.org/software/data-processing/teqc/teqc.html 

3) Twórca teqc.exe, po 22 latach opracowywania tego narzędzia programowego, ostatnio przeszedł na emeryturę (dr Lou Estey) i UNAVCO informuje, że nie będzie to narzędzie aktualizowane. Stąd ta zalecana sugestia RINEX w wersji 2.11 w instrukcji odbiornika AzusRTN.

4) Alternatywą dla kontroli jakości może być inne narzędzie programowe GFZRNX http://dataservices.gfz-potsdam.de/panmetaworks/showshort.php?id=escidoc:1577894 

• 

5) Powracając do sedna sprawy. Kontrola jakości wykazuje, że w linii 51677 pojawiają się śmieci. To ostatnia linia tego pliku. 

• 

6) Przypuszczam, że przyczyną tutaj jest brak programowego zakończenia operacji zapisu sesji. Powinno być zamknięcie rejestracji sesji w zakładce ‘Logging’, czyli ‘OFF’. Dopiero po tym ‘OFF” aplikacja kontrolera Reach View może rozpocząć konwertowanie surowych danych (raw data) na pliki tekstowe, tutaj RINEX. 

7) Po zakończeniu tej operacji można wyłączyć zasilanie odbiornika. Zalecane jest wyłączanie programowe, nie mechaniczne.

7) Można próbować poprawić te błędy wykonując samodzielnie konwersję z RTCM -> RINEX programem rtkconv.exe (RTKLIB). Ten zapis 'raw data' dla tego pliku powinien być też w pamięci odbiornika (prośba o udostępnienie na forum).

8) Do sprawdzenia tych podejrzeń J wykonałem podobną krótką rejestrację sesji pomiarowej (załącznik), zgodnie z instrukcyjnym postępowaniem.Jak widać kontrola jakości jest OK. (załącznik).

9)   

[IWING]

Co do przyczyny jak najbardziej się zgadzam, dlatego przeprowadziłem konwersję z rinex 2 na rinex 3.03 w rtkconv co skasowało błędy.

Z doświadczenia wiem że nawet poprawne zamykanie sesji i wyłączanie programowe nie zawsze rozwiązuje problem, te błędne końcowe linie a czasem nawet braki w liniach w środku potrafią występować i wtedy. Zdaję się błędy w convbin to powodują.

Dlatego obecnie zawsze stosujemy punkt 7. Czyli konwersja z ubx oraz rtcm do rinex, to całkowicie wyeliminowało problem.

[El Geodetos]

Dziękuje za odpowiedź IWING. Mam prośbę byś napisał w jakim programie to zrobiłeś - przydały by się też zrzuty z ekranu jak to zrobić. 

Jednak tych Twoich przekonwertowanych danych program GNSS Solutions mi nie wczytuje.Komunikat jest taki: 

Copying file "base_202004011526_rinex3.obs" in local folder ...  Ok

Cannot import file "base_202004011526_rinex3.obs" - Invalid raw data file

Czy u Ciebie one się wczytują?

[El Geodetos]

Dziękuje Panie Ryszardzie za odpowiedź

Pana przysłane dane też mi się nie wczytują się w GNSS Solutions. Komunikat:

Copying file "base_202004012149.20o" in local folder ...  Ok

Error: ephemeris file for 'C:\My Projects\01-04-2020-5\Qbaseb20.092' not found.

Cannot import file "base_202004012149.20o" - Invalid raw data file

Czyli pewnie mam jakiś inny problem z programem GNSS Solutions

[Tomasz Gołębiowski]

Witam Panów.

Ja miałem identyczny problem w GNSS Solutions jakieś pół roku temu - po ogłoszeniu end-of-life tego programu. Od tego czasu, po zakupie Azus RTN, mój Azus Star poszedł w odstawkę i już nie używam tego oprogramowania. Udało mi się wtedy unikać wspomnianego błędu poprzez wczytywanie punktów "na 2x". Najpierw po założeniu projektu wczytywałem punkty z obserwacjami z odbiornika, nie przechodziłem dalej do obliczeń i wyrównania. Zamykałem okienko, ponownie otwierałem okno importu i doczytywałem obserwacje ze stacji referencyjnych. Błąd już wtedy nie wyskakiwał i mogłem przejść dalej.

Nie wiem, czy to rozwiązanie jest nadal skuteczne, niemniej jednak warto spróbować :)

Pozdrawiam serdecznie.

[El Geodetos]

Witam

Ja nadal AzusStar+, stosuje to obejście, które Pan opisał i z danymi z tego odbiornika nie mam problemów. Tutaj te komunikaty wyskakują przy wczytywaniu pliku pojedynczo i jako pierwszego.

[RYSZARD PAŻUS]

1) Tutaj taki komunikat wynika z braku w pliku nawigacyjnym danych jonosfery.

 Copying file "base_202004012149.20o" in local folder ...  Ok

Error: ephemeris file for 'C:\My Projects\01-04-2020-5\Qbaseb20.092' not found.

Cannot import file "base_202004012149.20o" - Invalid raw data file

2) Trzeba poczekać parę dni. Sprawdziłem przed chwilą. Można je pobierać poprzez zakładkę 'Narzędzia' z naszego programu do pre-processingu autorstwa Aleksandra Mroza. To program dla odbiorników AzusStar i AzusStar+, w którym były moduły kanadyjskiej firmy,Novatel. W odbiorniku AzusRTN jest moduł szwajcarsiej firmy u-blox, dla którego są aplikacje preprocessingu RTKLIB. 

3) Mając RINEX w wersji 3.xx można z kolei przeprowadzić kontrolę jakości poprzez kanadyjski CSRS-PPP. Raport w załączeniu pokazuje poprawność danych. To metoda PPP, czyli chcemy tylko potwierdzenia formalnych zapisów, bez wnikania w szczegóły.

4) Jesli pierwszym wczytywanym punktem będzie RINEX z danymi jonosfery (broadcast) to wtedy zaakceptowane będą dane nawigacyjne z tego pierwwszego punktu. Czyli na początek 'rover', potem 'base'..   .

 

[El Geodetos]

Dziękuje Panie Ryszardzie ta porada powyżej w punkcie 4 wszystko załatwiła. Pierwszy sukces. Teraz mam kolejne pytanie jaki typ anteny wybieramy dla AzusRTN

[RYSZARD PAŻUS]

DF6255A

Tutaj widać, że jest uwzględniona wielkość ARP=0.080m przy tyczce 2m. Czyli w parametrach anteny dla programu wpisujemy zera.

W raporcie kanadyjskim CSRS-PPP jest ostrzeżenie:

Warning : Although an antenna record was located in the RINEX file, no phase centre information could be found in the IGS/NGS file for your antenna. Estimated height should be used with caution. Ensure that both the antenna type and the RINEX header record "ANT # / TYPE " are valid.

Antena jest produkcji chińskej o bardzo dobrych parametrach dla naszych zastosowań. Producent ma doktorat z projektowania anten, o ile dobrze pamiętam z Wuhan University!  

[El Geodetos]

Rozumiem, że w Azus Star+ też jest antena z Wuhan mam wpisaną DF5255A (nie pamięta na podstawie czego mam taką wpisaną) czy też powinna być DF6255A?

[El Geodetos]

W załączniku raport z wyrównania. Mam jeszcze kilka pytań. Baza wczytuje się jako jedno częstotliwościowa L1 a powinna jako L1/L2. Mamy obserwacje GPS/GLONASS - brakuje GLONASS to w pełni wykorzystania możliwości zarejestrowanych danych. Z bazy powinny być też obserwacje z systemu BeiDou. Czy to ograniczenia programu GNSS Solutions?

[IWING]

Dane nav skopiowałem akurat z najbliższej stacji euref , gdyż są praktycznie od razu dostępne, metody mogą być różne.

Co do konwersji to rtkconv z rtklib (wersja modyfikowana), dokumentacja EN. Dane się wczytują.

Pana dane to rzeczywiście tylko L1, ale w tym wypadku to nie ma znaczenia,natomiast są to jak najbardziej dane GPS+GLONASS+GALILEO. BeiDou bym się nie spodziewał w naszych warunkach.

[RYSZARD PAŻUS]

Na punkcie bazowym, czyli VRS (wirtualna stacja referencyjna) jest odbiornik wirtualny wieloczęstotliwościowy z systemami GPS+GLONASS+Galileo+Beidou.

Do tego punktu nawiązujemy nasz punkt pomiarowy tak krótkim wektorem, że wystarczy tylko GPS L1, aby otrzymać dokładność położenia rzędu 2-3 mm względem położenia VRS, który tutaj jest uważny za bezbłędny. Generowanie danych dla VRS nie jest wykonywane programem GNSS Solutions. Informacja o 'base' wynika z ograniczeń programu GNSS Solutions w tej użytej wersji i nie podaje rzeczywistej zawartości wirtualnego RINEX dla VRS, czyli GPS+GLONASS+Galileo+Beidou. RTN to analogiczna metoda co szybka statyczna...

[El Geodetos]

VRS zarejestrowany w odbiorniku AzusRTN- serwis NAWGEO (nazwa strumienia: RTN4G_VRS_RTCM32) systemu ASG-EUPOS

VRS wygenerowany z serwis POZGEO-D systemu ASG-EUPOS

Powyżej widać, że VRS zarejestrowany w odbiorniku ma więcej danych niż ten POZGEO-D. Odbiornik AzusRTN może odbierać sygnały:GPS, GLONASS, BeiDou, Galileo, QZSS and SBAS. Dla VRS z serwis NAWGEO zarejestrowanego w odbiorniku, użyteczna może być konfiguracja GPS+GLONASS+Galileo lub GPS+Galileo+Beidou - oczywiście ta pierwsza jest preferowana. Jednak program GNSS Solutions  w tej wersji darmowej wykorzystuje tylko GPS i GLONASS mamy więc marnotrawstwo obserwacji Galileo. Tutaj trzeba brać pod uwagę, że pomiary metodą szybką statyczną RS (Rapid Static) chce wykorzystywać w trudnych warunkach gdzie pomiar metodą RTN jest nie możliwy więc te obserwacje z systemu Galileo czasami mogą być warunkiem do prawidłowego obliczenia współrzędnych punktu. Wykorzystanie GPS+GLONASS+Galileo pozwoli zapewne też skrócić sesje pomiarową. Program GNSS Solutions sprawdzał się mi przez wile lat do obliczeń obserwacji z odbiornika Azus Star+ jednak teraz biorę pod uwagę zmianę oprogramowania.

[El Geodetos]

W przypadku gdy na obiekcie nie mamy połączenia z internetem bazę VRS możemy zarejestrować w biurze lub w domu za pomocą programu umożliwiającego połączenie z serwerem NTRIP. W załączniku instrukcja konfiguracji takiego połączenia na przykładzie programu GNSS Internet Radio. Powtórzyłem swój poprzedni test wykorzystując  program GNSS Internet Radio do pozyskania bazy. Poniżej porównanie współrzędnych z poprzedniego testu i dzisiejszego.

Przesyłam też raport z obliczeń oraz surowe dane.

[RYSZARD PAŻUS]

Panie Pawle, proponuję wykorzystywać aplikacje RTKLIB w wydaniu EMLID do uzupełniania w nagłówku plików RINEX istotnych danych (wysokości z uwzględnieniem ARP=0.080m, nazwy punktów itp,)

Pobrać można tutaj  https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/

Niestety dla Windows tylko w wersji 64 bit.

Krótka instrukcja z cyklu 'No comments' w załączeniu.

[El Geodetos]

Dziękuję Panie Ryszardzie za tą instrukcje. W załączniku przesyłam dane z obserwacji tutaj były trudne warunki i nie udaje mi się uzyskać prawidłowego obliczenia współrzędnych. Brakuje mi jakiegoś programu do pre-processing  - program AZUS-Star działa tylko na plikach binarnych więc nie mogę "wyczyści" obserwacji. Może komuś się uda wyliczyć współrzędne na tym przykładzie.

[Wiesław Lenar]

Witam.

Kilka słów wprowadzenia .

Obliczenia dokonano przy pomocy punktów wirtualnych Vir 415 , Vir 416 , Vir 417 , Vir 418 .

Punkt A1 -  punkt obliczany.

Punkty - Vir 415 i Vir 417 to te same punkty tylko dla

- Vir 415 czas obserwacji 0,5 godz.

- Vir 417 czas obserwacji 1,0 godz.

Punkty - Vir 416 i Vir 418 to te same punkty tylko dla

- Vir 416 czas obserwacji 0,5 godz.

- Vir 418 czas obserwacji 1,0 godz.

Punkty - Vir 415 , Vir 416 - ten sam czas obserwacji - 0,5 godz.

Punkty - Vir 417 , Vir 418 - ten sam czas obserwacji - 1,0 godz.

Odnośnie obliczeń .

Dla punktu A1 z obserwacji Vir 415 i Vir 416 mamy mały błąd dla rozwiązania typu float

Punkty wyznaczane

Błąd Status

Nr/Nazwa Współrzędne 95% =2m Współrzędnej Kontrola

A1 y 7318751.727 0.004 Wyrównana

x 5819651.102 0.003 Wyrównana

H(Kronsztad'86) 91.693 0.007 Wyrównana

Dla punktu A1 z obserwacji Vir 417 mamy duży błąd dla rozwiązania typu float

Punkty wyznaczane

Błąd Status

Nr/Nazwa Współrzędne 95% =2m Współrzędnej Kontrola

A1 y 7318752.298 0.046 Wyrównana

x 5819650.597 0.042 Wyrównana

H(Kronsztad'86) 92.953 0.083 Wyrównana

Dla punktu A1 z obserwacji Vir 418 mamy duży błąd dla rozwiązania typu fix

Punkty wyznaczane

Błąd Status

Nr/Nazwa Współrzędne 95% =2m Współrzędnej Kontrola

A1 y 7318751.576 0.044 Wyrównana

x 5819650.088 0.052 Wyrównana

H(Kronsztad'86) 91.821 0.079 Wyrównana

Dla punktu A1 z obserwacji Vir417 Vir 418 mamy bardzo duży błąd dla rozwiązania typu float i fix

Punkty wyznaczane

Błąd Status

Nr/Nazwa Współrzędne 95% =2m Współrzędnej Kontrola

A1 y 7318751.826 0.770 Wyrównana

x 5819650.436 0.798 Wyrównana

H(Kronsztad'86) 92.339 1.403 Wyrównana

Wniosek - coś musiało przeszkadzać w obserwacjach skoro takie zamieszanie w obliczeniach.

Dla zobrazowania tego podgląd w programie TGO wektora A1 - Vir416 na obrazach 1 , 2 , 3 , gdzie obserwacje satelitów są " bardzo ale to bardzo " poszarpane oraz bardzo dziwny wykres dla wszystkich obserwacji w dolnej części obrazka , tam gdzie są przyciski All , Previous , Next

Dla przykładu mój pomiar i obserwacje satelitów na obrazach "moje obserwacje 1" , "moje obserwacje 2" .

Pozdrawiam.

Wiesław Lenar

[El Geodetos]

Dziękuje Panie Wiesławie za te obliczenia. Jak już wcześniej pisałem pomiar był wykonany w trudnych warunkach. Mi się nie udało uzyskać prawidłowego wyniku. Punkt ten mam wyznaczony inną  metodą  – wcięciem liniowym z punktów wyznaczonych metodą RTN.  Nie mogę jednak sprawdzić, które z Pana obliczeń pokrywają się z tym wynikiem, bo obliczenia wykonał Pan w strefie 7 (południk osiowy 21) a powinno być w strefie 6 (południk osiowy 18).