wersje testowe - dyskusja testerów (było: Precyzja wskazań GPS podczas jazdy)

Ostatnie dni dosyć długiej trasy po PL, próbowałem zmusić ustawieniami opóźnień precyzję wskazań GPS w AM 5.1, aby ustawić ten optymalny i niestety nie daje się. W poprzedniej wersji działo się to bardziej precyzyjnie. W zasadzie bez względu na prędkość samochodu odchylenie mijanych punktów w naturze i wskazań na mapie odbiegały nawet o 2-3 sek. Nie było stałej opóźnienia, tylko ciągłe szukanie, co po bardziej gwałtownym zatrzymaniu samochodu, powodowało, że AM „dalej jechała” 2-3sek, aby potem „cofnąć” do faktycznego punktu. Tym razem byłem w trasie "normalnym" samochodem i przyspieszenia czy hamowanie odbywało się raczej płynnie, przy szybkościach do ok. 140km/h. Po obecnym zachowaniu AM mogę przepuszczać, że jazda tym drugim, bardziej "nienormalnym" pojazdem (500KM), będzie jednym wielkim chaosem i skakaniem obrazu, ale jeszcze nie miałem okazji tego poćwiczyć w boju. Jestem zawiedziony. Nie sadzę, aby nastąpiło jakieś zamulenie pracy urządzenia, bo procek w FS N560 jest szybki i zawsze zamykam wszystkie inne programy, ilość i moc satelit wystarczająca i widać, że wszystko działa szybko, ale nieprecyzyjnie. Takie odchylenia w warunkach miejskich eliminują przydatność AM. Jak to, o czym piszę się sprawuje u was koledzy?
Poza tym, AM 5.1 uważam za dobry produkt, co nie oznacza, że idealny. Moja ostatnia ocena dotyczy podstawowego zadania jaki powinna spełnić, czyli wytyczenie trasy i pilotowanie. Reszta, to jeszcze masa pracy, ale to już inny film.
Pozdrawiam

A próbowałeś wyłączyć w ogóle opóźnienie? Jaką masz ustawioną prędkość portu gps? U mnie nie zauważyłem takich objawów

A próbowałeś wyłączyć w ogóle opóźnienie? Jaką masz ustawioną prędkość portu gps? U mnie nie zauważyłem takich objawów

Oczywiście próbowałem i tego. Prędkość portu- 9600

A widzisz, u mnie jest 57600 Zmien ustawienia w systemie start-settings-system-gps I ustaw 57600 a w auto mapie podepnij sie pod port sprzetowy na tej predkosci, powinno pomoc

A widzisz, u mnie jest 57600 Zmien ustawienia w systemie start-settings-system-gps I ustaw 57600 a w auto mapie podepnij sie pod port sprzetowy na tej predkosci, powinno pomoc

To coś w AM musi być ładnie pokrzaczone. Najdłuższy komunikat NMEA jaki widziałem w zapisie *.gps ma 76znaków.
Co daje czas transmisji przy 9600 ok 80ms. Komunikaty pojawiają się ok raz na 1 sekundę (1000ms - jakby kto cierpiał
na obecnie modną dyskalkulię).
Zatem przestawienie na 57600 nie ma praktycznego znaczenia.   
900ms to kupa czasu na inne czynności.

A widzisz, u mnie jest 57600 Zmien ustawienia w systemie start-settings-system-gps I ustaw 57600 a w auto mapie podepnij sie pod port sprzetowy na tej predkosci, powinno pomoc

To nie wystarczy .Trzeba jeszcze zmienić prędkość komunikacji w samym chipset'ie gps np. dla chipset'ów Sirf    programem  SirfTech

U mnie chodzi tylko na com8 i 9600bps. Nie mam innego wariantu- dlaczego? nie wiem

U mnie chodzi tylko na com8 i 9600bps. Nie mam innego wariantu- dlaczego? nie wiem

A przeszkadza Ci to? Jak już pisałem dla AM nie powinno to  robić żadnej różnicy.
A dlaczego nie masz? Bo pewnie masz taki, a nie inny moduł GPS.

Zupełnie mi to nie przeszkadza i mam podobne zdanie jak ty, ale dalej nie wiem dlaczego następują aż takie odchylenia wskazań GPS. Właśnie pojawiła się wersja 5.1.1 i może problem sam się rozwiąże

