CW met mijn PC.

Grappige site, ook na vier jaar.... !
Maar de scoring snap ik niet. Wat zijn mijn 'Levenshtein errors'? Ik heb de link gevolgd en snap dat verhaal, maar begrijp niet wat het hiermee te maken heeft.

Sent   Received Errors 
Group   Group   [rood]
UVI87NI UVI87NI UVI87NI 0 
5/IBI   5/IBI   5/IBI   0 
1HG4M   1HG4M   1HG4M   0 
,AUQ    ,AUQ    ,AUQ    0 
US      US      US      0 
RUY/B7  RUY/B7  RUY/B7  0 
8F.M09  8F.M09  8F.M09  0 
/CGWK   /CGWK   /CGWK   0 
LW5     LW5     LW5     0 
XKZ     XKZ     XKZ     0 
6DPHX,  6DPHX,  6DPHX,  0 
Y6      Y6      Y6      0 
Q?546Y  Q?546Y  Q?546Y  0 
21Q     21Q     21Q     0 
?5U     ?5U     ?5U     0 
T4A5    T4A5    T4A5    0 
3VRC    3VRC    3VRC    0 
    Groups: 17 (85 characters), Errors: 0 = 0%
    Levenshtein-Errors: 2 = 2.3 %

ik sein en decodeer cw aan hoge snelheden en ik moet hierbij vertellen dat bij het gebruiken van een programma het veelal zal mislopen bij het decoderen. De reden is dat een programma de spatie's tussen letters en woorden heel exact zal opnemen.
Het decoderen van bijvoorbeeld een radioamateur die eerder gebrekkig seint valt in het niks met een programma, het zal een brabbelvertaling zijn. Enkel de geseinde teksten opgewekt door een machine (bv pc) worden perfect gedecodeerd, als het signaal het toelaat natuurlijk.
Best is zelf cw te leren en na een jaar of wat hoor je het als muziek.

Op die site ben ik nu al een paar weken aan het oefenen en dat is de beste die ik tot nu toe kon vinden. Ik ben gewoon weer bij les 1 begonnen en nu bij 10. Bij het met letter woordjes oefenen (4 letters) met de letters tm les 10 haalde ik gisteren 30wpm (zonder meeschrijven, maar wel na een keer of 4 luisteren) Echt gaaf.

Mijn decoder ontcijfert schrift met onregelmatige spaties, hij decodeert zelf mijn gehak dus dat wil wat zeggen Ik heb het wel eens met en pc geprobeerd maar dat was geen succes. Volume moest precies goed en ook de software. Ik kan nu met een potmetertje even bijpieken.

ik stel mij de vraag welke decoder u gebruikt. Stel dat een decoder X tijd gebruikt voor hij een ander woord ziet, dan kan er geen gekakketak gedecodeerd worden. Zelfs een ervaren seiner heeft daar soms moeite mee, laat staan een "machine" die geprogrammeerd is. Dit heeft niks te maken met een pot of zoiets als instelling. Het feit dat de spatie tussen letters vastligt zegt al alles en daar werken alle machines mee. Zelfs de spatie "in" de letters en cijfers ligt vast. Geen enkele machine of pc kan daar iets van maken als het niet gegenereerd is door een andere machine, tenzij door een geoefend seiner.

Dan zal jij het wel weten. Bij deze ligt die snelheid niet vast. Hij moet even doorstarten met een paar letters en vanaf daar kan je varieren wat je wil. Hij decodeert vanaf 1wpm tot 255wpm
Ik ben er in ieder geval blij mee en aangezien ik een beginner ben luister ik er mee naar andere beginners die alles behalve regelmatig seinen en hij decodeert dat toch behoorlijk goed. Hij mist wel eens een letter maar meer dan 95% is goed. Dat was nog met de oude firmware. Ik heb nu de nieuwe binnen maar nog niet kunnen testen.
Het is geen commerciële decoder, het is zelfbouw. Ik heb het analoge naar digitaal deel gemaakt en een andere amateur het decoder deel.
Met die potmeter kan ik de toondetectie bijregelen. Ik kan zo de lockfrequentie van de decoder van ongeveer 750 tot 850Hz verstellen.

Als ik daar een sounder achter zou hangen heb ik een "synthetisch" qrm vrij CW Dat wordt de volgende uitbreiding.

Die pauzes tussen de tonen, letters en woorden zijn precies vastgelegd in de Morse code. Hoezo zou een machine dat niet kunnen decoderen? En hoezo hebben ervaren seiners daar moeite mee? Ik heb zelf ooit ook het examen gedaan, en dat ging toch echt prima hoor. Ook software doet dat zonder problemen.
Waar zit het probleem dan volgens jou?

