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

    Wieder habe ich das Problem eine Frage beantwortet , 10 neue aufgeworfen .
    Also die ich schreibe Wanderungen damit ich nicht anecke , es gibt hier soviele Pfennigfuchser ,

    die ich irgendwo als Fit finde sind so wie Autonavi 200 m rechts ?
    Aber wo war das noch mal ? Das Menu ist für mich noch etwas hackelig , ja muß mir die Toturiels

    auf Y-toube noch mal anschauen Page sortieren und so ..

    Was mir noch schleierhaft ist , zu welcher Wanderung wird zusätzlich eine Fit auf das 66 geladen ,

    dass ist nicht 1:1 .... ?
    Ich hab da mal was in deinem Zitat gefettet .
    Was zum Teufel ist jetzt der Unterschied zwischen CP und Echtzeitrouting ????

    Vielleicht solltest Du mal deine Fragen und die Probleme dahinter etwas besser priorisieren.


    Wenn Dich die Speicherung der zusätzlichen FIT Dateien ärgern, weil sie Speicherplatz abzwacken, dann wird's halt schwierig. Entweder steht dazu etwas im offiziellen Handbuch Deines Geräts oder nicht.


    Ich habe Dir ja ein paar Einsatzzwecke dieses Dateityps aufgezählt und wenn Garmin bei Deinem GPSMAP 66 FIT-Dateien auch zum Speichern diverser Einstellungen nutzt - was viele Garmin Geräte definititiv tun - oder bei Routen-Importen eine automatische Konvertierung ins FIT-Course Format vornimmt, dann wirst Du das auch mit unserer Hilfe nicht verhindern können.


    Das zusätzliche Speichern im FIT File Format deiner protokollierten Wanderungen (im Fit File Jargon 'Activities' genannt) scheinst Du ja in den Einstellungen des Gerätes deaktivieren zu können.


    Aber wie gesagt, das FIT-File-Format wird mittlerweile - bzw. eigentlich schon seit seiner Einführung - auch für andere Daten rege genutzt und lässt sich daher nicht immer deaktivieren.


    Eventuell kannst Du direkt im Garmin Forum weiterführende bzw. bessere Infos einholen:


    Outdoor
    Outdoor
    forums.garmin.com


    Wobei im deutschsprachigen Forum dort nicht so viel los ist, da müsstest Du dann wahrscheinlich ins englische Forum schauen:

    GPSMAP 66i - inReach - Garmin Forums


    Wie auch immer, auch in der IT lässt sich leider nicht immer alles so feinjustieren, wie man das gerne hätte, daher muss man sich leider mit diversen Unschönheiten des öfteren arrangieren.

    Erstmal danke für deine Antwort . Ich dachte Fit steht für Fittness also das diese Dateien eben zusätzliche Daten aufzeichnen würden . Aber wenn du mit Abbiegehinweisen kommst , sind das dann

    noch Tracks oder Routen ? Ihr macht es mir nicht leicht . Ich stelle eine Frage , bekomme eine Antwort , die aber 5 neue Fragen aufwirft ???

    Jetzt kommst du noch mit SDK und parsen ? Ich will mich einfach nur beim Wandern nicht verlaufen ,

    dabei ist mir mein Puls scheißegal .
    Ich habe auch schon auf y-toube gehört , das Koordinaten nach grad / minuten / sekunden nicht mehr

    aktuell wären . Warum nicht ?

    Fit steht eigentlich für "Flexible & Interoperable Data Transfer (FIT) Protocol", wie der User Cabriote es ja bereits geschrieben hat.


    Ursprünglich wurde das Format als binäres platzsparendes Containerformat für alle möglichen Datenstrukturen konzipiert (siehe angehängte Grafik); ist aber vor allem als Protokollformat für Aktivitäten (Sportaufzeichnungen) bekannt geworden. Das war dem Umstand geschuldet, dass bei Einführung dieses Formates Speicherplatz auf den Bikecomputern und Sportuhren noch sehr knapp war und man daher wegkommen wollte von den relativ speicherhungrigen textbasierten XML-Formaten.


    Das GPX Format ist im Grunde genommen ja auch eine Art XML-Derivat, gut einsehbar, da textbasiert, bei längeren Aufzeichnungen können die GPX-Dateien aber sehr groß werden (vor allem bei sportbasierten Aufzeichnungen, wenn noch diverse Datenreihen dazukommen, die man eigentlich nicht braucht, manche User aber dann doch gerne auch bei ihren Outdoor-Handhelds protokollieren wollen -> da müssen die Hersteller also einen Mittelweg finden).


    Es wird aber auch zur Speicherung der Geräteeinstellungen und vielem mehr genutzt (nicht nur von Garmin), quasi als Ersatz der zuvor gerne verwendeten Ini-Dateien.


    Wissen muss man das als Endanwender sicherlich nicht, aber es kann ja nicht schaden, wenn man weiß, mit welchem Ziel das Format konzipiert wurde und weshalb es heutzutage Anwendung findet.


    Fit Course Files sind eigentlich eher Routen, die mit sogenannten CoursePoints genauer spezifiziert werden können. Die CoursePoints sind sozusagen die eingebundenen Routenanweisungen (links, rechts, geradeaus, etc.). Das verliert heute aber auch immer mehr an Wert, da die meisten Geräte ja Echtzeitrouting können und mittlerweile aufgespielte Routen häufig nachberechnet werden. Da diskutieren wir User dann immer sehr viel, wenn die Geräte meinen, unsere Routen überarbeiten zu müssen :saint:


    Aber das Format ist sehr offen, Fit Course Files können auch richtige Tracks beinhalten, es liegt dann an der jeweiligen Anwendung oder GPS-Gerät, welche Daten es aus dem Fit Format herausliest und verwendet und welche es ignoriert.


    Ja, das war jetzt vielleicht etwas sehr fachlich, aber Du hast gefragt, weshalb Fit-Dateien auf Deinem Outdoor Handheld Verwendung finden und um diese Fragen zu beantworten, muss man das Format nun mal beleuchten. Das hat auch nichts mit Klugschei%&erei zu tun.


    Man könnte auch darauf verzichten und die Settings im XML-Format textbasiert speichern, oder wieder ein proprietäres binäres Format verwenden, aber offensichtlich wird das von Garmin selbst bei vielen Outdoor-Handhelds nicht (mehr) gemacht und wir User müssen es nehmen, wie es kommt.


    Ich nehme an, dass Garmin bei seinen Outdoor- und Sportgeräten eine gewisse Vereinheitlichung anstrebt, jetzt nicht von der Oberfläche her, aber zumindest von den intern verwendeten Datenstrukturen, was ja auch Sinn macht, weil man dann bestimmte Codekonstrukte durchreichen kann.

    Nun habe mir Deine Links angeschaut. Es ist wie beschrieben nun mal doch wie vermutet und der Name FIT, eigentlich die Abkürzung für Flexible and Interoperable Data Transfer doch sich sinnigerweise auf die Erfassung von Fitnessdaten diverser Zusatzsensorik bezieht.

    Standard hin oder her, für die Nutzung, Auswertung, Speicherung reiner Goeokoordinaten wird das GPX Format als XML Datei schon viel länger verwendet und ist für die breite der Navigationsgeräte und diverser Apps ohne Sportdatenerfassung der Standard.

    Und unser Jörg mit dem GPSmap66 kann auch drauf verzichten.

    Du, mir geht's hier nicht um eine Meta-Diskussion :saint: , sondern ich habe lediglich eine Mutmaßung geäußert, wie die vom Fragesteller gesichteten Fit Dateien auf seinem GPSMap66 gelandet sein könnten.


    So ganz falsch scheine ich mit meiner Mutmaßung wohl auch nicht zu liegen, denn auf dem GPSMap werden Fit Dateien für alles Mögliche vewendet. Unter anderem zum Speichern der Geräte-Settings als auch als Container für 'Courses'.


    GPSrChive GPSMAP 66 - Files & Folders


    Mir selbst ist es völlig egal, welches Format wer aus welchen Gründen auch immer vorzieht und nutzt. Als User habe ich eh keinen Einfluß darauf und damit bin ich hier auch raus.


    Dass der User Jörg mit dem GPSmap66 drauf verzichten kann, glaube ich gerne, aber die Fit-Dateien scheinen auf seinem Gerät nun mal gelandet zu sein und irgendeinen Grund wird es dafür wohl geben.

    Es ist aber ein etablierter Industriestandard (von vielen). Es wurde Mitte 2010 eingeführt und jeder Hersteller tut gut daran, es zumindest alternativ zu nutzen (selbst günstige China GPS-Logger nutzen das mittlerweile).


    Das heißt nicht, dass es für Enduser erste Wahl ist! Hatte ich ja geschrieben.


    Das Fit File Format ist auch nur ein Container. Es ist nicht zwingend, dort Körperdaten abzulegen.


    Ich schrieb ja nur, dass das Fit Course Format von Garmin - und auch anderen Herstellern - intern auch für reine Navigationszwecke genutzt wird. Und es kann gut sein, dass beim Fragesteller genau diese Auto-Routenkonvertierung aufschlägt, denn er schrieb ja explizit, dass er die Fit Files in einem Folder Namens Course gesichtet hätte.


    Hier kann man das alles nachlesen (direkt ab Quelle sozusagen):


    File Types | FIT SDK | Garmin Developers

    File Types | FIT SDK | Garmin Developers

    T´schuldigung auch wenn du dich wieder angepieselt vorkommen wirst , der Inhalt des Fit Formates ist mir schon klar . Unklar ist mir warum in irgendeinem Ordner Fit-Dateien abgelegt werden obwohl

    ich nicht bewußt irgendwo einen Haken bei Fit gesetzt habe .
    Ich brauche nicht meinen Puls den ich beim Höhenmeter ??? hatte .
    Mein nächstes Ziel ist es die Oberfläche des ST zu bereinigen so dass ich nur noch sehe was ich brauche . Kein Geocatching nix Marine , ich will mich nur beim Wandern nicht verlaufen ...

    Fit wird auch für Routen (Fit File Course Format) verwendet.


    Vielleicht hast Du (GPX) Routen auf Dein Gerät hochgeladen und diese werden dann intern im Fit File Format abgespeichert? Zumindest bei den aktuellen Garmin Bikecomputern wird m.W. so verfahren, die Edges operieren dann direkt auf den Fit Course Dateien, die z.B. Abbiegehinweise in einer standardisierten Form enthalten. Man lädt eine GPX-Datei in den NewFiles Ordner hoch, der Edge importiert diese beim Neustart und konvertiert sie direkt ins Fit Course Format und speichert die konvertierte Fit Datei im Course Folder ab.


    Aber ob die reinen Outdoor-Handhelds das auch so machen, weiß ich nicht.


    Das Fit File Format ist mittlerweile de facto Industriestandard und ist im Gegensatz zu den vielen anderen Formaten genaustens spezifziert. Garmin bietet auch ein SDK an, sodass Entwickler relativ einfach die binären Fit Dateien parsen können. Für Entwickler ist das eigemtlich eine schöne Sache, die etwas dem Wildwuchs entgegenwirkt. Beim GPX-Format gibt es ja viele Derivate, die nicht ganz der groben Spezifikation entsprechen.


    Aber für den Alltagsgebrauch ist das GPX-Format natürlich besser zu handeln, weil man einfach mit einem Texteditor reinschauen und den Inhalt modifizieren kann. Hat alles seine Vor- und Nachteile.

    Wird sicherlich nicht für Jedermann interessant sein, aber für einige vielleicht doch ;)


    Die App wird immer noch weiterentwickelt und manchmal kann es ja ganz praktisch sein, einfache Handouts auf dem Smartphone on-the-fly anzufertigen (sofern man auf dem kleinen Smartphone-Bildschirm dafür Muße hat). Neu hinzugekommen sind unter anderem eine einfache Mapsforge Offline-Kartenunterstützung und erweiterte Lap-Marker Funktionen zu Illustrationszwecken.


    Derzeit noch in der öffentlichen Testversion im Play Store als Beta gelistet, aber ich denke, spätestens Ende der Woche dürfte die App dann auch als finale Version im Playstore verfügbar sein.


    PS: Die App ist nach wie vor frei (werbefrei), enthält keine versteckten Tracker, wenn man von der optionalen Einbeziehung des Google Play Location Service absieht - die Jump-To-Home Funktion verwendet den - und beschränkt sich weiterhin auf die Basisfunktionen einer einfachen GPS-Viewer App.

    Hat sich bei mir und meiner Frau im Zusammenspiel mit den BasicAirData GPS Logger und Locus Map Apps bestens bewährt.


    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|