Coś takiego to zauważyłem już od wersji 5.0.x, zatem nie wierze, żeby w 5.1.x się coś zmieniło w tym temacie.

Po opcjach ustawienia GPS to widać, że chłopaki z AM jeszcze dużo muszą się nauczyć.
Masz coś takiego:
a/ otwieraj port tylko gdy używany - kompletnie niepotrzebna opcja, bo domyślnie powinien tak pracować, to raz,
    a po drugie co to ZU obchodzi jak program obsługuje port.
b/ czytaj port w oddzielnym wątku - kolejna niepotrzebna opcja - poprawna implementacja powinna wykorzystywać
    tzw. zdarzenia bo to GPS wysyła dane. Oczywiście oddzielny wątek być powinien.
c/ uwzględnij pokazując pozycje - jaki ma sens? bez zaptaszkowania pozycja jest spóźniona o ok 100m.
   Przecież samo przez się rozumie się, że kompensacja ma być wszędzie.
d/ częstotliwość odczytu portu GPS - to konsekwencja błędu konstrukcji AM.
   BTW o jaka częstotliwość chodzi? Wygląda na to, że ktoś nie rozumie terminów jakich używa.
  Jak już, to powinna być częstość. To różnica mniej więcej jak między koniem, a koniakiem.

 Jutro obaczę co fajnego jest w 5.1.1 

a/ otwieraj port tylko gdy używany - kompletnie niepotrzebna opcja, bo domyślnie powinien tak pracować, to raz,
    a po drugie co to ZU obchodzi jak program obsługuje port.
b/ czytaj port w oddzielnym wątku - kolejna niepotrzebna opcja - poprawna implementacja powinna wykorzystywać
    tzw. zdarzenia bo to GPS wysyła dane. Oczywiście oddzielny wątek być powinien.
c/ uwzględnij pokazując pozycje - jaki ma sens? bez zaptaszkowania pozycja jest spóźniona o ok 100m.
   Przecież samo przez się rozumie się, że kompensacja ma być wszędzie.
d/ częstotliwość odczytu portu GPS - to konsekwencja błędu konstrukcji AM.
   BTW o jaka częstotliwość chodzi? Wygląda na to, że ktoś nie rozumie terminów jakich używa.
  Jak już, to powinna być częstość. To różnica mniej więcej jak między koniem, a koniakiem.

c - u mnie bez zaptaszkowania jest ok, z ptaszkiem praktycznie nic nie zmienia.

Coś takiego to zauważyłem już od wersji 5.0.x, zatem nie wierze, żeby w 5.1.x się coś zmieniło w tym temacie.

Po opcjach ustawienia GPS to widać, że chłopaki z AM jeszcze dużo muszą się nauczyć.
Masz coś takiego:.......................................

 Jutro obaczę co fajnego jest w 5.1.1 

Mnie wydaje się podobnie, ale w związku, że nie jestem informatykiem po prostu doszedłem do wniosku, że tego nie rozumiem poza tym że wydaje się bez sensu. Ale widzę, że poczucie bzdurnych funkcji i ustawień nie tylko mnie dotyczy. Może chodzi o poczucie, że trzymamy w ręku coś profesjonalnego dla profesjonalistów?. Cóż, trzeba sobie jakoś splendoru dodawać,  ale mimo wszystko dla mnie hitem są duszki domków. Zupełnie tego nie używam w trasie.

Nie było okazji jeszcze wybyć w dłuższą trasę z AM 5.1.1, ale pojeździłem trochę po mojej wsi Koszalin i problemu już szczęśliwie nie widzę. Pozycja daje się dostroić. Teraz opóźnienie mam ustawione na 1,2 + oczywiście ptaszek. Widać z tego, że to był jakiś bardziej indywidualny przypadek i bardzo się cieszę, bo często moja trasa przypomina dosłownie rajd, a nie delegację. Jeden ostro mocnym sprzętem kieruje, a drugi zajmuje się pilotowaniem, obsługą CB, GPS, map i telefonów. Może nie ma się czym chwalić, ale tak to często niestety jest aby nadgonić czas. Dlatego bardzo ważne jest dla mnie aby w obcym mieście AM nadążała w miarę precyzyjnie za faktyczną pozycją.
Pozdrawiam

