CW hängt beim Serial Port Scan

[MiK]

Wer war es doch gleich, der gesagt hat, dass seine PDA-Uhr nie genau geht? ;-)

Ich kann diese Abstürze beim Einschalten übrigens nicht nachvollziehen. Das hängt wohl von der Hardware ab. Gibt es denn keine Möglichkeit den Fehler direkt abzufangen? Wird dann beim Lesen keine Exception geworfen?

 

[pfeffer]

Weil meine PDA-Uhr häufig nicht das richtige Datum enthält, nehme ich ja auch die Veränderung der Differenz.

Ich glaube, es wird keine Exception geworfen, sondern die nonBlockingRead kehrt einfach nicht zurück.

Ich habe das Problem auch erst seit dem Firmware-Update des Sirf (und ich habe es schon immer im Destinator). Es tritt in verwandelter Form auf, wenn ich den WM5 eigenen Portsplitter nicht verwende: Dann zeigt CacheWolf im Testfenster nach dem Wiedereinschalten wirre Zeichen an, die so aussehen, als würde die Baudrate nicht übereinstimmen. Aber vielleicht sind es auch binäre Daten des SIRF-Protokolls.

Keins der Probleme tritt übrigens in dem mitgelieferten GPS-Locator auf, obwohl der auch den WM5-Software-Port nutzt.

Wenn jemand eine Idee hat, wäre ich sehr dankbar, sie zu hören.

Gruß,
Pfeffer.

 

[pfeffer]

so, mein Patch zum Testen und Durchsehen anbei.

 

[pfeffer]

Habe weiter daran analysiert, warum sich CW aufhängt, wenn das GPS lief und der PDA aus- und wieder eingeschaltet wird.
Das Problem tritt nur auf, wenn man den WM5-Portsplitter verwendet ("GPS automatisch verwalten"). Die Problemursache ist, dass der serielle Port des PocketPCs nach dem Einschalten nicht automatisch wieder mit den vorher eingestellten Werten (baudrate) bestückt wird. Das GPS sendet fröhlich mit der korrekten Baudrate, aber der PocketPC empfängt nur Müll und erkennt, dass es Müll ist (vermutlich irgendwie an fehlenden Stop-Bits o.ä.). Darauf leidet der Sportsplitter die Daten nicht an die Applikation weiter, meldet aber offenbar, dass neue Daten anliegen. Diese Kombination führt dazu, dass die native Routine nonBlockingRead nicht zurückkehrt, was dazu führt, dass CacheWolf nicht mehr reagiert, weil es kein echtes Multitasking macht.
Der integrierte GPS-Locator löst dieses Problem dadurch, dass es in der Regitry einen Eintrag gemacht hat, so dass es benachrichtigt wird beim Wiedereinschalten. GPS-Locator schließt in diesem Fall den Port und öffnet ihn erneut. Wenn kein anderes Programm gleichzeitig den "Programm-Port" verwendet, dann schließt der WM5-Sportsplitter auch den Hardware-Port und öffnet ihn nach dem der "Programm-Port" geöffnet wird, erneut und setzt dabei die Baudrate wieder korrekt.

Also, die Ursache habe ich jetzt

