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)

  • 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)

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



    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.

  • 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