Arduino oder PIC oder Atmel?

Zitat von DL2FI

Schwer zu beschreiben.

Moin,

denke, das könnte es treffen:
Umwandlung von Tastatureingaben auf zwei serielle High/Low Ausgänge.
Der eine produziert nur DITs, der andere nur DAHs.
Das Ganze standardmässig auf einen Stereoklinkenstecker geleitet.
Ab hier sieht der TX nur ein Paddle ohne Elektronik.

IAMBIC - gleich welcher Art - würde dann ja im Funkgerät generiert,
oder sehe ich das falsch? Die Simulation eines mechanischen Paddels
an und für sich beinhaltet keine Elektronik. Nur Hebel mit zwei
Kontaktpaaren...

Moin,

das hier https://blog.radioartisan.com/arduino-cw-keyer/ ist so der sehr weit verbreitete
Arduino-Keyer mit offener Software, der im WWW zu finden ist. So meine Recherche, als ich
noch den Funk-Fund der Woche im QRS NET-Thread bediente.

Vielleicht ist es ja möglich, die Dit-Dah-Erzeugung so umzuprogrammieren,
dass sie getrennt auf zwei Ausgängen zu finden ist.

Oder sowas https://brainwagon.org/2012/01…d-ibm-ps2-morse-keyboard/
hier.

Beim letzteren Link, liegt doch schon alles quasi bereit.
Da gibts 2 Funktionen dit und dah, und die muss man ja nur auf einen weiteren Pin legen...

void dit()
{
    digitalWrite(pin, HIGH) ;
    tone(tpin, FREQ) ;
    mydelay(ditlen) ;
    digitalWrite(pin, LOW) ;
    noTone(tpin) ;
    mydelay(ditlen) ;
 
}
 
void dah()
{
    digitalWrite(pin, HIGH) ;
    tone(tpin, FREQ) ;
    mydelay(3*ditlen) ;
    digitalWrite(pin, LOW) ;
    noTone(tpin) ;
    mydelay(ditlen) ;
}

z.B. wenn ich das richtig verstanden habe, mit dem keyer ...
Die um die Funktion mydeylay(ditlen) 2 Zeilen mehr :

digitalWrite(x,HIGH);
mydelay(ditlen) ;
digitalWrite(x,LOW);
wobei x entweder eine Pinnummer für Dit oder Dah ist.

Der rest der oben steht, kann wech...

Hallo,
ich sehe das Problem nicht im Prozessor, sondern im Timing. Die Keyerelektronik verlangt, daß das Dit und Dah zum richtigen Zeitpunkt kommt, und das steuert im Normalfall der Operator. Ändert man das Gebetempo im Keyer, muß auch das Tempo der Operators angepasst werden, sonst kommen die Dit/Dah zu schnell oder zu langsam. Der OP betätigt sein Paddle dann ja auch langsamer oder schneller, geschieht praktisch reflexartig
Man kann das Problem umgehen, indem man den Hubtasteneingang benutzt (so habe ich mein HM-Touchpaddle an den BCR angepasst). Allerdings kann man dann den Paddleanschluß nicht mehr benutzen. Auf alle Fälle muß die Gebegeschwindigkeit in der Tastatur eingestellt werden. Es dürfte einfacher sein, das Paddle in den Prozessor, der die Keybordtastatur "übersetzt", einzubinden, wie Keyer und Signale von der Tastatur in Gleichlauf zu halten, wenn man nicht mit Festwerten arbeitet.
Da ich gerade noch mal gelesen habe, Paddle-Signale sind Pflicht, dürfte es nur gehen, indem man die exakt gleichen Geschwindigkeiten für Keyerelektronik im Funkgerät und in der Tastatur einstellt, im Idealfall synchronisiert.
Letztlich kann man einen einfachen PC/Laptop (= Tastatur, viel Rechenleistung wird nur bei FT8 benötigt) benutzen und mit einem Programm wie Fldigi (oder anderes) das Funkgerät mit faktisch allen Modis steuern, von CW über (FT8) bis RTTY, PSK usw. Allerdings weis ich jetzt nicht, ob die Anschlußmöglichkeiten von KX2 und KX3 das zulassen, wenn ja, ist das die einfachste Lösung.

73 Reiner
Der Arduino-Keyer hat, soweit ich es überblicke, eine Vielzahl von Möglichkeiten und alle benötigten Anschlüsse, aber, wenn ich es richtig sehe, einfache Hubtastenausgänge. Ist auch logisch, ansonsten müssten ja wieder 2 Keyer (hintereinandergeschaltet) synchronisiert werden.