(...) Teraz opóźnienie mam ustawione na 1,2 + oczywiście ptaszek. Widać z tego, że to był jakiś bardziej indywidualny przypadek i bardzo się cieszę, bo często moja trasa przypomina dosłownie rajd, a nie delegację. (...)

Gwoli ścisłości, to chętnie bym chciał wiedzieć w stosunku do czego 'kompensuj opóźnienie sygnału'? Jak piszesz ustawiłeś sobie na 1.2s ... czy aby to nie zależy od aktualnej prędkości jazdy?
A jeżeli tak, to kolejna chybiona opcja w AM. Dobrze by było aby instrukcja zawierała dokładny opis tego co interfejs oferuje.

Gwoli ścisłości, to chętnie bym chciał wiedzieć w stosunku do czego 'kompensuj opóźnienie sygnału'? Jak piszesz ustawiłeś sobie na 1.2s ... czy aby to nie zależy od aktualnej prędkości jazdy?

Przestań w kółko marudzić, bo już mam dosyć Twoich pseudomądrych wypowiedzi. Jak Ci się AM nie podoba, to zmień na inny program i przestań d... zawracać.
Kompensacja (właściwie opóźnienie) sygnału nie zależy od prędkości bo ona kompensuje opóźnienie między odczytem pozycji przez GPS, a pojawieniem się tych danych i przetworzeniem w AM. Jest to zależne od rodzaju sprzętu i od chwilowego obciążenia przetwarzaniem danych.
Sorry, ale nie zdzierżyłem, czytam te Twoje wypociny od kilku tygodni i poza pluciem na AM nic nie wnoszą. Starczy już tego.

Przestań w kółko marudzić, bo już mam dosyć Twoich pseudomądrych wypowiedzi. Jak Ci się AM nie podoba, to zmień na inny program i przestań d... zawracać.
Kompensacja (właściwie opóźnienie) sygnału nie zależy od prędkości bo ona kompensuje opóźnienie między odczytem pozycji przez GPS, a pojawieniem się tych danych i przetworzeniem w AM. Jest to zależne od rodzaju sprzętu i od chwilowego obciążenia przetwarzaniem danych.
Sorry, ale nie zdzierżyłem, czytam te Twoje wypociny od kilku tygodni i poza pluciem na AM nic nie wnoszą. Starczy już tego.

Pozwolę się z Tobą nie zgodzić  , że nic nie wnoszą... wytykam te elementy, które są niejasne lub błędne w założeniach.  Nie po to kupowałem ten program, żeby kupować coś innego. W chwili zakupu (4.5.3) wydawał się być najlepszym na rynku. Nie byłoby tematu, gdyby wskazania położenia względem mapy nie pogorszyły się drastycznie wraz ze zmianą wersji.   

Cytat: voyager w Sierpień 14, 2008, 09:11:43

Gwoli ścisłości, to chętnie bym chciał wiedzieć w stosunku do czego 'kompensuj opóźnienie sygnału'? Jak piszesz ustawiłeś sobie na 1.2s ... czy aby to nie zależy od aktualnej prędkości jazdy?

Przestań w kółko marudzić, bo już mam dosyć Twoich pseudomądrych wypowiedzi.

Jak czegoś nie rozumiesz to zapytaj.
Napisane: Sierpień 14, 2008, 13:43:12

---

...
b/ czytaj port w oddzielnym wątku - kolejna niepotrzebna opcja - poprawna implementacja powinna wykorzystywać
    tzw. zdarzenia bo to GPS wysyła dane. Oczywiście oddzielny wątek być powinien.
...

Mniemam, że chodzi Ci o to, że port sygnalizuje nadejście znaku. Tylko ... wbudowane GPS'y tego nie robią. Trzeba jednak zapytać o dane w buforze. To zresztą niczego nie zmienia, bo o jedno i o drugie trzeba zapytać system i jedno i drugie nie musi wracać jak nie ma zmiany stanu/danych.

