Program GNSS Solutiuon nie wczytuje 3-go punktu

314 views
Skip to first unread message

Wiesław Lenar

unread,
Apr 15, 2019, 5:05:28 AM4/15/19
to AzusRTN
Po pomiarze w dniu 13-04-2019  punktu  metodą statyczną program GNSS Solution nie liczy pomiaru do 2-ch i więcej 
punktów referencyjnych . Po wczytaniu 2-ch punktów , wczytując 3-ci punkt zatrzymuje się .
Sprawdziłem dzisiaj działanie programu dla pomiaru wykonanego miesiąc temu - program [poprawnie wczytuje 3 punkty 
referencyjne i 4-y punkt obliczany . Próbowałem w różnych kombinacjach i zawsze wychodziło - wczytuje 2 punkty 
i zatrzymuje się na wczytaniu danych  3-go punktu . Program oblicza pomiar dla 1-go punktu referencyjnego 
i 1-go punktu mierzonego .
Skojarzyłem ten problem z taką informacją .  

W styczniu zażądałem od CHC - w związku ze zbliżającym się problemem zmiany numeracji tygodni GPS (patrz informacja w stopce emaila)  - przeprowadzenia  testów poszczególnych modeli na symulatorze. 

Wiadomość z ostatniej chwili: właśnie otrzymałem zapewnienie z firmy CHC, że po sprawdzeniu na symulatorze nie spodziewają się oni żadnych problemów w związku ze zmianą numeracji tygodni GPS w dniu 6 kwietnia. 

Proszę o informacje, gdyby problem jednak wystąpił. "

Czy moje skojarzenie z tą informacją jest dobre ?

W załączeniu raport z pomiaru w marcu i zrzut ekranu z programu GNSS Solution wykonany dzisiaj .

Wiesław Lenar


2019-04-15 raport Maciejowa.odt
2019-04-15_103737.tif
Message has been deleted
Message has been deleted

Eugeniusz Komenda

unread,
Apr 23, 2019, 4:48:47 AM4/23/19
to AzusRTN
Dzień dobry, 
jak wcześniej pisałem do p. Ryszarda, program GNSS Solutions  zawiesza się przy próbie wczytania danych do obliczeń statycznych na podstawie VRS.
Po wielu próbach w tym z pomocą administratorów sieci, którzy sprawdzali pliki RINEX i stwierdzili ich prawidłowość problemu nie udało się rozwiązać.
Na forum znalazłem informację; 
" niektóre odbiorniki mogą uzależniać prawidłowe oznaczenie czasu od daty utworzenia oprogramowania sprzętowego lub daty ostatniej aktualizacji - w takich przypadkach efekt GPS rollover może być zauważony niekoniecznie w momencie zerowania się licznika tygodni GPS,
na większe prawdopodobieństwo wystąpienia błędu narażone są odbiorniki dawno wprowadzone na rynek lub takie, które nie były przez długi czas poddawane aktualizacji oprogramowania " 
Mam programy; do preprocesingu na AzusStar 1.8.7.0 i GNSS Solutions 3.60.1. już dawno nie aktualizowane.
Zawieszanie się programu występuje też na innym komputerze, i pokazuje błędy w Studio.exe. 
Ponowna instalacja GNSS Solutions też wykazuje błędy w Studio.exe.
Mam pytanie;  czy nie będzie konieczności aktualizowania oprogramowania odbiornika Azus Star, jak i gdzie uzyskać nowe programy do obliczeń statycznych, bo dotychczas podawane strony są nieosiągalne.
Przy okazji chciałbym zapytać o odbiornik AzusRTN, czy aktualny program GNSS Solutions będzie przydatny do tego odbiornika, jakie odbiornik ma wymiary i masę, czy można nim wykonać tyczenie punktów.
Pozdrawiam, Eugeniusz Komenda   

RYSZARD PAŻUS

unread,
Apr 23, 2019, 3:03:15 PM4/23/19
to azu...@googlegroups.com

Tutaj pod tytułem ‘GNSS Solutions’ jest kilka pytań, które powinny być poza tym wątkiem.

1)      Cytat: „niektóre odbiorniki mogą uzależniać prawidłowe oznaczenie czasu od daty utworzenia oprogramowania sprzętowego lub daty ostatniej aktualizacji - w takich przypadkach efekt GPS rollover może być zauważony niekoniecznie w momencie zerowania się licznika tygodni GPS, na większe prawdopodobieństwo wystąpienia błędu narażone są odbiorniki dawno wprowadzone na rynek lub takie, które nie były przez długi czas poddawane aktualizacji oprogramowania " 

