Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Forum der DL-QRP-AG für QRP und Selbstbau im Amateurfunk. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Mittwoch, 26. September 2018, 11:37

Arduino oder PIC oder Atmel?

ist mir eigentlich egal, Hauptsache es funktioniert. Gebraucht wird eine Möglichkeit, Tastatureingaben (PS2 Tastatur) in die Emulation eines Paddles umzusetzen. PS2 auf Key gibt es als fertige Lösung schon, das ist nicht mein Problem, es soll diesmal Tastatur auf IAMBIC A umgesetzt werden. Schwer zu beschreiben. Rauskommen müssen zwei serielle strings, wie sie ein Paddle erzeugt, also nicht ein String in der Form

DI DI DAH _ _ _ ___ emuliert eine sehr exakte Hubtaste

sondern zweikanalig
DI DI DI ___ Emuliert Iambic A Eingabe am Eingang einer Keyer Elektronik
DAHxxxxxx . (musste x nehmen, da der Editor Leerzeichen frisst und TAB nicht kennt)


Kommt mir vor, wie eine umgekehrte keyer Elektronik ? Spannende Aufgabe? Dann nix wie ran, ich kann sowas nicht :thumbsup:



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.
73/2 de Peter, DL2FI
Proud member of Second Class Operators Club SOC and Flying Pig Zapper #OOO (Certificated Kit Destroyer)

2

Mittwoch, 26. September 2018, 11:56

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...
73 de Michael, DF2OK Ein Mensch, der keine Zeit hat, nimmt sich ganz einfach zu wichtig. Webseite qrz.com YouTube Twitter
~ DARC ~ G-QRP-Club ~ DL-QRP-AG ~ AGCW ~ FISTS ~ QRPARCI ~ SKCC ~

3

Mittwoch, 26. September 2018, 12:23

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...
So ungefähr, Michael. Es ist wohl in erster Linie ein Timing Problem.
Iambic entsteht in der Iambic Electronic im Gerät - richtig.
Das mechanische Paddle legt den Eingangskontakt links kurz auf LOW, die Elektronik macht daraus einen Punkt mit der Länge die zur eingestellten Geschwindigkeit passt, rechts wird mit einem kurzen LOW ein Strich der entsprechenden Länge produziert.

Wird eine der beiden Seiten länger gehalten, entstehen daraus mehrer Punkte oder Striche.
Der Mensch passt sich je nach Können / Kunst ziemlich automatisch an, wenn er es richtig kann, wird sogar SQUEEZE daraus :thumbsup:
Ich bin sicher, dass man das in einem Prozessor nachempfinden kann, aber ich weiß leider nicht wie. Wahrscheinlich wird es einfacher, wenn man ein einziges Tempo festlegt :whistling: deswegen der Hilferuf hier im Forum :P
73/2 de Peter, DL2FI
Proud member of Second Class Operators Club SOC and Flying Pig Zapper #OOO (Certificated Kit Destroyer)

4

Mittwoch, 26. September 2018, 12:45

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/21/an-ard…morse-keyboard/
hier.
73 de Michael, DF2OK Ein Mensch, der keine Zeit hat, nimmt sich ganz einfach zu wichtig. Webseite qrz.com YouTube Twitter
~ DARC ~ G-QRP-Club ~ DL-QRP-AG ~ AGCW ~ FISTS ~ QRPARCI ~ SKCC ~

5

Mittwoch, 26. September 2018, 13:32

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...

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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...

  • »DL8LRZ« ist männlich

Beiträge: 572

Hobbys: Bastelei rund um TRX und Computer

  • Nachricht senden

6

Mittwoch, 26. September 2018, 14:33

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.

7

Freitag, 28. September 2018, 22:38

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.

8

Freitag, 5. Oktober 2018, 17:55

Hallo Peter,

hast Du nun eine Lösung gefunden?

:PUSH:
73 de Uwe
DC5PI

9

Sonntag, 7. Oktober 2018, 23:33

Anderer Ansatz

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

10

Montag, 8. Oktober 2018, 11:37

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

11

Montag, 8. Oktober 2018, 12:45

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
Karsten, das kann der KX3 von Haus aus, ein simples Terminal Programm reicht aus. Der KX3 kann simple ASCII in CW oder PSK umsetzen, kann selbst dekodieren und als ASCII zurück schicken.
Der OM möchte aber die andere Möglichkeit nutzen: Gibt man mit einem Paddle CW Zeichen unter Benutzung des internen keyers ein, dann kann der KX3 daraus RTTY oder PSK machen und senden. Die dekodierten RTTY oder PSK Signale werden im KX3 oder im angeschlossenen P3 lesbar angezeigt. Der Haken dabei: Er hat zittrige Hände und kann kein Paddle benutzen. Einen PC will er nicht, er will nur eine Tastatur :rolleyes:
73/2 de Peter, DL2FI
Proud member of Second Class Operators Club SOC and Flying Pig Zapper #OOO (Certificated Kit Destroyer)

12

Montag, 8. Oktober 2018, 12:53

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".
Ja, Ralf, ich denke, das wäre die optimale Lösung. Die "Simulation des Menschen, der persönlich morst" wäre dann wohl doch von hinten durch die Brust ins Auge geschossen.
Jetzt muss nur noch ein KX3 Besitzer, der programmieren kann nen Hieper auf so ein Projekt bekommen :thumbsup:
73/2 de Peter, DL2FI
Proud member of Second Class Operators Club SOC and Flying Pig Zapper #OOO (Certificated Kit Destroyer)

13

Montag, 8. Oktober 2018, 16:44

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
»DK5BU« hat folgendes Bild angehängt:
  • hterm.png

  • »DJ4JZ« ist männlich

Beiträge: 799

Hobbys: Antennen QRP Meßgeräte Selbstbau, Solf #023, Mikrocontroller Programmierung

  • Nachricht senden

14

Montag, 8. Oktober 2018, 17:50

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.
vy73 Jürgen

15

Montag, 8. Oktober 2018, 17:59

Super Arbeit, Ralf, mni tnx.
Eigentlich sollte die Programmers Reference alle benötigten Befehle enthalten. Da ich selbst nicht programmiere, habe ich mich nicht ausführlich beschäftigt. Die Utility kommuniziert mit allen üblichen Baudraten bis 38400, kritisch ist (zumindest habe ich mal so etwas gehört) wohl der Stop Schritt. Ich glaube Elecraft ist da auf 1 Stop festgelegt. Die Utility tickert der Reihe nach alle Baudraten durch, bis sie die beim KX3 eingestellte gefunden hat.
73/2 de Peter, DL2FI
Proud member of Second Class Operators Club SOC and Flying Pig Zapper #OOO (Certificated Kit Destroyer)

16

Montag, 8. Oktober 2018, 18:24

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

17

Montag, 8. Oktober 2018, 22:33

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
»dk2jk« hat folgendes Bild angehängt:
  • kx3 interface arduino.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dk2jk« (9. Oktober 2018, 10:30)


18

Dienstag, 9. Oktober 2018, 10:25

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

19

Dienstag, 9. Oktober 2018, 10:37

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

20

Dienstag, 9. Oktober 2018, 10:55

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