Muszę stanąć tu w obronę voyagera, bo cenię sobie bardzo logikę, czego nie można odmówić voyagerowi. Wcale nie sądzę, że jego uwagi są pluciem na AM. Jeśli tak pojmujesz wyrażanie krytycznych opinii, to całe to forum ocieka śliną, bo 99% AMowców pisze, co szwankuje, co chcieli by zmienić itp i można odnieść wrażenie, że AM jest całkowicie do D.... Mało kto pisze o pozytywach, co jest po prostu przyjęte jako norma, która powinna być. Ja osobiście mam dostępnych kilka urządzeń (wbudowanych w drogie fury też) i programów i używam mimo wszystko FS N560 i AM. Oznacza to, że w boju na trasie najlepiej się spisuje ten układ, ale to też absolutnie nie oznacza, że AM jest idealna.
Jeśli myślisz logicznie, to odróżnisz przewidywanie pozycji od wskazania pozycji. Odczyt i przetwarzanie danych z satelit odbywa się co sekundę przez niezależny od AM moduł i program, więc w warunkach miejskich dalekich od utrzymania stałej prędkości przewidywanie położenia jest zgadywanką korygowaną co 1sek. Jest to oczywista niedoskonałość obecnych systemów i to jest obiektywne, voyager tego nie wymyślił. Ruch jest zauważany przez GPS od 4km/h, potem przyśpieszanie i odwrotnie hamowanie więc parametr prędkości i punktu odniesienia jest bardzo ważny i zależny. Problem zgadywania zniknie, jeśli moduły GPS będą podawały wyniki pomiaru częściej niż raz na sekundę, czym częściej tym lepiej. Jaki problem w sytuacji widocznych np 12 satelit zliczać położenie czterech z nich, co 1/3 sek, lub sześciu co 0,5sek. Voyager ma rację i tez tak sądzę, że AM pakuje możliwość wielu ustawień, gdzie i tak tylko jedno jest dobre? Możemy się mylić, ale przedstaw argumenty, a nie pałuj się. Bardzo chętnie się czegoś nauczę, nawet zmieniając poglądy zgodzę się z tobą. Na razie nie przekonałeś mnie. (to było do kolegi Akubit)

Panowie, poproszę parę dni na 'proof of concept'.  Coś chce sprawdzić na moim MIO

Nie byłoby tematu, gdyby wskazania położenia względem mapy nie pogorszyły się drastycznie wraz ze zmianą wersji.   

To może przyjrzyj się swojej instalacji AM, bo nie wszystkim się pogorszyło, a sądząc z wypowiedzi na forum, to całkiem niewielu.

Jak czegoś nie rozumiesz to zapytaj.

Nie muszę się pytać. Moja wiedza pozwala mi zrozumieć więcej niż Ci się wydaje. Ale jak masz problem, to służę pomocą 

Jeśli myślisz logicznie, to odróżnisz przewidywanie pozycji od wskazania pozycji. Odczyt i przetwarzanie danych z satelit odbywa się co sekundę przez niezależny od AM moduł i program, więc w warunkach miejskich dalekich od utrzymania stałej prędkości przewidywanie położenia jest zgadywanką korygowaną co 1sek. Jest to oczywista niedoskonałość obecnych systemów i to jest obiektywne, voyager tego nie wymyślił. Ruch jest zauważany przez GPS od 4km/h, potem przyśpieszanie i odwrotnie hamowanie więc parametr prędkości i punktu odniesienia jest bardzo ważny i zależny.

Niewiadomą, którą musimy ustalić, żeby określić pozycję na mapie w danym sprzęcie jest różnica czasu między odczytem danych przez moduł GPS i wyznaczeniem pozycji na mapie (łącznie z obliczeniami związanymi z przewidywaniem pozycji). Prędkość jak to zwykle bywa jest pochodną po czasie i jako taka jest użyta do wyliczenia pozycji, ale prędkość jest w danym momencie znana jako dana z modułu GPS i do obliczeń kompensacji potrzebna jest znajomość czasu, o którym pisałem. Reszta jest dana i komputer jest w stanie wyliczyć pozycję na mapie.
Opóźnienie jest czasem i nie zależy od prędkości.

