UCX "hängt" bei Interfacewechsel

[DF1LX]

Hallo,

ich habe folgendes beobachten können:

1. WinKeyer angeschlossen -> funktioniert
2. WAG mitgemacht
3. Interface gewechselt (auf FA Interface ONE) am gleiche "COM" Port

Beim nächsten Start von UCXlog habe ich das gleiche "Problem" wie bereits im winKey Thread berichtet - UCXlog scheint zu hängen und versucht wohl, den WinKey anzusprechen, obwohl nun ein anderes Interface angeschlossen ist.

Frage: Ist es möglich, ein Timeout einzubauen, das nach sagen wir 10Sek. meldet, das es das "vorher" angeshclossene USB Interface nicht initialisieren kann und dann das Interface einfach auf inaktiv setzt -> Dann muss man es manuell neu einrichten.

Gruss und weiteres kommt bei Gelegenheit
Peter DF1LX

[DL7UCX]

Hallo Peter,

zu

Frage: Ist es möglich, ein Timeout einzubauen, das nach sagen wir 10Sek. meldet, das es das "vorher" angeshclossene USB Interface nicht initialisieren kann und dann das Interface einfach auf inaktiv setzt

Im Startup-Fenster kommt bereits eine Meldung, wenn ein COM-Port weg ist.
Ein Inaktiv-Setzen eines "fehlenden Interfaces" geht nicht, da dann bei jedem abgefallenen Stecker oder ausgeschaltetem Gerät dieses aus den Settings verschwinden würde.
Und bei einem blockierenden Port-Treiber kann UcxLog sowieso nichts mehr erkennen ...

Wenn man ein Interface wechseln will, muß man dieses aus den Settings entfernen, dann wechseln und neu in die Settings eintragen.

Unterscheidet sich das FA Interface ONE vom WinKey?

73 Ben

[DF1LX]

Hallo Ben,

ok, die vorgeschlagene Reihenfolge wäre die beste.

Der WinKey ist nur für CW, das FA Interface für CAT und Digitale Betriebsarten. Da ich derzeit nur ein passendes USB Kabel habe, hängt dann jeweils eins der Interface am selben USB Port/COM Port (Ok, weiteres USB Kabel ist auf der Bestellliste).

D.h. der COM Port ist nicht "weg" sondern halt nur ein anderes Interface, welches dann nicht initialisiert werden kann, weil UCX noch "denkt", das andere wäre angeschlossen.
Somit mein Gedanke, das UCX checkt, wie lange es braucht, bis es "einsatzbereit" ist, hier sind es einige Minuten bei dem beschriebenen "hängen". Klar hilft dann das Kabel ziehen, aber für mich im Endeffekt auch keine Lösung.
Und da am Wochenende parallel der WAG und ein RTTY Contest lief, war es dafür prädestiniert, so ein Interfacewechsel machen zu müssen.

Also: Meines Erachtens schickt die SW was an das Interface und wartet auf Antwort. Wenn diese Antwort nicht nach dem 3ten oder 5ten Mal kommt sollte UCX sagen: Kein Interface -> prüfe Einstellungen. Im Endeffekt genau das, was ich vorher mit dem Winkeyer und "falscher" Geschwindigkeit schon hatte.

Gruss Peter

[DL7UCX]

Hallo Peter,

Kein Interface -> prüfe Einstellungen

was soll denn UcxLog dann "prüfen" oder machen?

73 Ben

[DL6ER]

Hallo Ben,

ich vermute Peter meinte, dass man überprüfen sollte, ob ein Interface überhaupt auf Anfragen antwortet (z.B. also beim WinKeyer immer "00" zurückgeliefert wurde, das ist wohl keine richtige Antwort). Aber ob man das für alle möglichen Interfaces (und TRX, ...) zuverlässig machen kann

73 Dominik

[DF1LX]

- ok -