Vielleicht kann man die Synchronisierung noch anders lösen :
Das CW Signal wird vermutlich vom KX irgendwas in form eines Tons doch ausgegeben.
Wenn dieser Ton (siehe NF-Vox) als Fedback genutzt wird sind das 1-2 Zeilen code mehr, und das nächste Zeichen kommt erst dann durch, wenn ein dit oder dah gesendet wurde.

Hallo Peter,

hast Du nun eine Lösung gefunden?

:PUSH:

Zitat von DL2FI

Hintergrund: KX2/KX3 können bei Nutzung des internen keyers mit angeschlossenem Paddle intern RTTY und PSK erzeugen. Ein OM mit zittrigen Händen möchte das gerne nutzen. Tastatur kann er, Paddle nicht mehr.

Hallo Peter,

Ich wollte Dich das eigentlich schon in Schluchsee fragen, hatte es aber vergessen und bin erst heute wieder nach Hause gekommen:
KX2/KX3 haben doch eine Serielle CAT Schnittstelle. Was spricht dagegen, wenn man schon einen kleinen Rechner zur Abfrage der Tastatur braucht und relativ sicher auch den Mithör-ton "lesen" muss, dann gleich eine CAT-Schnittstelle zu nehmen: Das, was getippt wird, geht als CAT-Kommando zum Senden an den TRX. Ob dann noch die akustische Rückmeldung aus dem TRX kommt, oder man ggf noch einen kleinen Lautsprecher braucht, wäre dann noch zuklären.

Wenn ein Laptop dann nicht schon zu groß ist, könnte man das Ganze ohne extra-Hardware (ggf. mit einem isolierten Modem) nur mit Software erledigen, wie es bei den digitalen Betriebsarten üblich ist. Oder hat der OM eine Abneigung gegen PC und Software beim Funken?

vy73 de Karsten, DD1KT

Moin,

ich habe den Thread verfolgt, mich aber rausgehalten, weil ich den KX3 überhaupt nicht kenne.

Die Tücken von Peters Ursprungsidee wurden ja bereits rausgearbeitet: der "Tastatur-Paddle-Adapter" darf nicht nur einfach ein "normales" 1:3-CW statt auf einen Ausgang auf zwei Ausgänge rausgeben (also Punkte und Striche getrennt), sondern er muss so arbeiten wie ein menschlicher CW-Operator.

Er braucht eine Rückkopplung über den Mithörton und darf z.B. auf dem Strichausgang nicht einfach nur normale Striche ausgeben, sondern muss z.B den jeweils letzten Strich oder Punkt verkürzen, damit nicht bei Timing-Abweichungen ein Strich oder Punkt zu viel rausrutscht.

Die Signalrückgewinnung aus dem Mithörton SOLLTE zwar nicht allzu schwierig sein, aber das müsste man erst mal an einem KX3 testen (ob da nicht doch irgendwelche Schmutzeffekte auftreten).

Ich hatte allerdings beim Mitlesen des Threads das Gefühl, dass mit diesem "Tastatur-Paddle-Adapter" vorschnell eine Idee gefunden wurde, die subobtimal ist.

