Beiträge von andreas.wernicke

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

    Hallo Klaus,



    du siehst, die Verwirrung wird nicht zwangsweise geringer. --- Jeder vertritt mit Leidenschaft seine Entscheidung, was letztlich ein Zeichen dafür ist, daß die am meisten genannten Lösungen beide sehr gut funktionieren.


    Das geringe Feedback zum Magellan zeigt, daß es offenbar deutlich schwerer für Magellan als für Garmin sein wird, später auch Tips für die tägliche Praxis zu bekommen.


    Das GPSmap 60 Cx/CSx und eTrex Legend Cx/Vista Cx (je mit und ohne Höhenmesser, Kompaß) sind funktional nahezu gleich.


    Die 60er haben die höchstmögliche Empfindlichkeit und die externen Anschlüsse für Serielle und Antenne, kosten dafür aber mehr.


    Die eTrex-Etreme-Modelle haben m. E. eine ausreichend hohe Empfindlichkeit, sind handlicher, haben brilliantere Displays und kosten weniger.


    Der eigentliche Unterschied ist die Bauform. Nimm' beide in die Hand und schau', welches Dir im Preis-/Leistungsverhältnis mehr liegt.


    Hier nochmal mein Artikel zu diesem Thema für Zweiradfahrer:


    http://www.navigation-gps-motorrad.stars-and-wings.de/



    viel Spaß bei der Entscheidungsfindung ;)


    Andreas

    Hallo Klaus,



    > Garmin sagte mir auf Anfrage, daß nicht geplant ist, die kleineren Serien mit Sirf
    > III chips auszustatten, - also werde ich wohl den GPSMAP 60 CX kaufen müssen.


    Das GPSmap 60 Cx ist sicher eines der leistungsfähigsten Handgeräte und in bezug auf SiRFstarIII eine gute Wahl.


    > Gibt es Alternativen?


    Ja, schau Dir mal die aktuellen Cx-Modelle aus der eTrex-Serie an, von Venture Cx, Legend Cx bis Vista Cx: In Punkto Empfangsqualität wirst Du da im Vergleich zum gelben eTrex auch schon eine Rückwärtsrolle machen.


    Die Empfindlichkeit ist nicht so spektakulär wie bei den SiRFstarIII-Modellen, aber in der Praxis hatte ich mit den Teilen noch keine Abrisse, die ich früher mit dem Vista alle naselang hatte (und das Vista war schon besser als das Gelbe).


    Wenn Du die extra Anschlüsse nicht braucht, denselben Aufbau und Funktionsempfang wie die 60er-Modelle für deutlich weniger Geld. Das Pandon zum GPSmap 60 Cx ist das eTrex Legend Cx, und für ein wenig mehr gibt's mit dem Vista Cx noch Höhenmesser und Kompaß.


    Nebenbei, einer der wenigen Unterschiede: Das Display der eTrex-Farbmodelle ist sichtbar brillianter, der Rest sind Fragen der Handlichkeit und Bedienbarkeit. --- Einmal in die Hand nehmen hilft bei der Entscheidung.



    viel Erfolg


    Andreas

    Hallo nochmal,



    ich habe mal alle Tracklogs aus meinem Backup von 1,2 Mbytre geparst und keine weiteren Fehler außer die Nullbytes gefunden.


    Dazu habe ich nochmal alle meine Tracklogs in eine Datei kopiert und aus MapSource in GPX exportiert und geparst, immerhin 4,5 Mbyte, und das fehlerfrei.


    Offenbar erzeugt MapSource valides GPX,


    Auf dem Empfänger können die Dateien Nullbytes enthalten, oder, bei Dir auch defektes Markup.



    viele Grüße


    Andreas

    Hallo,



    > Hast die Karte in einem Lesegerät oder im Garmin gelesen?


    Ich lese die Dateien vom Gerät im Übertragunsmodus.


    > Womit parst Du?


    Als alter SGML-er mußte ich erstmal eine Parser downloaden, weil ich sonst nur Industrielösungen benutze ;)


    Hab' einfach mal expat von James Clark genommen: http://www.jclark.com/xml/expat.html


    Es gibt aber auch Online-Parser für Dokumente, DTDs oder Schemas. Da vergesse ich aber immer die URLs.


    Ansonsten probier's doch mal mit einem validierenden Parser desselben Autors: SP oder so, möglicherweise fixt der Parser die Bugs schon von selbst, und dann mußt Du nur noch Artefakte wie leere Tags entfernen.


    Wie gesagt, ich würde die Zeit auch erstmal in einen Bugreport stecken, denn konformes GPX ist ja in allgemeinem Interesse.



    viel Erfolg


    Andreas

    Hallo,



    > Naja, wie ein anderer User schon meinte: Autorouting ist, wie der Name schon
    > beinhaltet, nur für Autos sinnvoll.


    Ja, da ist was dran :)


    > Es wäre doch so einfach gewesen einen kurzen Weg zu definieren, der für
    > motorisierten Verkehr gesperrt ist.


    Ja klar, aber vielleicht sollte man einfach festellen, daß diese Kartenprobleme schon recht klein sind, und die Hersteller einfach noch lange nicht so weit, solche Details flächendeckend zu erfassen, wo Süd- und Oseuropa noch nichtmal autotechnisch befriedigend abgedeckt sind.


    Mit solchen Details kommt man bei Erfassen auch vom Stöckchen aufs Hölzchen. Übrigens fällt mir da ein, daß auf Gran Canaria solche Durchgänge verzeichnet waren, worüber ich mich wunderte, denn ich mußte mein Rennrad über eine Gehsteigkante heben. Du siehst, es ist schwer allen gerecht zu werden.


    Das der Router einen groben Bug hat, der an jeder ähnlichen Strecke locker reproduzierbar ist, finde ich schon bemerkenswerter.



    viele Grüße


    Andreas

    Hallo nochmal,



    > so dass sich mir schon fast der Verdacht aufdrängt, das Navteq entsprechende
    > Sonderregelungen für Radfahrer vielleicht doch erfasst hat...


    Die Carmerstraße ist ein Einbahnstraße, wobei ich den Radfreigabestatus nicht kenne.


    Wenn das Vista C ein Rad in entgegengesetzter Richtung durch diese Straße routet, was MapSource und Vista Cx ums Verrecken nicht tun, dann würde das alte Vista C eine neue Verkehrsregel besser umsetzen als aktuelle Software und Geräte.


    Nach dem Fußgänger-Bug ist das fast zu glauben, aber ich bin ziemlich sicher, daß die Daten das nicht hergeben. --- Ein ausreichender Gegenbeweis wäre schon eine einzige Einbahnstraße, die in City Navigator erfaßt ist, und in der Fahrräder aber nicht Autos gegen die Einfahrtrichtung geschickt werden.


    Als Gegenprobe kannst Du ja mal testen, ob das Vista C nicht generell Fahrräder auch entgegen Einbahnstraßen schickt.



    Viele Grüße, und Danke für's Mitmachen


    Andreas

    Hallo zusammen,



    um den Fehler einzugrenzen, kann jemand mit einer Speicherkarte < 1 Gbyte mal mit einer Binärsuche über seine *.gpx-Dateien pflügen und schauen, ob er/sie


    1. Nullbytes findet?


    2. mehr als einen Tag <gpx oder </gpx> pro datei findet.


    Ich habe es nur in einer einzigen, der größten Datei mit 303 KByte gefunden. --- Kann es sein, daß da gerade der Active-Log-Speicher voll war und eigentlich eine neue Datei begonnen werden sollte.


    Vielleicht kann die Software bei vollem Trackspeicher die aktuelle Datei nicht fortschreiben, beginnt neu, hat aber keine Regel, wie sie zwei Dateien an einem Tag benennen soll?



    viele Grüße


    Andreas

    Hallo Bernd,



    ich habe mal die dickste meiner Dateien geprüft und als Unregelmäßigkeit 238 Nullbytes in Folge gefunden. An dieser Stelle fehlt auch ein Starttag <gpx>


    XML-Parser stolpern an dieser Stelle und beanstanden fehlende oder überflüssige Tags.


    Tatsächlich kommt das Tag nach dieser Sequenz, und wenn man die Nullbytes eliminiert und den Starttag ergänzt, dann ist das Dokument erstmal valide.


    Also, keine defekten Tags, aber Schluckauf in der Datei und infolgedessen fehlender Tag. Das es sich ja um UNICODE-kodierte Textdateien handelt, kann es jede Zeichenfolge betreffen. Ich denke, das sollte zunächst mal als Bugreport an Garmin gesendet werden.



    viele Grüße


    Andreas

    Hallo Bernd,



    das interessiert mich als Markup-Spezialisten auch besonders :) Hast Du die Dateien mal durch einen Parser gejagt?


    >

    Code
    </trk <trk>


    ETAGC missing. --- Ich habe solche Fehler in 1,2 MByte meiner Tracklogs auf dem Vista Cx nicht gefunden, werde aber mal darauf achten.


    Das sieht danach aus, als ob das XML mit Stringoperationen erstellt oder bearbeitet wurde, ohne Validierung oder baumorientierte Software.



    viele Grüße


    Andreas

    Hallo nochmal,



    > ... ähnliche Unterschiede tauchen übrigens auch bei der Fahrzeugauswahl "Fahrrad"
    > auf. PC-Variante über Savignyplatz/Kantstrasse, VISTA C über Carmerstrasse.


    Vista Cx in beiden Berechnungstypen über Savignyplatz/Kantstr. --- Das bedeutet, daß beim Vista C der Fußgänger richtig, der Radfahrer aber falsch geroutet wird?


    > "Leider" sitze ich hier in Köln und kann mir die Beschilderung der Carmerstrasse
    > nicht ansehen, aber vielleicht könnte 'mal ein Berliner aufklären, ob diese Strasse
    > für Radfahrer in beide Fahrtrichtungen freigegeben ist, oder nicht...


    Das ist unerheblich, weil die Straßendaten diese Regel nicht implementieren, zumal viele dieser Änderungen ja auch sehr neu sind.


    Du kannst es für jede Straße leicht testen: einfach eine Testroute mit zwei Punkten in der Carmerstraße erstellen, Routen, nochmal umgekehrt Routen. Dann weißt Du, ob es in CN8 eine Einbahnstraße ist, und ob diese für den Fahrzeugtyp relevant ist.


    Auf den o. g. Fehler hat das aber keinen Einfluß, denn Fußgänger und kürzeste Strecke funktioniert in MapSource und neuen Empfängern einfach nicht.



    viele Grüße


    Andreas

    Hallo,



    > Berechnung P1 bis P2 im VISTA C (CN8):
    > schnellste Berechnung
    > beste Route
    > jeweils über Grolmanstrasse und Savignyplatz.


    Das habe ich mir gedacht. Die "alte" Routergeneration arbeitet einwandfrei, die Neuentwicklungen, die in MapSource und neueren Geräten eingeflossen sind, beispielsweise den x-Modellen oder dem Quest 2, sind leider fehlerbehaftet.


    Danke für's Testen.



    viele Grüße


    Andreas

    Hallo zusammen,



    > "....The EGNOS system is now ready to broadcast, as of the beginning of July 2006,
    > a continuous signal, including the so-called "Message Type 0/2" allowing to offer a
    > graceful transition from ESTB...."


    Das war auch mein Verständnis daß es immer noch um das EGNOS System Test Bed, und insofern kann von "voll einsatzfähig" im Sinne des Endbenutzers nach wie vor nicht die Rede sein. --- Was ja nicht heißt, daß man es nicht spaßenshalber mal ausprobieren kann.


    "The ESTB Signal in Space is intended to be used in EGNOS for testing and is NOT an approved or certified source of navigation or aircraft guidance information."


    Ich hebe das nur deswegen hervor, weil das Einschalten im Normalbetrieb immer noch zu Positionsproblemen führen kann.



    viele Grüße


    Andreas

    Hallo Bunav,



    danke für die schnelle Antwort, und das passiert auch auf dem Vista Cx, nur daß man da den Berechnungstyp auch bei der Einstellung Fußgänger noch umstellen kann.


    Meine Frage: was passiert denn, wenn Du die Strecken als Fußgänger auf anderen Geräten wie Deinem GPSmap 76 Cx routest?


    Ich vermute, daß der Fehler auch in der Firmware der meisten aktuellen Empfänger enthalten ist.


    Ich teste gerne nochmal das "alte" Vista C, denn früher ist mir das nie aufgefallen.



    viele Grüße


    Andreas

    Hallo Felix,



    > Ich verstehe es trotzdem nicht ganz, wenn ich in den Bergen wandere, dann hat
    > es ja keine Strassen und es wäre angenehm, wenn er mir einfach rechts oder
    > links sagen würde.


    Du beziehst Dich auf Luftlinienrouten?


    Da kündigt er die Annäherung an eine Wende an, und wenn Du die Datenfelder entsprechen günstig einrichtest, dann bekommst Du


    eine Winkelangabe nach rechts oder links bezogen auf Deine Blickrichtung,


    oder Du verwendest den kleinen roten "Zeiger".


    Ich verwende immer zwei Datenfelder, Entfernung zum nächsten Zwischenziel, Entfernung oder Reisezeit zum Ziel, je nach Bedarf.



    Probiers mal


    Andreas

    Hallo Bunav,



    > nein, von mir nicht nachzuvollziehen.


    Das hat mich stutzig gemacht, denn ich habe wenig Zweifel an meiner Installation und an den zuvor beschriebenen Einstellungen:


    Die Ursache des Problems ist nach erneuter Beobachtung, daß MapSource beim Umstellen auf Fußgänger den Berechnungstyp zwar ausblendet, aber tatsächlich den zuletzt verwendeten Berechnungstyp verwendet.


    Beispielsweise P1 nach P2:


    War zuvor kürzeste Entfernung eingestellt, muß ich als Fußgänger 652 m über den Steinplatz latschen,


    war zuvor kürzeste Zeit eingestellt, brauche ich nur 464 m über Savignyplatz gehen.


    Damit ist das Routingergebnis zufällig und nicht wie zu erwarten reproduzierbar.


    Hinzu kommt, daß die für den Fußgänger kürzeste Entfernung irrwitzigerweise dann berechnet wird, wenn für den letzten beräderten Fahrzeugtyp nach kürzeste Zeit optimiert wurde.


    Fehlerbeschreibung:


    Bei Fußgänger wird der Berechnungstyp nicht explizit gesetzt.


    Für Fußgänger findet der Berechnungstyp kürzeste Entfernung bei vorheriger Einstellung nicht die kürzeste Strecke und übersieht im Beispiel 1 zwei kürzere Lösungen über Grolmanstr. und Knesebeckstr. --- Die kürzeste Entfernung wird für Fußgänger nur gefunden, wenn vorher kürzeste Zeit eingestellt wurde. Vermutlich, da Fußgänger auf allen Wegen mit 4,7 km/h gehen und beide Berechnungstypen bei dieser Maximalgeschwindigkeit dasselbe Ergebnis liefern.


    Der Fehler tritt auch bei Umkehrung der Routen auf, Ampeln oder Fußübergänge gibt es in den Beispielen nicht.


    Bitte testet das auch mal auf einem Empfänger, denn auf meinem Vista Cx passiert der gleiche Unfug.



    Danke und viele Grüße


    Andreas

    Hallo Sirius,



    > Ich habe bemerkt, dass er mich nicht an Sackgassen vorbeiroutet.


    Ja, das ist richtig, auch wenn es kein Routingfehler sondern ein Problem des Kartenmaterials ist:


    Die Quelldaten sind primär auf KFZ ausgerichtet, und Übergänge wie abgesenkte Bordsteine oder Fußgängerdurchgänge sind sicher ganz oft nicht erfaßt. Das Kartenmaterial repräsentiert einfach den Verlauf der Nebenstraße, und da die vor Einmünden in die verkehrsreichere Straße ohne Krezungsknoten endet, kann der Router auch keine Verbindung herstellen.


    Ähnliche Probleme gibt es auch bei kleinen Fußgängerbrücken, Parks etc.



    viele Grüße


    Andreas

    Hallo,



    > Na ja, du liest aber meine Posts anscheinend auch nicht richtig. [...] Also, erst
    > lesen und dann einen schwachen Kommentar loslassen


    Das ist unzutreffend: Ich lese Texte stets vollständig und kann meine Beiträge einigermaßen guten Gewissens mit meinem Namen unterschreiben.


    > Es gilt allerdings als nicht sehr freundlich, sich nicht vor Absetzen solcher Fragen
    > selbst per Internet informiert zu haben. Eine Suche auf http://www.zoll.de hilft dir weiter


    Genau das ist ein Punkt, vielleicht folgst Du hier erstmal mhitlzers Vorschlag?


    Darüber hinaus ist noch die Frage, ob man solche Foren für die Organisation von Kaufabwicklungen und Importgeschäften zum eigenen Vorteil nutzen sollte?



    Grüße


    Andreas

    Hallo zusammen,



    die wichtigsten Änderungen sind immer die nicht dokumentierten. Insbesondere wenn sie zu Problemen führen:


    Seit MapSource 6.11.1 kann man in der Voreinstellung Routing für Fahrzeug = Fußgänger keinen Berechnungstyp mehr wählen.


    Das ist eigentlich sinnvoll, denn Fußgänger laufen theoretisch auf allen Straßen gleich schnell und wollen überwiegend den kürzesten Weg haben. --- Die früheren Einstellmöglichkeiten sorgten für Verwirrung, wenn man von KFZ auf Fußgänger umstellte und den Berechnungstyp für KFZ typisch auf schnellste kürzeste Zeit beließ.


    Das Problem ist jedoch, daß MapSource trotzdem auf Basis der typischen Fahrgeschwindigkeiten nach kürzeste Zeit routet, und den Fußgänger selbst bei einfachsten Aufgaben über sinnlose Umwege führt, beispielsweise:


    P1 zu P2 mit 652 m in 8:12 min, obwohl 464 m in 5:56 min möglich sind:
    Pedestrian-routing-problem-1.gdb


    P3 zu P4 mit 613 m in 7:45 min, obwohl 373 m in 5:07 möglich sind, siehe:
    Pedestrian-routing-problem-2.gdb


    Bei diesen trivialen Aufgaben halte ich das für einen Fehler, zumal im Beispiel 1 zwei bessere Wege übersehen werden. Beispiel 2 zeigt, das das ursächlich an der für Fußgänger nicht sinnvollen Bevorzugung von schnellen Hauptstraßen liegt.


    Übrigens routet das Vista Cx hier auch denselben Müll, doch immerhin erkennt es für P1 bis P2 die kürzere Strecke, wenn man nach kürzere Zeit routet ;)


    Kann das jemand nachvollziehen oder erklären. --- Ansonsten schreibe ich einen Bugreport an garmin.de.


    Nachtrag: Der Fehler besteht bei den Cx- und HCx-Modellen. Garmin hat es unterlassen, die Auswahl der Optimierung für Fußgänger zu unterdrücken, wie es in MapSource realisiert ist. --- Lösung: Bis der Fehler behoben ist, darf man für Fußgänger nur die Optimierung auf Kürzere Zeit verwenden.



    viele Grüße


    Andreas