DX-Cluster

[dl8dww]

Hallo Ben,

Beim IARU HF World Championship hatte ich die Zeit auf vom DX Cluster Fenster auf 5 Minuten begrenzt. Ohne mein Zutun hat UCXlog diese Einstellung zurückgesetzt und einmal die Zeit auf auf über 130 Minuten hochgesetzt.
So wie ich es in Erinnerrung habe trat dieser Fehler zeitnah mit einem anderen Problem auf.
da hatte UCXLog den DL6ER-Keyer während einer etwas längeren Sendepause (ca 15 Minuten) verloren,d.h. die F-Tastenbedienung ging nicht mehr.
Nach dem Neustart von UCXLog war es wieder o.k.
Scheint ein HW/SW-Problem des Keyer zu sein. Nach dem Umstieg auf Winkey2 gab es keine Ausfälle mehr
Besteht die Möglichkeit eine Ausfallmeldung, analog zur TRX-Steuerung einzubauen ?

73 Wolfgang

[DL7UCX]

Hallo Wolfgang,

die Zeiteinstellung hat nichts mit dem Keyer zu tun.
Ich vermute eher ein einmaliges Software- oder Hardware-Problem des PCs.
Normalerweise wird der Ausfall eines Interfaces nicht gemeldet, das würde auch nicht wirklich helfen und man sieht es ja am Ausfall der Funktion.
Und ohne Tastung wird der Ausfall des Keyers gar nicht bemerkt, kann also nicht gemeldet werden.

73 Ben

[DL6ER]

Hallo zusammen,

ich habe dazu ein paar Fragen/Anmerkungen:

da hatte UCXLog den DL6ER-Keyer während einer etwas längeren Sendepause (ca 15 Minuten) verloren,d.h. die F-Tastenbedienung ging nicht mehr.

Hmm, das ist mir noch nicht untergekommen, ich habe schon in einigen Contesten teilgenommen mit meinem Keyer, während Pausen lasse ich UcxLog normalerweise durchlaufen (auch über Nacht!), um etwaige Probleme auszuschließen. Ich hatte auch schon mal vergessen das "Funk-Laptop" herunterzufahren und nach einer Woche laufendem UcxLog und angeschlossenem Keyer lief trotzdem alles reibungslos. Du siehst mich da also erst einmal ratlos bei der Suche nach einem eventuellen Fehler.

Und ohne Tastung wird der Ausfall des Keyers gar nicht bemerkt, kann also nicht gemeldet werden.

Naja, ich denke Du könntest über 0x00 0x04 (der Echo-Befehl) in regelmäßigem Abstand überprüfen, ob der Keyer noch da ist (bei Winkey2 und meinem Keyer völlig identisch). Dann könnte man einen Reconnect-Versuch unternehmen. Ich vermute aber auch, dass dann eher ein Softwareproblem vorliegt und der virtuelle serielle Port vermutlich komplett abgestorben ist.

Wobei:

Nach dem Neustart von UCXLog war es wieder o.k.

Hmm, dann lag es wohl doch am COM-Port und UcxLog hat beim Neustart den COM-Port wieder normal öffnen können

Nach dem Umstieg auf Winkey2 gab es keine Ausfälle mehr

Heißt das, dass der Ausfall mehrfach aufgetreten ist? Das würde mir dann ja schon zu denken geben...

73 Dominik

[dl8dww]

Hallo Dominik,
ja es gab zwei Ausfälle innerhalb von eventuell 2 Stunden.
Einmal war ich auf 40m und habe die Bandmap abgearbeitet und danach noch einmal übers Band gedreht. In dieser Zeit (ca.15min) war ich nicht auf Sendung.
Als ich dann wieder rufen wollte funktionierten die F-Tasten nicht. Mit dem Keyer konnte ich noch arbeiten.
Gleiches passierte später noch einmal auf 20m.
HF-Beeinflussung kommt eherl nicht in Frage, da es während des Sendens absolut keine Probleme gab.

Könnte es eventuell mit den Einstellungen der PTT-Vorlauf und/oder Nachlaufzeiten zu tun haben? Als Vorlaufzeit habe ich 50ms eingestellt.
Bei "G" sind es auch 50ms und bei "H " 3 Ditlängen

73 Wolfgang

[DL7UCX]

Hallo,

