Morse Decoder

[MX275 (Gast)]

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:

enum morseDecoderStates 
{
    MORSE_STATE_INIT = 0,
    MORSE_STATE_WAIT_FOR_INPUT,
    MORSE_STATE_MEASURE_ON_TIME,
    MORSE_STATE_MEASURE_OFF_TIME,
    MORSE_STATE_WAIT_FOR_RELEASE,
};

uint16_t timeOn  = 0;
uint16_t timeOff = 0;

unsigned long long debounceTimeStamp = 0;
uint16_t measuredTimes[20];
uint8_t  measureIndex = 0;
String   ditDahString = "";
String   decodedString = "";


static String morse[] = 
{
  // Buchstaben A..Z
  ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....",
  "..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", "--.-",
  ".-.", "...", "-", "..-", "...-", ".--", "-..-", "-.--", "--..",
  // Ziffern 0..9
  "-----", ".----", "..---", "...--", "....-", ".....", "-....", "--...", "---..", "----."
};


boolean checkDitDah()
{
    if (timeOn >= (timeOff * 0.2) && timeOn < (timeOff * 1.4) && timeOff > 0)
    {
        Serial.print(".");     
        ditDahString += ".";   
        digitalWrite(light0 + 2, HIGH);
        return true;
    }
    if (timeOn >= (timeOff * 1.4) && timeOn <= (timeOff * 5) && timeOff > 0)
    {
        Serial.print("-");  
        ditDahString += "-"; 
        digitalWrite(light0 + 3, HIGH);   
        return true;
    }
    return false;

}

char decodeString()
{
    for (uint8_t i = 0; i < 26 + 10; i++)
    {
        if (ditDahString == morse[i])
        {
            if (i <= 25)
            {
                return char('A' + i);
            }
            else
            {
                return char ('0' + i - 26);
            }
        }
    }  
}


void morseDecoder()
{
    if (millis() - debounceTimeStamp > 20)
    {
        debounceTimeStamp = millis();    
    
        switch(state)
        {
            case MORSE_STATE_INIT:
                debugMessage("MORSE_STATE_INIT");
                state = MORSE_STATE_WAIT_FOR_INPUT;
                timeOff = 0;
                timeOn  = 0;
                break;
    
            case MORSE_STATE_WAIT_FOR_INPUT:
                debugMessage("MORSE_STATE_WAIT_FOR_INPUT");
                digitalWrite(light0 + 2, LOW);
                digitalWrite(light0 + 3, LOW);
                if (!digitalRead(button0))
                {
                    // Taste gedrückt
                    digitalWrite(light0, HIGH);  
                    timeStamp = millis();
                    state     = MORSE_STATE_MEASURE_ON_TIME;
                }
                break;
    
            case MORSE_STATE_MEASURE_ON_TIME:
                debugMessage("MORSE_STATE_MEASURE_ON_TIME");
                timeOn    = millis() - timeStamp;
                //Serial.println(String(timeOn));
                if (timeOn > 5000)
                {
                    // Taste zu lange gedrückt
                    timeStamp = millis();
                    state = MORSE_STATE_WAIT_FOR_RELEASE;
                    break;     
                }
                if (digitalRead(button0))
                {
                    // Taste nicht mehr gedrückt
                    digitalWrite(light0, LOW);     
                    timeStamp = millis();
                    state = MORSE_STATE_MEASURE_OFF_TIME;
                }
                break;
    
            case MORSE_STATE_MEASURE_OFF_TIME:
                debugMessage("MORSE_STATE_MEASURE_OFF_TIME");

                timeOff   = millis() - timeStamp;
                //Serial.println(String(timeOff));
                 
                if (timeOff > timeOn * 6)
                {
                    // Taste zulange nicht gedrückt. Abbrechen.

                    timeStamp = millis();
                    state = MORSE_STATE_INIT;
                    Serial.print("##");
                    break;

                } 
                else
                {
                    if (!digitalRead(button0))
                    {
                        // Taste wieder gedrückt
                        timeOff   = millis() - timeStamp;
    
                        timeStamp = millis();
                        checkDitDah();
                        state = MORSE_STATE_MEASURE_ON_TIME;
                        break;
                    }  
                    else
                    {
                        // Taste noch nicht wieder gedrückt
                        if (checkDitDah())
                        {
                           timeStamp = millis();
                           state = MORSE_STATE_INIT;
                           break;
                          
                        }
                                          
                    }
                }
   
                break;


            case MORSE_STATE_WAIT_FOR_RELEASE:
                // Warten bis Taste wieder losgelassen wird
                debugMessage("MORSE_STATE_WAIT_FOR_RELEASE");
                if (digitalRead(button0))
                {
                    // Die Taste wurde endlich losgelassen. Von vorne beginnen
                    Serial.print("!!");
                    timeStamp = millis();
                    state = MORSE_STATE_INIT;
                    break;
                }     
                break; 
        }
    }
}