Jetzt fehlt "nur noch" die entsprechende "Therapie". - Eine Möglichkeit ist, nicht den WM5-Portsplitter zu verwenden :-(

Es ist leider nicht ganz einfach, das nachzuvollziehen, weil WM5 die eingestellte Baudrate im Portsplitter nicht übernimmt, so dass es nichts bewirkt, wenn man dort eine falsche einträgt. Deswegen funktioniert folgender Testweg nicht: in WM5 /Einstellungen/GPS/Hardware eine falsche Baudrate einstellen und "automatisch verwalten" aktivieren. Danach in CacheWolf Einstellungen/GPS/test aufrufen (vorher Port auf den Softwareport einstellen). Eigentlich müsste dann CW abstürzen.

Alternativ kann man CacheWolf auch so zum Nichtmehrreagieren bringen:
Mit einem anderen Programm (zB mit PUTTY) den HardwarePort mit der (falschen Baudrate) öffnen. Dann kann der WM5-Portsplitter den HardwarePort nicht mehr öffnen - und CacheWolf hängt, wenn man den Programm-Port testet.

Falls dieses Problem mit anderen Portsplittern nicht auftritt, sollten wir ausdrücklich in der Anleitung - oder sonst wo, darauf Hinweisen, dass der WM5-Portsplitter zu Abstürzen führen kann. Ist dieser Fehler vielleicht in WM6 behoben?

Mir fällt grad noch was ein: vielleicht kann man herausbekommen, auf welcher Baudrate der COM-Port vom PPC steht, wenn er nicht initialisiert wurde. Wenn man diese verwendet, dann dürfte es keine Probleme geben. Mein Sirf steht auf 57600 baud - welche Baudrate wird bei Euch verwendet? (testen in CacheWolf direkt am Hardware-port) [vielleicht das das Update der Firmware des Sirf zur Veränderung dieser Baudrate gefühert...)

Gruß,
Pfeffer.

 

[pfeffer]

so, mit http://www.gpsmeter.com/download/download.php?fname=./portsplitter_mobile2003_setup.zip wird zwar die Baudrate nach dem wiedereinschalten nicht richtig gesetzt, aber immerhin stürtzt CacheWolf damit nicht ab (sondern meldet "Daten nicht interpretierbar").
Außerdem muss man den immer manuell starten (oder er startet immer das GPS, wenn man den PDA einschaltet).
Schöner wäre also ein Splitter, der nur dann den HardwarePort öffnet, wenn ein Programm einen virtuellen Port öffnet.
Ideal wäre ein Portsplitter, der automatisch den HardwarePort nach Wiedereinschalten neu initialisiert.

Kennt jemand noch weitere kostenlose Portsplitter (die möglicherweise in einem der ganannten Punkte besser sind, als das von mir gerade getestete)?

Gruß,
Pfeffer.

 

[maierkurt]

Ist dieser Fehler vielleicht in WM6 behoben?

Unter WM6 (CE OS 5.2.1623 Build 18129.0.4.5) läuft der Portsplitter ganz geschmeidig.

EDIT: Ohne den Splitter von WM6 lässt sich das interne (oh, meintest Du auch das interne?) GPS gar nicht finden bzw. nicht ansprechen.

Gruß, maierkurt

 

[MiK]

Mir fällt grad noch was ein: vielleicht kann man herausbekommen, auf welcher Baudrate der COM-Port vom PPC steht, wenn er nicht initialisiert wurde. Wenn man diese verwendet, dann dürfte es keine Probleme geben. Mein Sirf steht auf 57600 baud - welche Baudrate wird bei Euch verwendet? (testen in CacheWolf direkt am Hardware-port) [vielleicht das das Update der Firmware des Sirf zur Veränderung dieser Baudrate gefühert...)

Kann man diese Baudrate denn irgends einstellen? Z.B. mit dem Tool Sirftech?

 

[pfeffer]

@maierkurt: ja, ich meine den internen GPSr

@MiK: die Baudrate, auf der der Sirf arbeitet, lässt sich verändern. Ich weiß nur nicht, auf was ich sie einstellen soll.

Gruß,
Pfeffer.

 

[MiK]

@MiK: die Baudrate, auf der der Sirf arbeitet, lässt sich verändern. Ich weiß nur nicht, auf was ich sie einstellen soll.

Auf das gleiche, dass Du auch im Cachewolf eingestellt hast.

 

[pfeffer]

@MiK: die Baudrate, auf der der Sirf arbeitet, lässt sich verändern. Ich weiß nur nicht, auf was ich sie einstellen soll.

Auf das gleiche, dass Du auch im Cachewolf eingestellt hast.

Du hast mich nicght richtig verstanden, da liegt nicht das Problem. Das Problem ist, dass WM5 die Einstellung der Baudrate des seriellen Ports vergisst, wenn man ihn in suspend schaltet und der WM5-Portsplitter (genauso wie ewe) die Einstellung nach dem Wieder-anschalten nicht wieder herstellt.
verstehst Du jetzt, was ich meine?

Gruß,
Pfeffer.

 

[MiK]

Was heißt denn "vergisst"? Irgendeine Baudrate wird dann doch wohl eingestellt sein. Und wenn man genau diese sowieso immer verwendet, sollte es auch nach dem Aus-/Einschalten noch funktionieren, oder?

 

[pfeffer]

ist ist keine >4800 baud mit kleineren muss ich nachher mal testen

EDIT: habe jetzt getestet: es ist auch keine >300 baud. Eventuell ist es auch die Bitanzahl - oder noch wahrscheinlicher vergisst er alle Einstellungen des seriellen Ports (Baud, Anzahl Bits, Anzahl StopBits, Parität...) da kann ich lange testen...

Gruß,
Pfeffer.

 

[pfeffer]

EDIT: Ohne den Splitter von WM6 lässt sich das interne (oh, meintest Du auch das interne?) GPS gar nicht finden bzw. nicht ansprechen.

"lässt sich" - was meinst Du? mit CW nicht? oder auch mit anderen Programmen nicht?
Oder findet CW ihn nur nicht automatisch?

Gruß,
Pfeffer.

 

[pfeffer]

bitte nicht vergessen meinen Patch für das suchen des richtigen Ports zu testen!

danke,
Pfeffer.

 

[maierkurt]

"lässt sich" - was meinst Du? mit CW nicht? oder auch mit anderen Programmen nicht?
Oder findet CW ihn nur nicht? (letztes Wort gelöscht)

Trifft alles zu
Tomtom mag dann auch nicht mehr.

bitte nicht vergessen meinen Patch für das suchen des richtigen Ports zu testen!

Ja, mache ich noch, wird aber wohl vor Montag nichts werden

Gruß, maierkurt

 

[MiK]

so, mein Patch zum Testen und Durchsehen anbei.

Ich habe jetzt nicht jede Codezeile überprüft, aber bei mir läuft der Scan damit einwandfrei.

@Pfeffer: Da es ein paar ICQ-Probleme gab, noch einmal hier: Mit kill() statt close() hatte ich auch keine Probleme mehr.

 

[pfeffer]

@Pfeffer: Da es ein paar ICQ-Probleme gab, noch einmal hier: Mit kill() statt close() hatte ich auch keine Probleme mehr.

ich aber noch :-(

Gruß,
Pfeffer.

 

[pfeffer]

so, habe den Patch nach den Hinweisen von MiK nochmal überarbeitet.

Bitte jetzt nochmal testen.

 

[2cachefix]

ist der Patch auch schon in der NB1456?

 

[MiK]

Wenn die Patches schon im SVN wären, bräuchte man sie hier nicht posten...

Um zu vermeiden, dass durch Änderungen neue Fehler entstehen, posten wir die Änderungen zuerst als Patches hier, so dass sie noch von anderen begutachtet werden können, bevor sie im SVN landen.