Etydhv

I, just as a hobby project, am writing a program for decoding Morse code.

I am not a ham, but generally interested in radio and programming.
I have a first version of the project, but it failed to decode the signal in the attached recording.

The length relation between the dash and the dots is far from "standard" and the length of the dashes varies wildly.

Is this type of signal common or should I say "skip this, too weird"?

I also have The ..... code in the recording, does it have some special interpretation ?

https://www.dropbox.com/sh/adoatd80zm0i37d/AADsdp7Az9SEgu5X7Vq6_yhIa?dl=0/StrangeMorse.mp3

I'm not an expert but it sounds like a regular CW to me.

The problem with decoding CW automatically is that it's synthesised by people. The speed (letters per minute) can change, the length of "dits" and "dahs" can change, etc. Whether you should support decoding such style of CW depends only on the time you are willing to invest in the project.

The code ..... is a regular code for number 5.

I can't listen to the recording at the moment, but what you describe sounds very much like a "bad fist" -- an operator whose sending isn't particularly standards compliant. Incorrect dot-to-dash ratio and varying dash length are characteristic of sloppy sending (though it's barely possible you recorded someone using the old American Morse, which had two different dash lengths and different ratios and spacing from International Morse).

One of the biggest challenges of writing a Morse reader program is handling the inconsistencies of hand-sent Morse. Even the best operator will have some variation in ratio and spacing -- this is the "fist" that lets an experienced operator recognize another ham from the sound of his Morse. Even highly developed software doesn't always manage to interpret some fists that an experienced human operator will read without problems. In some ways, it's like handwriting recognition in software (but at least without the image processing and need to handle both manuscript and cursive).

Whether you want to try to write your software to handle a broad range of fists, or only something close to the "perfect code" a machine would send, is up to you. The latter is far easier -- but the former is more useful, and a much greater challenge.

To my ears, that's not all that strange. I was able to casually copy some words by ear. I would guess that it was sent using a hand key, rather than a computer or electronic keyer.

I have some unfinished CW RX Pascal code here --somewhere-- that I wrote many years ago to compensate for variations in dit, dah, or spacing lengths. I suggest you think about writing something similar. It used if..then 'greater or less than' character length statements to correct and print the characters.

That sounds like code sent from a bug to me: machine-generated dits, hand-generated dahs. The operator seems fairly good actually; those things take lots of practice to use well, and I've definitely heard much worse code from bugs.

I can see how writing software to decode that would be challenging, but code like that won't seem unusual or more-difficult to copy to any long-time Morse operator. This is one area where machine learning and software are only now just catching up to an ability skilled humans have had for over a century.

That is Morse code, in Norwegian, being sent with a "bug" (Vibroplex type mechanical key). Probably not something you want to figure out how to decode with a machine, but the op's "fist" makes him very recognizable to those who know him (or her!).

I worked as a research assistant on the Honduran island of Utila the summer after graduating high school. The only reliable communications with the mainland were via the commercial radio shack a few hundred yards from our residence. Those ops had the true "banana boat swing," virtually indecipherable to my ears, even though I was already a Vibroplex veteran. The ops identified each other immediately by "fist," much as any of us recognize people we know by the timbre and cadence of their speech.