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

    Also ich habe Dir hier mal ein paar Strava-Segmente zusammengestellt, die jeweils mindestens 1 km lang sind. Die FIT-Files wurden hiermit erzeugt:
    http://gniza.org/segments/
    Eine Anzeige dieser Files z.B. in einem Garmin Edge 810 ist problemlos möglich.


    Kurze Frage: Ich sehe in jeder Beispieldateien einen recht kurzen Track, der aus einem Segment besteht. Ist das richtig? Oder sollte man mehr sehen?

    Sehe ich auch so. Das ist ein Outdoorgerät für Wandern, Radfahren, Geocachen und meinetwegen auch Kajakwandern. In dem Moment wo ein Kurs und die Abweichung davon nötig ist, hat man hoffentlich was Adäquates an Bord.

    Wie soll der Kompass in der App funktionieren, wenn es keinen Sensor gibt :confused:


    Wenn der Entwickler schlau war, bewegt sich da maximal was in Bewegung, weil man dann die Richtung aus der Positionsänderung ableiten kann. Aber so wie ich die 0815 Software auf den Smartphones kenne, wird einfach nur die API für den magnetischen Sensor ausgelesen. Und wenn der fehlt geht es halt nicht.

    Garmin's Firmwareentwicklung im Outdoorbereich tickt so:


    * Es wird Wert auf eine halbwegs einfache Bedienung gelegt.
    * Es wird Wert auf eine gute Positionsgenauigkeit gelegt.
    * Navigation beschränkt sich auf "active routing" oder die Gummiband-Navigation


    Alles andere ist nur dabei, weil es auf der Verpackung stehen muss, bzw weil es mal so war. Insbesondere die Datenfelder sind einmal entwickelt worden, ohne sie genauer zu testen oder zu hinterfragen. Bei offensichtlichen Fehlern braucht es schon einen anhaltenden Sturm der Entrüstung, damit nachgebessert wird. So geschehen bei den Höhenmetern im Aufstieg.


    Alles in allem ist die Firmware grottenschlecht. Allerdings, und das ist der Grund warum man ein Garmin kauft, hält das Gerät in Notsituationen, was es verspricht. Mein anfängliches Statement war kein Flachs. Bei Nebel, Schneesturm und White Out will man nur noch ein GPS Gerät haben, das unter diesen Bedingungen nicht die Grätsche macht und einen mit relativ primitiven Mitteln, ans Ziel bringt. Wenn jeder Schritt Mühe kostet, die Sicht keine Kante mehr erkennen lässt, hat man keine Ressourcen frei, um sich mit Kurs und Winkel zu beschäftigen. Der Zeiger, die Richtung und die Position auf einer guten Karte ist wichtig. Und das muss sich kurz mit einem Blick alle paar Meter kontrollieren lassen. So mies die Firmware ist, das funktioniert.


    Ich will euch hier nicht den Spaß am theoretischen Exkurs verderben. Nur in der in der Praxis, mit diesen Geräten, hat er wenig Sinn.


    Danke noch für den Tip mit QMapShack das schaue ich mal an, dann kann ich zumindest die Punkte richtig schieben aber bei der Auswertung werden die verschobenen Punkte ignoriert.


    Da muss ich dich enttäuschen. QMapShack ist, was das Türken von Tracks angeht, recht radikal. Wenn Du die Trackpunkte verschiebst kommt ein Track ohne Zeitmarken heraus. Die Höhendaten werden durch die aus dem geladenen Höhenmodel ersetzt. Wenn keine geladen sind, gibt es auch keine Höhendaten. Der Track verliert somit seine Eigenschaft als Aufzeichnung und wird zum Planungstrack.


    Du kannst einfach Punkte markieren und dann verstecken. Da jedes Element in QMS eine Änderungshistorie hat (solange es nicht in einer GPX Datei gespeichert wird), kann man das auch schnell rückgängig machen.


    Ich habe bei Aufzeichnungen in den Bergen öfters mal eine gerade Linie dabei. So ist es halt. An einigen Stellen kann man mit einem GPS keine Position bestimmen. Und dann ist mir eine gerade Linie, die das anzeigt, immer noch lieber als irgendein Pfusch.

    Du wirst es nicht gerne lesen, aber die Punkte löschen ist der einzige vernünftige Weg. Wenn Du anfängst die Punkte zu verschieben, dann brauchst Du kein GPS sondern kannst den Track gleich mit der Hand malen.


    Also entweder mit dem Fehler leben oder die Punkte löschen. Einige Programme (z.B. QMapShack) können die Punkte unterdrücken. D.h. sie bleiben erhalten, tragen aber nicht zur Auswertung bei.

    Was ist eigentlich an den STRAVA Dateien so besonders?


    Ich habe auch noch einen Aufruf auf meiner eigenen Mailingliste. Ich werde das mit STRAVA mal auch dort erwähnen.

    Hi,


    vielleicht schon aufgefallen: QMapShack kann Garmins FIT Dateien inzwischen einlesen.


    Wir würden gerne für den Code einen Unit Test definieren. Für die, die nicht Software entwickeln: Das sind automatisierte Tests mit denen man sicherstellt, dass sich kein Fehler einschleicht.


    Hierzu benötigen wir FIT Dateien als Testinput. Wir haben nur ein Gerät und das zeichnet nur die absoluten Basics auf. Ideal wäre eine echte Männeraufzeichnung mit allem möglichen Sensoren angeschlossen.


    Wenn jemand so eine Aufzeichnung hat und zur Verfügung stellt sollte folgendes klar sein: Die Aufzeichnung wird Teil der öffentlichen Codebasis von QMapShack, ist also von jedem einsehbar.


    Deswegen ist es besser eine kleine Testaufzeichnung zu machen. Also einmal um den Nachbarblock. Den Herzsensor kann gerne der Hund tragen. Hauptsache so viele Dinge wie möglich sind dabei. Der eigentliche Wert ist egal. Und auch mal zwischen drinnen das Gerät aus- und anschalten. Oder mal einen Sensor ausfallen lassen.


    Schön wenn sich jemand findet, damit wir den Code besser machen können.


    Oliver

    Ich frage mich ja bei dem ganzen Thread, wie ich am Wochenende bei Schneetreiben und Nebel überhaupt wieder in die Hütte finden konnte?! Lag vielleicht daran, dass ich weniger über die Theorie nachgedacht habe, sondern mit Hilfe meines Garmins einfach von einem Punkt zum nächsten gelaufen bin.


    Ich meine deswegen benütze ich ja ein GPS mit Kompass. Ich habe das Gefühl hier werden Probleme aus der klassischen Navigation einem Gerät übergestülpt, das aufgrund seiner Konzeption den Kern dieser Probleme nicht mehr kennt. Schließlich sind die aktuelle Position und die Zielkoordinate bekannt. Damit auch der Winkel, wenn dieser überhaupt noch interessiert. Eigentlich will man nur wissen, ob die Richtung stimmt.


    Bei (aero-)nautischen Anwendungen gibt es sicherlich noch höhere Anforderungen. Aber mal ganz ehrlich? Nehme ich dann ein Outdoorgerät von Garmin in die Hand? Besser nicht.


    Um es kurz zu machen: Ich würde bei Garmin's Outdoorgeräten nicht versuchen in die Kompassseite mehr hineinzuinterpretieren als drinnen steckt. Hier geht es einfach nur darum vom aktuellen Punkt zum Ziel zu kommen. Die Gummibandlinie hilft hier noch am meisten. Mit irgendeiner DIN hat das wenig zu tun. Zumal Garmin ein amerikanisches Unternehmen ist, das Deutschland nur als Marktzahl wahrnimmt. DIN sagt denen nix. Und auch bei den Datenfeldern ist Vorsicht geboten. Ich glaube außer der Uhrzeit gibt es keines, über dass man sich bei näherem Hinsehen nicht wundert.

    Es bleibt ja auch noch immer die Kommandozeile. Der ganze Schmarren mit dem Tool in QMapShack kommt ja nur daher weil Windows mit


    Code
    gdalbuildvrt My_Map_Name.vrt path1/*.hgt

    überfordert ist. Und die Windowsbenutzer mit:


    Code
    for %f in (*.hgt) DO echo %f >> hgt_list.txt 
    gdalbuildvrtMy_Map_Name.vrt -input_file_list hgt_list.txt


    ;)

    Das ist nicht so schön. Ich habe leider mit OS X überhaupt keine Erfahrung und der Ivo, der sich um OS X kümmert, ist wohl erst mal 2 Wochen nicht erreichbar.


    Prinzipiell muss gdalbuildvrt im Pfad sein. Wie das auch immer in OS X gelöst wird. QMapShack ruft einfach nur gdalbuildvrt auf und wenn es nicht im Pfad ist, kann es nicht funktionieren. Ich hätte erwartet, dass dies bei der Installation alles automatisch gemacht wird. Wenn nicht, dann würde ich Dich bitten einen Bugreport hier einzustellen:


    https://bitbucket.org/maproom/…es?status=new&status=open


    Du kannst dabei auch gerne auf das Forum referenzieren, dann ersparst Du dir das Wiederkäuen von Information. Ivo wird sich dann so schnell wie möglich um das Problem kümmern.

    Naja, eigentlich war schon immer >=5.4 aber es sind ein paar Fixes im Code, die das umgehen. Jetzt ist was zu den Systempfaden hinzugekommen, was es erst bei 5.4 gibt und sehr praktisch ist. Das lässt sich auch so nicht anders machen, sprich der Pfad wurde früher nicht abgefragt, sondern fest angenommen.


    Zumal es schon Qt5.5 und Qt5.6 in den Startlöchern steht. Das ist halt immer das Kreuz mit den Debian-basierenden Linuxen, die mit ihren Paketen laufend hinterher hinken.

    Bei openmaps.eu werden Garmin Karten mit DEM angeboten. Entweder die benutzen die Garmin Tools oder die haben herausgefunden, wie man die DEM Daten kodieren muss. Und einen Copyrightverstoß sehe ich hier aktuell nicht. Also halt mal den Ball flach.

    Alternativ kann man die opentopomap auch in einem sehr begrenzten Rahmen als Rasterkarte auf das Gerät bringen. Das benötigt aber ein wenig Geschick mit diversen Tools, die nicht gerade auf DAU Benutzung gebürstet sind.


    Aber mal aus der praktischen Erfahrung heraus: Die Schummerung ist bei großen Flächen auf dem PC schon sehr angenehm. Also dort immer gerne. Auf dem Gerät nimmt sie Brillianz aus der Karte, so dass diese bei schlechten Lichtverhältnissen auch schlechter ablesbar ist. Deswegen wird die Schummerung dort oft nach einem anfänglichen "Hui" wieder ausgeschaltet. Zumal der Effekt sich bei dem kleinen Display sehr in Grenzen hält.