·         Informacja prawdziwa, ale ogólna, nie dotyczy odbiorników Azus Star i Azus Star+. W tych odbiornikach ten problem nie występuje.

·         ‘GPS Week Rollover’ wystąpił w odbiornikach Azus L1 Static (produkowanych w latach 2008-2009). Zastosowany w odbiorniku moduł Super Star II firmy Novatel nie ma już wsparcia technicznego producenta. Problem rozwiązano w programie preprocessingu dla tych odbiorników i jest on opisany na grupie dyskusyjnej.

2)      Cytat: „Mam programy; do preprocesingu na AzusStar 1.8.7.0 … już dawno nie aktualizowane.

·         Programy warto aktualizować. Wersja 1.9.2.0 dla modeli Azus Star i Azus Star+ jest ogólnie dostępna na stronie  https://geodigitalgnss.pl/poprzednie-modele - trzeba kliknąć na grafikę postprocessingu.

3)      Cytat: „czy nie będzie konieczności aktualizowania oprogramowania odbiornika Azus Star,….”

·         Aktualnie nie ma takiej potrzeby, program działa poprawnie i nie zgłaszane są propozycje jego zmiany.

4)      Cytat: „Przy okazji chciałbym zapytać o odbiornik AzusRTN, ….., jakie odbiornik ma wymiary i masę, czy można nim wykonać tyczenie punktów”

·         Na te pytania jest szczegółowa odpowiedź w tekście instrukcji obsługi odbiornika AzusRTN. Instrukcja jest ogólnie dostępna na stronie  https://geodigitalgnss.pl/.


Wracając do głównego tematu tego wątku, czyli do ostatnio sygnalizowanych problemów z  GNSS Solutions, wyjaśniam, że program ten był zalecany przeze mnie do wykorzystania dla postprocessingu pomiarów statycznych i szybkich statycznych (VRS). Miało to być na okres przejściowy, do czasu kiedy system ASG-EUPOS przejdzie modernizację serwisu POZGEO i wprowadzi metodę Rapid Static tak, jak to jest w amerykańskiej CORS. Tak się jednak nie stało i mamy degradację serwisu POZGEO, opisaną w osobnym wątku.

Przypuszczam, że bieżące problemy z GNSS Solutions mają rzeczywiście związek z programem Studio.exe i niedługo zostaną rozpracowane. Jest coś na ten temat tutaj, ale dokładniej tym się nie zajmowałem – to poletko innego producenta. Może inni użytkownicy coś tu dorzucą :)

Eugeniusz Komenda

unread,
Apr 24, 2019, 1:04:41 PM4/24/19
to AzusRTN
Dziękuję za odpowiedź, dalej problem mam nie rozwiązany, dochodzę do wniosku, że muszę zainstalować nowy,
w miarę łatwy do opanowania program do postprocesingu, ponieważ nie mam rozeznania w tym temacie proszę o 
wskazanie przydatnych programów i możliwości ich zakupu czy też nabycia. Pozdrawiam, E.Komenda
Message has been deleted

Wiesław Lenar

unread,
Apr 25, 2019, 4:30:43 PM4/25/19
to AzusRTN

Ponieważ program GNSS Solution przestał obliczać pomiary dla 3-ch i większej ilości punktów wypatrzyłem program TERSUS Geomatics Office ,który na razie działa bez ograniczeń i oblicza pomiary statyczne z takim wynikiem .

Przy okazji wyszło jak mierzy AzusRTN i nie mogę w to uwierzyć . Oto próbka pomiaru RTK AzusRTN w programie Power GPS i pomiaru statycznego AzusRTN .

Wysokość PsA1 , PsA2 obliczono jako H elisoidalną i przeliczono programem TRANSPOL do wysokości normalnej