er is een letterspatie, een symboolspatie en een woordspatie. Die liggen heel dicht bij elkaar en software wordt geschreven naar die tekens/spaties. Een seiner heeft dat niet altijd in de hand, zelfs ik niet, want de zenuwen spelen ook nog altijd een rol als er bv een dx station terug komt op de aanroep. Als de decoder die spatie niet of niet volledig ziet zal hij het aannemen voor een andere letter of woord. Daarom worden veel contacten gemaakt door het seinen met de pc om deze vergissingen tegen te gaan en dan heeft de pc weinig kans om vergissingen te maken, zelfs niet bij hele kleine en zo goed als onhoorbare signalen.Daar bestaat ook software voor maar dan moet er gegarandeerd met de pc geseind worden.

Vroeger, toen er nog gehakt werd met straight keys haalde men 50 wpm ( H. Martin haalde dat in ieder geval bij een wedstrijd ergens rond 1900) Dat werd op het gehoor genomen en meegeschreven met de hand. Waarom moet dat nu met de pc verzonden worden ? Kunnen veel snelle jongens nu eigenlijk gewoon geen CW meer ?Het excuus aan de ene kant is dan dat de pc het niet meer kan decoderen dus moet de pc het versturen. Eigenlijk zeg je dan dat de zender niet goed genoeg kan sleutelen en deontvanger niet goed genoeg kan nemen en ze beide dus eigenlijk boven hun snelheid zitten te werken. Dat zal wel een status/imago kwestie zijn. Volgens mij werd er bij landlijnen trouwens al automatisch gedecodeerd en handmatig gezonden. Dat waren echt machines zonder intelligentie.

Een decoder heeft heel veel tijd tov de snelheid die hij dcodeerd. Bij de eerste testen zag mijn omzetter iedere negatieve sinus alternatie van 800Hz voor een punt aan. Zo snel is zo'n ding. Hij verzamelt dus gewoon een groepje letters in de buffer en laat daar statistieken op los. Daardoor zit er een kleine vertaging in het display. De laatste letter komt na 3 seconden uit de buffer als er niets meer ingaat. Een enkele letter wordt lastig. Dat kan een E of een T zijn. Maar een doorgaande stroom is geen probleem. Dus woordspaties zijn het probleem niet. De lengte van de streep of punt ook niet. Als de letter uit 4 onderdelen bestaat dan zijn er korte en lange tijden. Die korte zijn gemiddeld 1/3e van de lange. Alles wat meer dan een ingesteld percentage afwijkt van dat gemiddelde wordt als streep gezien. Dat wordt constant berekent en aangepast. Ongeoefende seiners hebben vaak langere woordpauzes en letter pauzes dus dat is ook het probleem niet.

Mijn decoder kan high speed, ik kan dat zelf niet seinen, daarom probeer ik beter te worden in seinen en ik ga nooit sneller werken dan dat ik zelf kan seinen. Ik ben helemaal niet blij dat ik een decoder nodig heb. Ik hoop ook dat ik op den duur zonder dat kan nemen. Net als de marconisten gewoon door te luisteren en zonder mee te schrijven. Anders wordt het net MSN met hindernissen.

[Bericht gewijzigd door fred101 op zondag 13 februari 2011 09:20:41 (33%)]

ikzelf decodeer aan hoge snelheden en sein aan hoge snelheden. Er wordt veel geseind met de pc bv bij dx pedities(niet altijd natuurlijk...)of bij moonbounce of......en dat kan je makkelijk horen.
Een decoder doet maar zijn werk voor 100 % als de spaties correct zijn, anders neemt hij een andere letter of woord.
Als je bij hoge snelheden niet kan decoderen met het oor heeft het geen zin als radioamateur om aan hoge snelheden te ontvangen via een decoder, je zal nooit de tijd hebben om een persoonlijke tekst te seinen aan hoge snelheden.
Ik gebruik normaal mijn Bencher en de pc wordt maar gebruikt als er een expeditie zit die 20 of meer split zit. Een half uur of meer mijne call zitten seinen tot het dxstation mij hoort doe ik niet meer daar heb ik de functietoetsen voor op het klavier.

In 1983 kocht ik een Commodore 64 computer, en daarmee moest natuurlijk onmiddellijk morse gedecodeerd worden. Dat deed ik met een eenvoudig Basic programma van een paar regels.

Dat programma was helemaal niet zo kritisch over exacte lengtes. Het enige belangrijke was dat de strepen langer moesten zijn dan het gemiddelde van streep en punt, en de punten korter dan dat gemiddelde.
Op dezelfde manier moesten de pauzes in de letters korter zijn dan de deze waarde, en de pauzes tussen de letters langer. Nog langer was dan woordpauze.
Natuurlijk, als er heel plakkerig geseid werd, dan werden woorden wel eens aanelkaar getoond, maar dat is logisch: zo waren ze ook geseind.