ich vermute weiter, daß das COM-Port zeitweilig ausgefallen war (Windows/Treiber/Hardware).
Da hilft wahrscheinlich auch keine Überwachung, da ein Schließen und erneutes Öffnen des Ports ohne UcxLog-Neustart mißlingen wird.
Auch die Überwachung der TRX-Kommunikation dient nur dazu, die Ungültigkeit der angezeigten Frequenz zu signalisieren.

73 Ben

[DL6ER]

Hallo,

ich vermute weiter, daß das COM-Port zeitweilig ausgefallen war (Windows/Treiber/Hardware).

dem schließe ich mich an.

da ein Schließen und erneutes Öffnen des Ports ohne UcxLog-Neustart mißlingen wird.

Ich habe folgendes probiert (ohne Garantie, dass das so wirklich den gleichen Effekt abbildet): Ich habe ein zusätzliches Kommando in den Keyer eingebaut, der es mir erlaubt über das Menü die Befehle

Code: Alles auswählen

Serial.close(); Serial.open();

auszuführen.
Wenn ich das tue kommt das Windows-Geräusch für entferntes und wieder eingestecktes USB-Gerät. In der Systemsteuerung verschwindet das Arduino für Sekundenbruchteile.
Wie erwartet funktioniert die Zusammenarbeit mir UcxLog dann nicht mehr. Wenn ich aber jetzt in Settings gehe den COM-Port auf einen anderen setze, das bestätige und danach wieder zurück auf den richtigen Port, wird die Verbindung wiederhergestellt und ich kann weiterarbeiten.
So komme ich in der Situation wenigstens um einen kompletten Neustart drum herum.

73 Dominik

[DL7UCX]

Hallo Dominik,

daß ein funktionierendes Port sich schließen und wieder öffen läßt, ist klar.
Ich vermute aber, daß ein Close des Ports in UcxLog bei ausgefallenem Port mißlingen wird.
Deshalb werden evtl. die Windows-Resourcen hängen und ein erneutes Open mit gleicher Port-Nummer wird auch mißlingen.
Solange der Fehler ein absoluter Ausnahmefall bleibt, möchte ich hier nichts unternehmen.

73 Ben

[dl8dww]

Hallo,
ich habe bei meiner HW/SW nach der Ausfallursache gesucht und festgestellt:
Winkey2 und der DL6ER-Keyer werden am selben USB-Port angesteckt.
Wird beim WK2 die Verbindung unterbrochen, ist nach Neustart von UcxLog WK2 wieder verfügbar.

Beim DL6ER-K wird beim betätigen des Resettasters der Keyer von UCXLog getrennt und bleibt auch nach einem Neustart getrennt.
Unter Settings wird das Port angezeigt, aber Start vom PRG nicht geöffnet.
Ich habe daraufhin den Treiber aus dem System entfernt und neu installiert. Das Port wurde erkannt und Anbinung war ok.
Wenn nach einem Verbindungsausfall ein anderes Port benutzt wird, funktoiniert die Anmeldung unter Settings.
Danach kann auch das ursprüngliche Port wieder verwendet werden.

Auf einem anderen Rechner ist das Gleiche aufgetreten.
Betriebssystem hier ist WinXP SP3

73 Wolfgang

[DL7UCX]

Hallo Wolfgang,

in den UcxLog-Settings wird ein vorher gewähltes Port weiter angezeigt, auch wenn es augenblicklich nicht verfügbar ist.
Das dient dazu, einmal eingestellte Ports auch bei temporären Hardware-Ausfall nicht zu verlieren.
Es kann also sein, daß das eingestellte Port des DL6ER-Keyers angezeigt, aber nicht geöffnet wird, weil es nicht mehr vorhanden ist.

73 Ben

[dl8dww]

Hallo Ben,
das mit den Portanzeigen in Settings ist mir klar.
Ich habe noch ein wenig probiert und kann nun den Fehler besser beschreiben:
Am PC sind zwei USB vorhanden (COM6 und COM8 lt.Anzeige vom Gerätemanager)
Der Keyer ist mit COM6 verbunden und wird auch von UCXLog so erkannt und verwendet.
Ziehe ich den Keyer ab, geht die Verbindung verloren. Ein Neustart von UCXLog bleibt wirkungslos, die Verbindung wird nicht aufgebaut
Im Gerätemanager wird am Port 6 der Keyer erkannt.

Ich beende UCXLog und
stecke ich den Keyer nach COM 8 und sofort wieder nach COM6 zurück.Der Wechsel wird im Gerätemanager angezeigt
Danach wird UCXLog erneut gestartet und jetzt wird der Keyer am COM6 erkannt