33 5490905.854 7459674.218 356.093

34 5490905.856 7459674.242 356.095

35 5490905.863 7459674.227 356.091                       jako punkty PsA1

36 5490905.849 7459674.216 356.088


PsA1 49 33 12.41246 20 26 33.51789 356.0899 PL_KRON86-NH z Hel_ETRF2000



37 5490862.309 7459673.538 355.701

38 5490862.330 7459673.532 355.701

39 5490862.324 7459673.534 355.696                    jako punkty PsA2

40 5490862.327 7459673.548 355.695



PsA2 49 33 11.00344 20 26 33.49862 355.6942 PL_KRON86-NH z Hel_ETRF2000

schemat wyrównania dla TERSUSGeomatics Office.tif

RYSZARD PAŻUS

unread,
May 4, 2019, 7:20:07 AM5/4/19
to azu...@googlegroups.com


Wykonałem prosty test dokumentujący problem, który tkwi w programie GNSS Solutions i ma związek z GPS Week Rollover z dnia 6 kwietnia br.

Pobrałem z dwóch stacji referencyjnych KATO i KRA1 obserwacje sesji z 5 kwietnia i 7 kwietnia, czyli przed i po tej nieszczęsnej dacie. Test ‘quality checking’ z teqc.exe  nie wykazał żadnych formalnych błędów w plikach.


2019-05-04_12-11-09.png



Obserwacje z 5 kwietnia są przyjmowane przez GNSS Solutions bez problemów


2019-05-04_12-17-16.png



ale już te z 7 kwietnia powodują zawieszanie się programu w tym miejscu


2019-05-04_12-19-05.png



Wniosek z tego taki, że nie należy rozpraszać się na szukaniu innych źródeł błędu tylko ograniczyć się do rozwiązania tego tutaj udokumentowanego.

Podobny test wykonałem na stacjach EUREF z takim samym skutkiem (stacje zagraniczne JOE2 i POTS). To potwierdza, że przyczyna tkwi wewnątrz programu GNSS Solutions. Czyli to sprawa jakichś założeń w programie, o których nie ma wzmianki w dokumentacji. Nie wiem czy to temat do rozpracowania bez kodów źródłowych programu. 

Problem jest poruszany na innym forach np. tutaj . Tam jest porada (George Tsipas) - podobna do tej mojej wcześniejszej, aby ograniczyć obliczenia tylko do dwóch punktów; punktu stałego, np. VRS, i punktu wyznaczanego. Wtedy obliczenia są poprawne.


Order_12 (1).zip

RYSZARD PAŻUS

unread,
May 10, 2019, 2:02:52 PM5/10/19
to azu...@googlegroups.com

Problemy z GNSS Solutions opisane są dosadnie przez specjalistę, którym od ponad 8-miu lat jest Mark Silver. Prowadził on bardzo dobry blog na ten temat i jest autorem wielu porad i filmów na you tube. Cytuję tutaj w oryginale jego ostatnią opinię z forum o zasięgu globalnym:.

 https://rplstoday.com/community/gnss-geodesy/are-you-ready-for-the-gps-week-rollover/paged/6/#post-495958

Tekst cytuję w oryginale, co przy obecnych możliwościach automatycznego tłumaczenia nie wymaga dodatkowego poprawiania.

„All my recent uses of GNSS Solutions have ended in the program hanging when importing 'some' CORS RINEX files (about half the stations trigger a hang). The HI's on imported files are not applied universally unless you open the occupation and click the 'Apply to All' button. The adjustment program is contained in an external tool which is removed by most anti-virus programs. These are only the worst issues. There are many more.

To this end, I am declaring 'GNSS Solutions' end of life and I am not supporting it anymore. If you are a hobbyist using 'GNSS Solutions' then good luck to you. If you are relying on 'GNSS Solutions' for any professional purpose then you playing with fire. GSol is not reliable by any measure and it is long past time for you to move on. 

