DL6ER-Keyer

[DL6ER]

Hallo Ben,

das habe ich auch eben bemerkt (Aussendungen bei unter 60CPM führten zu Timeout).
Jetzt wird beim "Anschlag" des Zeichens die entsprechende Meldung gesendet.

@Wolfgang: Jetzt ist die Verwirrung noch größer
Es funktioniert ja gottseidank aber nun auch so

Danke Euch für die Ideen, Tipps und Ratschläge.

73 Dominik

[DL6ER]

Hallo Ben,

jetzt muss ich nach Studie der Datei von Wolfgang doch noch etwas nachfragen:

Bei Wolfgang kommt:

...
17:26-22.046 WinKey - Send: 43 <---
17:26-22.046 Winkey - Sent completed.
17:26-22.093 WinKey received: C4
17:26-22.593 WinKey timeout
17:26-22.656 WinKey received: 43 <--- große Verzögerung (s.u.)
17:26-22.656 WinKey - Send: 51
17:26-22.656 Winkey - Sent completed.
17:26-22.796 WinKey received: 90 <---- ehrlich gesagt weiß ich nicht was das ist oder wo es her kommen ("DEVICE CONTROL STRING", nicht dokumentiert)
17:26-23.296 WinKey timeout
17:26-23.390 WinKey received: 51
...

Bei mir kommt aber (bei vermutlich gleicher Ausgabe von "cq"):

...
19:30-10.661 WinKey - Send: 7C 7C 43 <---
19:30-10.663 Winkey - Sent completed.
19:30-10.665 WinKey received: C4
19:30-10.667 WinKey received: 43 <--- kaum Verzögerung (s.u.)
19:30-10.670 WinKey - Send: 7C 7C 51
19:30-10.671 Winkey - Sent completed.
19:30-11.174 WinKey timeout
19:30-11.366 WinKey received: 51
...

Also bei Wolfgang ohne und bei mir mit 2x 1/2 Pause (7C) vor dem eigentlichen Zeichen.
Ich musste die zwei halben Pausen vor dem Zeichen eh abfangen, da die das Timing gestört haben, wüsste aber dann doch gerne warum unterschiedliche Dinge gesendet werden.
Ich habe keine Settings gefunden, die dieses Verhalten beeinflussen. Unsere Initialisierungssequenzen sind genau identisch (gleiche WpM, etc.).

Außerdem:

ich würde das Zeichen schon zurücksenden, wenn die Aussendung beginnt (so würde ich auch die WinKey-Beschreibung deuten).

So habe ich das jetzt auch gemacht: siehe sehr kleine Verzögerung zwischen erstem Zeichen und der Antwort (6ms).
Bei Wolfgang dauert die Antwort des ersten Zeichens aber 610ms. Laut Initialisierung verwenden wir beide 130CpM.

73 Dominik

[dl8dww]

Hallo Dominik,
der erste Teil war der Text von F1, danach habe ich auf Tastatur umgeschaltet und ein paar Zeichen geschrieben. Die Pausen zwischen den Zeichen waren nicht normgerecht, d.h. viel zu groß
Wolfgang

[DL7UCX]

Hallo Dominik,

die 7C sind für zusätzliche Pausen (Winkey revison >= 9) und werden bei "Settings - Station - Special - CW timing" mit Intervall > 3 erzeugt.

Mit ist auch aufgefallen, daß der WinKey das Echo später als erwartet liefert, das macht mir etwas Sorge, daß bei langsamen PCs das nächste Zeichen zu spät kommen könnte (auch wenn es noch nicht beobachtet wurde).
Eigentlich sollte auch ein Zeichen mehr im Voraus gesendet werden, das muß ich nun doch nochmal genau ansehen ...

73 Ben

[DL6ER]

Hallo zusammen,

@Wolfgang: Das macht nichts, der Unterschied tritt auch auf wenn ich die Zeichen manuell eintippe.

@Ben: Ah, okay... wusste nicht, dass ich bei "CW timing" etwas verstellt hatte... bin dann jetzt auf normgerechte Einstellung zurück.
Dann kann ich das absichtliche Ignorieren der zwei halben Pausen vor den eigentlichen zu sendenden Zeichen wieder raus nehmen .
@Timing: Ich weiß nicht, ob das wirklich ein Problem darstellt. Aus den beiden SYSLOG-Dateien ist ersichtlich, dass es bei Wolfgang häufig innerhalb von einer Millisekunde eine Antwort gibt.
Mein Computer braucht max 4ms, gehört aber sicherlich in die Kategorie "altes Eisen" (2x2.6 GHz, Baujahr 2004). Für alle Funkbelange mehr als ausreichend.

73 Dominik

[DL7UCX]

Hallo Dominik und Wolfgang,

@Dominik:
Die Antwort kommt nicht nach 1 oder 4 ms, sondern das Senden wird von Windows fertig gemeldet.
Dann kann es noch dauern, bis das über USB und serielle Datenübertragung beim Winkey ankommt.

Ich habe mal versuchsweise in 7.46 Beta 1 ein Zeichen mehr zum WinKey-Puffer geschickt.

@Wolfgang: Bitte ausprobieren, ob Du irgendeine Veränderung bemerkst, ich hoffe nicht.

73 Ben

[DL6ER]

Hallo Ben,

auf meinen Keyer hat die Änderung in Beta 1 keine nachteilige Auswirkung.
Es fällt aber auf, dass immer schon zwei Zeichen verschwunden sind, die noch nicht gegeben wurden.
Ich finde das sollte lieber vermieden werden, wenn noch keiner ein Problem damit gemeldet hat.

Alternativ könnte ich dir eine entsprechend hohe Wunsch-Winkey-Revisionsnummer (0xF0 ?) übertragen, damit dieses neue Verhalten bei meinem Keyer umgangen werden kann .

Nachtrag:
Alternativ passe ich es so an, dass das erste Zeichen auch erst gegen Ende zurückgegeben wird.
Ich versuche das mal zuerst (wir wollen ja möglichst Winkey ähnlich sein).

Nachtrag 2: okay ... jetzt sende ich das Zeichen 1 dit-Länge bevor der Puffer des Keyers leer ist. Funktioniert immer noch.

73 Dominik

[DL7UCX]

Hallo Dominik,

ja, nun müssen zwei (statt 1) Zeichen verschwinden, weil beim Beginn gleich 2 zum WinKey geschoben werden, aus Sicht von UcxLog sind die "weg", können ja auch nicht mehr editiert werden.

Dadurch ist nach dem Echo des Winkey eine Pause+Zeichen lang Zeit, bis das nächste Zeichen beim WinKey ankommen muß.
Es ging bisher auch ohne dieses Zeichen, aber vor kurzem gab es einen ungeklärten Fall, daß ein WinKey zu lange Pausen zwischen den Zeichen gemacht hat. Ich weiß noch nicht, ob es daran lag.

73 Ben

Nachtrag: Leider ist nicht klar, wann der WinKey das Echo genau sendet. Im ungünstigsten Fall (am Ende des CW-Zeichens) blieben bisher nur 3 Punkte Zeit, das nächste Zeichen dorthin zu bekommen.

[DL6ER]

Hallo Ben,

okay. Kein Problem.
Es gibt scheinbar auch mit Beta 2 keine negativen Auswirkungen.
Dadurch, dass ich das Zeichen erst kurz vor Abschluss zurück gebe, bin ich wieder näher am alten Verhalten und wir sind trotzdem immer mit einem Zeichen im Puffer auf der sicheren Seite.

P.S.:
Ich werde scheinbar auf 9600baud bestehen müssen...habe seit der Implementierung von Winkey Probleme mit einem ungeklärtem Resets des AVR-Microcontrollers beim Start von UcxLog.
Den Grund konnte ich gerade in der Dokumentation finden:

Rather than requiring a physical press of the reset button before an upload, [...] is designed in a way that allows it to be reset by software running on a connected computer. The reset is triggered when the virtual (CDC) serial / COM port is opened at 1200 baud and then closed. When this happens, the processor will reset, breaking the USB connection to the computer [...].

Da habe ich also keine Änderungsmöglichkeiten.

Die Auswirkungen sind mehr oder minder fatal: Nach dem Reset meldet es sich wieder neu am PC an. Unter Linux ist es relativ folgenlos, denn nach ca 0.5sec funktioniert es dann wie erwartet. Aber unter Windows ist die alte serielle Schnittstelle dann noch nicht durch Timeout verschwunden, d.h. es wird die nächste freie COM-Portnummer verwendet. Man müsste also nach jedem Starten die Settings ändern...

Ich würde dich dann bitten bei gegebener Zeit der Hinweismeldung zu 9600Bd einen Hinweis auf den meinen Keyer hinzuzufügen (sodass der Nutzer nicht denkt hier einen Fehler zu machen).
Mit 9600 tritt kein Reset auf.

Nachtrag: Ich habe herausgefunden, wie der Reset durchgeführt wird. Jetzt weiß ich auch wie ich das aufhalten könnte.
Da dann aber das Aufspielen von evtl. Updates beträchtlich erschwert werden würde (denn ohne Reset kein Aufspielen von neuer Firmware) bleibt es bei 9600baud.

73 Dominik

[DL7UCX]

Hallo Dominik,

- Das Puffern des zusätzlichen Zeichens werde ich evtl. noch schaltbar machen.
- Welche Revision simulierst Du denn jetzt? Bei den höheren mußt Du wohl das 7C ("|") für das Leerzeichen zwischen Worten verarbeiten.
- Gibt es für das "Human Interface Device" eine DLL zur Datenübertragung unter Windows? Dann könnte man ähnlich wie mit dem ExpandIO arbeiten ...
- Wieviel Port-Ausgänge sind noch frei (Antennen schalten ...)?

73 Ben

[DL6ER]

Hallo Ben,

- Das Puffern des zusätzlichen Zeichens werde ich evtl. noch schaltbar machen.

Mir ist ein potentielles Problem aufgefallen (@Wolfgang: Bitte auch testen!):
CPM: 80
Incr/Decr: 80 (extra so hoch, damit man den Unterscheid gut hört)
Memory Text auf F2: 5nn+tu
Wenn ich das jetzt sende wird t noch langsam gesendet und erst das u schnell
Möglicherweise liegt das an meiner Implementierung, möglicherweise gibt es Problem aber auch mit dem Winkey.

- Welche Revision simulierst Du denn jetzt? Bei den höheren mußt Du wohl das 7C ("|") für das Leerzeichen zwischen Worten verarbeiten.

Ich habe jetzt die gleiche Revision wie Wolfgangs Winkey (0x0A).
Die 0x7C habe ich implementiert, man kann mit den Einstellungen bei "CW Timing" das beabsichtigte Verhalten erzielen.

- Gibt es für das "Human Interface Device" eine DLL zur Datenübertragung unter Windows? Dann könnte man ähnlich wie mit dem ExpandIO arbeiten ...

Uff...um ehrlich zu sein muss ich da passen wie es genau unter Windows arbeitet. Die Keyboard-Emulation ist etwas das der Microcontroller in seiner neuesten Version auf Anfrage "out-of-the-box" erzeugen kann, ich glaube kaum, dass man da groß etwas dran drehen kann. Es gibt sich wohl direkt als Tastatur aus und benutzt die normalen Windows-Treiber. Hier habe ich überhaupt keine Erfahrung...

Zur emulierten seriellen Schnittstelle:

- Wieviel Port-Ausgänge sind noch frei (Antennen schalten ...)?

Beliebig viele
Ich verwende das kleinste (=billigste) Modul (Pro Micro) und das besitzt 18 I/O.
Davon brauche ich aktuell 6 für meine Zwecke (Paddle, Speaker, TRX, etc.)
Es sind also 18-6 = 12 I/O verfügbar.

Dann gibt es noch das Leonardo Modul das scheinbar recht weit verbreitet ist und mit meinem Quellcode und der aktuellen IDE auf den neuesten Stand gepatcht würde. Gleiche Anzahl an I/O verfügbar.
Außerdem das Arduino Due, das ist das aktuelle High-End Modul, da hätte man sogar 54-6 = 48 I/O verfügbar.