Das Startfenster kommt, aber es baut sich nicht das "survive" auf, das Feld bleibt einfach leer.
Der Com Port ist ja nicht weg, es hängt einfach ein andere Interface dran, das leider gegen dem WinKeyer nicht mit 9k6 sondern mit 4k8 betrieben wird. D.h.
UCX bekommt keinerlei Antwort und wie bei dem Phänomen meines WinKeyers (9k6 anstelle 1k2) pollt UCX wohl laufend die Schnittstelle und der Rechner
(3Ghz, keine anderen Programme am Laufen ausser die bekannten Firewall/Virenscanner) scheint zu hängen.
Ziehe ich das USB Kabel startet UCXlog wie gewohnt schnell und zuverlässig.

Somit meine ich nicht, das alle möglichen Interface erkannt werden müssen, sondern eher der Fall, das überhaupt keine Antwort beim Pollen (Abfragen) zurückkommt.
Hängt kein Interface dran klappt es.

[DL6ER]

Noch eine Idee: Was passiert wenn du (während UcxLog "hängt") das Kabel abziehst? Ich kenne die Hardware-Seite von Windows zwar nicht so gut, aber dürfte der Port dann nicht sofort wegfallen und somit der Zugriff von dem entsprechenden Modul aus UcxLog unterbunden werden?

73 Dominik

[DF1LX]

Wenn ich das USB Kabel ziehe klappt es sofort und es startet wie gehabt schnell.

[DL7UCX]

Hallo Peter,

leider ist es nicht ganz so einfach.

UcxLog "pollt" prinzipiell nie.

Jedes COM-Port wird asynchron (nicht-blockierend) in einem eigenen Thread gelesen.
Der Thread wird dann auf einem Windows "WaitForSingleObject" vertagt, bis etwas empfangen wird oder ein TimeOut auftritt (funktioniert nicht bei Windows 98). Beim Timeout vertagt sich der Thread zusätzlich, um die CPU-Last zu reduzieren.

Im Gegensatz zu den Threads für alle anderen COM-Ports muß der WinKey-Thread in hoher Priorität laufen, da sonst die CW-Ausgabe stockt.

Warum diese Mechanismen in Deinem Fall versagen, ist unklar und nur sehr schwer zu ermitteln.
Ein allgemeines Problem war das bisher nicht.

Aus meiner Sicht könntest Du damit leben, indem Du Dir
- für 10 EUR ein zweites COM-Port leistest (das wäre wohl am einfachsten) oder
- UcxLog für den Interface-Wechsel beendest und dann neu startest oder
- den USB-Stecker beim Wechseln rausziehst.

73 Ben

[DF1LX]

Danke für die Erklärung. Ich verstehe es und werde es wie vorgeschlagen machen.
Ich hoffe, das das andere User helfen kann, wenn diese einen ähnlichen Fall haben und
diese Vorgehensweise befolgen.

End of Thread - danke

[DL7UCX]

Nun hat es mir doch keine Ruhe gelassen.

Ich habe einen Winkey auf einem COM-Port ohne Winkey-IC eingerichtet.
Kein Problem.

Ich habe einen Winkey angeschlossen, eingerichtet und betrieben.
Funktioniert.

Dann habe ich die Bitrate auf 9600 hochgesetzt.
Der Winkey arbeitet natürlich nicht mehr, es ist aber kein anderes Problem erkennbar, keine hohe CPU-Last.

Auch der Start mit falscher Bitrate am Winkey verläuft ohne Probleme.

Ein Wechsel des Winkey ohne COM-Port-Wechsel geht bei mir nicht, da Winkey + USB-COM-Adapter zusammen sind (ehemaliger FA-Bausatz).

Es ist m.E. also kein prinzipielles Problem.

73 Ben

[DL7UCX]

Bin nochmal über dieses Verhalten gestolpert:

Das Startfenster kommt, aber es baut sich nicht das "survive" auf, das Feld bleibt einfach leer.

Was steht im Startup-Fenster?

Das könnte bedeuten, daß das Öffnen des COM-Ports übers Windows-API hängt, was völlig unzulässig wäre.

73 Ben

[DF1LX]

Hallo Ben,

danke für den Test und leider habe ich mir das nicht gemerkt, was in dem Fenster stand.
Derzeit kann ich das Verhalten nicht nachstellen. Was jetzt die Ursache war, ich könnte raten, aber
ich lass es lieber. Falls ich es wieder beobachte, werde ich einen Printscreen machen bzw. notieren.
Und es als PN schicken.
- Peter -