CW met mijn PC.

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.