Hallo zusammen
Ich möchte gerne mit meinem Arduino einen Morse-Decoder bauen.
Möglichst simpel:
1 Taste zum Morsen an Eingang von Arduino.
1 LED visualisiert den Tastendruck.
Der Output wird seriell ausgegeben.
Mir geht es in erster Linie darum, zuverlässig Punkt (. Taste kurz
gedrückt) und Strich(- Taste lange gedrückt) zu erkennen). Das
decodieren der Punkt-Strich-Sequenz stellt dann kein Problem mehr dar.
Dies ist die Definition des Morsecodes:
"Der Code verwendet drei Symbole, die Punkt ( · ), Strich ( − ) und
Pause ( ) genannt werden, gesprochen als dit, dah (oder doh) und
„Schweigen“. ... Die Pause zwischen zwei gesendeten Symbolen ist ein Dit
lang. Zwischen Buchstaben in einem Wort wird eine Pause von der Länge
eines Dah (oder drei Dits) eingeschoben. Zwischen einzelnen Wörtern
(Leerzeichen) wird eine Pause von 7 dits eingeschoben"
Das Problem ist, dass es mit jeder beliebigen Morse-Geschwindigkeit
funktionieren soll. Wie kann ich dann ein einzelnes "T" = "-" von einem
einzelnen "E" = "." unterscheiden? Ein "-" könnte ja auch ein langsam
gemorster "." sein.
Aktuell messe ich die On-Zeit (Taste gedrückt) und Off-Zeit (Taste
losgelassen) und vergleiche dann die Zeiten.
Es ist ein Strich wenn On-Zeit = 3 * Off-Zeit (+- gewisse Toleranz)
Es ist ein Punkt, wenn die On-Zeit = Off-Zeit entspricht (+- Toleranz).
Das Letzte Symbol eines Buchstabens erkenne ich noch nicht richtig...
Könnt ihr mir weiterhelfen? Vielen Dank!
Hier ein Ausschnitt aus meinem Code:
Ein Morsedecoder ist nicht trivial. Es gibt viele schlechte und noch
mehr sehr schlechte. Man kann also nicht sagen, dass das Rad schon
erfunden wurde. Es gibt immer wieder Verbesserungen.
MX275 schrieb:> Das Problem ist, dass es mit jeder beliebigen Morse-Geschwindigkeit> funktionieren soll. Wie kann ich dann ein einzelnes "T" = "-" von einem> einzelnen "E" = "." unterscheiden?
Indem du wartest, bis es nicht mehr ein einzelnes 'T' oder 'E' ist, i.e.
du pufferst deine Zeichen und entscheidest dann.
Ein Funker hat das gleiche Problem.
Sieht mehr nach einem Morse-Encoder, nicht nach einem Morse-Decoder aus
(Nur Pins als Ausgänge geschaltet). Habe schon Arduino Morse Decoder
gefunden im Internet, aber nur mit festgelegter Morse-Geschwindigkeit!
@oszi40
MX275 schrieb:> Sieht mehr nach einem Morse-Encoder, nicht nach einem> Morse-Decoder aus> (Nur Pins als Ausgänge geschaltet). Habe schon Arduino Morse Decoder> gefunden im Internet, aber nur mit festgelegter Morse-Geschwindigkeit!
MX275 schrieb:> aber nur mit festgelegter Morse-Geschwindigkeit!
Das ist trivial.
Aber der Witz ist ja gerade die laufende Anpassung an
Geschwindigkeitsänderungen. Es reicht also auch nicht aus, ein einziges
Mal die Geschwindigkeit zu vermessen.
@wolfgang: wie soll ich mich dann entscheiden. Angenommen ich habe eine
On-Zeit von 2 Sekunden, und eine Offzeit, welche ein Timout bedeutet
(sagen wir 10 Sekunden... damit meine ich das Ende der Übertragung). War
es nun ein Punkt oder ein Strich?
Ein Morsedecoder ist nicht pillepalle, aber auch kein Hexenwerk.
So ein Morsedecoder muss nur das nachvollziehen, was in Ohr und Hirn
eines Morse-Hörers abläuft. Niemand sendet ein einzelnes T, oder E. Erst
aus dem Zusammenhang von ein bis mehreren Zeichen zeigt sich, was als
dit, oder dah gesendet wurde.
Bei einer neuen Morsesendung muss man sich auf das Tempo des Senders
einstellen. Dazu wird ein Zeitwert ermittelt, der die letzten dit
(kürzer) und dah (länger) sicher voneinander trennt. - Gleiches gilt für
die 3 möglichen Pausenlängen.
Geübte Hand-Morser machen oft eher 1:2 statt 1:3 bei dit:dah - und das
Entsprechende bei den Pausen. - Diese Werte müssen ständig nebenbei
ermittelt und nachgeführt werden. Anders geht's nicht!
Auffällig kurze Zeiten für Signal, oder Pause werden ignoriert.
Das sind wahrscheinlich Übertragungsfehler...
Auffällig lange Zeiten (Signal, oder Pause) werden z.B als
Satzende, Sendungsende, Zeilenvorschub, ... gewertet.
Und was beim Morse-Hörer im Unterbewusstsein geschieht, nämlich auch die
ersten dit-s und dah-s unbekannter Länge vom Anfang der Sendung zu
decodieren, kann man im µC mit Zwischenspeicherung (hier empfiehlt sich
ein Ringspeicher) und Decodierung erst nach dem die Zeiten bekannt sind,
nachvollziehen.
Wie man das macht, musst du versuchen, selbst herauszufinden.
Geholfen wird dir hier gern, aber Hausaufgaben für Leute, die nicht
aufgepasst haben, sind eher unbeliebt...
MX275 schrieb:> Sieht mehr nach einem Morse-Encoder, nicht nach einem Morse-Decoder
Morsezeichen von Morsetaste rein, serielle Daten raus - das IST ein
Decoder
MX275 schrieb:> War es nun ein Punkt oder ein Strich?
Das wirst du nicht entscheiden können und egal ist es auch. Es ist
relativ sinnfrei ein einzelnes 'E' oder 'T' zu übertragen.
Hallo,
ich habe jetzt alle Beiträge aufmerksam gelesen und Alles ist mehr oder
weniger richtig, nichts Falsches.
Aber ich habe den Verdacht dass keiner der Schreiber sich jemals mit
Morsen auseinander gesetzt hat, d.h. wirklich Geben und Hören kann.
Am besten beschreibt es noch
Jakob schrieb:> So ein Morsedecoder muss nur das nachvollziehen, was in Ohr und Hirn> eines Morse-Hörers abläuft.
und das hat auch viel mit Wahrscheinlichkeit zu tun.
Wer jemals in die AFU-Bänder rein gehört hat der weiß dass sich der
gesamte Morse-Betrieb mit Geschwindigkeiten zwischen 80BpM und 125BpM
abspielt.
Weniger als 80BpM gilt als Anfänger und mehr als 125BpM gilt als "High
Speed".
Mit diesem Wissen kann man mit gewisser Wahrscheinlichkeit abschätzen ob
ein einzelnes Zeichen ein E oder T ist.
Des weiteren ist es bei diesen Geschwindigkeiten (um die 100BpM) dem
Hörer nicht mehr möglich die Punkte oder Striche der schnell aufeinander
folgenden Zeichen mitzuzählen.
Der Hörer hat vielmehr die Klangbilder aller Zeichen im Kopf und sein
Gehirn entscheidet aufgrund dieser Klangbilder um welches Zeichen
(Buchstaben) es sich handelt.
Meiner Ansicht wäre es also am besten wenn eine Maschine (Computer)
Klangbilder erkennen und auswerten könnte. Nichts mit starrem Abzählen
von Punkt und Strich. Auf diese Weise wären auch unsaubere und stark
verrauschte Signale kein Problem.
Gruss
von Stefan schrieb:
>Meiner Ansicht wäre es also am besten wenn eine Maschine (Computer)>Klangbilder erkennen und auswerten könnte.
Das kann aber kein Computer, dem bleibt nichts anderes über
als die Längen der Striche Punkte und Pausen zu messen.
Computer können nicht alles.
http://www.blutner.de/philos/comp.html
Irgendwo hatte ich mal was gelesen was man mit einem
Algorithmus oder Programm nicht lösen kann, oder für
dieses Problem unmöglich ist ein Programm zu schreiben,
was aber für einen Menschen trivial ist. Das war irgend
ein Spiel, ich finde es aber nicht wieder.
Vor etlichen Jahren gab es einen Morse-Decoder auf der Basis eines
6502-Systems (AIM oder KIM) inkl. ELIZA von der c't. Das System passte
sich automatisch an die Geschwindigkeit an. Das ELIZA-Programm
beantwortete einfache Fragen.
Vielleicht hat jemand noch das alte (Sonder-)Heft.
Stefan schrieb:> Meiner Ansicht wäre es also am besten wenn eine Maschine (Computer)> Klangbilder erkennen und auswerten könnte. Nichts mit starrem Abzählen> von Punkt und Strich. Auf diese Weise wären auch unsaubere und stark> verrauschte Signale kein Problem.
Aber woraus besteht für dich das "Klangbild", wenn nicht aus einer Reihe
kurzer und langer Pulse, die man in einer Maschine halt abzählt?
Günter Lenz schrieb:> Das kann aber kein Computer, dem bleibt nichts anderes über> als die Längen der Striche Punkte und Pausen zu messen.
Ein neuronales Netz, das man auf die Erkennung trainiert, wäre noch am
nächsten an dem, wie es Menschen tun, dran. Das erkennt die Muster.
Guten Tag MX275
vor vielen Jahren ...ca 35. hab ich einen Morse Decoder auf dem C64
geschrieben.
Das Decodieren besteht, wie du schon rausbekommen hast, vor allem an dem
ausdauernden herausfinden der Punkt, Strich, Pause Längen.
Meine Vorgehensweise damals.
1. Ringpuffer anlegen wo alle Ereignisse abgelegt werden.
2. Nach den ersten paar Zeichen (ca.10) den Ringpuffer mit diesen
Zeichen erst mal füllen. Ist zwar nicht gut ... aber dann schon mal
ein Anfang.
Alles was danach reinkommt über die Kopierten Zeichen drüberschreiben.
3. laufende jetzt Punkte Striche Pausen suchen, erkennen und bewerten.
dabei beachten, dass der Mensch ein sehr schlechter Morsezeichen Geber
ist.
Ein Punkt zu Strich Verhältnis senkt sich bei Hi-Speed mit zu 1.3xPunkt
= Strich. Ein Verhältnis 1:2 ist schon gut.
4. Wenn dein Ringpuffer analysiert ist, die Längen für Punkte Striche
Pausen im Mittel bekannt sind, kannst du dich ranmachen deinen
Ringpuffer zu dekodieren.......
Dies beudeutet aber auch, dass es vorkommen wird. Dass dein Text in der
Länge deines Ringpuffers sich immer wieder ändern wird, da du neue
Analyse Ergebnisse hast....
vy73 Thomas de DG5MPQ
MX275 schrieb:> Aktuell messe ich die On-Zeit (Taste gedrückt) und Off-Zeit (Taste> losgelassen) und vergleiche dann die Zeiten.> Es ist ein Strich wenn On-Zeit = 3 * Off-Zeit (+- gewisse Toleranz)> Es ist ein Punkt, wenn die On-Zeit = Off-Zeit entspricht (+- Toleranz).> Das Letzte Symbol eines Buchstabens erkenne ich noch nicht richtig...
Das war schon vor 40 Jahren eine beliebte Programmierübung. Die Lösung
war schon vor 40 Jahren:
* Mit einer Basiszeit T rechnen. Z.B. def.
1
T = 2 * T_punkt = T_strich / 1.5
* Zur Initialisierung dieser Basiszeit T ein paar Zeichenlängen messen
bis man zwei Zeichenlängen t1, t2 findet für die gilt:
1
Wenn
2
2 * t1 < t2; d.h. t1 war wahrscheinlich ein ".", t2 ein "-"
3
oder
4
t1 > 2 * t2; d.h. t1 war wahrscheinlich ein "-", t2 ein "."
5
dann
6
T = (t1 + t2) / 2
7
sonst
8
weiter t1, t2 messen.
* Mit T dann kontinuierlich Zeichen dekodieren. Zeit t eines Zeichens
messen:
1
t <= T --> Punkt
2
t > T --> Strich
* T kontinuierlich anpassen. Beispiel (Gewichtung musst du
ausprobieren):
Wenn Punkt erkannt wurde:
1
T_neu = (T_alt + 2 * t) / 2
Wenn Strich erkannt wurde:
1
T_neu = (3 * T_alt + 2 * t) / 6
Rolf M. schrieb:> Ein neuronales Netz, das man auf die Erkennung trainiert, wäre noch am> nächsten an dem, wie es Menschen tun, dran. Das erkennt die Muster.
Mann kann sich auch richtig ins Knie schießen.
Nur mal als Überlegung, würde ich vielleicht mal an eine Clusteranalyse
denken. Man hat statistisch rauschende Werte, die Längen der
Tastenbedienungen, und möchte die in die Cluster 'lang' und 'kurz' und
vielleicht noch 'Pause' einteilen. Da gibt es sicher auch was für
eindimensionale Daten.
Wolfgang schrieb:> Morsezeichen von Morsetaste rein, serielle Daten raus - das IST ein> Decoder
Die Morsezeichen sind doch schon seriell bei der Eingabe; also ist das
Format doch nicht generall umgesetzt oder verändert.
Einzig die Exaktheit soll hier mittels des Schnelldenkers hergestellt
werden.
Was macht dann deiner Meinung nach im Gegensatz hierzu (im Sinne
"Morsezeichen") ein Encoder? ;-)
Hannes J. hat das grundlegende Verfahren richtig beschrieben: die
Timings des gegebenen Codes müssen kontinuierlich erfasst und gemittelt
werden und dann dynamisch als Entscheidungsbasis zwischen dit und dah
("Punkt" und "Strich" für Nicht-Funker) zu dienen. Interessant und
entscheidend ist hier die Art der Mittelung: nimmt man zu viele
Einzel-Signale, wird die erkennung einer geänderten Geschwindigkeit zu
träge, nimmt man zu wenige, reagiert der Algorithmus empfindlich auf
leichte Schwankungen der Gebegeschwindigkeit.
Vor einigen Jahren habe ich für unsere Kids-Bastelecke auf dem
jährlichen Field Day einen Morsedecoder mit AVR entworfen. er war zum
Schluss in der Lage >256 WPM (Ja. WPM, nicht BPM) fehlerlos zu erkennen
und hat eine harte Speed-Umschaltung am Eingang von 20 auf 120 WPM
innerhalb von 1 Zeichen (zurück innerhalb von maximal 3 Zeichen)
geschafft. (Ist aber closed source)
-- Thilo, DL2THL
Hallo, lieber MX275.
Ich habe das morsen noch beim Bund gelernt, in einer Fernmeldeeinheit.
Ich bin kein Programmierer, aber mein Ansatz wäre so:
1. Abtasten des Signals mit einer x-fach höheren Auflösung, speichern
2. Feststellung: Die Decodierung, die Dits und Dats und Pausen müssen
früher ausgemessen sein, als der Speicher wieder neu beschrieben wird.
Sonst verliert man Morsezeichen.
3. Sammeln aller Dits und Mittelwertbildung
4. Sammeln aller Dats und Mittelwertbildung
5. Sammeln aller kurzen Pausen und Mittelwertbildung
6. Sammeln aller langen Pausen und Mittelwertbildung
7. Prüfung auf Plausibilität: Sind die Dits kleiner als die Dats, etc.
8. Decodierung des Streams
Die Mittelwerte müssen natürlich nachgeführt werden. Wie oft, hängt von
der Speichertiefe und Geschwindigkeit der Decodierung ab.
Viel Erfolg!
Der müde Joe.
1984 hab ich als erstes Programm überhaupt einen Morsedecoder für den
VC20 geschrieben.
Die Zeichenerkennung und Geschwindigkeitsmessung waren nur ein paar
Zeilen.
Ging bis 150BPM.
Wenn ich das Listing finde poste ich es.
Da Rechenleistung heutzutage im Überfluss da ist würde ich die
dynamische dit-dah Zeichenlängendefinition nach jedem vermuteten
Morsezeichen(also nach jeder etwas längeren pause) durchführen.
Wenn sich mit den werten kein gültiges Morsezeichen erkennen lässt
veruchen ob die dit-da vom letzten Zeichen evtl. doch noch mit dazu
gehören, bzw das nächsten Zeichen abwarten ob das dazugehört, der Geber
also keine echte Zeichenpause machen wollte.
Wenn nach einer Sequenz unklar Zeichen geblieben sind kann das Programm
dann ja gleich ein QSM zurück geben ;-)
Im einfachsten Fall schreibt man die Zeiten zwischen den Flanken in
einen Ringpuffer, 8Bit Auflösung sollte reichen. Den gleitenden
Mittelwert der Pulse nimmt man dann, um Punke und Striche zu
unterscheiden und die Zeichenpause. Damit sollten dann auch von 1:3
abweichende Verhältnisse zu erkennen sein. Man könnte aber auch ein
Histogramm anlegen.
Die CPU-Last dürfte gering sein.
>> Die CPU-Last dürfte gering sein.
Jo. In meinem o.g. Programm mit Averaging nach jedem Zeichen, Ausgabe
auf LCD und seriell usw. war die CPU-Auslastung bei 120 WPM (=600 BPM)
bei etwa 4% auf einem ATMega32 mit 8 MHz.
Stefan schrieb:> Wer jemals in die AFU-Bänder rein gehört hat der weiß dass sich der> gesamte Morse-Betrieb mit Geschwindigkeiten zwischen 80BpM und 125BpM> abspielt.
Die Aussendungen, bei denen sich Leute fließend mit 200 oder gar 300BpM
unterhalten, hast du dabei wahrscheinlich gar nicht als Morse-Betrieb
erkannt.
125BpM lässt sich noch gut von Hand mitschreiben. Die Leute im HSC
fangen bei 125BpM erst an. Und Meteor Scatter liegt bei 3000BpM.
MX275 schrieb:> static String morse[] =
Warum so kompliziert. Ein Zeichen besteht aus max 6 Bit, läßt sich also
bequem in ein Byte packen. Ein führendes 1-Bit kodiert die Länge.
0b00000010: E
0b00000011: T
0b00000100: I
usw.
Sortiert man dann noch die Bytes aufsteigend, geht eine binäre Suche am
schnellsten.
Moin, das Bauen/Programmieren eines CW-Decoders bis in höchste
Geschwindigkeiten ist nun wirlich trivial. Das ist ja heutzutage in
vielen Transceivern eingebaut. Selbst der QCX kann das. Es gibt hunderte
von Ansätzen und Lösungen und trotzdem versucht man es immer wieder neu.
Warum? Weil die Praxis an der Antenne zeigt, dass es eben nicht gut und
konstant funktioniert, wenn die NF nicht mit einem vernünftigen Pegel
dekodiert werden kann. Da gibt es natürliche Störungen und Schwund,
Mensch-gemachte Störungen, nicht konstante Gebeweise. Es gibt
Handtastengeber, welche mit ele-Keyern, mechanische Lösungen wie Bugs
usw usw usw. Wenige Hertz abseits der Frequenz. Auf alles stellt sich
das menschliche Gehirn ein. Und das Gehirn kann häufig sich Bruchstücke
zusammenbauen.
Das was der Mensch kann, kann der Rechenknecht niemals und wird es nie
können. Schreibt doch mal ein QSO mit so einem Decoder mit. Ein
einfaches von dritter Seite eingeworfenes ..--.. wird die Dekodierung zu
Fall bringen.
Holger