@karomue: Mich auch, interessiert mich auch! 
Daß TT die Maus umprogrammiert ist ziemlich eindeutig, denn auch wenn man mit anderen Mitteln die benötigten NMEA-Sentences abgeschaltet hat, läuft Tomtom. Sprich es schaltet zumindest die Sentences wieder ein.
Man bräuchte also mal einen Comport-Monitor a la SysInternals "portmon", um die Kommandos Tomtom->Maus mitzuschneiden. Und eine Liste/Infos über die Möglichkeiten von NMEA. Gibts dafür brauchbare Literatur?
Hallo Anderl,
Deine Lösungsansätze hören sich ja ganz plausibel an.
Bin mal gepannt auf Deine Forschungsergebnisse.
Vielleicht helfen sie uns ja bei der "Bewältigung" von TT5.
Gruß und schönes Wochenende
Andreas
Wenn TT5 die Maus beim Start nach seinem Bedarf programmiert und dann in Ruhe läßt, und die berichtete verschlechterte GPS-Fix-Akzeptanz durch Umprogrammierung behoben werden kann, könnte man sich vielleicht mit einem Comport-Splitter wie GPSGate behelfen, und nach dem TT-Start der Maus sagen, sie soll sich wieder so vehalten wie von TT3 gewohnt.
Ist zwar wiedermal nur ne Krücke, aber... Wenigstens hat es ein gutes: Tomtom zwingt seine User dazu, einen ungeahnten Erfindungsreichtum an den Tag zu legen. 
Vielleicht meinten sie DAS ja mit "Kundenwünsche". Die Kunden wünschten sich einfach mehr Fantasie von dem Programm.
ZitatAlles anzeigenOriginal von Yakumo300delta
Hallo Anderl,
kurze Frage zu dem Thema , hast du eine Erklärung dafür, dass GPSGATE
grün ist !!!!
Nachdem ich TT5 starte und unten die "Patschhand" erscheint GPSGATE gelb wird !!!!
und es dann ewig dauert, bis in TT der Fix erscheint !!!!!!!!!!!!!!!!
Also ich denke schon, dass TT5 da massiv irgendwie am Protokoll was dreht, ferner verliert TT5 sehr oft den Fix, das gabs bei der 3-er nie in dieser Art.
Gruss YAK
Also bei mir (Bluemedia 255) bleibt GPSGate grün (!) nach dem TomTom Start. Und dann nach der Wartezeit von etwa 20 sek (graues Bild) hat TTN dann einen Fix.
Ist GPSGate denn nicht eine Einbahnstrasse ? Wenn ich nämlich den virtuellen GPSGate Ausgang mit GPSMaus Tool anschaue, kann ich an den empfangenen Daten sehen, dass das GPSMaus Tool den GPSEmpfänger nicht rückgesetzt hat. Die Daten kommen dann nämlich ohne (!) die Headerinformation wie sonst nach einem Reset ohne GPSGate. Wenn GPSMaus das über GPSGate nicht kann, kann es doch wohl TTN auch nicht ?
Ich habe mich jetzt mal ein bischen mit TTN5 ausgetobt. Dabei hab ich die unten genannten Tests durchgeführt. Als Hardware standen mir ein iPAQ h2210 und ein Haicom 303MMF im CF-Slot zur Verfügung.
Softwaretechnisch wurde TTN5, VisualGPSce, GpsMaus, GpsGate und Serilot verwendet.
1. Ich habe die Maus auf die Protokolle GGA und GSV im Sekundentakt programmiert. Zur Beweisführung dient das Log "GGA.txt". Dieses Log wurde mit VisualGPSce aufgezeichnet. VisualGPSce war auf den virtuellen Comport von Serilot konfiguriert.
2. Mit den gleichen Mauseinstellungen habe ich nun zuerst VisualGPSce gestartet, die Logaufzeichnung aktiviert und einige Sekunden verstreichen lassen (Logfile "GGA_TTN5.txt"). Anschließend wurde TTN5 gestartet. Um 15:35:29 Uhr erfolgte die erneute Initialisierung der seriellen Schnittstelle.
Erkennbar ist dies am Logeintrag "Internal Beacon" (Logzeile 643). Wobei "Internal Beacon" mehr oder weniger für eine kurzzeitige Störung der Datenübertragung von der Maus zum PDA steht. Dies ist aber als unproblematisch einzustufen, da kein Fixabriss unmittelbar deshalb nachzuweisen ist. Um 15:35:34 Uhr erfolgte in einem Abstand von nur ca. 5s ein Neustart der Maus (ab Logzeile 668). Der Neustart wurde durch TTN5 erzwungen. Acht Sekunden später hatte die Maus wieder einen Fix (Logzeile 708). Dies bestätigte auch VisualGPSce. TTN5 konnte in dieser Konfiguration kein gültiges GPS-Signal ermitteln.
Dies lässt sich auf die fehlenden Protokolle zurückführen. Während des gesamten Durchlaufs konnte keine Veränderung an den Protokollen festgestellt werden. Dies führt zu dem Schluss, dass TTN5 die Maus nicht umprogrammiert.
3. Die Maus wurde umprogrammiert auf die Protokolle GGA, GSA, GSV, VTG. Die Updaterate wurde für alle Protokolle auf 1s gesetzt. Zunächst wurde wieder VisualGPSce gestartet und die Logaufzeichnung aktiviert (Logfile "GGA-GSA-GSV-VTG.txt"). Wie aus dem Logfile zu erkennen ist, sind die Protokolle GGA, GSA, GSV und VTG auf eine Updaterate von jeweils 1s gesetzt worden. Um 16:05:55 wurde die Schnittstelle, bedingt durch den Start von TTN5, erneut geöffnet (Logzeile 371). Ersichtlich ist das wieder durch die Logzeile mit dem Inhalt "Internal Beacon". Entgegen den vorhergegangen Erfahrungen kommt es nun zu keinem Neustart der Maus. Anstelle eines Neustartes verliert aber die Maus den Fix. Auffällig ist, das zwischen der letzten protokollierten GGA-Zeile vor der Schnittstelleninitialisierung und der darauffolgenden GGA-Zeile ein nicht dokumentierters Zeitloch von 3s festzustellen ist. Ebenfalls ist in der Zeit nach der Initialisierung der Schnittstelle durch TTN5 für 1s kein Fix vorhanden. Auch in diesem Durchlauf wurde durch TTN5 keine Änderung an den Protokolleinstellungen festgestellt.
4. In diesem Durchlauf verzichtete ich interessehalber vollständig auf einen reellen GPS-Empfänger (Logfile "Simulator_TTN5.txt"). Anstelle dessen trat GpsGate im Simulatorbetrieb. Mangels freier Comports auf meinem iPAQ h2210 musste ich auf Serilot als Comsplitter verzichten. Ich habe sowohl VisualGPSce als auch TTN5 auf einen virtuellen Port von GpsGate konfiguriert. Als Input für GpsGate wählte ich, wie bereits schon angesprochen, den programminternen Simulator. Die Position für den Simulator wurde mit 48,089N und 11,827E bewusst etwas neben einer Straße gewählt.[Blockierte Grafik: http://mq-mapgend.websys.aol.com/?e=9&GetMapDirect=Gme5diw%2Ca%3A9u12%3B%40%2455-7gh672%26u2%265]
Zuerst wurde GpsGate und dessen Simulator gestartet. Im Anschluss wurde VisualGPSce gestartet und die Logaufzeichnung aktiviert. Erwartungsgemäß tritt in diesem Log keine Störung auf. Trotz des ständig vorhandenen Fix benötigt TTN5 von dessen Start bis zu einer gültigen Positionsanzeige auf der Karte im Mittel ca. 25s auf meiner Hardware. Vom Startaufruf von TTN5 bis zum blauen Willkommensbildschirm beträgt die Zeit immerhin nur 13s. Das bedeutet, dass fast nochmals 12s vergehen, bis TTN5 einen Fix ermittelt, obwohl dieser vorhanden ist. Diese Beobachtung deckt sich auch mit den subjektiven Beobachtungen beim vorangegangen Test. Des Weiteren fällt auf, dass TTN5 die Position erst nach und nach auf die Straße versetzt. Dies lässt sich deutlich durch die bewegte Kartendarstellung erkennen. Das ganze hab ich nochmals in einem kleinen Video (TT5 Fixproblem - Simulator.wmv) dokumentiert.
Bis zu diesem Zeitpunkt kann man also folgendes Feststellungen treffen.
- TTN5 programmmiert die Maus nicht um, benötigt aber zwingend GGA, GSA, GSV und VTG um überhaupt eine gültige GPS-Position definieren zu können.
- TTN5 erzwingt in einer Comportsharingumgebung eine erneute Initialisierung der Schnittstelle. Ob dies zwingend zu einem Neustart der Maus führt, steht offen. Definitiv verliert die Maus aber aus diesem Grund kurzzeitig den Fix.
- Unabhängig von einem vorhandenen Fix benötigt TTN5 nach erfolgtem Start eine m. E. nach erhebliche Zeit bis eine gültige GPS-Position vorliegt.
Es stellt sich nun die Frage, ob man überhaupt in der Lage ist, eine Maus mittels eines virtuellen Comports umzuprogrammieren. Die Antwort auf diese Frage, muss ich momentan schuldig bleiben, da ich keine Möglichkeit habe dies auszuprobieren.
Gruß
Anderl
ZitatOriginal von Anderl
Zuerst wurde GpsGate und dessen Simulator gestartet. Im Anschluss wurde VisualGPSce gestartet und die Logaufzeichnung aktiviert. Erwartungsgemäß tritt in diesem Log keine Störung auf. Trotz des ständig vorhandenen Fix benötigt TTN5 von dessen Start bis zu einer gültigen Positionsanzeige auf der Karte im Mittel ca. 25s auf meiner Hardware.
Anderl
In der gleichen Konfiguration mit GPSGate und Simulator steht bei mir dann kurz vorm farbig werden des Displays noch der Text "Letzes gültiges GPS Signal vor 20 Sekunden". Wie erklärt sich das bei mir ? Den Text sehe ich auf deinem Video nicht, irgend eine Idee? Bei mir vergehen tatsächlich ca. 20 Sekunden vom Programmstart bis zum (simulierten) Fix von TTN (farbiges Display) auf meiner Hardware.
ZitatOriginal von fwsurfer
Anderl
In der gleichen Konfiguration mit GPSGate und Simulator steht bei mir dann kurz vorm farbig werden des Displays noch der Text "Letzes gültiges GPS Signal vor 20 Sekunden". Wie erklärt sich das bei mir ? Den Text sehe ich auf deinem Video nicht, irgend eine Idee? Bei mir vergehen tatsächlich ca. 20 Sekunden vom Programmstart bis zum (simulierten) Fix von TTN (farbiges Display) auf meiner Hardware.
Der Text steht bei mir normalerweise auch. Das Video ist über ActiveSync Remote Display gemacht. Das bremst den PDA zusätzlich aus. Komischerweise wenn Remote Display läuft, dann verschluckt TTN5 dies Meldung???
Gruß
Anderl
ZitatOriginal von Anderl
Der Text steht bei mir normalerweise auch. Das Video ist über ActiveSync Remote Display gemacht. Das bremst den PDA zusätzlich aus. Komischerweise wenn Remote Display läuft, dann verschluckt TTN5 dies Meldung???
Ah ja, dass bedeutet also, TTN erkennt (interpretiert) sofort beim Programmstart einen gültigen Fix vom GPS Empfänger. Die Software ist, warum auch immer, aber so programmiert, dass das nicht sofort angezeigt wird.
ZitatOriginal von Anderl
Es stellt sich nun die Frage, ob man überhaupt in der Lage ist, eine Maus mittels eines virtuellen Comports umzuprogrammieren.
Mein Versuch, die Yak300-Maus durch GPS-Gate mittels GPSMaus umzuprogrammieren, ist jedenfalls fehlgeschlagen. Die Maus sendet die eingestellten Protokolle, immer weiter, auch wenn ich sie abschalte und GPSMaus den "Send"-Befehl gebe. Ebenso konnte kein Reset der Maus durchgeführt werden. Umprogrammieren direkt auf den echten COM-Port geht einwandfrei.
Man kann also davon ausgehen, daß Tomtom in diesem Fall die Maus auch nicht umprogrammieren kann. Ein transparenter Comport-Monitor wäre nützlich, um wirklich festzustellen, was Tomtom tut oder versucht.
ZitatOriginal von Anderl
- Unabhängig von einem vorhandenen Fix benötigt TTN5 nach erfolgtem Start eine m. E. nach erhebliche Zeit bis eine gültige GPS-Position vorliegt.
Bei mir (getestet mit GPSGate-Simulator, der also permanent den sauberstmöglichen Fix liefert) sieht es so aus:
1. Klick auf "Tomtom starten"
2. Rote Patschhand erscheint im Systray
3. 9 Sekunden später geht der Hauptbildschirm auf. Anzeige "Kein GPS-Gerät."
4. 12 Sekunden später erscheint kurz "letztes gültiges GPS-Signal vor 20 Sekunden", dann wird der Screen farbig.
Alternativtest:
1. Klick auf "Tomtom starten"
2. Rote Patschhand erscheint im Systray
3. 8 Sekunden später geht der Hauptbildschirm auf. Anzeige "Kein GPS-Gerät."
4. Ich öffne sofort die "GPS-Einstellungen" aus der Config. Dort steht auch "Kein GPS-Gerät."
4. 12 Sekunden später wechselt der Text sofort auf "Anderes Kabel-NMEA" und die Position wird angezeigt.
Ein Gegentest mit der echten Maus zeigt, daß im Falle von "kein Fix" dort "Kein gültiges GPS-Signal!" steht. Dieser Text erscheint NICHT bei Verwendung des Simulators.
D.h.: die Tatsache, daß im Hauptscreen kurz (ca. 1 Sekunde) "letztes gültiges Signal vor..." steht, heißt NICHT, daß wirklich kein Fix vorliegt. Das dürfte eher irgendeine programminterne Verzögerung beim Aufbau des Screens sein.
Warum Tomtom 12 Sekunden braucht, um das GPS-Gerät zu initialisieren, weiß ich nicht (wird schon irgendnen technischen Grund haben ), aber es dauert definitiv keine 30 Sekunden, bis der Fix vorliegt.
ZitatOriginal von Anderl
- TTN5 programmmiert die Maus nicht um, benötigt aber zwingend GGA, GSA, GSV und VTG um überhaupt eine gültige GPS-Position definieren zu können.
GSA und GSV (Satellites Active und Satellites in View) sind nicht unbedingt nötig. Der Navigon braucht die, aber Tomtom kommt auch ohne aus. Tomtom zeigt bei fehlendem GSA und GSV einfach keine "Sats in view/use" Informationen an.
Tomtom kommt schon mit RMC (Recommended Minimum) alleine aus und zeigt dann Position und Geschwindigkeit. Mit GSV und GSA kommen, wie erwartet, die grauen und blauen Satbalken dazu.
Anstelle RMC kann man auch [GGA oder GLL] und VTC einschalten.
Interessant ist es, nur GSA und nicht GSV einzuschalten. Dann werden die Sats-in-use als blaue Kreise ohne Balken und alle "im Norden auf Horizonthöhe klebend" angezeigt. Klar, die Positionsinfo ist ja im GSV enthalten. GSA enthält nur die Nummern der Sats-in-use.
Mein nächster Test bestätigt, daß TT5 die Maus in der Tat nicht umprogrammiert. Nach Abschalten aller Protokolle per direktem COM-Zugriff (ohne GPSGate) erkennt TT die Maus nicht mehr. Interessant ist, daß sich das "Traffic"-Rädchen alle ~10 Sekunden mal kurz dreht und dann wieder stehenbleibt.
Allerdings - und damit zurück zum Ausgangsproblem - habe ich auch keine Informationen gefunden, ob man an der Maus irgendwelche Empfindlichkeitsparameter o.ä. einstellen kann. Die einzigen Programmierbefehle, die ich gefunden habe, dienen zur Festlegung der Baudrate und Data/Stop/Parity-Bits und der gewünschten Sentences mit Sendeintervall.
Hallo loc,
das bestätigt die ganze Problematik ja jetzt. Es ist ja bei mir in etwa genau die gleiche Zeit, die TTN5 vom Hauptbildschirm bis zu einer gültigen Position benötigt. Sind bei mir meist so 12-15s.
Jetzt mal was anderes. Du sagst du hättest die Steuerbefehle zum umprogrammieren gefunden. Wo und wie und was sind die. Meld dich mal, ich such das nämlich schon ganz verzweifelt.
Gruß
Anderl
ZitatOriginal von Anderl
das bestätigt die ganze Problematik ja jetzt. Es ist ja bei mir in etwa genau die gleiche Zeit, die TTN5 vom Hauptbildschirm bis zu einer gültigen Position benötigt. Sind bei mir meist so 12-15s.
Yepp, hier auch. Wobei diese Zeit mit "Kein GPS-Gerät" verbracht wird, also das Teil wohl aus irgendwelchen Gründen auf die Maus wartet, ein merkwürdiges Delay eingebaut hat, den Port oder die Maus gründlichst resettet oder sonstwas tut. Jedenfalls dreht sich in der Zeit das Traffic-Rad gar nicht, er wird wohl in der Zeit keine Daten von der Maus entgegennehmen.
ZitatJetzt mal was anderes. Du sagst du hättest die Steuerbefehle zum umprogrammieren gefunden. Wo und wie und was sind die. Meld dich mal, ich such das nämlich schon ganz verzweifelt.
Ich kann jetzt so direkt nur für den SiRF-Chipsatz was sagen, den hab ich in meiner Maus und da konnte ich die Programmierkommandos nachvollziehen.
$PSRF100,M,Baudrate,Datenbits,Stopbits,Parity*Checksum
(M=0: Umschalten in Binärmodus, M=1: ASCII-NMEA verwenden)
Bsp.: $PSRF100,1,9600,8,1,0*3C
$PSRF104 gibt dem Empfänger eine Position für schnelleren Fix vor und hat Befehle zum Reset der Maus.
$PSRF103,S,M,R,C*Checksum schaltet die Sentences ein und aus.
S:Sentence (00=GGA, 01=GLL, 02=GSA, 03=GSV, 04=RMC, 05=VTG)
M:Mode (00=Set, 01=Query)
R:Rate in Sekunden, 00=aus
C:Checksumme senden (01:ein, 00:aus)
Umfangreiche Details hierzu hier:
