DL6ER-Keyer
Moderator: DL7UCX
DL6ER-Keyer
Hallo zusammen,
ich arbeite seit ca einer Woche an einem kleinen Selbstbauprojekt, einem CW-Keyer auf < 20 Euro Basis. Ich weiß, dass ich damit das Rad quasi neu erfinde, aber mir ging es dabei im Wesentlichen um ein paar Dinge, die kein fertig verfügbarer Keyer aktuell leisten kann (außerdem ist Selbstbau fordernd und macht Spaß ). Ich möchte dieses kleine Projekt über die CQDL Anfang nächsten Jahres bekannt machen. Der Nachbau ist jederzeit (auch ohne mein Zutun) möglich, da alles offen gelegt wird und man die Komponenten frei beziehen kann.
Nun funktioniert also schon alles soweit und zu guter Letzt hätte ich natürlich auch gerne eine Software-Kopplung mit UcxLog. Ich habe dort die Unterstützung für den WinKey gefunden.
Führt mich zu der Frage: Wie am besten die Kopplung umsetzen?
Möglichkeit A: Verwendung des WinKey-Protokolls.
Soweit möglich und sinnvoll könnte ich das vielleicht so machen, hat jemand einen Hinweis auf die Spezifikationen des Protokolls?
Dann würde ich daraus aber eine Minimalimplementierung machen, in der Hoffnung, dass das alles so funktioniert .
Möglichkeit B: Festlegung eines eigenen (sehr einfachen) Protokolls.
Könnte beispielsweise so aussehen, dass UcxLog einfach immer nur ein Zeichen + aktuelle WpM an den Keyer sendet und der sendet das dann.
Rückmeldung wenn das Zeichen gesendet wurde. Auf Stopp-Kommando hört der Keyer sofort auf.
Wäre somit maximal einfach und hoffentlich weniger fehleranfällig als große Implementierungen und mit der UcxLog-Philosophie vereinbar jedes Zeichen bis zum tatsächlichen Senden noch ändern zu können.
73 Dominik
ich arbeite seit ca einer Woche an einem kleinen Selbstbauprojekt, einem CW-Keyer auf < 20 Euro Basis. Ich weiß, dass ich damit das Rad quasi neu erfinde, aber mir ging es dabei im Wesentlichen um ein paar Dinge, die kein fertig verfügbarer Keyer aktuell leisten kann (außerdem ist Selbstbau fordernd und macht Spaß ). Ich möchte dieses kleine Projekt über die CQDL Anfang nächsten Jahres bekannt machen. Der Nachbau ist jederzeit (auch ohne mein Zutun) möglich, da alles offen gelegt wird und man die Komponenten frei beziehen kann.
Nun funktioniert also schon alles soweit und zu guter Letzt hätte ich natürlich auch gerne eine Software-Kopplung mit UcxLog. Ich habe dort die Unterstützung für den WinKey gefunden.
Führt mich zu der Frage: Wie am besten die Kopplung umsetzen?
Möglichkeit A: Verwendung des WinKey-Protokolls.
Soweit möglich und sinnvoll könnte ich das vielleicht so machen, hat jemand einen Hinweis auf die Spezifikationen des Protokolls?
Dann würde ich daraus aber eine Minimalimplementierung machen, in der Hoffnung, dass das alles so funktioniert .
Möglichkeit B: Festlegung eines eigenen (sehr einfachen) Protokolls.
Könnte beispielsweise so aussehen, dass UcxLog einfach immer nur ein Zeichen + aktuelle WpM an den Keyer sendet und der sendet das dann.
Rückmeldung wenn das Zeichen gesendet wurde. Auf Stopp-Kommando hört der Keyer sofort auf.
Wäre somit maximal einfach und hoffentlich weniger fehleranfällig als große Implementierungen und mit der UcxLog-Philosophie vereinbar jedes Zeichen bis zum tatsächlichen Senden noch ändern zu können.
73 Dominik
- DL7UCX
- Beiträge: 6503
- Registriert: Donnerstag 8. August 2002, 19:23
- Wohnort: Dabendorf
- Kontaktdaten:
Re: DL6ER-Keyer
Hallo Dominik,
bei so einer (vorläufigen) Einzel-Lösung ist die Variante A wahrscheinlich besser:
- Ich habe keine Arbeit
- Man kann es auch mit anderen Programmen nachnutzen
Hier ist ein Manual zur Steuerung:
http://k1el.tripod.com/files/WK2_Datasheet_v23.pdf
Spezielle Kommandos (Leerzeichen-Länge ...) kannst Du ja erstmal einfach weglassen.
Bei UcxLog kannst Du das Protokoll mit "Help - Trace System Events - Winkey Control" in der SYSLOG.TXT ansehen.
73 Ben
Nachtrag:
Interessant wäre es, eine Anbindung an das UcxLog-Interface viewtopic.php?f=33&t=1140 über SPI (Steuerung dann ohne COM-Port) zu untersuchen ....
bei so einer (vorläufigen) Einzel-Lösung ist die Variante A wahrscheinlich besser:
- Ich habe keine Arbeit
- Man kann es auch mit anderen Programmen nachnutzen
Hier ist ein Manual zur Steuerung:
http://k1el.tripod.com/files/WK2_Datasheet_v23.pdf
Spezielle Kommandos (Leerzeichen-Länge ...) kannst Du ja erstmal einfach weglassen.
Bei UcxLog kannst Du das Protokoll mit "Help - Trace System Events - Winkey Control" in der SYSLOG.TXT ansehen.
73 Ben
Nachtrag:
Interessant wäre es, eine Anbindung an das UcxLog-Interface viewtopic.php?f=33&t=1140 über SPI (Steuerung dann ohne COM-Port) zu untersuchen ....
Re: DL6ER-Keyer
Hallo Ben,
danke für deine Antwort, den Link und den Hinweis auf das Trace System Events.
Die Herangehensweise über die serielle Schnittstelle hat den Grund, dass als Hauptbaustein ein kleines, günstiges Arduino-Modul zum Einsatz kommt. Das wird über USB mit dem PC verbunden und hat zwangsläufig eine serielle Schnittstelle. Das Modul wird hierüber auch programmiert: der Nutzer kann den Quellcode jederzeit verändern und selbst ohne zusätzliche Hardware hochladen (wenn er will...).
Somit ist die serielle Schnittstelle eh da und wird lediglich softwareseitig nicht genutzt.
Die Problematik mit gelegentlichen Umnummerierungen unter Windows ist mir bekannt, jedoch nicht aus eigener Erfahrung.
Es scheint aber nicht so schlimm zu sein, denn schließlich verwenden immer noch alle die serielle Schnittstelle für ihre TRX CAT-Steuerung.
@SPI: Ja, das ließe sich sicher auch machen, dafür müsste ich mich dann nur in den Umgang mit SPI einlesen und das entsprechend einbauen.
Aber wie groß ist der Nutzen?
a) wieviele Nutzer des expandIO-Chipsatzes gibt es?
b) wieviele wollen evtl. einen neuen Keyer haben?
c) wieviele wollen die beiden Systeme über den SPI-Bus verbinden?
Und du müsstest da ja dann auch noch etwas einbauen - da ist es fraglich, ob es am Ende mehr als 3 Leute nutzen, die auch genau so gut mit der seriellen Schnittstelle glücklich wären
73 Dominik
danke für deine Antwort, den Link und den Hinweis auf das Trace System Events.
Die Herangehensweise über die serielle Schnittstelle hat den Grund, dass als Hauptbaustein ein kleines, günstiges Arduino-Modul zum Einsatz kommt. Das wird über USB mit dem PC verbunden und hat zwangsläufig eine serielle Schnittstelle. Das Modul wird hierüber auch programmiert: der Nutzer kann den Quellcode jederzeit verändern und selbst ohne zusätzliche Hardware hochladen (wenn er will...).
Somit ist die serielle Schnittstelle eh da und wird lediglich softwareseitig nicht genutzt.
Die Problematik mit gelegentlichen Umnummerierungen unter Windows ist mir bekannt, jedoch nicht aus eigener Erfahrung.
Es scheint aber nicht so schlimm zu sein, denn schließlich verwenden immer noch alle die serielle Schnittstelle für ihre TRX CAT-Steuerung.
@SPI: Ja, das ließe sich sicher auch machen, dafür müsste ich mich dann nur in den Umgang mit SPI einlesen und das entsprechend einbauen.
Aber wie groß ist der Nutzen?
a) wieviele Nutzer des expandIO-Chipsatzes gibt es?
b) wieviele wollen evtl. einen neuen Keyer haben?
c) wieviele wollen die beiden Systeme über den SPI-Bus verbinden?
Und du müsstest da ja dann auch noch etwas einbauen - da ist es fraglich, ob es am Ende mehr als 3 Leute nutzen, die auch genau so gut mit der seriellen Schnittstelle glücklich wären
73 Dominik
Re: DL6ER-Keyer
Hallo Ben,
ich fürchte ich brauche doch noch einmal deinen Rat.
SYSLOG.TXT:
Ich interpretiere das folgendermaßen:
Ich kann in der Anleitung nicht erkennen, dass etwas ständig gesendet werden müsste.
73 Dominik
ich fürchte ich brauche doch noch einmal deinen Rat.
SYSLOG.TXT:
Code: Alles auswählen
18:20-42.517 WinKey - COM Properties read : 01 00 01 00 01 00 00 00 00 00 00 00 00 10 00 00 00 10 00 00 00 00 02 00 01 00 00 00 CB 00 00 00 3F 00 00 00 FF 6B 06 00 0F 00 07 1F 00 10 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
18:20-42.522 WinKey - COM State written: 1C 00 00 00 B0 04 00 00 01 00 00 00 00 00 0A 00 0A 00 08 00 02 11 13 FF 1A 00 00 00
18:20-42.522 WinKey - COM Settings : B0 04 00 00 01 00 00 00 08 00 02
18:20-42.522 WinKey - ClearComm - lpErrors: 00 00 00 00
18:20-42.522 WinKey - ClearComm - COMSTAT: 00 00 00 00 00 00 00 00 00 00 00 00
18:20-43.024 WinKey timeout
18:20-43.025 WinKey - Send: 13 13 13 13 00 04 55
18:20-43.026 Winkey - Sent completed.
18:20-43.029 WinKey received: 55
18:20-43.029 WinKey - Send: 00 02
18:20-43.030 Winkey - Sent completed.
18:20-43.033 WinKey received: FF
18:20-43.033 WinKey - Send: 0F 04 18 05 32 0A 00 08 20 00 00 0A 32 32 04 FF 07 15
18:20-43.034 Winkey - Sent completed.
18:20-43.099 WinKey - Send: 09 05
18:20-43.100 Winkey - Sent completed.
18:20-43.535 WinKey timeout
18:20-44.036 WinKey timeout
18:20-44.537 WinKey timeout
18:20-45.038 WinKey timeout
18:20-45.539 WinKey timeout
- 13 = nichts tun
- 00 = Admin-Modus -> 04 = Echo (von 55).
Also gebe ich das nach der 04 empfangene Byte genau so wieder an UcxLog zurück. Wird scheinbar akzeptiert. - Als nächstes soll mit 00 -> 02 der Host-Modus aktiviert werden. Ich sende FF zurück. Scheint auch okay zu sein.
- 0F (Settings) - werden nicht bestätigt
- 09 (auch irgendwelche Settings...) - werden auch nicht bestätigt
Ich kann in der Anleitung nicht erkennen, dass etwas ständig gesendet werden müsste.
73 Dominik
- DL7UCX
- Beiträge: 6503
- Registriert: Donnerstag 8. August 2002, 19:23
- Wohnort: Dabendorf
- Kontaktdaten:
Re: DL6ER-Keyer
Hallo Dominik,
die Timeouts sind kein Fehler, sie besagen nur, daß das COM-Port eine Weile nichts empfangen hat.
Den Rest kann ich jetzt nicht ohne Einarbeitung beurteilen...
Du müßtest das am besten mit einer Aufzeichnung eines "richtigen" WinKey vergleichen.
Zum vorigen Beitrag:
Das UcxLog-Interface wäre eher für einen zweiten Mikrocontroller, nicht für Arduino interessant.
Ich hatte die Vision eines besseren Interfaces:
- das nicht auf dem COM-Port des vorigen Jahrtausend aufsetzt,
- das nicht die richtige COM-Port-Nummer verliert,
- das nicht von den richtigen Treibern abhängig ist,
- das ohne jegliche Einstellungen des Users einfach funktioniert,
- das nicht mehrere Hundert EURO kostet und permanent laufende Steuer-Programme erfordert, von deren Einstellungen viele überfordert sind.
Ich habe aber auch eingesehen, daß so eine proprietäre Lösung nur bei wenigen "Spezialisten" ankommt und nicht zu vermarkten ist ...
73 Ben
die Timeouts sind kein Fehler, sie besagen nur, daß das COM-Port eine Weile nichts empfangen hat.
Den Rest kann ich jetzt nicht ohne Einarbeitung beurteilen...
Du müßtest das am besten mit einer Aufzeichnung eines "richtigen" WinKey vergleichen.
Zum vorigen Beitrag:
Das UcxLog-Interface wäre eher für einen zweiten Mikrocontroller, nicht für Arduino interessant.
Ich hatte die Vision eines besseren Interfaces:
- das nicht auf dem COM-Port des vorigen Jahrtausend aufsetzt,
- das nicht die richtige COM-Port-Nummer verliert,
- das nicht von den richtigen Treibern abhängig ist,
- das ohne jegliche Einstellungen des Users einfach funktioniert,
- das nicht mehrere Hundert EURO kostet und permanent laufende Steuer-Programme erfordert, von deren Einstellungen viele überfordert sind.
Ich habe aber auch eingesehen, daß so eine proprietäre Lösung nur bei wenigen "Spezialisten" ankommt und nicht zu vermarkten ist ...
73 Ben
Re: DL6ER-Keyer
Hallo Dominik,
Hier findest Du Anregungen für Dein geplantes Projekt.
http://blog.radioartisan.com/arduino-cw-keyer/
http://www.dl7bj.org/bj-keyer/
Die dort vorgestellten Lösungen sind an Winkey angelehnt und die Firmware ist auch offen.
Da würde es sich eventuell anbieten auf Vorhandenes aufzubauen und nach eigenen Vorgaben entsprechende Anderungen vorzunehmen.
Das UCXLog-Interface von Ben kann ich nur weiterempfehlen.Ich habe es ebenfalls aufgebaut und durch durch geringfügige Änderungen für meine Anwendung angepasst.
73 Wolfgang
Hier findest Du Anregungen für Dein geplantes Projekt.
http://blog.radioartisan.com/arduino-cw-keyer/
http://www.dl7bj.org/bj-keyer/
Die dort vorgestellten Lösungen sind an Winkey angelehnt und die Firmware ist auch offen.
Da würde es sich eventuell anbieten auf Vorhandenes aufzubauen und nach eigenen Vorgaben entsprechende Anderungen vorzunehmen.
Das UCXLog-Interface von Ben kann ich nur weiterempfehlen.Ich habe es ebenfalls aufgebaut und durch durch geringfügige Änderungen für meine Anwendung angepasst.
73 Wolfgang
Re: DL6ER-Keyer
Hallo Wolfgang,
danke für die Links, aber ich hatte bewusst nicht vorher geguckt, denn ich wollte mal wieder selbst ein Projekt vorantreiben ohne auf irgendetwas aufzubauen (hatte zu lange Abstand vom Selbstbau und wollte mal schauen, ob ich es noch kann).
Ich bin schnell vorwärts gekommen und alles was ich möchte funktioniert jetzt:
Die Winkey Emulation hängt in den letzten Zügen, ich muss nur noch heraus finden, was ich UcxLog zurück geben muss, damit es mir den nächsten Buchstaben sendet (erledigt).
Mehr folgt dann demnächst.
Soviel vorab: Mir war es wichtig ohne irgendwelche Treiber einfach den Keyer an einem XY-beliebigen PC anzuschließen und Betriebssystemunabhängig (d.h. keine Treiber oder Software) das Paddle als Tastatur verwenden zu können (QRQ-Training im Alltag: Bspw. schreiben von E-Mails mit der Taste). Funktioniert ufb mit einer einfachen USB-Keyboard-Emulation.
73 Dominik
danke für die Links, aber ich hatte bewusst nicht vorher geguckt, denn ich wollte mal wieder selbst ein Projekt vorantreiben ohne auf irgendetwas aufzubauen (hatte zu lange Abstand vom Selbstbau und wollte mal schauen, ob ich es noch kann).
Ich bin schnell vorwärts gekommen und alles was ich möchte funktioniert jetzt:
Die Winkey Emulation hängt in den letzten Zügen, ich muss nur noch heraus finden, was ich UcxLog zurück geben muss, damit es mir den nächsten Buchstaben sendet (erledigt).
Mehr folgt dann demnächst.
Soviel vorab: Mir war es wichtig ohne irgendwelche Treiber einfach den Keyer an einem XY-beliebigen PC anzuschließen und Betriebssystemunabhängig (d.h. keine Treiber oder Software) das Paddle als Tastatur verwenden zu können (QRQ-Training im Alltag: Bspw. schreiben von E-Mails mit der Taste). Funktioniert ufb mit einer einfachen USB-Keyboard-Emulation.
73 Dominik
Re: DL6ER-Keyer
da bin ich auf des Ergebnis gespannt.
73 und viel Erfolg bei Deinem Projekt
Wolfgang
73 und viel Erfolg bei Deinem Projekt
Wolfgang
Re: DL6ER-Keyer
Hallo zusammen,
nach einigem weiteren Experimentieren funktioniert es jetzt flüssig und wunderbar.
Aber es gibt eine Sache, die mir Bauchschmerzen bereitet:
Der Spezifikation folgend muss ich den Zustand BUSY senden, sobald der Keyer beginnt ein Zeichen zu senden. Sobald dieses Zeichen fertig ist, folgt ein IDLE.
Hört sich soweit logisch an, funktioniert aber nicht zusammen mit UcxLog (was ja an einen echten Winkey angepasst ist).
Es funktioniert aber, wenn ich es genau anders herum mache
Nachdem ein Zeichen erfolgreich gesendet wurde, muss ich ein BUSY übertragen, damit mir UcxLog das Nächste schickt.
Wenn also mal jemand mit einem laufenden Winkey die Funktion "Help - Trace System Events - Winkey Control" aktivieren und mir danach nach ein paar Aussendungen (direkt eingetippt und auch mal aus dem Speicher (z.B. F1)) die SYSLOG.TXT schicken könnte, würde mir das helfen.
Bevor ich das so stehen lasse, möchte ich wenigstens wissen, ob sich der Winkey selbst nicht an seine Spezifikation hält, oder ob das jetzt hier nur aufgrund einer zufälligen Konstellation funktioniert.
73 Dominik
nach einigem weiteren Experimentieren funktioniert es jetzt flüssig und wunderbar.
Aber es gibt eine Sache, die mir Bauchschmerzen bereitet:
Der Spezifikation folgend muss ich den Zustand BUSY senden, sobald der Keyer beginnt ein Zeichen zu senden. Sobald dieses Zeichen fertig ist, folgt ein IDLE.
Hört sich soweit logisch an, funktioniert aber nicht zusammen mit UcxLog (was ja an einen echten Winkey angepasst ist).
Es funktioniert aber, wenn ich es genau anders herum mache
Nachdem ein Zeichen erfolgreich gesendet wurde, muss ich ein BUSY übertragen, damit mir UcxLog das Nächste schickt.
Wenn also mal jemand mit einem laufenden Winkey die Funktion "Help - Trace System Events - Winkey Control" aktivieren und mir danach nach ein paar Aussendungen (direkt eingetippt und auch mal aus dem Speicher (z.B. F1)) die SYSLOG.TXT schicken könnte, würde mir das helfen.
Bevor ich das so stehen lasse, möchte ich wenigstens wissen, ob sich der Winkey selbst nicht an seine Spezifikation hält, oder ob das jetzt hier nur aufgrund einer zufälligen Konstellation funktioniert.
73 Dominik
- DL7UCX
- Beiträge: 6503
- Registriert: Donnerstag 8. August 2002, 19:23
- Wohnort: Dabendorf
- Kontaktdaten:
Re: DL6ER-Keyer
Hallo Dominik,
wenn ich meine Programmierung zum WinKey richtig verstehe (ist Jahre her), sendet UcxLog das nächste Zeichen, wenn es das Echo des letzten Zeichens vom WinKey empfängt.
Frage: Wer erzeugt das WinKey-COM-Port für UcxLog, wenn Dein Keyer als USB-Keyboard-Emulation ohne Treiber angeschlossen ist ?
73 Ben
wenn ich meine Programmierung zum WinKey richtig verstehe (ist Jahre her), sendet UcxLog das nächste Zeichen, wenn es das Echo des letzten Zeichens vom WinKey empfängt.
Frage: Wer erzeugt das WinKey-COM-Port für UcxLog, wenn Dein Keyer als USB-Keyboard-Emulation ohne Treiber angeschlossen ist ?
73 Ben
Re: DL6ER-Keyer
Hallo Ben,
das habe ich so nicht probiert, weil das nicht in den Spezifikationen stand.
Laut Spezifikation muss man unaufgefordert folgendes Statusbit senden, wenn sich der Status ändert (binär): 00B00011
Das hatte ich zuerst als B=1 für BUSY (= bin beschäftigt CW zu senden) und B=0 für IDLE (warte auf nächstes Zeichen) interpretiert.
Gezeigt hat sich aber, dass es so nicht, aber dafür genau anders herum funktioniert.
Die Beschreibung in der Spezifikation zum BUSY-Bit lautet:
Wie dem auch sei, es funktioniert jetzt so und ich warte ab, ob jemand Zeit hat ein bisschen rumzuspielen und mir danach seine SYSLOG.TXT zur Verfügung zu stellen.
Du brauchst nicht deine Zeit verwenden um im Code von UcxLog zu suchen.
@deine Frage
Das Board meldet sich als Multifunktions-USB-Gerät an. Das ist so in den Spezifikationen des USB-Protokoll vorhanden. Es ist ähnlich wie ein Multifunktions-Drucker. Der meldet auch zwei Geräte über "das gleiche Kabel" an (Scanner + Drucker). Ich mache etwas ähnliches und melde drei Geräte an:
a) Communications / Abstract (modem) / No protocol
b) CDC Data
c) Human Interface Device / Generic / input
(a) ist für die Programmierung mit der frei verfügbaren Arduino-Software (man kann auch programmieren während UcxLog läuft, ohne dass es schädliche Auswirkungen hat ).
(b) registriert die serielle Schnittstelle und (c) simuliert ein normales USB-Keyboard.
Was Treiberbedarf angeht, bin ich ja bekanntlich immer etwas nachlässig, eben weil man unter Linux (/ Mac) sich eigentlich nie um Treiber kümmern muss. Gerade mal an einem Windows-Rechner probiert. Tatsächlich muss man unter XP einen Treiber installieren, wenn man die Winkey-Funktionalität nutzen will... Der Keyer funktioniert für sich aber auch ohne Treiber einwandfrei, dann eben wie vorgestern (Grundfunktionen + Tastatur geht, Winkeyemulation nicht mangels COM-Schnittstelle).
Es scheint sich aber um den 08/15-Standardtreiber für USB/serielle Schnittstellen zu handeln, den man unter XP immer installieren muss.
73 Dominik
das habe ich so nicht probiert, weil das nicht in den Spezifikationen stand.
Laut Spezifikation muss man unaufgefordert folgendes Statusbit senden, wenn sich der Status ändert (binär): 00B00011
Das hatte ich zuerst als B=1 für BUSY (= bin beschäftigt CW zu senden) und B=0 für IDLE (warte auf nächstes Zeichen) interpretiert.
Gezeigt hat sich aber, dass es so nicht, aber dafür genau anders herum funktioniert.
Die Beschreibung in der Spezifikation zum BUSY-Bit lautet:
Ich glaube eigentlich, dass man da nicht allzu viel falsch verstehen kann.BUSY: Keyer is busy sending Morse when = 1
Wie dem auch sei, es funktioniert jetzt so und ich warte ab, ob jemand Zeit hat ein bisschen rumzuspielen und mir danach seine SYSLOG.TXT zur Verfügung zu stellen.
Du brauchst nicht deine Zeit verwenden um im Code von UcxLog zu suchen.
@deine Frage
Das Board meldet sich als Multifunktions-USB-Gerät an. Das ist so in den Spezifikationen des USB-Protokoll vorhanden. Es ist ähnlich wie ein Multifunktions-Drucker. Der meldet auch zwei Geräte über "das gleiche Kabel" an (Scanner + Drucker). Ich mache etwas ähnliches und melde drei Geräte an:
a) Communications / Abstract (modem) / No protocol
b) CDC Data
c) Human Interface Device / Generic / input
(a) ist für die Programmierung mit der frei verfügbaren Arduino-Software (man kann auch programmieren während UcxLog läuft, ohne dass es schädliche Auswirkungen hat ).
(b) registriert die serielle Schnittstelle und (c) simuliert ein normales USB-Keyboard.
Was Treiberbedarf angeht, bin ich ja bekanntlich immer etwas nachlässig, eben weil man unter Linux (/ Mac) sich eigentlich nie um Treiber kümmern muss. Gerade mal an einem Windows-Rechner probiert. Tatsächlich muss man unter XP einen Treiber installieren, wenn man die Winkey-Funktionalität nutzen will... Der Keyer funktioniert für sich aber auch ohne Treiber einwandfrei, dann eben wie vorgestern (Grundfunktionen + Tastatur geht, Winkeyemulation nicht mangels COM-Schnittstelle).
Es scheint sich aber um den 08/15-Standardtreiber für USB/serielle Schnittstellen zu handeln, den man unter XP immer installieren muss.
73 Dominik
- DL7UCX
- Beiträge: 6503
- Registriert: Donnerstag 8. August 2002, 19:23
- Wohnort: Dabendorf
- Kontaktdaten:
Re: DL6ER-Keyer
Hallo Dominik,
in der Spezifikation steht auf Seite2:
"Echo back Morse in ASCII as it’s being sent ..."
Und das funktioniert augenscheinlich mit allen WinKey-Versionen.
73 Ben
in der Spezifikation steht auf Seite2:
"Echo back Morse in ASCII as it’s being sent ..."
Und das funktioniert augenscheinlich mit allen WinKey-Versionen.
73 Ben
Re: DL6ER-Keyer
Hallo Dominik,
vielleicht hilft es
73 Wolfgang
vielleicht hilft es
73 Wolfgang
- Dateianhänge
-
- SYSLOG.TXT
- (14.39 KiB) 201-mal heruntergeladen
Re: DL6ER-Keyer
Hallo Ben,
ja okay ... da war ich wohl nachlässig im Lesen, ich erinnere mich zwar an das Bild auf Seite 2, aber den Text habe ich scheinbar übersehen.
Aus Timing-Gründen habe ich keinen "Klartext"-Puffer, sondern nur einen Code-Puffer in dem direkt die Aktionen für den Keyer eingetragen sind:
E = dit
T = dah
' ' = dit-pause
'H' = 1/2 dit-Pause (jetzt neu für Winkey erforderlich gewesen)
Dadurch kann die Zeichengenerierung mit hoher Priorität und dadurch höchster (zeitlicher) Präzision erfolgen (es muss nicht immer nachgeguckt werden wie die einzelnen Zeichen zu geben sind).
Das Befüllen dieses Puffers erfolgt im Hintergrund, da man hier selbst bei 60 WpM noch massig Zeit hat. Die technische Grenze liegt irgendwo bei etwas über 250 WpM, aber ich glaube irgendwie das das keine echte Grenze für den Betrieb darstellt...
Der Vorteil von dem Verfahren wird in einem Vergleich offensichtlich: Ich habe mal 5er Gruppen mit 60 WpM erzeugt (1min). Die gleichen 5er Gruppen habe ich mit dem CW-Generator von LCWO (Fabian Kurz, DJ1YFK) erzeugt.
Dann beides mit einem Audioprogramm verglichen (1x Mikrofonaufnahme und 1x MP3-Import). Das Ergebnis: Es ist auf weniger als 5 Millisekunden nach 1 Minute identisch.
Die Präzission stimmt natürlich auch bei niedrigen WpM, aber da kann man nicht so gut auf Millisekundenbasis vergleichen.
Deswegen wird da jetzt auch nichts mehr dran verändert.
Also speichere ich jetzt den zuletzt angekommenen Buchstaben in einer Variable und gebe ihn zurück, wenn der Sendepuffer durchgelaufen ist. Das funktioniert natürlich nur, solange wie mir das Logbuchprogramm immer nur einen Buchstaben auf einmal übergibt. Das ist bei UcxLog der Fall und ich habe momentan weder Interesse noch Lust das mit irgendwelchen anderen Programmen zu testen.
Mit Echo kurz vor dem Abschluss des Zeichens sieht es so aus:
Ich erhalte dann direkt noch während dem Abschluss eines Zeichens ein Neues und das funktioniert wunderbar.
73 Dominik
ja okay ... da war ich wohl nachlässig im Lesen, ich erinnere mich zwar an das Bild auf Seite 2, aber den Text habe ich scheinbar übersehen.
Aus Timing-Gründen habe ich keinen "Klartext"-Puffer, sondern nur einen Code-Puffer in dem direkt die Aktionen für den Keyer eingetragen sind:
E = dit
T = dah
' ' = dit-pause
'H' = 1/2 dit-Pause (jetzt neu für Winkey erforderlich gewesen)
Dadurch kann die Zeichengenerierung mit hoher Priorität und dadurch höchster (zeitlicher) Präzision erfolgen (es muss nicht immer nachgeguckt werden wie die einzelnen Zeichen zu geben sind).
Das Befüllen dieses Puffers erfolgt im Hintergrund, da man hier selbst bei 60 WpM noch massig Zeit hat. Die technische Grenze liegt irgendwo bei etwas über 250 WpM, aber ich glaube irgendwie das das keine echte Grenze für den Betrieb darstellt...
Der Vorteil von dem Verfahren wird in einem Vergleich offensichtlich: Ich habe mal 5er Gruppen mit 60 WpM erzeugt (1min). Die gleichen 5er Gruppen habe ich mit dem CW-Generator von LCWO (Fabian Kurz, DJ1YFK) erzeugt.
Dann beides mit einem Audioprogramm verglichen (1x Mikrofonaufnahme und 1x MP3-Import). Das Ergebnis: Es ist auf weniger als 5 Millisekunden nach 1 Minute identisch.
Die Präzission stimmt natürlich auch bei niedrigen WpM, aber da kann man nicht so gut auf Millisekundenbasis vergleichen.
Deswegen wird da jetzt auch nichts mehr dran verändert.
Also speichere ich jetzt den zuletzt angekommenen Buchstaben in einer Variable und gebe ihn zurück, wenn der Sendepuffer durchgelaufen ist. Das funktioniert natürlich nur, solange wie mir das Logbuchprogramm immer nur einen Buchstaben auf einmal übergibt. Das ist bei UcxLog der Fall und ich habe momentan weder Interesse noch Lust das mit irgendwelchen anderen Programmen zu testen.
Mit Echo kurz vor dem Abschluss des Zeichens sieht es so aus:
Code: Alles auswählen
16:46-56.575 WinKey - Send: 7C 7C 43
16:46-56.576 Winkey - Sent completed.
16:46-57.071 WinKey timeout
16:46-57.344 WinKey received: 43
16:46-57.344 WinKey - Send: 7C 7C 51
16:46-57.344 Winkey - Sent completed.
16:46-57.845 WinKey timeout
16:46-58.217 WinKey received: 51
16:46-58.217 WinKey - Send: 7C 7C 7C 7C 7C 7C 7C 7C
16:46-58.217 Winkey - Sent completed.
16:46-58.218 WinKey - Send: 7C 7C 43
16:46-58.218 Winkey - Sent completed.
16:46-58.719 WinKey timeout
16:46-59.199 WinKey received: 43
16:46-59.199 WinKey - Send: 7C 7C 51
16:46-59.201 Winkey - Sent completed.
16:46-59.702 WinKey timeout
16:47-00.073 WinKey received: 51
73 Dominik
- DL7UCX
- Beiträge: 6503
- Registriert: Donnerstag 8. August 2002, 19:23
- Wohnort: Dabendorf
- Kontaktdaten:
Re: DL6ER-Keyer
Hallo Dominik,
ich würde das Zeichen schon zurücksenden, wenn die Aussendung beginnt (so würde ich auch die WinKey-Beschreibung deuten).
Dann ist mehr Zeit für die Übertragung des nächsten.
73 Ben
ich würde das Zeichen schon zurücksenden, wenn die Aussendung beginnt (so würde ich auch die WinKey-Beschreibung deuten).
Dann ist mehr Zeit für die Übertragung des nächsten.
73 Ben