On April 18th, when I found myself responding to WNRO issues from 7 until midnight (I literally was getting over 20 questions per day by email from non-customers, worldwide and in 4 languages) I officially pulled the plug. There is a complete description of my frustration at my blog, and this time I am serious. From my perspective 'GNSS Solutions' is dead. If you are using it, you are foolish. End of discussion.

I am very sorry about this. I really liked GNSS Solutions (and the predecessor Ashtech Solutions) and I don't love any of the replacements that are available today. The engine that is in GNSS Solutions was excellent. I am wary of any tool that does not closely match. But GNSS Solutions is so unreliable that it is a waste of time to load data into it. Every move you make is one closer to it hanging. 

So no more talk about 'GNSS Solutions': it is dead. To beat it more exposes us as idiots.”

 

Szymon Węgliński

unread,
May 16, 2019, 11:03:22 AM5/16/19
to AzusRTN
Problem wyrównania kilku plików pomiarowych i jednego VRS można obejść ładując kolejny plik pomiarowy później. Wpierw należy załadować plik otrzymanego punktu VRS i 1 plik pomiarowy. Wybrać załadowanie do programu i wyrównanie sieci (Import, process and adjust). Program ładuje dane i wyrównuje 1 punkt pomiarowy do VRS. Następnie wybieramy z menu po lewej dodanie plików (Import Raw Data), wybieramy kolejny plik pomiarowy i znów dodajemy go do obliczeń. Później trzeba wszystko razem wyrównać, jeśli program nie zrobił tego samoczynnie (Adjustment).

Pozdrawiam
Szymon Węgliński

RYSZARD PAŻUS

unread,
May 16, 2019, 4:43:37 PM5/16/19
to AzusRTN
Ta wspaniała porada p. Szymona rozwiązuje problem, który zaczął dokuczać bardzo wielu użytkownikom korzystajacych z metody szybkiej statycznej. Wykonałem przed chwilą test potwierdzający. Przykład jest z wątku dotyczacego TGO. Przyjąłem w ostatniej fazie wyrównania punkty ASG jako stałe, punkty VRS jako kontrolne, czyli wyrównywane i dwa punkty pomierzone odbiornikiem Azus Star. To tak celowo, bo chodziło o jak najpełnieszy test. Test potwierdza proponowaną procedurę obliczeniową. Dla obliczeń szybkiej statycznej czas obliczeń jest minimalnie dłuższy. Specjalne podziękowania dla p. Szymona. Widać jak ważne jest dzielenie się informacjami na forum. 
Szkic wyrównywanej sieci (w załączeniu raport):

2019-05-16_22-15-56.jpg

:
Raport_25-04-2019.pdf

jur...@wp.pl

unread,
May 16, 2019, 5:15:28 PM5/16/19
to AzusRTN
Witam. Korzystając z podpowiedzi Pana Szymona dokonałem obliczeń ładując pierwszy VRS po nim kolejny import pierwszego punktu, po czym wyrównanie, następnie drugi punkt i wyrównanie i na koniec drugi VRS i wyrównanie. Wyniki różnią się od obliczeń w TGO o pojedyńcze milimetry. Ukłony i podziękowania Panie Szymonie. Pozdrawiam. W załączeniu raport.
Raport GNSS.pdf

RYSZARD PAŻUS

unread,
May 17, 2019, 4:08:14 AM5/17/19
to AzusRTN
Z raportu wynika, że brakuje tu jeszcze tego końcowego wyrównania. Pisze o tym p. Szymon (klawisz F7 na końcu obliczeń).To uwaga kosmetyczna, bo i tak serwisy krajowych aktywnych sieci geodezyjnych nie podają dokładności generowanych VRS, co jest małoprofesjonalne. Pisalem w tej sprawie kilkakrotnie. Możemy tutaj wspierać się kanadyjskim systemem CSRS, który dla wszystkich użytkowników na całym świecie robi to bezpłatnie i bezzwłocznie - po kilku minutach dostajemy komplet wyrównania. W załączniku raport z CSRS dla VRS006. 
Czyli tak, jak tutaj:

2019-05-17_09-34-04.jpg


2019-05-17_09-42-53.jpg



2019-05-17_09-45-54.jpg


 
V006129G.pdf
V006129G.txt
Reply all
Reply to author
Forward
0 new messages