Zgadzam się z Krzyśkiem i Kubą
Jestem programistą i programowanie GPS-a znam od kuchni. W języku Java napisałem aplikację na telefon komórkowy, która analizuje dane GPS. To co daje nam technologia, to między innymi: współrzędne geograficzne, aktualna prędkość oraz wysokość n.p.m. Dane te uzyskujemy przez parsowanie (dzielenie na fragmenty) przekazywanego przez urządzenie GPS ciągu NMEA:
http://pl.wikipedia.org/wiki/NMEA_0183
, ale często wbudowane urządzenia posiadają możliwość bezpośredniego pobierania danych, np. w API Javy funkcja GetAltitude() podaje nam aktualne dane na temat wysokości w metrach. Ciąg NMEA jest zawsze przekazywany przez moduły GPS, który łączą się z telefonem komórkowym przez Bluetooth (ja mam taki), a w przypadku GPS-ów wbudowanych w komórkę mamy możliwość bezpośredniego pobrania danych (moja aplikacja obsługuje oba sposoby komunikacji). Podejrzewam, że w zegarkach pobieranie danych działa podobnie - z wewnętrznego GPS-a lub z nadajnika przyczepianego na rękę. Powyższe informacje raczej nie będą interesowały zwykłych użytkowników
Moduły GPS mogą być lepsze, lub gorsze. Często zwracają niedokładne dane, położenie może być przesunięte nie o dziesięć, a kilkadziesiąt, a nawet więcej metrów. Jeszcze gorzej jest z wysokością. Tutaj skoki bywają zaskakujące.
To, co się dzieje z danymi przekazanymi przez urządzenie, zależy od oprogramowania w urządzeniu (zegarku/telefonie komórkowym). Super, jeżeli software ma do dyspozycji dane np. z czujnika bezwładnościowego oraz czujnika barometrycznego, który znacząco redukuje wahania wysokości. Fajnie, że producenci zegarków dla biegaczy próbują wygładzić tempo biegu. Mogą to robić na podstawie wskazań tych dodatkowych urządzeń, a także analizować pomiary z kilku pozycji i na tej podstawie uśrednić prędkość.
Dane GPS-a mogą być pobierane z różną częstotliwością. Im większa częstotliwość (np. co sekundę), tym pomiar będzie dokładniejszy. W przeciwnym wypadku jest mniej danych do analizy tempa chwilowego, a także pomiar przebytej drogi może być inny. Jeżeli między pomiarami mamy interwał 10 sekund i biegniemy np. po łuku stadionu, to urządzenie obliczy nam odległość w linii prostej między punktami (przez boisko), a tak naprawdę biegliśmy przecież po łuku, więc dystans powinien być trochę dłuższy. Tutaj też można się popisać implementacją jakiegoś algorytmu, który w takim przypadku zwiększa nieco pomiar dystansu, jeżeli zmienił się kierunek biegu. Przy krętych trasach może to mieć spore znaczenie.
Może powiem, jak rozwiązałem kwestię pomiaru w mojej aplikacji. Nie stosuję żadnych algorytmów spłaszczających tempo chwilowe. Na wyświetlaczu komórki pokazuję to, co zwrócił mi w ostatnim pomiarze GPS (można ustawić w konfiguracji pobieranie co 1, 3 lub 10 sekund, ten ostatni jest najbardziej znośny dla baterii). Drogę obliczam w następujący sposób: na podstawie współrzędnych geograficznych dwóch punktów liczę odległość między nimi na globie, uzyskuję wynik odległości w rzucie, a który dodatkowo koryguję twierdzeniem Pitagorasa o zmianę wysokości. Obliczam po prostu długość przeciwprostokątnej trójkąta, gdzie przyprostokątne to: odległość między punktami oraz zmiana wysokości n.p.m. Mieszkam w górach i wiem, że taka korekta jest bardzo ważna, kiedy poruszamy się w terenie mocno pagórkowatym, a zbocza są o sporym nachyleniu. Wydaje mi się, że np. Garmin F305 nie uwzględnia zmiany wysokości. Żona biega właśnie z tym popularnym zegarkiem, a ja z komórką i np. po dzisiejszym porannym wybieganiu jej pomiar wyniósł 14 km, a mój - prawie 15! Z drugiej strony, zdaję sobie sprawę, że ciągłe liczenie tej przeciwprostokątnej zawyża pomiar, bo jak wcześniej wspomniałem, GPS często nie pokazuje dokładnie wysokości i generuje dziwne „skoki”, nawet w odstępach kilku sekund. Prawidłowy pomiar leży pewnie zatem pośrodku. Tutaj jest ten trening, o którym mówię:
http://runcalc.byledobiec.pl/index.php? ... &tr_id=349
Ślad na Google Maps w miarę się zgadza, z wyjątkiem jednego odcinka. Biegliśmy na wschód doliną Straconki ulicą Górską, a tu przekłamanie jest fatalne (znaczne przesunięcie śladu na północ).
Jeżeli chodzi o „spłaszczenie” pomiaru, to moja aplikacja na bieżąco oblicza dystans i jeżeli przekroczy określony interwał (np. 100 m), to automatycznie łapie międzyczas (na załączonym wyżej przykładzie widzimy kolejne międzyczasy złapane na dystansach 109, 200, 314... m). Te dane mogą też automatycznie wysłane na portal i można śledzić biegacza on-line. Automatyczne łapanie międzyczasów co określony dystans na pewno spłaszcza pomiar tempa i redukuje wahania wysokości.
Podsumowując mój długi wywód (jeżeli ktoś to czyta, to znaczy, że dotrwał do końca
): jakość modułu GPS to jedno, a oprogramowanie i wykorzystanie dodatkowych urządzeń, to inna sprawa.
A jeżeli chodzi o pomiar tempa chwilowego, to radziłbym nie opierać się wskazaniach GPS. Interwały najlepiej robić na stadionie, lub wymierzyć sobie idealnie (licznikiem rowerowym lub kilka razy GPS-em) jakąś fajną, płaską trasę, oznaczyć odcinki i na tym trenować. Np. moja aplikacja posiada też możliwość wyznaczenia sobie targetów czasowych i na kolejnych międzyczasach pokazuje odchylenia od planu. W tym stoperze nie jest w ogóle wykorzystywany GPS. Biegacz musi za to łapać międzyczas np. po każdym okrążeniu stadionu i widzi na ekranie komórki, czy leci zgodnie z planem i jakie jest ewentualne odchylenie. A spokojne wybiegania można sobie robić z GPS-em. Jest bardzo przydatny, żeby analizować potem przebytą trasę na mapkach, profil trasy, tempo, ale czasem może nas uratować nawigacyjnie, kiedy zgubimy się w nieznanym terenie
skoro działa dobrze inna to o tej zapominam i spię spokojnie 
