Beiträge von Carsten

    Zitat von "consultancy"

    Für meine Wandertour in den Bergen suche ich einen preiswerten Garmin, der auch die Höhen im tracklock speichert. So kann ich anschließend in ttqv im trackreplay die Wandertour nacherleben mit den exakten Höhenmetern.


    Mein Garmin 12 leistet dies nicht. Welche preiswerten Geräte können dies? Bereits der Forerunner, Geko oder eTrex? Auf der Garmin homepage fand ich hierzu nichts!


    Geko201. Der geht hervorragend effektiv mit seinen 10.000 Trackpunkten im Automatik Modus um, und auch die SavedLogs enthalten weiterhin die Höheninfos. Wenn es wirklich gebirgig wird, wäre ggfs. der GEKO301 anzuraten, der liefert durch sein Barometer auch bei schlechten Empfangsbedingungen noch oder nur Höhenaufzeichnungen. Im Gebirge ist die GPS Höhe alleine oft sehr ungenau, wegen Mehrwegeffekten und weil nur sehr wenige Satelliten sichtbar sind.


    - Carsten


    Nein, das geht nicht, weder durch Anpassungen an Pathaway, noch durch irgendwelche Konverter. Es gibt ein GPS Bundle von Kirrio für den TungstenE, aber der Ansatz lässt sich nicht ohne Weiteres auf Pathaway übertragen, das ist zu aufwendig.


    - Carsten

    Zitat von "M@rs"

    Hallo,


    Dann will ich unbedingt die Positionsdaten vom Datalogger meines Royaltek GPS-Empfängers in der Karte in Pathaway als zurückgelegte Strecke anzeigen lassen.
    Man kann da die .txt Logdatei in das .nmea Format umwandeln. Soweit ich weiß muss man die NMEA-Datei an einem virtuellen COM-Port "anschließen".
    Aber wie mache ich das auf dem Palm mit Pathaway und auf dem PC mit ttqv z. B.?


    Auf dem Palm geht das nicht, den virtuellen COM fürs Trackreplay gibts nur auf PPCs. Du kannst die NMEA Datei in TTQV importieren, dort lässt sie sich auch wieder als Track nach Pathaway exportieren.


    - Carsten

    WAAS ist zur Zeit im Regelbetrieb und wird gelegentlich auch von Empfängern in Europa empfangen, allerdings kriegen in Garmin Empfänger in letzter Zeit bei ihren Firmwareupgrades beigebracht, den WAAS Satelliten zu ignorieren, wenn sich der Empfänger in Europa befindet.



    Momentan findet der Übergang vom ESTB zu EGNOS statt. Das ist aber kein schleichender Übergang. ESTB Signale werden zur Zeit nur vom Satelliten IOR gesendet. Die taugen aber nicht viel und sind in Zentraldeutschland eh nur schwer zu empfangen. Auf den neuen EGNOS Satelliten AOR-E, ARTEMIS und IOR-W/F5 werden zur Zeit die Transponder getestet und da gibts immer mal ein paar Signalfragmente, aber nichts Brauchbares. Dieses Verhalten bringt die Empfänger schonmal etwas durcheinander, daher können die Satelliten schonmal kommen und gehen und an falschen Stellen im Skyview auftauchen.


    Da der gesamte EGNOS Signalsatz fast 10min zur Übertragung braucht, ist das relativ mühsam. Vorläufig würde ich empfehlen, WAAS in den Garmins abzuschalten - es kostet nur sinnlos Batterie und viele Empfänger werden auch beim Userinterface etwas zäher.
    Wenn es soweit ist, wird man es schon erfahren ...


    - Carsten Kurz

    Der Tungsten E hat keine serielle Schnittstelle mehr. Die Kopplung an Garmins und andere GPS Empfänger ist daher nicht möglich.
    Auch über USB geht das nicht, weil die USB Schnittstelle des T-E ausschließlich für den HotSync ausgelegt ist.


    Das Kirrio Teil faked einen seriellen Port - das funktioniert aber wohl ausschließlich mit der mitgelieferten Michelin Software.


    Ciao - Carsten

    Ist leider etwas kompliziert.


    Streng genommen handelt es sich um zwei verschiedene Bugs im T3.
    Der eine, forced HardwareHandshake, lässt sich mit der Brücke am Stecker beheben. Leider gibt es noch einen Bug, der den Sendepuffer betrifft, der lässt sich nur per Software beheben. Theoretisch können die Programmierer von Pathaway, GPilotS und CETUS das innerhalb des Programmes regeln. Aber ich kann nachvollziehen, daß man nicht um einen derartig derben Bug des PalmOS herumprogrammieren will ...


    Ich stehe seit mehreren Wochen in Kontakt mit Palm bezüglich dieses Fehlers. Leider ist es seit der Trennung von PalmOne und PalmSource etwas schwierig geworden, jemandem dort die Schuld eindeutig zuzuweisen. Nicht jede Kombination von GPS Empfänger und Software ist von dem Problem betroffen - mit GPilotS und einem Geko z.B. treten keine Probleme auf. Das liegt an den unterschiedlichen Protokollvarianten der Empfänger und der unterschiedlichen Art der Programme, den Sendebuffer zu bedienen. Prinzipiell betrifft das Problem auch Magellans, denn auch diese werden mittels Magellan Protokoll bidirektional bedient.
    Ob das Problem mit meinem SporTrak auftritt, muss ich noch testen.


    Fazit: Wer JETZT volle Unterstützung fürs Garmin Protokoll in Pathaway braucht, kommt um den Fix nicht herum.


    Wenn von Seiten Palm nicht kommt, werde ich den Fix mit meinen T3 Kabeln bundlen, vermutlich kostenlos.


    - Carsten Kurz, http://www.gpskabel.de

    Also, es ist definitiv ein Bug beim Tungsten T3, der sich mit einiger Sicherheit irgendwann mittels Patch beheben lässt. Scott Northmore ist informiert und hat das an den Palm Support weitergeleitet.


    Vorläufig ist das Garmin Protokoll auf dem T3 nur mit einer Kabelmodifikation zu regeln, die glücklicherweise mit einiger Sicherheit keine Spätfolgen zeitigen wird, weder mit späteren Palms, noch nach einem ggfs. verfügbaren PalmOS Patch. Ich habe die TouraTech Technik informiert, von dort werden vorläufig nur modifizierte Kabel rausgehen.


    Bei Pathaway verhindert der Bug den Austausch von Wegpunkten/Routen/Tracks, sowie die Verwendung des seit kurzem ebenfalls unterstützten Garmin PVT Protokolls (Einstellung GARMIN-GARMIN) für die Echtzeitnavigation. NMEA läuft ohne Probleme, weil der Bug lediglich das SENDEN von Daten blockiert, nicht den Empfang. Da das Garmin Protokoll bidirektional arbeitet, ist es auf Empfang UND Senden angewiesen. Aus dem Grund geht auf dem T3 ohne Kabelmodifikation auch nicht der Wegpunkttransfer mit Magellan Geräten - die arbeiten zwar mit NMEA, aber für den W/R/T Austausch ebenfalls bidirektional.


    Tungsten T und T2 sind von diesem Problem nicht betroffen.


    Weils ein PalmOS Fehler ist, tritt es auch bei anderen Programmen mit Garmin Protokollunterstützung auf, z.B. GPilotS und CETUS GSYNC.
    Auch diese Programme laufen mit der Kabelmodifikation auf dem T3 GPilotS aber aus anderen Gründen derzeit nur in der Version 6.2 in Verbindung mit ldserlib.prc.


    Ciao - Carsten Kurz, http://www.gpskabel.de, support@gpskabel.de

    Etwas esoterisch diese Anwendung, aber ...


    - Entweder komplette Datenbank rüberbeamen - geht sofort mit den üblichen Palm Filemanagern, BeamBox, etc. pp. Hat den Nachteil, daß auf dem Zielgerät die Original Datenbank immer überschrieben wird. PalmOS kennt leider kein systemübergreifendes 'PDB Merge'.


    - Prinzipiell können, zumindest mit GPilotS, zwei Palms sich gegenseitig suggerieren, sie seien ein GPS. Dann kann man auch beliebige Teile der W/R/Ts transferieren. Pathaway hat leider selbst keinen 'GPS Emulationsmodus'. Es ginge aber Pathway als Partner zu Gpilots.


    Dafür braucht man freileich ein Nullmodemkabel Palm-Palm. Pathaway könnte auch über IR connecten, aber leider nicht GPilotS.



    - Carsten

    Damit der Tripmate mit normalen NMEA Anwendungen läuft, braucht es nur ein spezielles Kabel. Das muss einerseits den Receiver einschalten können und andererseits ein Autoinit vornehmen.


    Das funktioniert an Notebooks ebenso wie an PDAs.


    Ciao - Carsten

    Die von Andreas gepostete Selbstbaulösung kann man auch recht einfach bidirektional gestalten, mit einem zweiten Transistor für die Sendeleitung.


    Diese Transistoren erledigen die Pegelwandlung und Invertierung des Signals.


    ABER: Die SONY Specs für die Clie T/SJ/SL/NR/NX Schnittstellen sind ziemlich hart.
    Wer mit dieser einfachen Variante arbeitet, knallt 4.1 Volt auf die 3.3 Volt Eingänge des Clie. Außerdem schreibt Sony vor, daß nur dann Pegel auf dem Interface des Clie liegen darf, wenn der Clie mit DTR anzeigt, daß die Schnittstelle geöffnet ist.


    Auf gut Deutsch: Man riskiert, sich den seriellen Port seines Clie mit dieser simplen Transistorlösung zu zerschießen. Wenn das passiert ist, ist definitiv Essig mit GPS am Clie - es gibt dann keinerlei Reparaturmöglichkeit, denn die Schnittstellensignale liegen direkt am Prozessor an.


    - Carsten

    Wir reden über zwei verschiedene Dinge:


    Die Fremdversorgung eines seriellen Clie T/SJ/SL/NR/NX HotSync Kabels über eine Batterie o.ä. funktioniert mit allen Clie Modellen, also auch dem SL. Genauer gesagt ist das vorläufig die einzige Möglichkeit, den SL überhaupt mit einem GPS zu verbinden.


    Einige Leute sparen sich die zusätzliche Batterie, indem Sie den Akkuausgang des Clie anzapfen. Das geht aber nur, weil diese Clies - SJ, T, NR, NX da genügend Saft zu Verfügung stellen.


    Der SL liefert dort nur 3 Volt. Das ist auch der Grund dafür, warum meine Clie - GPS Kabel nicht mit dem SL funktionieren, die brauchen wenigstens 3.5 Volt, laufen aber ohne irgendwelche Modifikationen mit T,SJ,NR,NX Clies.


    Die Verbindungen sind immer bidirektional, egal ob Clie-GPS Kabel von mir oder fremdversorgtes HotSync Kabel.


    - Carsten

    Thomas Flemming hat meinen Vorschlag schon umgesetzt, DTR UND RTS an der seriellen Schnittstelle zu aktivieren. Damit gehen jetzt übliche serielle HotSync Kabel für Clie T/NR und VISOR für den Waypoint Austausch über Garmin Protokoll mit TTQV (z.B. via GPilotS), wie ich gerade an der Build 2.51.13 testen konnte. Wenn sich mit dieser Version keine Probleme in anderer Hinsicht ergeben, wird die wohl demnächst offiziell gemacht werden. Bitte solange NICHT nachfragen!


    Für Pathaway ist das nicht direkt wichtig, da der Datenbanktransfer zwischen Pathaway und TTQV über andere Mechanismen stattfindet.


    Siehe dazu meine anderen postings zum Clie T/NR GPS Interfacing.
    Die Problematik Clie T/NR bzw. VISOR - GPS Anschluss hat damit auch nichts zu tun.


    Ciao - Carsten

    Wenn ich eine TOP50 in TTQV geladen habe, kann ich immer nur bis zu einer gewissen Grenze zurückzoomen. Das ist dann auch gleichzeitig der größte Ausschnitt, den ich am Stück nach Pathaway exportieren kann (weil ich beim Pathaway Export nur das aktuelle Fenster auswählen kann).


    Das ergibt zwar alles schöne Karten, aber mit maximal so 600-700kByte (8Bit, Kompression).


    Wenn ich einen größeren Ausschnitt wählen will, wie mache ich das?


    Ist der maximal möglich Ausschnitt bei den TOP50 Karten eine Lizenzlimitierung? Warum kann ich für den Pathaway Export nicht analog zum Druckdialog einen beliebigen Kartenausschnitt wählen?

    Es gibt solche Module in unterschiedlichsten Ausführungen, auch direkt zum Anschluss an eine VGA Buchse (die die meisten Notebooks ja noch haben).


    Aber: Die Dinger fallen nicht unter den für Consumer TFTs üblichen Preisverfall, sind also schweineteuer!


    Außerdem sollte man sich darüber klar sein, daß so eine Anschaffung nur dann Sinn macht, wenn man ein besonders helles Modul kauft (wieder teurer), ansonsten ärgert man sich mehr drüber als es nutzt.


    Die meisten billigen Module sind bei weitem nicht so hell wie ein üblicher TFT Bildschirm. Als Anhatlspunkt: Die üblichen TFTs für Büroanwendungen haben so 200-350cd Leuchdichte. Notebook Displays üblicherweise 80-150cd.


    Ein auch bei Sonneneinstrahlung noch gut ablesbares TFT sollte mindestens 250-300cd haben.


    Außerdem sind die meisten dieser Kleinpanels auf Auflösungen von maximal 640/480 bis 800/600 konzipiert - das ist für heute übliche Windows Anwendungen schon etwas knapp. 8"-10" TFTs mit XGA Auflösung sind noch seltener.


    Die an verschiedener Stelle erhältlichen billigen Mini-TFT Videodisplays sind ausschließlich für Videodarstellung geeignet. Die lassen sich zwar an die bei Notebooks verbreiteten S-Video/Cinch Ausgänge anschließen, aber dargestellt wird bei 150.000-300.000 Pixeln Auflösung lediglich Matsch.



    Ich würde vor diesem Hintergrund lieber die Anschaffung eines kompletten Subnotebooks erwägen.


    Ciao - Carsten

    Den HotSync unter NT kriegt man mit den verschiedentlich angebotenen RS232 HotSync Kabeln für T/NR ans Laufen.


    Allerdings wird man darüber mit einiger Sicherheit nicht auf spezielle Features wie MsGate/MemoryStick Leser zugreifen können, das dürfte USB voraussetzen.


    Ciao - Carsten