Beiträge von kiozen

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    * Ablesbarkeit bei Sonne + Sonnenbrille ist sehr wichtig
    * Laufzeit von 12h+ ist wichtig (inkl. einfach austauschbarem Akku)
    * 100% Bedienung über Tasten muss möglich sein
    * Eine gut positionierte Antenne, damit der Empfang mal nicht nur besseres Mittelmaß ist
    * Endlich mal eine ordentliche Rucksackhalterung
    * Gerne einen Tick größeres Display (wobei Ablesbarkeit und Stromverbrauch wichtiger sind)
    * Barometer + Kompass (aber das sollte sich von selbst verstehen)



    Möglichst Verzicht auf jeglichen erodierenden Gummi. Das Thema kotzt mich nämlich langsam wirklich an. Beim Sportiva hat sich der eigentlich überflüssige Gummirand nach 2 Jahren abgelöst. Beim 62er löst er sich nach 4 Jahren auf. Beide Geräte wären eigentlich technisch noch im einwandfreien Zustand, wenn Gummi dem ganzen nicht vorzeitig ein Ende setzen würde.


    Da ich jetzt das 62er zwangsläufig durch ein 64er ersetzt habe, hat Compe wieder 4 Jahre Zeit ein fürs Bergsteigen überzeugendes Gerät herauszubringen. Schön wäre es.

    Besser wäre eine Pausentaste und ein Pieps wenn das Gerät der Meinung ist, dass es sich zu weit vom Pausenpunkt entfernt. Dann kann der Benutzer immer noch selber entscheiden.


    Auch besser wäre eine zweigleisige Aufzeichnung wie sie TwoNav macht. Bei Pause wird ein weiterer Track an andere Stelle aufgezeichnet. So geht nichts verloren.


    Ideen gäbe es genug. Aber Garmin macht jetzt auf Wearables. Da bleibt keine Zeit für Innovation auf dem schrumpfenden Outdoorsektor.

    Der Track ind dem von hans_kohler übermittelten gpx file hat beim Öffnen in Basecamp eine Länge von 16 km. Das entspricht der Länge in der Anzeige des Tripcomputers.


    Aber auch nur weil es so hartkodiert in der GPX Datei steht. Und hätte der Tripcomputer 200km angezeigt würde anstatt 14.8km dort 200km stehen. Lösche die Zeile mit der Erweiterung und Basecamp zeigt auch 14.8 km an.



    Werden die Pausenaufzeichnungen editiert und damit der Track auf den tatsächlichen Wegverlauf "gelegt", so ist die Tracklänge 13,4 km.
    Also nahe dran an die von Dir festgestellten "knapp 14 km".


    Ich lege die nicht fest. 14.8km ist die Summe aller Teilstücke die durch die in der GPX Datei abgespeicherten Positionen definiert sind. Das ist knallharte Mathematik und nicht mein persönliches Gusto.



    Was wäre also falsch daran, die Aufzeichnung zu pausieren, wenn man dann eine Pause macht ? So wird doch der Track ohne Pausenschlenker aufgezeichnet und die Tracklänge entspricht dem tatsächlichen Wegverlauf.
    Die Aufzeichnung auf maximale Punktezahl zu setzen würde in der Tat noch mehr Pausenfehelr erzeugen.


    Da der Tripcomputer eigentlich unabhängig von der Trackaufzeichnung läuft, wird eine Pause nur was für die Aufzeichnung bringe. Nicht aber für den Tripcomputer. Aber ihr könnt es gerne ausprobieren. Jede Änderung der Firmware bekomme ich nicht mit.


    Generell wäre eine Pausentaste gut, wenn sie clever programmiert wäre und auch merkt, wenn man weiter geht. So wie Garmin das macht, ist es fehleranfällig. Lieber Punktewolken, als Teile vom Track verloren, weil ich die Pause vergessen habe.




    Wäre es also nicht besser, dem Wanderer zu empfehlen, die Trackaufzeichnung im Setup mit normaler Punktmenge und auf ein festes Wegintervall zu setzen ?
    Ihm ist doch die Verlässlichkeit der im Tripcomputer angezeigten Werte wichtig.
    Es wäre doch einen Versuch wert, oder ?


    Nochmal: Der Tripcomputer macht sein eigenes Ding. Erst deswegen kommt es ja zu der Differenz. Die Einstellungen zur Aufzeichnung beziehen sich auf den Track, nicht auf den Tripcomputer.


    Wer es anders haben will, ist bei Garmin falsch aufgehoben. Der nimmt TwoNav.

    Hier habe ich ein Bild gefunden:


    http://www.navigation-professi…p62_trackaufzeichnung.jpg


    Das Intervall kannst Du jetzt von "normal" auf "Am häufigsten" setzen. So habe ich es eingestellt. Kann man aber auch anders sehen.


    Ich bin kein Freund von festen Intervallen. Zwar könnte man mit festen Intervallen eine ganz andere Mathematik anwenden, als mit variablen Intervallen. Wenn man es dann aber wirklich mal macht und sich auch den nötigen Code zur Auswertung schreibt, merk man schnell: "Viel Arbeit, viele Daten, nicht wirklich ein Gewinn."

    Gut, dann kann man einen fehlerhaften Reset ausschließen.


    Erhöhst Du die Punkteanzahl in der Aufzeichnung, wird die Strecke, die aus dem Track berechnet wird auch länger. Das würde dann eher dem Wert im Tripcomputer entsprechen. :D


    Ob es allerdings näher an der Wahrheit liegt? Da fängt dann die Philosophie an. Ich persönlich zeichne lieber mehr auf, um Serpentinen gut abzubilden. Und entferne dann nachträglich so viel wie möglich, um die Struktur des Weges noch wieder zu geben, aber dennoch einen sehr konservativen (lies: niedrigen) Wert für die Distanz und die Höhenmeter zu bekommen. Nach der Bearbeitung habe ich dann durchaus den selben Unterschied wie Du. Bei der Aufzeichnung stimmen aber meine Werte besser mit dem Tripcomputer überein, weil ich mehr Punkte aufzeichne.


    Eine genaue Wahrheit gibt es bei der Art der Messung leider nicht, da auch schon ohne Messfehler, die Anzahl der Messpunkte die Länge beeinflusst. Es gibt da aus der Fraktal und Chaostheorie ein interessantes Gedankenexperiment, das die Küstenlinie von England unendlich lang werden lässt, wenn man das Messintervall nur unendlich klein wählt. Der selbe Effekt arbeitet auch hier. Die Messung ist folglich immer ein Kompromiss aus Detailtreue und einer vernünftigen Anzahl von Messpunkten, um auf realistische Werte zu kommen.

    Der Wert im Tripcomputer des GPS62 ist in dem hier diskutierten Fall korrekt.
    Die Angabe von 16 km im Tripcomputer ist okay.
    Die Gesamtstrecke ist incl. der Pausenaufzeichnungen ( Schlenker ) etwa 16 km.
    Werden die Pausenaufzeichnungen gelöscht, so entsteht annähernd und mit vertretbarer Abweichung die tatsächlich gelaufene Strecke.


    Nein, leider nicht. Bei der Auswertung der Aufzeichnung, ohne die Pausenknäule zu entfernen, kommt man nach bestem Willen leider nur auf 14.8. Wenn der Tripcomputer tatsächlich mit der Trackaufzeichnung gestartet wurde, sollte aber immer das Selbe herauskommen.


    16km sind somit zu viel. Ob es nun daran liegt, dass der Tripcomputer seine Werte nicht aufgrund der aufgezeichneten Punkte berechnet, sonder aufgrund der sekündlich anfallenden Daten, oder weil er intern nicht sauber zurückgesetzt wird und deswegen eine alte Position zum Ergebnis zählt, kann man nachträglich nur noch schwer beurteilen.


    Welcher von den beiden Fällen nun auch zutrifft, ist egal. Genau genommen handelt es sich in beiden Fällen um eine falsche Berechnung. Wobei die Diskrepanz in der Regel nicht so groß ausfällt.


    Das wurde auch alles schon oft an Garmin herangetragen. Bewegt hat sich leider wenig. Letztlich muss man es im Werksforum von Garmin immer wieder diskutieren und mit Tracks untermauern. Vielleicht kommt ja dann mal eine zukünftige Generation von Geräten heraus, die es besser machen. Für das 62er sehe ich keine Lösung. Das Gerät ist mehr als 4 Jahre alt. Bei meinem verwandelt sich der Gummi inzwischen komplett in klebrige Pampe. Für Garmin ist das nur noch eine lahme Ente.


    Zu den 16 km: Die sind in der GPX Datei kodiert. Wenn man die mit einem Editor aufmacht, sieht man dass die in den Erweiterungsfeldern des Tracks stehen. Entfernt man das, zeigt auch Basecamp 14.8km an.


    Es wird schon seit Jahren bemängelt, dass der Tripcomputer, die Trackzusammenfassung und Basecamp unterschiedliche Statistiken für Tracks anzeigen. Das kommt eben davon, dass Garmin im Tripcomputer andere Daten verarbeitet, als dann abgespeichert werden. Doof, unnötig, aber sie machen es so.


    Als eine gewisse Antwort auf die Beschwerden hat Garmin dann angefangen Daten vom Tripcomputer in die Datei zu schreiben, um diese in der Statistik anzuzeigen. Ehrlich gesagt ist das noch dümmer. Da ich aber kein Basecamp benütze ist es mir egal.


    Das gleiche Drama bei den Höhenmetern. Die wurden sehr lange im Tripcomputer falsch berechnet. Mit der aktuellen FW sind die Werte in der Regel realistisch. Ruft man die später bei der Tripzusammenfassung auf, dann sind sie zu hoch weil einfach nur die Deltas zwischen den einzelnen Punkten addiert werden. Basecamp hingegen führt eine gewisse Glättung durch und kommt auf realistischere Werte.


    Ich kann auch nicht sagen, warum Garmin sich diese Blöße gibt. Würden sie einfach nur eine Statistik aus den aufgezeichneten Daten berechnen, und das überall mit dem gleichen Algorithmus, käme diese ganze Diskussion nie auf.

    Ein GPS ist kein Tacho ;) Sondern ein Messgerät für die Position. Die Position wird bei sehr gutem Empfang auf ca 3-10m genau angegeben. Und kann eine Streuung in ähnlicher Größenordnung haben.


    Bei 4km/h legst Du pro Sekunde 1.1 m zurück. Also einen Betrag, der der Streuung ähnlich ist. Es ist folglich nicht ganz einfach aus den Daten Stand und Bewegung zu unterscheiden. Das ist aber wichtig, um die Geschwindigkeit zu bestimmen.


    Wenn man sich die Auswertung ansieht, gehst Du zwar durchaus 4km/h. Die aber nicht besonders konstant. Damit sind die 3.3km/h aus der Berechnung durchaus realistisch.


    Ähnliches gilt für die Höhe. Das was das GPS misst unterliegt einer hohen Streuung. Wenn man die mit aufsummiert, dann wird es die Megatour ;). Darf man natürlich nicht machen. Eine Möglichkeit ist der barometrische Sensor. Der kennt ohne Kalibrierung zwar nicht die absolute Höhe. Dafür schwankt sein Wert aber nicht so stark. Zusammen mit dem GPS (das muss am Gerät eingestellt werden) kommt man auf relativ gute Werte. "relativ gut" heißt bei ca 800Hm +-50m. Bei schlechtem Empfang kann das aber auch nach hinten losgehen. Ich hatte jetzt eine Tour, da sind die fast 1300Hm nach der Auswertung auf 1000Hm zusammengeschnurrt. Hier hat Garmin auch die Schwäche, dass die Daten im Tripcomputer nicht aus den aufgezeichneten Daten abgeleitet werden, sondern aus den konstant im Empfänger anfallenden Daten. Damit ist die Berechnungsgrundlage unterschiedlich. Was oft beim Benutzer zu Verwirrung führt.


    Aber auch mit barometrischen Sensor kann man die Deltas nicht einfach addieren. Das führt immer zu einem zu hohen Wert. Da hat dann jeder so seinen Algorithmus. Welchen kann man schlecht sagen. Bei meinen Bildern wird eine Schwankung unter 5m ignoriert. Das hat in der Praxis zu sehr realistischen Ergebnissen geführt. Und wenn ich mir das Profil von deinem Track ansehe, dann liege ich mit meinen Werten doch ganz gut.


    Die Werte im Tripcomputer sollte man deswegen nicht als absolut präzise verstehen. Die Erfahrung zeigt, dass bei gutem Empfang die Werte recht nahe an den zu erwartenden Werten liegen. Die Präzision ist jedoch nie mit der eines Tachos zu vergleichen. Sollte zwischendurch der Empfang schlecht sein, dann kommt es sogar zu größeren Fehlmessungen.

    diese "Schlenker" waren eine länger Pause -- aber diese Szene ist nicht typisch für die ganze Strecke, sondern eher ein "Ausreißer" und führt sicherlich nicht zu einer Abweichung von 20 % auf der ganzen Strecke --


    Frage/Vermutung: könnte es nicht so sein, dass Google-Earth bei einem Hügel, den man hinauf und hinab geht, lediglich die Strecke auf der Basis misst (also im Sinne eines Dreieckes) die Hypotenuse misst ( A nach B) während der Garmin die beiden Katheten (also A nach C und dann nach B) berechnet ?


    Meines Wissens berechnen alle nur die Strecke über der Ebene. Der Fehler, der dadurch entsteht ist in der Regel zu vernachlässigen.

    Erfahrungsgemäß stimmt die Länge eigentlich immer relativ gut überein. Bei ~15km sind es vielleicht ein paar hundert Meter. Ob 16.1 km zu 14.8 km jetzt noch im Rahmen ist... grenzwertig. Vielleicht war der Tripcomputer nicht zurück gesetzt. Vielleicht war noch ein entfernter Punkt vom letzten Einschalten im Speicher.


    Nachdem man den Track nachbearbeitet (Punkteknäule entfernen, überflüssige Punkte reduzieren) hat sind Differenzen von 1-2 km bei ~15km durchaus drinnen.

    Ein Proxy wird momentan überhaupt nicht beachtet. Das liegt im Grunde daran, dass ich nur transparente Proxies habe, bei denen es einfach funktioniert. Wer etwas anderes benötigt, muss den nötigen getesteten Code liefern. Dann baue ich ihn gerne ein.