Morse-Übungsgenerator mit Mikroprozessor

  • Danke, dachte das wäre eine vorläufige Version.


    Ich will ja nicht unverschämt sein (oder doch?) aber könnte man die erforderlichen Fuse Bits anstatt als Hex-Wert auch namentlich benennen, damit man als nicht C-Programmierer, der nicht mit AVRDude brennt, seine Häkchen in einem AVR-Programmer mit graphischer Oberfläche setzen kann? Wäre eine große Erleichterung.


    tnx. Günter

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)

  • Die Software läuft nur auf atTiny45 oder atTiny85, deshalb ist die Betrachtung anderer nicht relevanter µP unbrauchbar.


    Die angehängten Bilder zeigen die realen max. Ströme und Spannungen des tiny85, nur als Info, ich will darüber nicht diskutieren.


    Hallo Uwe, der von mir angebrachte Punkt der Portüberlastung hat nichts mit dem µP zu tun, daher ist die Betrachtung anderer µP doch relevant :)
    Die angehängten Kurven hören bei 20 mA auf, und das hat seinen Grund, genau genommen viele Gründe.


    Wenn ich den Strom höher als erlaubt wähle, kann, speziell bei statischer Ansteuerung, die lokale Verlustleistung auf dem Chip überschritten werden.
    Zusätzlich können noch Migrationseffekte auftauchen. Die Metallisierung innerhalb des Chips ist für bestimmte Maximalströme ausgelegt, üblicherweise per Pin,
    per Port und für die Summe von allen. Verletze ich diese langfristig kann die Metallisierung sich verändern. Hier gibt es zwischen Kurzschluss und hochohmig werden
    alle möglichen Varianten.


    Bei dynamischer Ansteuerung tauchen andere "Schmutzeffekte" auf. Wenn der Strom durch den Pin, und damit durch den gesamten Prozessor, nur noch durch den Widerstand des Ausgangstransistors beschränkt wird belaste ich meine Versorgung mit dem Laststrom. Das kann man natürlich durch entsprechend gute Abblockung der Versorgung nach außen hin in den Griff kriegen. Spannend ist aber was im Chip passiert: Die höhen Ströme können zu einer lokalen Verschiebung der Versorgungsspannung führen, mit dem unerwünschten Effekt dass irgendwelche Gatter oder Flip-Flops nicht mehr so recht wissen was sie eigentlich sind.


    Unvermeidbar ist auch eine kapazitve Kopplung, die intern weitere lustige Effekte verursachen kann. Wenn die Logik die meine Ausgangstransistoren treibt nicht mehr so recht weiß was sie eigentlich ist dann können auch mal beide Transistoren gleichzeitig eingeschaltet werden.


    Diese Liste kann man noch beliebig fortsetzen.


    Das fiese bei dieser Art von Fehlern ist dass sie meist sproradisch auftreten, da abhängig von Temperatur, Versorgungsspannung, Prozess bei der Fertigung...
    Die Migrationseffekte werden durch höhere Temperaturen verstärkt, und sind natürlich auch zeitabhängig. So kann es z.B. passieren dass ein Prozessor bei Raumtemperatur niemals einen Ausfall zeigt, bei Betrieb mit höherer Temperatur aber relativ schnell dauerhaft ausfällt.


    Gruß aus Wuppertal


    Dieter DD5DD

  • Hallo QRPForum,


    die letzte und fehlerfreie Firmware für den Morse-Übungsgenerator mit Mikroprozessor ist fertig.


    Nach vielen Tagen debuggen, bin ich gestern Nacht auf die Lösung gestoßen:


    Ich dachte der Prozessortakt von 8Mhz, reicht für die Ausgabe der 128-PWM-Sinus Tabellenwerte aus, leider war das nicht so. Somit stimmte die Ausgabefrequenz nicht mit der kalkulierten überein !
    Problem es wurden einige PWM-Sinus Werte ausgelassen und insgesamt war der Ton dann höher.


    Abhilfe schaffte heute das Neuschreiben der Timer0 Interrupt Service Routine (ISR), die Umstellung der Programmlogik und das anheben des Prozessortakt auf 16Mhz.


    Hier die Einstellungen für meinen ISP-Programmer avrdude:

    Code
    # set fuse-bit
    # 16MHz PLL
    #avrdude -c usbasp -p attiny85 -P usb -U lfuse:w:0xc1:m -U hfuse:w:0xdc:m
    # Programm
    avrdude -c usbasp -p attiny85 -P usb -B 25 -U flash:w:main.hex:i


    Das Programm benötigt nun 3953 Byte Flashspeicher (tiny45 max. 4096 Byte) und somit kann nur ein atTiny45 oder atTiny85 verwendet werden.


    Das HEX-File für beide µP Versionen findet ihr im Anhang.


    Über PB4|B3 ist weiterhin die Auswahl der Tonfrequenz möglich:


    PB4|B3 = 11 : 660Hz
    PB4|B3 = 10 : 570Hz
    PB4|B3 = 01 : 750Hz
    PB4|B3 = 00 : 840Hz


    Der Schaltplan hat sich nicht verändert und kann hier


    - http://www.qrpforum.de/index.p…0110138ae53f705a9e078888f


    geladen werden.


    .

  • Hallo Uwe,


    super, dass Du den Bug gefunden hast! Noch etwas zu den Reaktionszeiten beim Morsen (Entprellen). Wie schnell wird der Mikroprozessor auf einen Tastendruck reagieren? Wie schnell wird er auf das Loslassen reagieren? Wenn Du mit 10ms entprellst, dann kann die Reaktionszeit ja gar nicht schneller als 10 ms sein, oder? Würde Entprellen mit 1 ms auch funktionieren?


    Zum Vergleich: Das Tempo 125 Buchstaben pro Minute (25 Worte pro Minute) ist für gute OPs an einer Hubtaste realistisch. Mit 50 Punktlängen pro Wort (siehe hier) ist ein einziges Dit nur 60/(50 * 25) = 48 ms lang.


    73 Daniel DM3DA

  • Hallo Daniel,


    das Entprellen und die Auswertung der Taste (AN / AUS) finden in drei verschiedenen Task statt.


    Siehe "main.h" in dem Quellcode:


    Code
    #define DEBOUNCETICK				5
    #define ADD_SCHEDULER_DEBOUNCE()		timeradd( task_debounce, SECONDS( (double)DEBOUNCETICK/1000.0 ) )
    #define ADD_SCHEDULER_PRESS_PADDLE()		timeradd( task_press_paddle, SECONDS( 0.02 ) )
    #define ADD_SCHEDULER_RELEASE_PADDLE()		timeradd( task_release_paddle, SECONDS( 0.02 ) )


    Alle 20ms wird überprüft, ob sich der Status der Taste geändert hat, da erst nach 4 Durchläufen der Entprellroutine task_debounce ein Ergebnis anliegt.


    Evtl. kann ich hier noch etwas anpassen und den Task task_debounce auslagern und wieder in der ISR ausführen.


    Aber es ist auch wichtig, das alles was in einer ISR steht, sollte so schnell als möglich abgearbeitet wird !


    Dort verbraucht diese Routine dann evtl. wichtige Rechenzeit, die sonst vom Programmteil der PWM-Sinus Erzeugung gebraucht wird.


    Alles was außerhalb einer ISR läuft - also in einem Task - kann jederzeit von einem Interrupt unterbrochen werden.


    Reichen Dir DEBOUNCETICK 1ms und task_press_paddle, task_release_paddle 5ms ?


    -- Vielleicht fällt mir da noch etwas anderes ein. --


    CW-Kurs mit DG4FDQ
    Reinhard, DG4FDQ fängt nächste Woche wieder einen CW-Kurs an, da möchte ich ihm den kleinen Morse-Übungsgenerator mit Mikroprozessor vorstellen und hoffe er gefällt ihm.
    Falls die OMs aus dem Kurs auch gefallen daran finden, könnte man wir im OV ein kleines Bauprojekt daraus machen.


    Ein Platine ist bei den wenigen Bauteilen schnell geroutet.


    Ausblick
    Michael, DF2OK hat mir in seinem Beitrag Tonqualität noch eine schöne Anregung gegeben.
    Ich habe mir eben beim Radtraining schon eine Umsetzung der tönenden Telegrafie überlegt und werde dazu den zweiten PWM an PB4 aktivieren.
    Der PWM an PB4 erzeugt dann die zur PWM an PB1 gehörenden "Oberwellen", die wir dann mit OPA aktiv mischen können. Danach kann danach kann dann keiner Verstärker alias LM386 kommen. Ich habe noch Analog Device SSM2211 da.


    Mit einem Poti können wir auch den Mischfaktor, also die Oberwellenlautstärke beeinflussen.


    .

  • Hallo Uwe,


    kurz zu Michaels Hinweis auf die Tonqualität. Das Sägezahnsignal erspart alle Anti-Plopp-Funktionen. Du fängst ja immer bei Null an, dann kommt eine gleichmäßige Steigung, bis der Zahn abrupt abgebrochen wird. Start und Stopp geht in jeder Geschwindigkeit. Der letzte, unvollständige Zahn ist einfach nur leiser als die anderen. Und kürzer, aber das betrifft nur eine einzige Welle.


    Wenn Du einen "rauhen" Hochgeschwindigkeits-Modus einbauen möchtest, dann idealerweise einen echten Sägezahn. Wenn die RC-Filterung klein genug ist, bekommst Du auch all die Oberwellen, die Du haben möchtest.


    Vielleicht braucht der Sägezahn gar keine Tabelle. Einfach nur den PWM hochzählen sollte doch reichen, oder?


    Angehängt die Sägezahnvariante der Abbildung von Posting Nr. 49602. Du siehst: viel deutlicher, viel schärfer. Und die Information in den Oberwellen lassen sich nutzen, wie Michael oben ja deutlich beschreibt.


    73 Daniel DM3DA

  • Hallo Daniel,


    vor Deinen bzw. Euren Programmierkenntnissen ziehe ich meinen Hut, darin habe ich mich noch nie eingearbeitet. Vielleicht mal, wenn ich das Rentenalter erreichen sollte. ;) Habe früher (C64) mal ein wenig mit Basic gespielt, vorhandene Programme etwas angepaßt oder später ein paar einfache ! Progrämmchen in Turbo-Pascal getippt. Aber das ist laaaange her, hi. Und nicht vergleichbar mit den ganzen modernen Sachen hier im AFU.


    Das, was Ihr entwickelt, liest sich gut und sieht auch so aus. So ein richtig guter ! Morsegenerator als Einzelgerät fehlt mir auch noch.

    73 Michael, DF2OK.

    ~ "Nur die Weisesten und die Dümmsten können sich nicht ändern." (Konfuzius *551 v. Chr. †479 v. Chr.) ~


  • Hallo Michael,


    ich bin mir sicher, dass ich auch nicht mehr Progammier-Erfahrung habe als Du. Außer vielleicht, dass ich mir mal das Python Tutorium angesehen habe. Die Bespiele abgetippt und die Übungen durchgeführt. Wirklich zu empfehlen, macht Spaß.


    Nur gut, dass Uwe Mikroprozessoren programmieren kann :)


    73 Daniel DM3DA

  • Hallo Uwe,


    nochmal eine kurze Zusammenfassung des Programmablauf - habe ich die wesentlichen Punkte richtig verstanden? Die einzelnen Schritte (ohne LED) sind:


    • Der Prozessor geht an und spielt den Begrüßungstext.
    • Die PWM stellt die Spannung an Pin 6 auf die halbe Betriebsspannung (2,5 V).
    • Der Prozessor wartet, bis ich die Morsetaste drücke.
    • Sobald die Morstaste gedrückt wird, passiert folgendes:
    • Der Prozessor überprüft, ob das auch stimmt (= Entprellen). Dieser Schritt sollte idealerweise nur 1 ms dauern.
    • Wenn die Taste auch wirklich gedrückt wurde, beginnt die PWM mit der ersten Tabelle "up". Das sind 6 Wellen, die von Null bis zur maximalen Amplitude ansteigen. Genau wie in Deinem Programm, siehe 49602.
    • Daran wird die Sinustabelle angehängt und wiederholt. Und zwar so lange, wie der Ton erklingen soll.
    • Währenddessen überprüft der Prozessor, ob die Morsetaste noch gedrückt ist. Geht das einmal pro Sinuswelle? Oder einmal pro 1 ms? (Bei 660 Hz dauert eine Sinuswelle 1,5 ms).
    • Wenn die Morsetaste nicht mehr gedrückt ist, führt der Prozessor die aktuelle Sinustabelle aus. Dann beginnt die Tabelle "down", bis der Spannungsmittelwert erreicht ist.


    Jetzt meine Fragen:


    Wie lange dauert es vom ersten Drücken der Morsetaste bis die PWM reagiert und die Tabelle "up" startet? Ideal wäre ca. 1 ms.


    Wie lange dauert es vom Loslassen der Taste bis zum Beginn der Tabelle "down"? Ideal wäre innerhalb der aktuellen/nächsten Sinuswelle.


    Ich fürchte 5 ms Reaktionszeiten sind viel zu lang. Wie gesagt, die Punktlängen von "normalem Morse" sind um die 50 ms lang. Schnelles Morsen ist noch viel kürzer. Mein K2 (DSO-Screenshot oben) macht bei Tempo 40 WpM Punktlängen von etwa 30 ms. Ich kann mir nicht vorstellen, dass Leute mit einer Handtaste oder Rechts-Links-Taste mit einer wie auch immer merkbaren Zeitverzögerung glücklich werden.


    73 Daniel DM3DA

  • Hallo Uwe,


    noch ein Gedanke zum Entprellen: Der Schalter, den Du abliest, ist ein Präzisionsinstrument, dass neu 100 Euro und mehr kosten kann. Für einen einzigen Druckschalter! Du kannst also davon ausgehen, dass die Mechanik des Schalters (Morsetaste) weitgehend prellfrei ist. Vielleicht reicht dann auch eine Entprellfunktion von 0,5 ms?


    Die hohen mechanischen Anforderungen an die Hubtasten sind vermutlich auch der Grund, warum Hubtasten im Morselabor unterrepräsentiert sind.


    73 Daniel DM3DA

  • Der Schalter, den Du abliest, ist ein Präzisionsinstrument, dass neu 100 Euro und mehr kosten kann. Für einen einzigen Druckschalter! Du kannst also davon ausgehen, dass die Mechanik des Schalters (Morsetaste) weitgehend prellfrei ist.


    Bitte doch im Auge zu behalten: Es ist ein Morse-Übungsgenerator.
    Will heißen, derjenige, der einen Morseübungsgenerator braucht, hat oft keine Präzisionsmorsetaste, sondern nur eine Billigtaste zum Üben. Und ein CW High-Speeder braucht sicher keinen Übungsgenerator mehr. Also sollte doch die Konstruktion nicht so an der Grenze liegen, dass dabei ein zwar genial einfacher Generator herauskommt, der aber nur an teuerer Präzisions-Mechanik zufriedenstellend funktioniert.


    Hat vielleicht jemand ein Speicherscope und kann den Prellvorgang ( Batteriestromkreis über Vorwiderstand schalten) einfach mal kurz testen und dokumentieren, so dass man - anstatt im Dunkeln zu tappen - für die Prellzeiten einer guten Taste und eines einfachen Drucktasters einen aussagekräftigen Hinweis bekommt? Ein simples RC-Glied als Deglitcher zwischen Taster und Tiny muss nicht auf Polling oder einen Interrupt warten und hilft zur Unterstützung der Entprellung sicher ein Stück weiter.


    73, Günter

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)

    Edited 3 times, last by DL4ZAO ().

  • Guten morgen Daniel,


    da hast du mir ja eine schöne Aufgabe geben. ^^


    Ich will es mir mal einfach machen, die Entprellroutine (debounce) wird sicherlich für den Übungsbetrieb ausreichen schnell sein.

    • Ich gehe davon aus, dass Anfänger nicht so teuren und guten Tasten haben. Also eher etwas einfacheres.
    • Bisher habe wir auch keine Praxisrückmeldungen, ob es überhaupt ein Problem, bei zu schnellem Tempo/ Geben, gibt.
    • Diese neue Anforderung hätte man ganz am Anfang des Programmdesign berücksichtigen sollen, so müsste ich einen Großteil der Programmlogik umschreiben. Lust habe ich jetzt keine
    • Aber eine Idee wie es trotzdem gehen könnte, habe ich mir schon überlegt -wäre aber mit zusätzlichem Hardwareaufwand verbunden.
      Siehe Artikel: Hardwareentprellung
      [Blocked Image: http://www.mikrocontroller.net…s/b/b0/NAND_debouncer.png]

    Zu Deiner Ausführung Programmablauf versuche ich einiges klar zu stellen, siehe auch das Mindmap-Bild.

    • Das Programm wartet generell nicht, alles ist im "Fluss" über den Taskmanager.
    • Der Taskmanager stellt das Benutzerinterface dar, über ihn sind Interaktionen mit Programmkern möglich: die LED blinkt (Out), die Frequenzauswahl (In) und, das Paddel/ Taster abfrage (In).
    • Die gesamte Tonerzeugung findet über die beiden Timer1 PWM-Signal und Timer0 Sinusschwingung statt.
    • Timer0 hat auch noch andere Aufgabe und ist u.a. der Kern die alle zeitkritischen Aufgaben zuständig
    • Timer1 ist eine Hardware PWM Generator der läuft immer auch ohne Einfluss von außen, Timer0 verändert nur das Tastverhältnis des PWM Signals.
    • Angenommen wir es liegt keine Ton an und wir befinden uns am Anfang - der aus drei teilen bestehenden - Tonerzeugung:

      • Warte (T0_IDLE),
      • Anschwingen (T0_SWEEP_ON),
      • Ton halten (T0_TON_HOLD) und
      • Ausschwingen (T0_SWEEP_OFF)


    Der Übergang von 1. --> 2. erfolgt durch das Signal (T0_TON_ON), das der Task task_press_paddle setzt.
    Der Übergang von 2. --> 3. ist eine "epsilon transition" mit Signal (T0_TON_HOLD) und wird nach Ausgabe aller Anschwingperioden gesetzt.
    Legende: eine "epsilon transition" wird hier erklärt: Finite State Machine.
    Der Übergang von 3. --> 4. erfolgt durch das Signal (T0_TON_OFF), das der Task task_release_paddle setzt. Nach einer weiteren "epsilon transition" befinden wir uns wieder im Warte-Zustand (T0_IDLE).


    [*]Eine Sinusschwingung besteht aus 128 Stützstellen, z.B. bei 660Hz müssen wir alle
    11,84µs = 1/( 660Hz * 128 ) Sekunden den Wert des PWM Generators ändern. Jede Sinusschwingung wird komplett ausgegeben, erst danach ist ein Zustandswechsel möglich.


    [*]Ich verweise auf das Bild und hoffe es erklärt sich selbst ?
    Man beachte was links und rechts zu sehen ist !.

  • Hallo QRPGemeinde,


    so das erste Video von Testaufbau auf einem Steckbrett ist gemacht und steht bei Youtube zur Verfügung:


    Edit: Wurde leider gelöscht.


    Es soll euch den Klang verdeutlichen und einen Eindruck über die Funktion vermitteln.


    Ich habe das Audiosignal aus dem Video extrahiert und auf den Teil der automatischen Begrüßung begrenzt, das Rauschen wurde abgesenkt und der Pegel auf -6dB normiert.


    Frage: Was gibt der Übungsgenerator als Begrüßungstext aus ?

  • Hi Uwe,


    super Teil! Nun fehlt nurnoch die Hardwarebasis und dann kann der Übungsgenerator offiziell als fertig beschrieben werden!
    Ich besorge mir schonmal Teile dafür .. ;)

  • Guten Morgen QRPForum,


    wie es so ist, mache ich mir Gedanken um den Code auf der µP Familie atTiny861 zum laufen zu bekommen. Das ist mir gestern Nacht gelungen.


    Der atTiny861 ist der großen Bruder des atTiny85 und besitzen noch mehr I/O Ports und insgesamt 3 Hardware-PWM. Darüber hinaus besitzt er auch die notwendige PLL um die Hardware-PWM mit 64MHz betreiben zu können !


    Das Programm im Anhang benötigt nun folgenden Flashspeicher:


    3945 Byte t85/t45
    3955 Byte t861/t461



    Hans-Peter, DL6FAP hat mir noch diesen Link zu gesendet und damit eine Erweiterung für seinen TRX eingebaut.


    ATtiny13-Elbug von Ralf Beesner, DK5BU, ELO Mikrocontroller


    So kam bei mir auch die Idee auf eine Paddle Unterstützung müsste noch realisiert werden. Mit einem atTiny861 wäre noch genügend Platz für weiteren Code sowie weitere PWM-Sinus Tabelle !


    Ausblick
    Das könnte man mit einem atTiny861 noch alles anstellen:

    • erzeugen von Brummen erzeugen: f0:50Hz, f2:100Hz, f3:150Hz über PWM 2
    • erzeugen von Rauschen über PWM 3
    • Paddelbetrieb implementieren und
    • die Geschwindigkeit für dit und dah Regelbar (ADC) machen.

    Je mehr ich darüber nachdenke, um so spannender finde ich das Thema CW.


    .

  • Das könnte man mit einem atTiny861 noch alles anstellen

    Die Gedanken sind frei und vielleicht gibt es ja in denTiefen des Web schon C-libs, die man für diese Zwecke recyclen kann:

    • Automatisches Geben von Übungs-Fünfergruppen nach dem Zufallsprinzip (nur Buchstaben, oder Buchstaben und Zahlen)
    • Einstellbare Wort-Geschwindigkeit ( Lernpsychologisch ist es angeblich günstiger, die Zeichen schneller zu geben, und dafür die Zeichenabstände zu verlängern - Koch Methode )
    • Serielle Verbindung zu einem PC zur Morseausgabe von Texten aus einer Textfile oder direkt vom Keyboard.
    • Zur Gebekontrolle: Decodierung von Morsezeichen, die mit der Taste gegeben werden und Ausgabe auf einem Industriestandard LCD Display oder über ser. Schnittstelle zum PC

    Je mehr ich darüber nachdenke, um so spannender finde ich das Thema CW

    Ja, so lange man nur darüber nachdenkt und es nicht selber lernen muss ^^ "Morsen Lernen - Methoden und Softwarehilfen pdf"
    CW ist, wie wenn man sich freiwillig ein Bein amputiert, um sich fortan auf Krücken fortzubewegen 8)


    73, Günter
    nach Diktat schnell verreist

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)

    Edited 3 times, last by DL4ZAO ().