Eine gewisse Anzahl davon kann auch analoge Signale (0-5V) lesen (bei mir 4). Analoge Ausgänge sind bei mir nicht vorhanden.

73 Dominik

[DL7UCX]

Hallo Dominik,

das ist bei mir zwar anders, aber auch nicht gut.
Das Speed-Kommando wirkt leider lt. Manual sofort, d.h. bei mir wird nun (wie zu befürchten und zu erwarten!) schon die zweite 9 von 599+tu schneller gesendet (geht aber nur bis 70%, bei 80% versagt es).

Der ExpandIO gibt sich auch als Tastatur aus, hat aber eine DLL, um auf etwas höherem Level zu kommunizieren.

73 Ben

[DL6ER]

Hallo Ben,

@Speed-Kommando:
Ich habe die seriellen Kommandos bislang nur dann ausgewertet, wenn keine Sendung im Gange war.
Das habe ich nun verworfen, da sich der Prozessor sonst solange bis ein Zeichen fertig ist nur im Kreis dreht.
Jetzt ist das Verhalten bei mir wie von dir beschrieben (sofortige Auswirkung).

@Winkey Settings:
Wo ist eigentlich der Unterschied zwischen "Winkey Port 1" und "Winkey Port 2" unter "Key/PTT control"?
Das wird mir aus dem Hilfetext dazu nicht ersichtlich.

@HID:
Es gibt natürlich prinzipiell die Möglichkeit ein weiteres HID-Gerät aufzumachen. Das Problem ist nur: Das ist so nicht vorgesehen = Dokumentation ist Null-Komma-Nix.
Braucht also seine Zeit bis ich verstanden habe ob und wenn ja wie ich das machen muss um was sinnvolles zustande zu bringen. DLLs schreiben kann ich nicht - soviel vorab...
Aber die prinzipielle Möglichkeit besteht und wir bleiben mal zuversichtlich .
((( Mit Vorsicht gesagt: Wenn wir hier schon Emulieren, kann vielleicht auch das expandIO emuliert werden )))

73 Dominik

[DL7UCX]

In 7.46 Beta 3 ist das Buffern schaltbar:
Settings - Station - Interfaces - WinKey: "+buffer"

Der WinKey hat zwei Hardware-Ausgänge (jeweils Key + PTT), kann also 2 TRX bedienen.

73 Ben

[DL6ER]

Hallo Ben,

okay, ohne den Haken funktioniert alles einwandfrei.
Ich ignoriere die Angabe ob Port 1 oder 2 weiterhin, ließe sich aber bei Bedarf einfach nachrüsten.

Beim Thema HID ist doch recht schnell klar geworden, dass es nicht geht, denn dafür muss grundlegend etwas ein Software-Level tiefer umgeschrieben werden. Ich könnte das zwar machen, müsste dann aber modifizierte Versionen für alle Betriebssysteme erstellen und verteilen, damit jeder selbst Updates einspielen kann (das ist mir wichtig). Das geht nicht und ist damit leider recht schnell wieder vom Tisch.
Mit der Originalsoftware würde die Definition des zusätzlichen HID-Gerätes wieder entfernt werden, da der ursprüngliche Code zusätzliche HID-Geräte bewusst deaktiviert.

Bezüglich zusätzlicher Aus-/Eingänge lässt sich aber dennoch so ziemlich alles machen.
Da ich nicht weiß wie sich der Winkey verhält wenn man für ihn unbekannte Befehle übergibt, würde also vorschlagen, dass du eine eigene Auswahlmöglichkeit unter "Key/PTT control" definierst.
Ich ignoriere die Einstellungen unter "Other Interfaces" eh alle und brauche standardmäßig 9600baud.
Dabei bliebe alles beim Winkey-Protokoll, außer dass von uns zusätzliche Befehle in beide Richtungen definiert werden könnten.
0x80 (Ende ASCII Tabelle) - 0xFF (Ende 1 Byte) sind im Winkeyprotokoll nicht vergeben und werden aktuell von mir einfach verworfen.

73 Dominik