Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Samoadaptujący dekoder sygnałów Morse-a do 100 WPM

LChucki 20 Sty 2019 10:12 2100 18
  • Samoadaptujący dekoder sygnałów Morse-a do 100 WPM
    Zainspirowany tematem Odbiornik morsa, zewnętrzny kwarc atmega8, BASCOM postanowiłem spróbować swoich sił w dekodowaniu sygnału. Próby przeprowadziłem na płytce KA-NUCLEO F411. Program zadziała na każdym F411. Mikrokontroler pracuje na wewnętrznym RC, więc do pracy wymaga niewiele elementów. Zdekodowane informacje pojawiają się na UART2 z prędkością 115200 8N1. Dane z klucza/komparatora mogą być doprowadzone do PB12 (przycisk USER na płytce NUCLEO) lub PB3 (D3 w nomenklaturze Arduino). Aktywny poziomem jest stan niski. Na razie, efekt pracy programu, można zaobserwować tylko na terminalu, ale podłączenie LCD "to formalność".

    Program uczy się tempa, z jakim są nadawane sygnały. W tym czasie dane są wyświetlane na szaro. Gdy nauka dobiegnie końca (odebrane zostanie 30 znaków) odczytane znaki kresek i kropek przyjmują kolor żółty, zdekodowane znaki alfanumeryczne zielony. Nieznane kombinacje oznaczone są czerwonym znakiem zapytania. W prawej górnej części terminala wyświetlana jest informacja o zmierzonym czasie naciskania klucza oraz wyliczonych czasach trwania kropki, kreski oraz pauzy pomiędzy znakami.
    Na wyjściu PA10 (D2 Arduino) nadawany jest sygnał Morse'a. Używałem go do testowania programu. Początkowo testowałem, używając przycisku USER, co było dość męczące.
    Czy powstanie z tego pełnosprawne urządzenie, z LCD, obwodem wejściowym, zależy od zainteresowania forumowiczów. Jak na razie, prace nad programem trwały 12 godzin. W załączniku hex do wgrania.


    [EDIT]
    Po kolejnych 2 godzinach nowsza wersja z nadawaniem/odbiorem znaków dodatkowych znaków jak ' " , . ; : @ ! STAR, STOP itd.
    Samoadaptujący dekoder sygnałów Morse-a do 100 WPM





    Film
    pokazuje odbiór znaków nadawanych ręcznie mikrowstchem, więc łatwo nie jest. Ponadto to moja pierwsza przygoda z nadawaniem Morsem. Co ciekawe, w MON ponad 16 miesięcy byłem radiotelegrafistom :-). To, że nie znam Morsa, wynika z tego, że używałem teleksów i faksu. Miało być "SOS" a wyszło, co wyszło, następnie "ALA" wyszło "ALET" ponownie "SOS" ale się pogubiłem. Jak program zebrał wystarczająca liczbę próbek to nawet "ALA" się udało". Później podałem sygnał z automatu. Po znanym już tekście nadawałem ręcznie "SOS". Około 3 minuty filmu widać przejście z próbki 29 na 0. Od tego momentu moje "SOS" jest odczytywane poprawnie.


    [EDIT]
    Poprawiona zamiana "S" z "O" i wyświetlanie WPM:
    Samoadaptujący dekoder sygnałów Morse-a do 100 WPM
    Soft radzi sobie z czasem kropki/kreski 20/60ms czyli 92 WPM.

    Tyle człowiek kto nie da rady (max to 40).


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • #3 20 Sty 2019 14:15
    LChucki
    Poziom 25  
  • #5 20 Sty 2019 14:47
    LChucki
    Poziom 25  

    Film i nowszą wersję softu wrzuciłem do pierwszego postu. Film robiłem FreeScreenVideoRecorder_3.0.48.703_d, ale wypróbuję FreeScreenVideoRecorder_3.0.48.703_d.

    Program wymaga jeszcze sporo pracy, a nie wiem, czy jest sens, czy program wzbudzi zainteresowanie. Może na jakimś forów radioamatorów więcej chętnych będzie? Wydaje mi się jednak, że na tych forach to nie używają takich wynalazków, tradycyjny klucz i ucho.
    W programie, do poprawienia na pewno jest algorytm uczenia się. Program może, po kilku znakach zacząć odróżniać kropki od kresek oczywiście im więcej danych zbierze, tym jest skuteczniejszy. Przy dużych prędkościach nadawania po 30 próbkach w buforze zdarzają się błędy, dopiero po 60 jest ok. Gdy nadawałem z palca, to po 10 próbkach rozpoznawanie było poprawne. Na razie na sztywno ustawione jest min 30 próbek.

  • #6 20 Sty 2019 19:21
    FRANKOX
    Poziom 14  

    Witam ! W literach "s" i "o" wkradł się błąd , powinno być odwrotnie -
    s … o --- .

  • #7 20 Sty 2019 19:38
    LChucki
    Poziom 25  

    FRANKOX napisał:
    Witam ! W literach "s" i "o" wkradł się błąd , powinno być odwrotnie -
    s … o --- .

    Poprawiłem.
    Samoadaptujący dekoder sygnałów Morse-a do 100 WPM

    Ponadto najnowszy soft wyświetla WPM (nie mylić z "Wniebowstąpienie Panny Marii") i radzi sobie z czasem blisko100 WPM.

  • #9 23 Sty 2019 09:00
    sylwek_b86

    Poziom 15  

    Nie zniechęcaj się. Byłoby super, gdybyś dorobił jeszcze nadawanie. Ja niedługo umieszczę na forum kilka projektów do budowy odbiorników KF. Im więcej projektów związanych z krótkofalarstwem na forum tym lepiej. Może więcej ludzi z innych środowisk się zacznie interesować.

  • #10 23 Sty 2019 14:22
    LChucki
    Poziom 25  

    sylwek_b86 napisał:
    Byłoby super, gdybyś dorobił jeszcze nadawanie.

    Nadawanie jest. Używam do testowania dużych prędkości.

    Na razie zainteresowanie zerowe więc raczej nie będę projektu rozwijał chyba, że znajdzie się sponsor. Czas pokaże bo w planach miałem:
    - Wyświetlacz (raczej alfanumeryczny).
    - Obsługa klawiatury USB.
    - Demodulator tonu.
    - Wejścia klucza półautomatycznego (jedno położenia kreska, drugie kropka)
    i co tam jeszcze przyjdzie do głowy.

  • #11 23 Sty 2019 15:28
    Janusz_kk
    Poziom 18  

    Dziwisz się? Bo ja nie, radioamator z licencją i tak musi umieć titać, więc monitora nie potrzebuje.
    A innym nie jest to do niczego potrzebne, mało kto teraz słucha pasm amatorskich.
    Krótkofalarstwo powoli umiera, nawet jakby zlikwidowali licencje, to już jest za późno,
    podobnie się dzieje z usenetem, grupy dyskusyjne umierają jedna po drugiej, kosztem for.
    A teraz twarzoksiążki.

  • #12 23 Sty 2019 16:01
    AdamC
    Poziom 23  

    Janusz_kk napisał:
    Dziwisz sie? bo ja nie, radioamator z licencją i tak musi umieć titać więc monitora nie potrzebuje


    Kiedyś tak, teraz nie musi znać Morsea by mieć licencję.
    Gdyby rozpropagować temat na forach krótkofalarskich, w sporej grupie nasłuchowców kf to i pewnie zainteresowanie tematem byłoby większe.

  • #13 23 Sty 2019 16:05
    LChucki
    Poziom 25  

    AdamC napisał:
    Gdyby rozpropagować temat na forach krótkofalarskich, w sporej grupie nasłuchowców kf to i pewnie zainteresowanie tematem byłoby większe.

    Zajrzałem w kilka miejsc ale tematu automatu do odbioru Morsa tam nie znalazłem. Może dlatego, że to nie łatwe napisać taki program? 100ms to kreska czy kropka?


    Gotowca można kupić za blisko 600zł, zwie się "MFJ-461 - Kieszonkowy deszyfrator telegrafii /CW".

  • #14 24 Sty 2019 11:22
    uluz
    Poziom 9  

    W środowisku radiowców temat dekoderów CW ma już długą i siwą brodę. Ze sprzętu poza wzmiankowanym MFJotem były/są na rynku jego klony sprzedawane jako uruchomione płytki. Aktualnie kto chce korzysta raczej z oprogramowania na PC. Chyba najlepszy (z powszechnie dostępnych) jest CW Skimmer ale niewiele ustępuje mu MixW. Wiem, że są także inne tego rodzaju programy oraz istnieje komercyjny bardzo zaawansowany soft używany np. przez stacje contestowe w czasie zawodów. (nawet na SSB w zawodach dominują już nagrania, syntezery mowy no i dekodery mowy - w końcu mamy je w swoich PCtach i komórkach). Operatorka na CW i SSB upodabnia się więc do emisji cyfrowych a łączność sprowadza się do siedzenia przed monitorem i naciskania klawiszy.... (oczywiście są nadal tradycjonaliści a nawet użytkownicy sztorców)
    Wracając do dekodera - o ile mi wiadomo kluczowym problemem nie są tutaj algorytmy samego dekodowania co filtrowanie odbieranego sygnału i odczytywanie kiepskich sygnałów (np. słabych, mocno zakłócanych, nakładających się albo zgoła odwróconych - coś jak zmiany lub zaniki szumu w rytm telegrafii). I tutaj ludzkie i doświadczone ucho zostawia w tyle dekodery. (aczkolwiek nie wiem jak wypadają komercyjne względnie najlepsze militarne programy)

  • #15 25 Sty 2019 01:34
    andrzejlisek
    Poziom 28  

    Jakieś rok temu mnie też interesował taki temat, z tą różnicą, że źródłem sygnału będzie dźwięk, ale w całym algorytmie od dźwięku do zdekodowanego przekazu na pewnym etapie jest lista sygnałów i przerw, czyli co druga pozycja listy to stan wysoki, a co druga to stan niski i dla każdej pozycji jest zmierzony czas trwania. Projekt udostępniam: https://github.com/andrzejlisek/MorseCode

    U mnie, poczynając od tej listy (filtracja i przetwarzanie dźwięku, żeby uzyskać taką listę nie jest przedmiotem tego tematu) mam taki algorytm, że dekoder musi znać progi długości sygnałów i przerw, do kalkulacji tempa używam takich parametrów:
    1. Liczba ostatnich sygnałów (jako sygnał należy rozumieć impuls, dźwięk od naciśnięcia do zwolnienia klucza) używanych do kalkulacji tempa - domyślnie 20
    2. Stosunek czasu trwania najdłuższego do czasu trwania najkrótszego sygnału do wyznaczenia granicy czasu pomiędzy sygnałem krótkim (kropka), a długim (kreska) - domyślnie 50%
    3. Próg krótkiej przerwy (między literami/cyframi) wyrażony jako procent czasu trwania sygnału krótkiego (kropki) - domyślnie 200
    4. Próg długiej przerwy (między słowami/grupami) wyrażony jako procent czasu trwania sygnału krótkiego (kropki) - domyślnie 500
    5. Co ile sygnałów następuje automatyczna kalkulacja tempa - domyślnie 10

    Algorytm kalkulacji wygląda następująco:
    1. Sporządź histogram zarejestrowanych sygnałów, czyli informację o ilości wystąpień sygnału o każdym czasie trwania na podstawie zbioru sygnałów do analizy (domyślnie ostatnie 20).
    2. Wyznacz i zapamiętaj czas trwania najkrótszego i najdłuższego sygnału.
    3. Wyznacz próg rozróżnienia sygnału długiego i krótkiego na podstawie minimalnego i maksymalnego czasu trwania, wartość z pkt 2 parametrów określa "położenie" tej wartości na osi liczbowej pomiędzy wartością minimalną, a maksymalną z kroku 2, konkretnie według wzoru: Min + (((Max - Min) * Stosunek_Max_Min_w_procentach) / 100).
    4. Wyznacz i zapamiętaj dominującą długość sygnału, osobno w zakresie od minimum do progu i od progu do maksimum, te wartości przyjmuje się jako zmierzone czasy trwania sygnału krótkiego i długiego.
    5. Wyznacz próg długości długi/krótki ze wzoru tego samego, co w kroku 3, ale z podstawieniem ostatecznie przyjętych czasów trwania sygnałów Krotki + (((Dlugi - Krotki) * Stosunek_Max_Min_w_procentach) / 100).
    6. Oblicz czasy trwania progów z ustawień nr 3 i 4, jako czas trwania sygnału krótkiego przyjmuje się czas jego trwania z kroku 4.

    Samo dekodowanie jest już bardzo proste, myślę, że nie trzeba opisywać, w każdym razie do rozróżnienia sygnałów i przerw z serii impulsów są używane wyłącznie progi obliczone w krokach 5 i 6.

    Pytanie do LChucki: Czy zastosowałeś podobny algorytm "uczenia" tempa, czy zupełnie inny?

    Dodano po 18 [minuty]:

    uluz napisał:
    Wracając do dekodera - o ile mi wiadomo kluczowym problemem nie są tutaj algorytmy samego dekodowania co filtrowanie odbieranego sygnału i odczytywanie kiepskich sygnałów (np. słabych, mocno zakłócanych, nakładających się albo zgoła odwróconych - coś jak zmiany lub zaniki szumu w rytm telegrafii). I tutaj ludzkie i doświadczone ucho zostawia w tyle dekodery. (aczkolwiek nie wiem jak wypadają komercyjne względnie najlepsze militarne programy)


    Testowałem trzy lub cztery takie programy i każdy (!) ma wadę taką, że w przypadku sygnału nieznanego, spowodowanego na przykład błędami w długościach sygnałów i przerw bądź chwilowym zanikiem sygnału, program nie daje żadnej informacji, co było nadane, po prostu pomija ten fragment lub wypisuje znaki informujące o braku dekodowalnej treści, również w przypadkach, w których człowiek jeszcze mógłby zdekodować. Z tego właśnie powodu, jak, bardziej w ramach eksperymentu, utworzyłem swój program https://github.com/andrzejlisek/MorseCode w którym człowiek bierze udział w procesie dekodowania, a dodatkowo jest prezentowany surowy dźwięk, który pozwala ocenić, czy program prawidłowo odczytał długie i krótkie sygnały na podstawie dźwięku. Jednak idąc dalej, stwierdziłem, że inną metodą (łatwiejszą niż "na słuch", ale nie polegającą na żadnym automacie) jest śledzenie prezentacji wizualnej dźwięku i traktowanie kodu CW jako pewnego rodzaju "pisma obrazkowego" (tę możliwość dostrzegłem już podczas testowania algorytmu dekodowania obserwując sygnał źródłowy). Z tego względu, a także ze względu na wykorzystywanie prezentacji dźwięku do innych celów niż dekodowanie CW, napisałem aplikację prezentującą samo widmo działającą i na komputerze i na smartfonie w HTML5/JavaScript: https://github.com/andrzejlisek/AudioSpectrum . Jakby nie patrzeć, jest to właściwie powrót do pierwotnej telegrafii, gdzie treść była rysowana pisakiem na papierowej wstędze, a później zauważono, że do odbioru wystarczą odgłosy pracy pisaka i rysowania.

  • #17 26 Sty 2019 11:05
    LChucki
    Poziom 25  

    andrzejlisek napisał:
    Czy zastosowałeś podobny algorytm "uczenia" tempa, czy zupełnie inny?

    Bardzo podobny.
    Zapamiętuję 30 próbek czasu obecności sygnału i przerw między nimi. Po zebraniu próbek są one sortowane. Sprawdzam czy znajdę zależności długi sygnał >= 3 * krótki. Jeśli są to wyliczam próg KRÓTKI + DŁUGI / 2. Z odstępami jest gorzej. Pomiędzy kropkami/kreskami wystarczy, że sygnału nie ma. Czas 0,8 czasu kreski informuje o końcu serii sygnałów czyli znaku (litery/cyfry) 3 * kreska * 0,8 to odstęp pomiędzy wyrazami. Próbowałem innych algorytmów obliczania odstępów ale działały źle.

  • #18 26 Sty 2019 11:46
    andrzejlisek
    Poziom 28  

    W moim przypadku, progi można ustawiać, ale warto zwrócić uwagę na pewną prawidłowość , jeśli chodzi o czasy domyślne:
    Próg przerwy krótkiej - 200% czas kropki - dokładnie średnia arytmetyczna pomiędzy przerwą między sygnałami (jedna kropka), a przerwą pomiędzy literami (trzy kropki)
    Próg przerwy długiej - 500% czas kropki - dokładnie średnia arytmetyczna pomiędzy przerwą między literami (trzy kropki), a przerwą pomiędzy grupami (siedem kropek)
    Próg końca nadawania - 900% czasu kropki - dobrany tak, żeby ogólnie przyjęty czas przerwy długiej (7 kropek) był średnią arytmetyczną pomiędzy progiem przerwy długiej, a progiem końca nadawania
    Czy próbowałeś taki?

    Można powiedzieć, że w Twoim przypadku (to samo, co sam napisałeś, tylko przeliczone na procent czasu kropki):
    Próg przerwy krótkiej - 80% czasu kreski, czyli 240% czasu kropki
    Próg przerwy długiej - niezdefiniowany
    Próg końca nadawania - 80% czasu trzech kresek, czyli 720% czasu kropki

    Dodano po 12 [minuty]:

    Jakiś czas temu eksperymentalnie zmontowałem układ wyrównujący timing klucza sztorcowego:
    https://www.youtube.com/watch?v=fHfBRleM9tI

    Tu też było potrzebne rozróżnienie następujących stanów:
    - Nadanie kropki - jedna jednostka (jedna jednostka to czas trwania kropki)
    - Nadanie kreski - trzy jednostki
    - Sygnał wysoki - trzymane klucza nieskończenie długo
    - Cisza między sygnałami - jedna jednostka
    - Cisza między znakami - trzy jednostki
    - Cisza między słowami - siedem jednostek
    - Cisza nieskończenie długo

    Wobec powyższego, przyjąłem progi dla stanu wysokiego:
    - Pomiędzy kropką a kreską - 2 jednostki
    - Pomiędzy kreską a sygnałem stałym - 4 jednostki
    Dla stanu niskiego:
    - Pomiędzy przerwą między sygnałami a miedzy literami - 2 jednostki
    - Pomiędzy przerwą miedzy literami z między wyrazami - 4 jednostki
    - Pomiędzy przerwą miedzy wyrazami a stałym brakiem sygnału - 10 jednostek

  • #19 30 Sty 2019 01:09
    WS38
    Poziom 11  

    Cikawe.
    Kiedyś nawet próbowałem nauczyć się telegrafii używając do tego programu komputerowego.

    Mnie interesowałaby taka przystawka. Wyobrażam sobie ją tak:
    Podłączam dwa kabelki do klucza nadawczego Morsa i naciskając klucz, od razu na małym wyświetlaczu wyświetla mi się tekst, który nadaje. Mam podgląd czy nie popełniam błędów. Sygnał jest dekodowany na litery, wyrazy itd.
    Z drugiej strony można pomyśleć o odwrotnym działaniu przystawki, to znaczy wpisuję litery, tekst i podłączam kabelki do klucza Morsa i z przystawki leci tekst nadany morsem.