In Fort Veldhuis, nabij Heemskerk, staat nog steeds een PC'tje met daarop een simpel programma om morse te decoderen. De kinderen mogen dan hun naam seinen, en krijgen een certificaatje als het gelukt is. Het lukt iedereen na een paar keer proberen.

--
Een goed decoderprogramma van déze tijd kan natuurlijk nog veel beter morse decoderen; ook als er storing bij zit zal dit nog lang goed gaan.

Het is goed te vergelijken met de verbetering in tekstherkenning. Tegenwoordig herkent zo'n programma immers ook teksten ook al worden verschillende lettersoorten en -grootten gebruikt, of zit er 'sneeuw' in de afbeelding.
Het is zelfs zo dat de ontwikkelingen in de OCR technieken rechtstreeks van toepassing zijn op morse decoderen. Dat is ook makkelijk te begrijpen: je zou een spectrogram van het ontvangen signaal als 'tekst' kunnen laten behandelen, waarbij de punt- en streeppatroontjes gewoon letters in een apart lettertype zijn.

als "Morseleek" heb ook ik een software decodertje bij mijn softwareradiotje
De werking is inderdaad eenvoudig en gebaseerd op het langer of korter zijn van signalen tov een zich aanpassend gemiddelde van 1.5 X een dot.
(Waarschijnlijk vergelijkbaar met de basicdecoder van FET).
De algoritmiek is gebaseerd op de code van fldigi.

Gevoeligheid voor snelheidsveranderingen bij het seinen is niet heel groot, eigenlijke probleem is dat bij een matige signaal ruisverhouding soms ruis gezien wordt als een dot. In de gedecodeerde tekst bij een zwak signaal zit dus ook een overmaat aan 'E' tjes.
Vinden van een goed begin van dot of streep, daar zit de ellende. Na een aantal seconden ruis doe je aannames over de minimale sterkte van een geen-ruis signaal, dat kan ook adaptief maar werkt dan steeds beter naarmate je meer
sigalen binnen krijgt, het begin van een sessie is dan altijd wat hakkelend. Sterk filteren heeft uiteraard een dempende werking, te sterk filteren vervormd de tekens wel heel erg en geeft rommel.

janS

Sterk filteren is ook niet nodig, een goede PLL "tone decoder" is alles wat je nodig hebt:

http://courses.cit.cornell.edu/ee476/FinalProjects/s2006/cc425/Paul_Ji…

Op 13 februari 2011 08:41:01 schreef tune:
zelfs niet bij hele kleine en zo goed als onhoorbare signalen.Daar bestaat ook software voor maar dan moet er gegarandeerd met de pc geseind worden.

Het verbaast me anders behoorlijk wat mijn pc allemaal uit de ruis trekt. Daar kan ik weinig van maken op het gehoor.
ook de amateurs die achter hun call 'INCLUDE CW' zetten.

Ik denk dat de hele verwarring veroorzaakt wordt door de tijd. Vroeger... waren de automaten erg simpel. Min of meer vast ingestelde pauze tijden. Onregelmatig morse schrift resulteerde in foutieve decodering. Echter, tegenwoordig heb je met een kleine AVR al meer power dan een C64 en kan de software dus vele malen intelligenter zijn. Die kan gewoon meerdere opties uitproberen en de beste kiezen. Een korte pauze lijkt dan een andere letter, maar de software bekijkt ook nog even de situatie waarbij de pauze wel als echte pauze aangenomen wordt en dan krijg je wel de juiste letter. En klopt de volgende letter ook weer. Beetje vage uitleg misschien.
Bottom line, de software doet tegenwoordig meer dan gewoon domweg de tijden meten en in een tabel de letter erbij zoeken zoals vroeger.

Eat, die gebruik ik maar die is zo snel dat hij elk 800Hz component pakt. Ook ruis dus. Ik kon hem zelfs triggeren op elke piek van een 800Hz signaal. Door het loopfilter en de juiste waarden van de externe componenten kon ik hem wat breedbandiger krijgen. Zonder filtering na dat IC of softwarematige bewerking is er bijna niet mee te werken. Als het mooi schoon cw is lukt het nog wel maar zodra er wat bounch, vervorming, tjoepen of fading bij zit werd het niets. Ik kon het softwarematig niet dus heb ik het discreet met HW gedaan. Het belangrijkste is dat het nu werkt.

Dat hoort niet zo Fred, er zijn twee mogelijkheden:

- Je overstuurt de 567.
- Je gebruikt het verkeerde schema.