Kolego Akubit - to oczywiste, ale ja piszę o czymś, co można nazwać bezwładnością urządzenia, czyli o zbyt szybko następujących zmiennych w stosunku do tego, co sprzęt (bez względu na powód) jest w stanie wyliczyć i pokazać jako efekt, czyli pozycję rzeczywistą. Jestem pełen szacunku dla gości którzy ułożyli algorytm pozwalający przewidywać pozycję. Pisałem też, że jeśli się pojawi technologia pozwalająca kilka razy na sekundę (a nie aż co sekundę)podać pomiar z satelit, to problem zniknie albo będzie pomijalny, czyli zwiększy się precyzja wskazań pojazdów będących w ruch niejednostajnym, i to wszystko. Opóźnienie będzie zawsze oczywiście, ale będzie nieodczuwalne. Czy się mylę?

To może przyjrzyj się swojej instalacji AM, bo nie wszystkim się pogorszyło, a sądząc z wypowiedzi na forum, to całkiem niewielu.

Instalacja standardowa. Nic szczególnego. Powtarzana kilka razy.

Niewiadomą, którą musimy ustalić, żeby określić pozycję na mapie w danym sprzęcie jest różnica czasu między odczytem danych przez moduł GPS i wyznaczeniem pozycji na mapie (łącznie z obliczeniami związanymi z przewidywaniem pozycji). Prędkość jak to zwykle bywa jest pochodną po czasie i jako taka jest użyta do wyliczenia pozycji, ale prędkość jest w danym momencie znana jako dana z modułu GPS i do obliczeń kompensacji potrzebna jest znajomość czasu, o którym pisałem. Reszta jest dana i komputer jest w stanie wyliczyć pozycję na mapie.
Opóźnienie jest czasem i nie zależy od prędkości.

Zadanie się zgadza. Pokazanie na danym sprzęcie aktualnej pozycji, bo to m.in. jest zadaniem programu nawigacyjnego,  (zatem pozostaje przy swoim zdaniu, że ptaszek 'uwzględnij pokazując pozycje' nie ma sensu).

Załóżmy, że moduł GPS został ustawiony na automatyczne wysyłanie informacji nawigacyjnych (sprawdzę, czy wszystkie moduły da się tak przestawić). GPS przesyła nam informacje o aktualnej prędkości i kursie. Teraz to wszystko trzeba pożenić i pokazać nasze autko tam gdzie jest (mniej wiecej).

