Beiträge von Ralphie

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 ...

    Auch wenn der Beitrag schon ein paar Woche alt ist und das Problem vermutlich mittlerweile selbst gelöst werden konnte.


    Schuss ins Blaue: Indoor Aktivität gewählt bzw. GPS bei der eingestellten Aktivität deaktiviert, was zur Folge hat, dass das GPS eben deaktiviert ist und keinerlei Trackdaten mehr protokolliert.


    Bewegungsdaten (Distanz, Speed) kommen dann von einem externen Sensor, der auch als eine Art Foot-Pod fungieren kann (z.B, HRM Run Pro HR Gurte). Einige Garmin Outdooruhren können wohl auch ohne externe Sensoren mittels eines Bewegunsgsensor diese Daten generieren.

    Würde vielleicht auch erklären, weshalb einmal doch eine Distanz protokolliert wird (HRM Pro getragen), das andere Mal nicht.

    Hallo Kiozen,


    ich weigere mich nicht, ich kam bisher noch nicht dazu, bzw. habe die original Trackaufzeichnung nach dem Synchronisieren vom Gerät gelöscht. Ich werde mal schauen heute Abend. Ich weiss ja nicht was mit den Tracks passiert, wenn sie mal zu Garmin hochgeladen wurden. Dort wären alle Tracks noch vorhanden.


    Grüße

    Im Garmin Connect Webportal kann man die Original Import Datei normalerweise* in der jeweiligen Activity Ansicht über das Einstellungssymbol oben rechts auch wieder exportieren.


    * Hängt aber davon ab, wie die Importdatei hochgeladen wurde (automatisiert oder manuell).

    Wie kiozen und ich zuletzt schrieben, ohne genauere Datenanalyse wird man nicht einschätzen können, wo genau die Ursache liegt.


    Die Nachbesserung via den 'fachgerechten Vermessungsdaten' (= von Garmin aufbereitete SRTM Daten) ist ja im Grunde genommen nichts anderes, als das Ersetzen der vom Gerät protokollierten Höhenwerte durch SRTM-Höhenwerte.


    Wahrscheinlich werden die Höhenwerte bei diesem Verfahren auch gleich geglättet, sodass die aus den Datenreihen berechneten Auf- und Abstiegswerte automatisch weniger werden (im Vergleich zu den manchmal eher verrauschten Werten des Gerätes). Das kann man ja im Garmin Connect Webservice mit dem von Dir erwähnten Schalter sehr gut nachstellen.


    Ich habe früher beruflich ziemlich viel mit diesen Daten zu tun gehabt, eigentlich gab es wirklich wenige Gründe für solche Abweichungen bei Parallelaufzeichnungen:


    1.) ein Gerät hat die Höhenwerte per Barometer (Höhenemesser) gemesen, das andere Gerät rein per GPS. In diesem Fall wies die GPS-Messung normalerweise immer deutlich höhere kumulierte Auf- und Abstiegswerte auf (da GPS Höhen im Normalfall eher sehr verrauscht sind -> wobei das auf heutige Geräte nicht generell übertragbar ist, da sich auch in Sachen GPS Messung einiges getan hat und die GPS-Höhen mitunter bereits geglättet werden).


    2.) bei dem einen Gerät wurden die Auf- und Abstiegswerte mittels eines Hysteresealgorithmus berechnet, beim anderen Gerät ohne irgendeine Filterung. Auch dann gab es größere Abweichungen, selbst wenn beide Geräte die Höhen barometerbasiert gemessen hatten. Garmin ist aber lange genug im Geschäft, ich kann mir nicht vorstellen, dass die gänzlich ohne Filter die Höhenwerte aufaddieren.

    Das Justieren eines passablen Hysteresefaktors, der dann in die Firmware eingepflanzt wurde, war dann immer auch eines der ToDos, die im Praxistest ausgelotet wurden.


    3.) eine Amoklaufende autom. Höhenkalibrierung (wenn diese zu oft während einer Aufzeichnung stattgefunden hatte und immer wieder das Barometer aus dem Tritt gebracht hat).


    4.) Echte Software (Firmeware) oder Hardwareprobleme.


    Aber wie gesagt, man kann das bis ins Gehtnichtmehr sezieren, letztlich sind diese Werte immer nur eine (grobe) Hausnummer, am Ende zählt der Spaß an der Aktivität draußen und nicht irgendwelche Kennzahlen.

    Ich saß vor kurzem auch wieder vor dieser Frage und wollte noch mal schauen, ob man das Problem bei unterschiedlichen Importdaten, die von allen möglichen Quellen stammen, irgendwie passabel generalisieren könnte. Habe dann wieder mal etwas mit Glättungsverfahren, Hysteresefiltern, etc. experimentiert, aber letztlich kann man das immer nur für ein bestimmtes Gerät abstimmen (und auch dann läuft es auf eine ungefähre Hausnummer hinaus).

    Das ist der Grund, weshalb ich in diesem Thread aktiv geworden bin ;)

    Ausreißer sind keine zu erkennen….das ist ja das seltsame

    Hast Du ein Programm oder App installiert, mit denen es möglich ist, den Hysteresefaktor für die Höhenkumulierung beliebig zu justieren?


    Dann könntest Du die GPX-Dateien (oder FIT oder was auch immer Deine Garmins exportieren können) damit einlesen und testen, wie sich die Auf- und Abstiegsberechnung bei den GPX-Dateien verhält.

    Sind ca. maximal 15 Minuten Aufwand, das durchzutesten, wenn Du auf die GPX-Dateien der beiden Geräte zugreifen kannst.


    Dann hättest Du eine Hausnummer, ob es generell an den Aufzeichnungen liegt (falls sich beide GPX-Exportdateien unterschiedlich verhalten) oder dein GPSMAP 30 das intern einfach nur falsch berechnet.

    Falls es generell auf den Aufzeichnungen liegen sollte, dann müsste die Höhenkurve beim GPSMAP 30 ja verrauschter sein, denn irgendwoher müssen die zusätzlichen Höhenmeter ja herkommen.


    Will keine Werbung machen, aber mit meiner freien Android App Namens WRPElevenationChart kann man das z.B. durchtesten, indem man dort in den Einstellungen den Glättungsfaktor auf 0 setzt und etwas mit dem Hysterese Faktor spielt.


    Aber erst mal die neue Firmware testen, sollte das nichts ändern und Du der Sache auf den Grund gehen möchtest, dann wirst Du um eine tiefergehende Datenanalyse wahrscheinlich nicht umhinkommen.


    Mehr fällt mir jetzt nicht ein, diese Berechnungen sind aber gerade bei flachen Strecken immer etwas problematisch, weil genau hier diese Hysteresefaktoren am meisten aufschlagen (filtern). Das würde auch erklären, weshalb die beiden Geräte im Gebirge nicht so groß voneiander abweichen (wenn ich das jetzt richtig im Thread verfolgt habe).

    Ausprobieren! :)

    Ich neige immer noch zu der Lesart, dass das primär vom jeweiligen Hysteresealgorithmus abhängig ist und Garmin diesen Algorithmus aufgrund unterschiedlicher Hardware nicht wirklich vereinheitlichen kann.


    Ob Garmin bei den Geräten an diesen Faktoren noch größere Änderungen vornimmt, ist schwer abzusehen. Aber ausschließen kann man das natürlich nicht (vor allem dann nicht, wenn das eine ein Seiteneffekt eines anderen Bugs sein könnte)!


    Was mir noch einfällt (und womöglich in diesem Thread schon erörtert wurde -> es wurden hier ja schon viele mögliche Ursachen erörtert):


    1.) Kann man bei den Geräten Sportarten (Aktivitäten) auswählen? Falls ja, könnte es durchaus sein, dass die Höhenberechnung je nach Profil anders implementiert ist. Also z.B. bei Sportart Radfahren eher eine konservative Berechnung, beim Wandern das Gegenteil (weil beim Gehen/Wandern jede kleine Höhenänderung von Relevanz ist, wohingegen beimn Radfahren kleine Hubel einfach überfahren werden und daher nicht (muss natürlich in diesem Fall NICHT heißen!) unbedingt in die Berechnung miteinfließen sollen/müssen).


    2.) Nachtrag, ist wohl hinfällig. Autokalibrierung hast Du ja deaktiviert, dann kann das nicht aufschlagen. Sofern Du bei beiden Geräten die Autokalibrierung aktiviert hast? Hast Du bei beiden Geräte auch exakt die selben Optionen aktiviert? Also z.B. fortlaufende automatische Kalibrierung bei beiden Geräten aktiviert. Das kann man m.W. ja feintunen und das könnte schon größere Auswirkungen haben, wenn das eine Gerät regelmäßig den Barometer kalibriert und das andere Gerät nicht.


    Viel Spaß beim Eruieren (da hast Du einen guten Grund, auch bei schlechtem Wetter draußen aktiv zu sein ;) )

    Bei alpinen Touren wird nur auf die Höhenmeter geschaut (und natürlich auf die Herausforderungen des Geländes). Solange man nicht noch einen langen Zubringer entlang latschen muss, hält sich die Distanz im überschaubaren Bereich. Aber schon im Mittelgebirge ist das kaum noch relevant und man schaut auf die Distanz.

    Deswegen hatte ich ja hervorgehoben, dass ich aus der Rennradecke komme und ich das (wahrscheinlich) alles sehr subjektiv betrachte.


    Glaube ich Dir also aufs Wort, dass bei hochlapinen Touren andere Maßstäbe gelten.


    Allerdings könnte man noch anmerken, dass Berge auch vor Einführung der GPS Geräte bestiegen wurden. Da hat man einen einfachen Höhenmesser und etwas Kopfrechnerei genutzt. Und selbst davor, also vor Einführung des barometrischen Höhenmessers, war man schon im Gebirge unterwegs.


    Ich will die Technik keinesfalls schlechtreden, nutzte diese Gadgets selbst sehr gerne.

    Aber letztlich muss man sich immer der Situation und den Umständen anpassen und meistens bekommt der Mensch das auch sehr gut hin (auch ohne Technik, wenn er denn muss).

    Hallo Ralphie,


    war länger nicht mehr hier. Mittlerweile einige Tests, auch im Vergleich mit dem Montana 700. Die Ergebnisse waren sehr unterschiedlich. Es gibt kein besser oder schlechter. Habe mich jetzt damit abgefunden. Es navigiert zuverlässig, das ist das Wichtigste. Bei der gestrigen Wanderung wurden die Höhenmeter absolut realistisch aufgezeichnet.

    Da bin ich 100% bei Dir. Im Grunde genommen gibt es nur wenige Szenarien, bei denen die Höhendaten relevant sind.


    1.) Hinterher bei der Auswertung, wenn man sich die Wanderung (den Track) nochmal einmal genauer ansehen will. Meistens wirft man dann ja auch einen Blick auf das Höhenprofil. Selbst bei sprunghaften GPS-Höhendaten kann man zumindest das Höhenprofil mittels Glättung dann einigermaßen geradebiegen.

    Die Auf- und Abstiegsmeter kann aber nur zum Teil restaurieren, falls diese total versaut sind. Wenn man da eine Konstante reinbringen will, dann wird man sich auf eine Variante beschränken müssen, also z.B. Neuzuweisung der Höhendaten per (hochauflösender) SRTM-Daten und Neuberechnung der Auf- und Abstiegsmeter.

    Oder man nimmt es, wie es ist (jede Tour ist eh anders ;)), oft kann man ja schon einem Höhenprofil den Charakter einer Tour entnehmen.


    2.) Während der Aktivität als eine Art Vorschau: ich komme mehr aus der Rennradecke und wenn man sich - was die noch vor einem liegenden Höhenmeter betrifft -, auf das GPS-Gerät verlässt, dann hat man schon verloren. Beim Wandern ist es nicht anders sein.

    Ob die vor einem liegenden Anstiege jetzt noch viele Höhenmeter bedingen, das sollte man besser von der selbst errechneten Differenz aus aktueller Höhe und Zielhöhe ableiten. Zur groben Orientierung reicht das.


    Mir sind eh wenige Leute bekannt, die die Höhenmeter während einer Tour als Index für die noch zu erwartenden Schwierigkeiten nutzen. Natürlich wird man sich vor der Tour Gedanken machen und dabei auch die vorausberechneten Aufstiegsmeter einbeziehen, aber während der Tour merkt man dann doch recht schnell, ob man die angesetzte Distanz schaffen wird oder nicht.


    Das ist jetzt natürlich alles sehr subjektiv :)


    PS: Ich habe mich auch lange mit dem Krempel beschäftigt (auch mal beruflich). In meiner Android App gibt es viele Stellschrauben, um die Höhenmeterberechnung rein mathematisch feinzutunen.

    Wenn ich ehrlich bin, hat das alles wenig Praxisbezug, weil fast alle GPS Daten ihren einen eigenen Charakter aufweisen. Man kann versuchen, das alles mit einer Hysterese und Datenglättung einzufangen, bei manchen Daten kommt man vielleicht sogar sehr nahe an vorzeigbare Werte, aber bei anderen Daten müsste man dann wieder gänzlich andere Hysterese- und Glättungsfaktoren verwenden und selbst dann liegt man wieder daneben. Man verwirrt den User häufig mehr, als dass man ihm hilft. Wenn man das bei einem bestimmten Gerät in den Geräteeinstellungen justieren kann, dann kann das sinnvoll sein.


    Alles nicht so einfach, wenn man zuviel High Tech einbezieht. Am Ende zählt eh nur die reale Erfahrung, also die eigentliche Aktivität und der Spaß vor Ort :)

    Aus irgendeinem Grund hats mir vorletztes Jahr bei einer Reise in der Osttürkei das Garmin auf die Werkseinstellungen zurückgesetzt. Seither kann ich anstellen was ich will, das ActiveLog heißt beim download immer gleich. Ich muss es immer manuell umbenennen, damit es mir am nächsten Tag nicht das vom Vortag überschreibt.


    Hat jemand eine Ahnung, wie ich die Schnittstelle wieder dazu bekomme, den Filenamen mit Datum auszugeben.

    Vorab: ist sehr lange her, dass ich eines dieser älteren Garmin Outdoor GPS Geräte benutzt habe und ich kann mich jetzt auch irren, aber ich meine mich erinnern zu können, dass es eine Option gab, die Track-Aufzeichnungen parallel auf der SD-Karte zu speichern.


    Diese Option kam erst mit einem späteren Firmware Update hinzu und musste manuell aktiviert werden. Vielleicht diese Option (Track Aufeichnung auf SD-Karte - oder wie auch immer das im Gerätemenü bezeichnet wird) aktivieren und schauen, ob das hilft.


    Die auf der SD Karte gespeicherten Tracks kannst Du nur über einen PC einsehen, aber nicht direkt auf dem Gerät (wenn ich mich nicht irre). Aber das wäre ja in Deinem Fall kein Problem.

    Ja das kann natürlich sein. Das wäre tatsächlich mal eine Idee. Werde ich bei Gelegenheit mal testen. Ich hab ja auch bissl übertrieben. Es sind ja nicht mehrere 100 Meter, welche zu viel sind. Aber ich bin einfach vom Montana 700 verwöhnt. Da sind die Aufzeichnungen einfach glaubhafter. Auf einer ebenen Strecke zählt es höchstens mal 2 M oder so….


    Ich versuche und berichte, danke dir


    Grüße Hardy

    Die Frage ist halt, ob Dein GPSMAP 67 die kumulierten Auf- und Abstiegsmeter anhand der GPS-Höhenwerte oder der Barometerhöhenwerte berechnet.


    Garmin selbst behauptet in irgendeiner FAQ, dass die Barometerchips nicht temperaturkompensiert seien (was ich allerdings etwas bezweifle, da die Barometersondern m.W. allesamt intern eine autom. Temperaturkompensation vornehmen).


    Wie auch immer, vielleicht zum Testen erst mal warten, bis Dein GPS die Außentemperatur aufgenommen hat und dann die Aufzeichnung starten (wobei bei den Garmin Outdoorgeräten die Aufzeichnung - im Gegensatz zu den Bike-Computern und Sportuhren - ja quasi immer aktiviert ist, oder?).

    Glaube zwar nicht, dass das wirklich etwas ändern wird, aber vielleicht einen Versuch wert.


    Wie gesagt, bei den Outdoorgeräten verwendet Garmin m.E. einen kleineren Hysteresefaktor* (die Edge Bike-Computer unterschlagen da einiges, was bei den Handheld Outdoor-Geräten nicht der Fall ist).


    Ggfs. mal mit einer Software oder App, bei der man den Hysteresefaktor manuell zuweisen kann, mit einer protokollierten GPX/Fit Datei gegentesten.


    * an den Hysteresefaktoren stricken alle Hersteller immer mal wieder, da kann ein Firmware-Update mitunter genügen, um gänzlich andere Werte zu erhalten (geht leider nicht immer in die richtige Richtung)

    Erst mal danke für diese ausführlichen Hinweise.

    So über'n Daumen gepeilt, gehe ich davon aus, dass Applikationen, die man bei f-droid wohl, aber bei google nicht bekommt, Daten besser schützen („Verzicht auf Google-Dienste“ - mein Händi hat keine SIM-Karte und bekommt auch keine). Der beim mendhak voreingestellte Speicherort ist zwar unschön, lässt sich aber von außerhalb Androids erreichen, das reicht mir eigentlich. Du hältst den mendhak aber für weniger resourcenschonend als den BasicAir? das wäre ein starkes Argument für mich.

    1.) Datenschutz: man kann auch Apps im Google Play Store anbieten, die keine Google-Dienste nutzen (und diese daher auch nicht in den Programmcode einbetten).


    Aber klar, die App-Downloads (Installationen) werden in gewisser Weise protokolliert und bei App-Abstürzen kann der App-Entwickler im Normalfall über die Play Console in das Absturz-Log hineinschauen (was ich jetzt aber nicht als schlecht erachte, weil das bei der Bugsuche für Entwickler sehr hilfreich ist).


    Das ist aber so eine Meta-Diskussion (Google, Big Brother, etc.). Letztlich müssen wir User das nutzen, was uns am besten taugt. Ich bin halt sowohl als User als auch als Entwickler unterwegs und daher bei diesem Thema wohl etwas entspannter (obwohl ich Google wirklich sehr oft verfluche).


    Google nimmt den Datenschutz gegenüber Entwicklern aber sehr ernst. Wenn man Apps außerhalb vom PlayStore platziert, kann man im Grunde genommen mehr Hintertürchen einbauen als wenn man diese über den PlayStore anbieten will (und Google über die Einhaltung der (Daten)schutzregeln wacht).

    Wobei ich Apps, die auf FDroid angeboten werden, davon aber ausnehmen will (die sind schon sauber), bei anderen Quellen wäre ich aber eher vorsichtig.


    2.) Resourcenschonender: das habe ich so nicht geschrieben. Meine Mutter kommt halt mit dem BasicAirData Logger besser klar, weil sie nur die Aufzeichnung mit dem Start-Button starten muss und am Ende nur den Stopp-'Button' klicken muss. Mehr will sie gar nicht machen. Automatisieren will sie nichts, da sie nur ihre Wandertouren protokollieren will (diese macht sie ja nicht täglich ;) ).


    Ich hätte ihr auch einen anderen Logger eingerichtet*, mit dem mendhak Logger wurde sie halt nicht wirklich warm.

    Vom Resourcenverbrauch schenken sich die einfachen Logger, die auf eine Karteneinbettung verzichten, alle nicht viel. Laufen normalerweise auch dezent im Hintergrund, sofern man es schafft, die (Android)-Batterieoptimierungen entsprechend zu deaktivieren (was bei manchen Smartphones aber eine richtige Strafarbeit sein kann).


    Mir selbst fordert der Logger aber etwas zu viele Schreib- und Leserechte ein - zumindest wenn man auf das externe Laufwerk zugreifen will. Es gibt nur wenige (System) Apps, denen Google die erweiterten MANAGE_EXTERNAL_STORAGE Rechte zugestehen würde (https://developer.android.com/…ge/manage-all-files?hl=de), ein GPS Datenlogger würde diese m.E. nicht bekommen und für den PlayStore mit diesen Rechten daher keine Freigabe bekommen, zumal es auch nicht wirklich nötig ist.


    Aber um das klar hervorzuheben, ich bin mir sicher, dass der Logger diese Rechte NICHT missbrauchen wird, man kann das als Schönheitsfehler abtun.


    Nichtsdestotrotz hätte ich mir etwas schwer getan, weil es eben das Smartphone meiner Mutter ist und ich da nicht alle paar Tage einen Blick draufwerfen kann. Hat alles seine Vor- und Nachteile.


    Wichtig ist, dass Du mit den von Dir genutzten Apps klarkommst, man sollte sich da m.E. auch gar nicht soviel von Außen reinreden lassen.

    So, dann will ich mal mitteilen, was ich durch Probieren glaube herausgefunden zu haben. Das Programm erhält man kostenlos bei f-droid. Vermutlich spezifiziert der Ausdruck „mendhak“ das Programm. Vom Namen her ist es leicht verwechselbar mit mit einem im play-store (oder github) erhältlichen GPS-Logger, der vermutlich durch den Ausdruck „BasicAirData“ spezifiziert wird. Das folgende bezieht sich ausschließlich auf „mendhak“.

    Ich will hier keine Empfehlung geben, weil diese Logger alle recht gut sind und letztlich die eigenen Vorlieben den Ausschlag geben, aber wenn es um einfaches Handling geht, dann ist der BasicAirData GPS Logger sicherlich auch einen genaueren Blick wert.


    Meine Mutter (> 80 Jahre) nutzt diesen gerne beim Wandern, weil er recht schlicht daherkommt und einfach zu bedienen ist. Ist ein reiner GPS-Logger (ohne Kartenansicht, etc.), der allerdings mit externen GPS Viewer Apps gut kombiniert werden kann -> man kann externe Viewer einbinden, die per Knofpdruck - ohne Umweg eines Exports - direkt aufgerufen werden können. So kann man hinterher schon einmal direkt auf dem Smartphone einen ersten genaueren Blick auf die Aufzeichnung werfen.


    Den von Dir genannten GPS Logger hatten wir auch mal testweise in Benutzung. Wenn Du auf den externen Speicherort (SD Card) zugreifen willst, dann benötigt dieser GPS Logger meines Wissens sehr weitreichende Lese- und Schreibrechte, weil er zum Auswählen des gewünschten Folders einen eigenen Dialog verwendet (zumindest war das mit der von uns getesteten Version der Fall und soviele Rechte möchte ich zumindest auf dem Phone meiner Mutter einer GPS-Logger App nicht zugestehen, weil das nicht notwendig ist). Es kann gut sein, dass dieser Logger einen eigenen Auswahldialog nutzen muss, um FDroid konform zu sein (da gibt es m.W. nämlich einige Auflagen, weitgehendst Verzicht auf Google-Dienste, etc.).


    Das ist bei dem BasicAirData GPS Logger besser gelöst, weil dieser den von Google favorisierten Weg über einen Intent-Aktion ACTION_OPEN_DOCUMENT_TREE Folderauswahl-Dialog nutzt.


    Google hat seit Android 11 (leider) sehr viele Einschränkungen an den Schreib- und Leserechten vorgenommen, die Verzeichnisauswahl ist unter aktuellen Androidversionen sehr regelementiert (und wird zukünftig womöglich sogar noch weiter eingeschränkt werden, wenn man nicht die angedachten API Funktionen dafür nutzt): https://developer.android.com/…red/documents-files?hl=de.


    Aber wie gesagt, ich will Dir bei der Frage nicht reinreden: der mendhak GPS Logger hat z.B. einige sehr gute Automatisierungsoptionen, die der BasicAirData Logger nicht aufweist.


    Beides sehr gute Logger, wenn man es einfach haben will.

    Falls das jetzt dem TE zu weit geht, bitte melden.

    Ralphie : Tatsächlich lassen sich bei Twonav Geräten auch noch Filter auf die Höhenmessung legen. Wir haben die Wahl zwischen exponentiellen Filter (mit einstellbarem Exponential Alpha Wert) oder einem Kalman Filter (mit einstellbarem Meas Error und Q Varianz Wert). Das ist aber völlig undokumentiert und ich bin da zu unwissend, um das für mich gut einzustellen, daher lasse ich den Filter ausgeschaltet.

    Ich will das Thema jetzt auch nicht überstrapazieren, weil wir wirklich Gefahr laufen, das alles auf eine Metaebene zu verlagern.


    Anbei noch zwei Links (nur der allgemeinen Information wegen).


    Vielleicht kann sich noch jemand an Klaus Bechtold erinnern? (Er war der geniale Kopf hinter der GPSies Plattform, die es leider nicht mehr gibt, aber uns Freunden der GPS Tourenplanungen sicherlich Jahre lang sehr gute Dienste geleistet hat und die bestimmt noch viele User kennen). Klaus hatte sich dem Thema auch einige Mal angenommen, am Ende dann aber auch wieder einen etwas einfacheren - oder besser gesagt pragmatischeren - Ansatz verfolgt. Geht aber wahrscheinlich etwas in die gleiche Richtung, die Twonav eingeschlagen hat, wenn ich das richtig einschätze, daher poste ich die beiden Links.


    Die Links sind leider nur noch über https://web.archive.org/ einsehbar, da sein Blog nicht mehr existiert.


    Neue Methode zur Berechnung der Höhenmeter

    GPSies Blog
    konvertieren nach Google Earth (KML, KMZ), Google Maps directions (XML, JSON), PCX5 (tracks, waypoints), GPX (tracks, routes, waypoints), GPX Garmin…
    web.archive.org

    Ich hätte jetzt zuerst geschrieben, dass das gegenüber Garmin und Wahoo - um mal zwei weitere etablierte Firmen aus dem Sportumfeld zu nennen - wirklich sehr gut dokumentiert ist, habe aber gerade gesehen, dass die beiden genannten Firmen das Thema mittlerweile auch etwas ausführlicher behandeln:


    Garmin schreibt zum Thema: https://support.garmin.com/de-DE/?faq=FhOYuggxmV6Atph276U4h8


    Wahoo: https://support.wahoofitness.c…fferences-in-my-ride-data


    Wobei diese Technik aber sicherlich über die Jahre immer weiter optimiert wurde und sich nicht jede Geräteserie gegenüber anderen Modellen gleich verhalten wird.


    Man könnte das auch alles auf die Spitze treiben und jene durch eine Kalibrierung bedingte n Höhensprünge mittels eines gleitenden Mittelwerts weich anpassen, sodass man hinterher diese Neujustierungen nur schwer dem Höhenprofil bzw. den Datenreihen entnehmen könnte. Der Kumulierung der Auf- und Abstiegswerte würde das sogar entgegen kommen.


    Aber den Stress wird sich vermutlich kein Hersteller wirklich antun, sondern irgendwo wird man dann einen Cut machen und sagen, das ist halt der Consumerbereich und dafür taugt's dann erst mal.


    Daher nehme ich wirklich an, dass bei vielen dieser Produkte im Pflichtenheft festgehalten sein dürfte, was der primäre Einsatzweck ist und welche spezifischen Eigenschaften damit einhergehen.


    Bei eher universelleren Geräten wird man dann ggfs. mehr Optionen zur Verfügung stellen (diverse Autokalibrierungen, mitunter einen variablen Hysteresefaktor - da ist mir aber kein Gerät bekannt, bei dem man das Geräteseitig eimnstellen könnte, ich kenne das nur bei PC-Software und Apps - , etc.).


    Man muss halt für das verwendete Gerät ein Gefühl bekommen, dann kann man sich m.E. gut auf die Gegebenheiten einstellen. Bei Parallelaufzeichnungen, querbeet durch die Hersteller, wird man aber sicherlich weiterhin die ein oder andere Überraschung erleben.

    Das stimmt nicht so ganz, man kann es bei Twonav auswählen und zwischendurch wird tatsächlich immer wieder mal das Barometer automatisch geeicht.

    Ausführlich siehe hier:

    Für mich geht das alles etwas in Richtung Voodoo, weil man als User nicht weiß, nach welchen Regeln diese Autokalibrierung funktioniert. Auf den Herstellerseiten findet man dbzgl. auch nur wenig Informationen. Prinzipiell sicherlich eine gute Sache, aber nach Möglichkeit sollte diese Autokalibrierung so erfolgen, dass sie so wenig Einfluß wie unbedingt nötig auf die eigentlichen Datenreihen hat.

    In dem von Dir gesposteten Parallelthread sieht es ja so aus - sofern ich das richtig überflogen habe -, dass die Autokalibrierung im Höhenprofil richtige Sprünge erzeugen würde?! 8|

    Und somit schließt sich der Kreis dann wieder, weil man in dem Fall um eine zusätzliche Glättung der Daten nicht herumkommen wird.

    Ob das dann direkt im GPS Chipsatz passiert - wie das einige moderne Chipsätze wohl machen - oder erst hinterher beim Generieren der (Export)Daten, macht ja keinen Unterschied.


    Sind aber alles Faktoren, die bei der Berechnung der Auf- und Abstiegsmeter hineinfließen. Wenn man SRTM Daten verwendet und die voraussichtlichen Höhenmeter einer Route berechnen will, muss man die Höhenwerte auch zuerst glätten, sonst passt es einfach nicht (selbst bei den neueren relativ feinauflösenden Daten).


    Die aktuellen Sportcomputer speichern die Höhenwerte mittlerweile mehr oder weniger durch die Bank im Fließkommaformat (mit mehreren relevanten Nachkommstellen). Macht sich auf dem Papier zwar gut, aber letztlich wird hier auch eine Genauigkeit vorgespielt, die so akkurat gar nicht sein kann, bei Geräten, die sich ständig in der Bewegung befinden (sowohl horizontal als auch vertikal).


    Ich bleibe dabei, das ist sicherlich keine Raketentechnik, aber man wird immer nur näherungsweise dem Problem beikommen können und ich nehme an, die Hersteller wissen das auch und reagieren deswegen auch recht gelassen auf dieses Thema. Es wird nämlich auch in den Hersteller eigenen Foren immer wieder diskutiert (und jede neue Gerätegeneration sorgt der Erfahrung nach wieder für etwas Aufregung) :)

    Aber es scheint dennoch genug Stolpersteine zu geben, sonst würde dieses Thema ja nicht immer wieder in den Foren und Weiten des Internets aufschlagen ;)


    Ich bin übrigens auch eher ein Freund von anpassbaren Hysteresefaktoren, ob jetzt 2m, 3m oder 5m am Universellsten sind, das ist dann mehr so eine akademische Frage. Hängt halt viel von der Hardware ab (selbst die Position des Barometer Chips innerhalb des Gerätes kann Einfluß haben, den man unter Umständen irgendwie abfangen muss).


    Ich habe viele Daten im Nachinein darauf beleuchtet, bei einigen bewirkt eine Änderung des Hysteresefaktors eine recht kleine Abweichung, bei anderen liegen dann mitunter Welten dazwischen, wenn der Hysteresefaktor minimalst von zwei auf drei verändert wird (Samplerate der Aufzeichnung, aber auch das Verhalten der Höhenmessung spielen da mit rein).


    Das Fusionsding bei Garmin (und einigen anderen Herstellern) ist ja so eine closed-box Geschichte. Da scheinen viele Geräte ein Eigenleben zu führen,

    von Kalibrierung nur beim Start der Aufzeichnung, über Kalibierung zu bestimmten Anlässen/Ereignissen hin zu einer Kalibrierung nach einem festen Zeitfenster scheint alles dabei zu sein.


    Ich habe aber wirklich selten Daten gesehen, bei denen diese Fusionierung merklich Einfluß auf die berechnten Höhenmeter hatte. Die Aufstiegsmeter werden ja aus den jeweiligen Deltas zweier Meßpunkte berechnet.

    Da müsste diese Autokalibierung schon einen echten Sprung aufweisen, dass das bei der Berechnung der Aufstiegsmeter große Auswirkungen hätte.

    Ähnlich bei der reinen Barometermessung und wetterbedingten Barometerdrifts. Auch das hat kaum Einfluß, es sei denn, man läuft/fährt in einen brutalen Wettersturz rein, bei dem das Berometer in sehr kurzer Zeit wirklich sehr stark ansteigt oder fällt.


    Ob reine GPS-Höhen oder Barometeraufzeichnungen besser sind, ist halt auch so eine Frage. Bei reinen GPS-Messungen hat man halt immer ein Rauschen, welches bei Barometer basierten Aufzeichnungen in dieser Form normaler nicht existiert.

    Dafür sind bei den GPS-Höhen die absoluten Höhenwerte häufig genauer, weil der Barometerdrift wegfällt (einen Tod stirbt man immer )


    Da hat aber jeder sicherlich seine eigenen Erfahrungen gemacht, für mich (primär Bike-Computer Nutzung, aber auch etwas Wandern) taugt die Barometermessug nach wie vor am besten.


    Auf GPS-Seite hat sich in den letzten Jahren aber vieles getan: ich habe GPS-Aufzeichnungen gesehen, bei denen die Höhenwerte sehr glatt/konstant waren. Weiß aber nicht, ob das Gerät die Höhendaten bereits geglättet hat oder nicht, was (Glättung) ich annehmen würde. Und wenn die Daten geglättet werden, dann spielt ja schon wieder eine dritte Variable mit in die Berechnung hinein, denn die Datenglättung bewirkt ja auch wieder eine künstlich vorgenommene Korrektur.


    Daher kann ich Deinem letzten Satz nur beipflichten, man kann das nämlich alles auf die Spitze treiben, am Ende muss man es aber eh nehmen wie es kommt (und sämtliche Maßnahmen, mit denen man das im guten Glauben auf einen gemeinsamen Nenner bringen will, weisen dann doch wieder Stolpersteine auf).


    Am Ende zählt eh nur der Spaß und jeder Berg ist anders :saint:

    Kann ich bestätigen, hab mich auch mal reingelesen…..👍

    Freut mich zu hören. Der Beitrag ist halt schon etwas älter und in Sachen Höhenauswertung auch etwas gestraft.


    'Wir' haben das in den einschlägigen Fahrradforen immer wieder mal diskutiert. Ich habe das Thema dort auch mal aus Entwicklerseite erörtert, aber wie es so ist, einige Webseiten und Foren bzw. Forenbeiträge existieren leider nicht mehr bzw. sind unauffindbar.


    Noch was zu Hysterese: Ende der 90'er, Anfang 2000 wiesen die Barometer-Sensoren noch eine sehr grobe Auflösung auf (anfangs 3m, irgendwann dann 1m Auflösung). Daher war es relativ einfach, einen geeigneten Hysteresefaktor zu finden.


    Mittlerweile lösen die Barometerchips im cm Bereich auf (https://www.amsys.de/produkte/…zisions-barometer-sensor/) und sind auch nicht mehr so träge in der Messung. Das heißt, man muss im Grunde genommen viel filtern, weil jeder Luftzug oder auch Temperatursprung schon eine Änderung der Höhenmessung bedingt (das Rauschen also zunimmt).


    Das erklärt dann vielleicht auch, weshalb selbst große Hersteller wie Garmin und Konsorten sich bei neuen Geräten immer wieder an die Berechnung der Höhenmessung herantasten müssen, weil sich einfach die verwendeten Komponenten grundlegend verändert haben und ältere gegenüber neueren Geräten - trotz des Versuchs, das irgendwie anzugleichen -, häufig dann doch andere Ergebnisse liefern.

    Diese Höhenberechnungnen sind wirklich eine kleine Wissenschaft für sich, sicherlich keine Raketentechnik, aber auch nicht so trivial, wie es auf dem ersten Blick erscheint. Bei Biekcomputer, bei denen man von einer schnelleren Fortbewegung ausgeht, wird dann in der Regel ein etwas höherer Hystresefaktor verwendet. gegenüber der Outdoor Handheld Geräte.


    Daher wird das auch immer wieder diskutiert :saint:


    Webportale, die die Höhenmeter anhand von SRTM-Datenbanken berechnen haben es da wesentlich einfacher, weil die halt auf eine konstante Datengrundlage aufbauen können, sodass zumindest die Berechnungen innerhalb ihres Mediums konsistent sind.

    ...

    Fakt ist aber, dass mein Bike Navi, das Edge 830 für mein Empfinden sehr genau ist und wirklich erst positive Höhenmeter aufzeichnet, wenn es gefühlt auch aufwärts geht.


    Grüße Hardy

    Das liegt aber auch darin begründet, dass bei reinen Bike-Computern in der Regel andere Hysteresefaktoren Verwendung finden. Der Hysteresefaktor spielt bei der Berechnung der Höhenmeter eine sehr große Rolle, sowohl im Gerät selbst als auch bei den Auswertungsprogrammen oder Webplattformen, die anhand der Höhenwerte (Datenreihen) eigenständig die kumulierten Auf- und Abstiegsmeter berechnen.


    In meinem Blog bin ich vor vielen Jahren einmal auf die Thematik eingegangen (dort sind auch eine Links eingebunden, die das Thema erörtern. Sehr interessant z.B. die Ausführungen von Jobst Brandt zum Thema: https://yarchive.net/bike/altimeter.html ). Im Internet findet man auch viele Seiten, die sich mit dem Thema befassen. In der Regel wird man leider keine generelle Lösung des Problems finden, weil einfach zuviele Faktoren mit reinspielen.


    Hier der Beitrag aus meinem (schon etwas älter, aber an der Messung und Berechnung hat sich eigentlich nichts grundlegendes geändert und auch wenn die verwendeten Barometer-Messsonden immer genauer auflösen können, ist das bei der Berechnung der realen Aufstiegsmeter nicht immer von Vorteil):


    GPS Daten oder spezifische Sensor Daten (Part 1: die leidige Sache mit der Genauigkeit)

    Glaube nicht.

    Ich habe auf der Connect Webplattform bei einer Activity auf Satellitenansicht gewechselt (dort scheint Garmin Connect die Einstellung auch zu speichern), weil manchmal Änderungen innerhalb der Webplattform auch in der (Android) App übernommen werden.

    Aber in der APP scheint die normale Standard-Kartenansicht als default fest verdrahtet zu sein. Sowohl in der Preview als auch beim Aufruf der Kartenanzeige (Vollansicht) wird die Karte immer im Standardmodus geöffnet.


    PS: bin mit der Garmin Connect Beta Version unterwegs, wird aber wahrscheinlich keinen Unterschied machen.

    Dann ist es sicher möglich, die App auch über f-droid.org oder direkt auf github anzubieten. Bei github wird auch der Quellcode eingestellt und daneben kann die APK veröffentlicht werden. Wie das bei f-droid.org funktioniert, weiß ich nicht.

    Freeware bedeutet ja nicht zwangsläufig Open Source.


    Die App ist frei und wird frei bleiben - da ein reines Side Projekt (in dem ich aber auch eigenen Code aus einem größeren 'kommerziellen' Projekt verwende). Insofern ist github für mich derzeit kein Thema, das ich aufgreifen kann/will. Bei F-Droid verhält es sich leider ähnlich.


    Direktes Hochladen auf APKPure werde ich aber ins Auge fassen.