Volgend deelschema komt van PI4ZLB, op mijn verzoek is daar het schema van de tone decoder wat jaren terug aangepast. Mijn CW decoder ken je van de Heilloze dag.

Op 13 februari 2011 14:33:32 schreef zwembroek:
[...]

Het verbaast me anders behoorlijk wat mijn pc allemaal uit de ruis trekt. Daar kan ik weinig van maken op het gehoor.
ook de amateurs die achter hun call 'INCLUDE CW' zetten.

wie zet er achter zijn call "include cw" ? nog niet meegemaakt.

@Rd12tf:
een tone decoder in software vraagt om een goed filter, van electronica weet ik niet veel maar het lijkt mij hetzelfde

grjanS

Eat, ik gebruik nagenoeg het zelfde schema. http://www.pa4tim.nl/?p=2076 , gewoon aan de hand van de datasheet en vervolmaakt door metingen. Ik gebruik alleen een andere input protectie (een 3,6V zener met led) Grappig dat ze die zelfde oplossing met knipperled hebben. Jullie hebben maar ongeveer 100nF input. Ik 470nF.

Dit http://www.pa4tim.nl/?p=2068 heb ik gemaakt om de waarden te optimaliseren. Het probleem bleek later te zijn dat hij te snel reageerde. Er ontstonden 100uS durende valse pulsen door 800Hz componenten uit de ruis, wat immers breedbandig is, die de software dan als E zag. Ook gebeurde het dat hij door fading uit lock viel en dan kreeg je ook hele smalle spikes, het koste me veel moeite die zichtbaar te maken. De Rigol zag ze niet doordat er bijna niet op te triggeren is. maar met de Tek7704 zag ik ze wel. Toen ik wist waar ze zaten vond ik ze ook op de Rigol. De software reageerde daar op.

Ik heb nu de nieuwe firmware en de Atmel heeft nu ook wat extra opties gekregen waaronder filtering en de mogelijkheid een testsignaal te genereren om de toondecoder optimaal af te regelen en een sidetoon voor het oefenen in sleutelen. Dus daar ga ik nu mee verder testen.

De snelheid staat er niet bij.

Is dat niet lastig als je de letters in uppercase uittiept moet je steeds naar lower case voor de cijfers.
Beroepstelegrafisten deden dat toch niet? De hele goeie tikten op een mill wel aan het begin van een zin een hoofdletter en bij namen ook.

Die foutmelding zal wel een bug in de software zijn. Die methode wordt gebruikt om als iemand een letter overslaat (die er met _een_ edit handeling ingezet kan) dat dan niet alle volgende letters die een plaats verschoven zijn fout gerekend worden, denk ik. Weet t verder ook niet.

[Bericht gewijzigd door Henry S. op woensdag 10 augustus 2011 20:00:29 (98%)]

wie zet er achter zijn call "include cw" ? nog niet meegemaakt.

Staat op hun QSL kaart. Op PSK zie je het ook wel eens achter de call staan. Hier in de buurt zetten ook een aantal amateurs het achter hun call. (voormalig PA3'ers) om aan te geven dat zij nog een CW examen hebben afgelegd. Deze zijn nog erg actief met CW.

Op 13 februari 2011 16:32:05 schreef Rd12tf:
...
Volgend deelschema komt van PI4ZLB, op mijn verzoek is daar het schema van de tone decoder wat jaren terug aangepast. Mijn CW decoder ken je van de Heilloze dag.

[afbeelding]

Wij hebben dit NE567 circuit gebruik in ons CW reader/keyer project. Werkt perfect, al is het even fingerspitzengefühl om de NE567 juist in te stellen.

Op 13 februari 2011 21:03:42 schreef PbSn:
De snelheid staat er niet bij. .. Is dat niet lastig als je de letters in uppercase uittiept moet je steeds naar lower case voor de cijfers.

De snelheid was wat er toevallig voorstond; het was op het TEST account. Snelheid was 20wpm karakters, met extra letterspaties tot 15wpm netto.
Ik heb geen hoofdletters ingetypt hoor, dat deed de site.
Voegâh bij 't ontvangen van de krant inderdaad wel, bij eigennamen en aan het begin van de zin; maar alleen als de ontvangst minstens redelijk was.

Ik denk dat je uitleg aardig in de richting komt. In dit geval was het een bug, maar inderdaad, als je letters verschuiven door een gemiste of gedubbelde, dan komt dit ter sprake. Ga ik eens expres proberen. Dank je!

Hugo, Heb jij dat schema voor mij ? Dan kan ik daar misschien wat van toepassen rond dat LM567 verhaal.

Fred, zie jouw meeldoos.