Zgadzam się, że należy dokonać kompensacji położenia wynikającą ze skończonych czasów: przesyłania danych (jest dany explicite z prędkości przesyłu danych, oraz czasu obróbki tych danych (jest zależny od sprzętu).

Ten drugi człon jest nie dość, że zmienny (od chwilowego obciążenia przetwarzaniem danych), to jeszcze zależny od sprzętu (jak akubit był napisał).

Zależność od sprzętu można w prosty sposób estymować wykonując na starcie programu zadaną liczbę razy (odpowiednio dużą) pewnych instrukcji procesora (ma się informacje o możliwościach sprzętu). I to też jest jakaś w miarę stała składowa. Pozostaje element zależny od aktualnych obliczeń związanych z topologią mapy. To jest najbardziej zmienny element, ale też do określenia.

Kolego Akubit - to oczywiste, ale ja piszę o czymś, co można nazwać bezwładnością urządzenia, czyli o zbyt szybko następujących zmiennych w stosunku do tego, co sprzęt (bez względu na powód) jest w stanie wyliczyć i pokazać jako efekt, czyli pozycję rzeczywistą.

Sam widzisz, że zwiększenie częstotliwości odczytu pozycji z GPSu (= ilości danych do przetworzenia) nic tu nie da.
Prędkość zaś nie wpływa na ilość danych do przetworzenia.

zwiększy się precyzja wskazań pojazdów będących w ruch niejednostajnym, i to wszystko. Opóźnienie będzie zawsze oczywiście, ale będzie nieodczuwalne. Czy się mylę?

Jak widać z powyższego - mylisz się. Do tego potrzebny jest wzrost mocy obliczeniowej sprzętu, bo już obecnie ledwie wyrabia z przetwarzaniem.

Instalacja standardowa. Nic szczególnego. Powtarzana kilka razy.

Wrócę z urlopu, to zainstaluję koledze z Mio P560 nową wersję, bo aż nie mogę uwierzyć, że się pogorszyło. Na moich sprzętach oraz Lark 35.0, Lark 35.3, Mio C520, FS 560, różnicy nie widać. Na forach też pojedyncze głosy, rozwiązania problemu zwykle są związane z innymi przyczynami.

Zadanie się zgadza. Pokazanie na danym sprzęcie aktualnej pozycji, bo to m.in. jest zadaniem programu nawigacyjnego,  (zatem pozostaje przy swoim zdaniu, że ptaszek 'uwzględnij pokazując pozycje' nie ma sensu).

Wolno Ci mieć własne zdanie. Nie musisz jednak od razu pluć o to na AM. Ja bowiem uważam, że to bardzo dobre rozwiązanie, bo oprócz ustawienia domyślnego, które jest ustalane w trakcie instalacji (prawdopodobnie w zależności od rodzaju sprzętu), każdy może sobie dostroić program w zależności od własnych upodobań oraz np. posiadanej karty pamięci.

Zależność od sprzętu można w prosty sposób estymować wykonując na starcie programu zadaną liczbę razy (odpowiednio dużą) pewnych instrukcji procesora (ma się informacje o możliwościach sprzętu). I to też jest jakaś w miarę stała składowa.

No nie do końca. Zainstalowanie programu, map, POI w wewnętrznej pamięci sprzętu, na kartach o różnych prędkościach odczytu czy zapisu, wreszcie włączenie różnych opcji programu (np pokazywanie POI, zapisywanie śladu itd.) może poważnie zakłócić przetwarzanie pozycji.
Uwzględnienie tych wszystkich czynników jest praktycznie niemożliwe, dlatego ja jestem zdecydowanie za obecnym rozwiązaniem tzn. domyślne ustawienie w zależności od sprzętu + możliwość dostrojenia.
Dzięki temu można uniknąć problemu (w zasadzie nie do rozwiązania) opóźnienia pozycji o jakim choćby obecnie dyskutuje się na podforum TomToma.

Przepraszam akubit ale na tej lekcji fizyki akurat byłem w podstawówce, gdzie była mowa o rodzajach ruchu. Albo się mylisz w całej rozciągłości, abo się nie rozumiemy, albo zaprzeczasz podstawowym prawom fizyki, albo się uparłeś na obecny przyjęty model oparty na przyjmowaniu zmiennych w obecnej jednostce czasowej czyli 1sek, już sam nie wiem.
Masz oczywiście rację, że nie istotne z jaką szybkością porusza się antena GPS, bo to tylko jakaś wielkość matematyczna i z tego punktu widzenia to się zgadza, ale ja upierdliwie i chyba nieudolnie próbuje tobie wytłumaczyć, że im krótsza jednostka czasowa "zbierania danych" tym realna pozycja GPS jest bardziej precyzyjna w sensie bezwzględnym. W drugą stronę jeśli zmienne działania będą zbierane np aż co 1min, to dla anteny w bezruchu i anteny będącej w ruchu jednostajnym (bez względu na prędkość) to nie ma znaczenia, czy to będzie co 1sek, czy 1min, ale dla będącej w ruchu niejednostajny, wręcz zmiennym i nieprzewidywalnym to ma ogromne znaczenie, a tak właśnie poruszają się samochody zwłaszcza w mieście. Zrób bardzo prosty test. Wystartuj na światłach w miarę żwawo do np 60km/h, i policz ile czasu minie zanim zobaczysz na ekranie AM rzeczywistą prędkość. To jest właśnie ta bezwładność. Można to zmniejszyć (wyeliminować się nie da), tylko przez zmniejszenie jednostki czasowej pomiaru, zamiast siwieć nad coraz wspanialszymi algorytmami przewidującymi pozycję.

Co do sprzętu, to miałem na myśli jego część, czyli moduł GPS, który nie wiem jaką ma wydajność i nie podejmuje się oceny, poza praktyczną obserwacją, że nie grzeje się z przepracowania. Jeśli są na rynku anteny potrafiące odbierać i przetwarzać dane z dziesiątek satelitów jednocześnie, to nie sądzę aby to był jakiś problem technologiczny. Zasadnicza część czyli PDA jeśli jest obciążona, to grafiką a nie przetwarzaniem danych z GPS, bo nie ma co w zasadzie już przetwarzać. To robi moduł. AM zresztą ma możliwość odczytu danych z modułu GPS w krótszych jednostkach niż 1sek.
Wniosek: Obstaje przy swoim.

Co do sprzętu, to miałem na myśli jego część, czyli moduł GPS, który nie wiem jaką ma wydajność i nie podejmuje się oceny, poza praktyczną obserwacją, że nie grzeje się z przepracowania. Jeśli są na rynku anteny potrafiące odbierać i przetwarzać dane z dziesiątek satelitów jednocześnie, to nie sądzę aby to był jakiś problem technologiczny. Zasadnicza część czyli PDA jeśli jest obciążona, to grafiką a nie przetwarzaniem danych z GPS, bo nie ma co w zasadzie już przetwarzać. To robi moduł.

Tylko zastanów się co się potem z tymi danymi dzieje. Muszą być one przesłane do PDA/PNA i tam powiedzmy, jeżeli odczyt z GPSu będzie co 0,1s, to 10x częściej na ich podstawie będzie obliczana pozycja na mapie i przetwarzana grafika.
Nikt tu nie dyskutuje nad tym, czego przyczepiłeś się jak rzep psiego ogona, że częstotliwość próbkowania zwiększy dokładność pozycjonowania, bo to jest oczywiste, tylko mówi się o tym, że wymaga to większych mocy obliczeniowych. I nie ma wątpliwości, że w tym kierunku pójdzie rozwój technologii, ale będzie to możliwe równocześnie ze wzrostem mocy obliczeniowej PDA/PNA.

Zaś jeśli chodzi o uważanie na lekcjach fizyki w podstawówce, to uważałem na tyle, że nie miałem problemów z fizyką później na politechnice, a i obecnie jako inżynier mechanik z 20 letnim stażem w zawodzie, nie stwierdzam w tej dziedzinie ubytków wiedzy 

oczywiste to jak oddychanie
jakoś nie widzę pracy mojego pda z procesorkiem 400mhz i ramem w pojemności 64mb z czego połowa zajęta jest przez coś tajemniczego  próbującego co 0,1 sek obliczać zmianę położenia z gps 1sek jest wystarczająca przy dobrze działającym sprzęcie

Akubit - przecież grafika, nie musi by przetwarzana 10x szybciej - jej przetwarzanie może pozostać bez zmian (a właśnie na grafikę idzie lwia cześć mocy obliczeniowej). Natomiast 10-krotne szybsze przetwarzanie danych z gps-u dla dzisiejszych pda/pna to pestka i rzeczywiście pozwala zwiększyć dokładność pozycjonowania.

Nie wiem ile czasu potrzeba na przetwarzanie grafiki, ile czasu na transfer z GPSu, a ile z karty, ile w końcu na obliczenia przewidywanej pozycji. Wiem jedno: słabsze PDA/PNA ledwo z tym wszystkim nadążają, niektórym wystarczy korekcja opóźnienia 0,5s, ale niektórym 1,5-2s, a to oznacza, że dane z GPSu potrzebowały 1,5-2s by zostać odwzorowane na ekranie.

Przetwarzanie danych z gps-u to pewnie tak około 1% całej mocy obliczeniowej. W obecnej AM jest rzeczywiście jakoś tak, że zmiana częstości odczytu gps-u powoduje czkawkę na niektórych urządzeniach. ale to pewnie dlatego, że ta zmiana wpływa też na inne modułu aplikacji a wcale nie musi. Przecież cześć urządzeń nawigacyjnych już od dawna szybciej niż co sek. odczytuje pozycje z gps-u.

A ja twierdzę, że 50% (masz dowód, że 1% ) biorąc pod uwagę wpasowanie pozycji podanej z uwzględnieniem opóźnienia w aktualną pozycję na mapie. Ale nie o to chodzi w tej zabawie.
Chodzi o to, że programy do nawigacji muszą działać sprawnie na sprzęcie z procesorem 200MHz i to, że część sprzętu może przetwarzać dane częściej niż 1x/s to tylko dowód na to, iż technologia nie stoi w miejscu. Przecież profesjonalny sprzęt GPS już od dawna działa na częstości odczytu 10x/s i sfera kosmiczna technologii GPS od zawsze to obsługuje. Producenci modułów GPS do nawigacji dopiero zaczynają zwiększać częstotliwość odczytu modułów, bo wcześniej nie było takiej potrzeby, ze względu na urządzenia PDA/PNA.