Jetzt habe ich mir mal das Handbuch des KX3 runtergeladen und die (32bit)-Linux-Konfigurations-Software für den KX3 (hab' kein Windows mehr).

Der Hinweis von DD1KT auf die CAT-Schnittstelle scheint mir goldrichtig zu sein. Der KX3 hat RxD und TxD auf eine 3,5mm-Klinkenbuchse rausgeführt und mit einem USB-Seriell-Wandler und der Konfigurations-Software kann man offenbar das Gerät KOMPLETT fernsteuern.

Die Konfigurations-Software hat ein Terminalfenster, in dem man beliebige Befehle und Texte eingeben kann, also vermutlich auch die Texte, die als PSK31-Signal ausgesendet werden sollen. Und man kann allerlei Makros auf irgendwelche Buttons legen, um sich das Leben zu vereinfachen.

Das wäre die einfachste Lösung, wenn der OM einen PC hat.

Hat er aber vermutlich nicht; sonst wäre Peter da wohl drauf gekommen.

Trotzdem ist die CAT-Schnittstelle die solidere Lösung. Da sie TTL-Pegel (oder 3,3V-Pegel) aufweist, könnte man sie auch direkt mit einem Mikrocontroller ansteuern. Der Mikrocontroller könnte dann ein paar Eingänge für hart einprogrammierte Makros aufweisen, und für PS2-Tastaturen gibt es Arduino- bzw. Bascom-Libs (wobei ich nicht sicher bin, ob die Lib bei Bascom standardmäßig vorhanden oder kostenpflichtig ist; ich glaube, die Befehle zur ABFRAGE von PS2-Tastaturen sind standardmäßig dabei; die Emulation einer Tastatur kostet extra).

Die optimierte Aufgabenstellung wäre also:

Ein AtMega bzw. ein Arduino-, der eine PS2-Tastatur und ein paar Taster (für Makrobefehle) abfragt und ein serielles TTL-Signal ausspuckt und Rückmeldungen der seriellen Schnittstelle auswertet.

Für den Empfang bräuchte man ja auch noch eine Anzeigemöglichkeit. Man könnte z.B. ein 4zeiliges LC-Textdisplay nehmen - aber das serielle Empfangssignal auf ein kleines Grafik-LCD zu bringen ist auch keine "schwarze Kunst".

Das scheint mir recht übersichtlich. Ich würd' mich da ranmachen, wenn ich einen KX3 hätte, aber ohne ein Gerät für Vorversuche und zum Testen wäre mir das zu mühsam und fehlerträchtig. Und vielleicht gibt es da in der Praxis doch noch irgendeinen Show-Stopper, an den man nicht gedacht hat.

73,
Ralf

Ich war neugierig und habe mal mit der Konfigurations-Software "Elecraft KX3 Utility ("kx3util") herumgespielt.

Mangels eines KX3 habe ich zwei USB-Seriell-Wandler mit einem Nullmodemstecker gekoppelt. Der eine wurde von "kx3util" belegt, auf dem anderen lauschte das Terminalprogramm "hterm 0.81b"

Die Beschreibung des Elecraft-CAT-Protokolls ist etwas dürftig, weil sie nicht bei "Adam & Eva" beginnt, deshalb war etwas reverse engineering nötig.

Wenn ich bei kx3util "Test Communications" anclicke, sagt er nach einer Weile "KX3 is not responding". Auf dem Hterm kommt nur Müll an, ausser bei 4800 bit/s 8N1:

Ein ASCII-Zeichen dezimal 255, dann meist ein "s" und zwei Semikolon.

Mit Hterm habe ich auf Verdacht die ID zurückgesendet; nach etwas Doku lesen dachte ich, der String müsste "id017" oder "idk3n" lauten, aber nach weiterem Herumprobieren reagierte das kx3util auf den String ";k3n".

Den habe ich automatisch mit Hterm "abgefeuert", weil eine händische Eingabe zu langsam war. Hterm hat den String ";k3n" auf Verdacht 50 mal mit 10ms Abstand "rausgehauen", und das kx3util nahm sich den erstbesten, der gerade passte.

Nachdem kx3util meint, es mit einem Elecraft-Transceiver zu tun zu haben, schickte es weitere Befehle, mit denen es die Zusatzausstattung und Firmareversion abzufragen versucht:

"RVM;RVD;OM;ER83FA0281;"

Dann kommt allerdings wieder ein Timeout, weil keine KX3-Antworten eingehen.

Aber man sieht, dass die Kommunikation recht gemächlich läuft (4800 bit/s) und dass die Befehle, die im Manual stehen, anscheinend mit ";" eingeleitet werden müssen.

Ein Mikrocontroller müsste also den KX3 auf PSK31 konfigurieren, dann mit dem Befehl "tt" bzw. ";tt" den KX3 auf transparent schalten und anschliessend alles 1:1 durchreichen, was von der PS2-Tastatur kommt. Und alles, was über die serielle Schnittstelle reinkommt, auf ein LCD ausgeben.

Wäre also alles recht überschaubar, sofern man etwas Erfahrung mit Arduinos hat und Zugriff auf einen KX3 fürs Testen.

73,
Ralf

Hallo Ralf,
die CAT-Befehle an den KX3 müssen nicht mit ; beginnen sondern enden . Ohne ein CR LF!
Die Baudrate ist 4800 Baud.
Das KX3util kenne ich nicht, aber ich schaue es mir mal an.

Hallo Jürgen, hallo Peter,

danke für die Hinweise. Die Bitrate des Konfigurationsprogrammes scheint also fest auf 4800 bit/s eingestellt zu sein, während der KX3 sich automatisch anpasst. Und der Befehl, den ich als Serie zurückgefeuert hatte, hätte also "k3n;" statt ";k3n" heissen müssen.

Trotzdem ist mir noch nicht klar, welche initiale Befehlsfolge das Konfigurationsprogramm beim "Communication Test" an den KX3 sendet. Erwarten würde ich sowas wie "id;" - aber das tauchte beim Belauschen mit dem Hterm nicht auf. Oder reicht ein simples ";" um den KX3 aufzuwecken ?

Tja, ohne Hardware ist das doch alles schwierig, und das "Programmers Reference", in das ich bereits reingeguckt hatte, schweigt sich über solche Basics aus.

Aber vielleicht wird nun jetzt jemand "angefixt", der einen KX3 hat und schon mal mit der Arduino-Umgebung programmiert hat.

73,
Ralf

Hallo Funkfreunde,
die Fernsteuerung über die CAT-Schnittstelle habe ich mal mit einem Arduino ausprobiert ( Schaltung s.u.).
In Mode "CW" kann man mit dem Kommando "KY Test über CAT;"
den Text "Test über CAT" in CW ausgeben , ebenso im Mode "FSK D" in RTTY, auch im Mode "PSK D" (**);
diese Betriebsart "PSK D" = PSK31 war ja ursprünglich gewünscht.

73
Heribert

(**) Mode "PSK D" läuft erst nach einem Softwareupdate des KX3 (serNr 2995) mit dem Kommando "KY xxxx;" ,
jetzt habe ich Version 2.90 MCU / 1.52 DSP

Hallo Heribert,

welche Geschwindigkeit hast Du auf der seriellen Schnittstelle verwendet?

Hast Du den String "KY Test über CAT;" im Arduino fest einprogrammiert oder bereits mit dem PS2-Keyboard erzeugt?

Ein PS2-Keyboard sendet bei Drücken und Loslassen einer Taste jeweils einen Scancode, der sprachunabhängig ist. Erst der PC-Tasturtreiber macht daraus ein lokalisiertes Zeichen.

Wenn man auf einer deutschen Tastatur ein "ö" drückt, kommt der gleiche Scancode wie auf einer US-Tastatur beim Drücken des ";", weil die jeweils an der gleichen Stelle auf der Tastatur liegen.

Die Arduino-PS2-Library wandelt den Scancode in das US-Äquivalent, d.h., die gibt statt eines "z" ein "y" und statt eines "ö" ein ";" aus. Das muss man dann leider noch umcodieren.

Oder hast Du die interne Tabelle der PS2-Library bereits auf deutsche Verhältnisse angepasst?

Bei der Arduino-USB-Tastatatur-Emulation des Arduino Leonardo oder Arduino Micro ist das übrigens ähnlich, aber genau umgekehrt. Wenn man ein "ö" auf den PC-Bildschirm zaubern will, muss das virtuelle Arduino-Keyboard ein ";" aussenden.

Ich hatte mir mal vor ein paar Jahren ein Array mit einer Übersetzungstabelle angelegt, die den letzteren Fall abdeckt; sie macht aus einem deutschen Zeichen erst mal ein amerikanisches, damit der deutsche PC-Ttastaturtreiber da wieder ein deutsches daraus macht
http://www.elektronik-labor.de/Arduino/Leonardo3.html

73,
Ralf

Zitat von DK5BU

Hast Du den String "KY Test über CAT;" im Arduino fest einprogrammiert oder bereits mit dem PS2-Keyboard erzeugt?

Hallo Ralf,
ich habe nicht mit PS2-Tastatur getestet. Ich habe aus dem Arduino auf Knopfdruck einen festen String gesendet. Für mich ist die CAT Fernsteuerung total neu.
Test mit PS2-Tastatur steht noch aus. Eine Umcodiertabelle dürfte nicht schwer sein.

73
Heribert

Zitat

Eine Umcodiertabelle dürfte nicht schwer sein.

Stimmt, allerdings könnte es mit "exotischen" Zeichen, für die man auf einer deutschen Tastatur die "AltGr"-Taste drücken muss (z.B. "\"), Probleme geben, weil die Arduino-PS2-Library das gar nicht vorsieht. Aber ich weiss nicht, ob die im Elecraft-CAT-Protokoll überhaupt vorkommen.

An sich ist das Elecraft-CAT-Protokoll schön simpel, weil es ASCII-Zeichen verwendet. Ich hatte mal mit dem ICOM-Protokoll herumgespielt, und das war eine ziemliche Bit-Kniffelei.

Aber da ich keinen Elecraft-TRX habe und nur in das "Programmers Reference" gucken kann, höre ich mal mit dem Klugscheißen auf und überlasse das Feld den OMs, die das alles direkt an einem Gerät austesten können.

73,
Ralf