[oszi40 (Gast)]

Das Rad wurde mehrfach erfunden ist heute trotzdem noch rund.
Morse-Decoder gibt es schon einige wie die Suchmaschine mir verriet. 
Vergleiche Deine Erkenntnisse. 
https://praxistipps.chip.de/arduino-morse-uebersetzer-bauen-so-gehts_104474

[OM (Gast)]

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.

[Wolfgang (Gast)]

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.

[MX275 (Gast)]

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 (Gast)]

@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!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[MX275 (Gast)]

@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?

[MX275 (Gast)]

@Lothar M.:
Das ist mir auch bewusst :-)

[Jakob (Gast)]

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

[Wolfgang (Gast)]

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.

[Stefan (Gast)]

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

[Günter Lenz (Gast)]

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.

[Günter Lenz (Gast)]

Jetzt habe ich es gefunden, es war ein You-Tube-Video.

https://www.youtube.com/watch?v=BW2PFQz85Do

[Bernd (Gast)]

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.

[Rolf M. (rmagnus)]

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.

[Michael W. (dbru61)]

MX275 schrieb:
> Hallo zusammen
>
>
>
> static String morse[] =
> {
>   // Buchstaben A..Z
>   ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....",
>   "..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", "--.-",
>   ".-.", "...", "-", "..-", "...-", ".--", "-..-", "-.--", "--..",
>   // Ziffern 0..9
>   "-----", ".----", "..---", "...--", "....-", ".....", "-....",
> "--...", "---..", "----."
> };
>

Moin,

Es fehlen noch Trennung, Komma, Punkt , Slash, Bindestrich und die 
Irrung (i.d. Praxis eine, rein Formal aber dann zwei Versionen).

Viel Erfolg

[MX275 (Gast)]

Danke für eure Beiträge. Das hat mir weitergeholfen! Ich starte einen 
neuen Versuch.. mit abschätzen etc..

[Thomas K. (joshua314)]

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

[Hannes J. (Firma: _⌨_) (pnuebergang)]

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.

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:

Wenn
    2 * t1 < t2; d.h. t1 war wahrscheinlich ein ".", t2 ein "-"
oder
    t1 > 2 * t2; d.h. t1 war wahrscheinlich ein "-", t2 ein "."
dann
    T = (t1 + t2) / 2
sonst
    weiter t1, t2 messen.

* Mit T dann kontinuierlich Zeichen dekodieren. Zeit t eines Zeichens 
messen:

    t <= T --> Punkt
    t > T --> Strich

* T kontinuierlich anpassen. Beispiel (Gewichtung musst du 
ausprobieren):

Wenn Punkt erkannt wurde:

   T_neu = (T_alt + 2 * t) / 2

Wenn Strich erkannt wurde:

   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.

[Dussel (Gast)]

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.

[Michael M. (michaelm)]

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?  ;-)

[Thilo L. (bc107)]

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

[Der müde Joe (Gast)]

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.

[Manfred H. (manfredbochum)]

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.

[Chris (Gast)]

http://skovholm.com/cwdecoder

[d*?*** (Gast)]

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

[Peter D. (peda)]

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.

[Thilo L. (bc107)]

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

[Wolfgang (Gast)]

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.

[Peter D. (peda)]

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.

[Holger D. (hodoe)]

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