Da dieses Problem auf zwei meiner Rechner auftritt, gehe ich mal davon aus, daß es nicht an den PCs liegen wird.

73 Wolfgang

[DL7UCX]

Hallo Wolfgang,

aus Sicht von UcxLog wird das Öffnen eines COM-Ports mit bestimmter Nummer von Windows bestätigt oder nicht, da gibt es keine weiteren Tricks oder Einstellungen.
ich wüßte also nicht, wie ich das Verhalten ändern könnte.

73 Ben

[DL6ER]

Hallo zusammen,

mir ist folgendes aufgefallen und ich dachte es wäre so "normal" (d.h. jeder USB/Seriell-Wandler würde es so machen). Getestet auch auf einem Win XP Laptop (mein einziges eigenes Gerät auf dem auch Windows installiert ist).

1. UcxLog läuft und der Keyer ist angeschlossen (WIndows sagt COM6). Alles funktioniert.
2. Ich ziehe das USB-Kabel ab und stecke es wieder dran.

Windows weist dem Keyer danach COM7 zu. Ich vermute das liegt daran, dass UcxLog den nicht mehr existierenden Port "geöffnet hält" und der Port für Windows also irgendwie besetzt scheint (reine Spekulation meinerseits)

Versuche ein andersweitiges Problem mit den Ports bei mir zu provozieren schlugen bislang fehl.

73 Dominik

[DL7UCX]

Tja, UcxLog macht eher gar nichts, weil "Wer nichts macht, kann nichts falsch machen."

Es merkt evtl. gar nicht, daß das Port weg ist.
Auch wenn die Port-Kommunikation mißlingt, versucht es nicht, den Port zu schließen und neu zu öffnen.
Das Port wird nach dem Open nicht mehr über die COM-Nummer angesprochen, sondern über einen Handle, den Windows liefert.
Keine Ahnung, ob der zum Schließen noch gültig ist.

Ich sehe das auch immer noch nicht als Problem an einer Station ohne Wackelkontakte.

73 Ben

[dl8dww]

Hallo Ben,
das mit den Portanzeigen in Settings ist mir klar.
Ich habe noch ein wenig probiert und kann nun den Fehler besser beschreiben:
Am PC sind zwei USB vorhanden (COM6 und COM8 lt.Anzeige vom Gerätemanager)
Der Keyer ist mit COM6 verbunden und wird auch von UCXLog so erkannt und verwendet.
Ziehe ich den Keyer ab, geht die Verbindung verloren. Ein Neustart von UCXLog bleibt wirkungslos, die Verbindung wird nicht aufgebaut
Im Gerätemanager wird am Port 6 der Keyer erkannt.
...
73 Wolfgang

Hallo Ben, Hallo Dominik,

das Verbindungsproblem beim DL6ER-Keyer liegt wahrscheinlich beim USB-Treiber für den Arduino Micro.
Für Testzwecke habe ich den Keyer mit dem Atmega 328 und FT232 von FTDI auf dem Steckbrett aufgebaut.

Mit diesem Testaufbau gibt es nun keine Verbindungsprobleme zwischen Keyer und UCXLog. Von Windows und UCXLog wird der Keyer zuverlässig erkannt.
Der FT232 merkt sich auch die bei der Treiberinstallation vergebene Portnummer, auch an anderen Ports.

@ Dominik: Ich habe den Treiber Version 1.0.0.0 vom 4.1.20213. Gibt es da schon etwas Neues?

73 Wolfgang

[DL6ER]

Hallo Wolfgang,

die aktuellen Treiber scheinen vom 23.06.2015 zu sein, wobei man natürlich nicht weiß, ob evtl einfach nur ein Board dazu gekommen ist oder ob sich wirklich etwas an den Treibern geändert hat.

https://github.com/sparkfun/SF32u4_boar ... master.zip

Dennoch: Bei mir ist der Keyer ja nun auch schon seit fast einem 3/4 Jahr im Einsatz und hat mich auch schon durch zwei 24h-Contestteilnahmen begleitet (48h mache ich nicht mehr) ohne das die Verbindung dabei auch nur ein mal verloren ging. Ich stimme zu, dass es ein Problem geben kann, wenn die Verbindung zwischenzeitlich kaputt geht, aber ich glaube dass ich/wir da über kurz oder lang machtlos sind. Ich werde heute nachmittag recherchieren, ob ich seitens des Mikrocontrollers selbst festlegen kann, welcher Port verwendet werden soll, aber die Chancen dafür schätze ich unter 2% ein...

73 Dominik