How we test our tools

• ITU-R M.1677-1, the international Morse code recommendation, for the letters, digits, punctuation, prosigns and the timing rules.
• The PARIS word for speed: one unit lasts 1.2 / WPM seconds, a dash is three units, and the gaps are one unit inside a letter, three between letters and seven between words.
• The ARRL Farnsworth formula for training speeds, where letters are sent fast and only the gaps are stretched.
• Published national tables for the other alphabets we support: American railroad Morse, Cyrillic, Greek, Hebrew, Arabic, Japanese Wabun and Korean SKATS.

Each table is checked by automated tests on every change:

• No two characters in a table share a code.
• Every code decodes back to the character it came from.
• Unknown characters are marked, never silently dropped, and an invalid group is flagged instead of guessed.
• Pasted Morse is accepted in the forms people really type: ·, •, —, – and _ as dots and dashes, and /, | or three spaces as a word gap.

The character pages (the alphabet, numbers and punctuation) are generated from the same tables the translator uses, so a chart and the tool can never disagree.

Sound, the flashing lamp, vibration and the downloadable WAV, MP3 and video files are all timed from one signal model, built from the unit length above. Browser tests check that tones are shaped to start and stop without clicks, that sound only starts from your tap (the rule phones enforce), and that a downloaded WAV of SOS at 20 WPM lasts exactly the 27 units the timing predicts.

Decoding is the hard part, so the decoders are tested against recordings we synthesize with known answers, including the ways real signals go wrong:

• speeds from 5 to 40 WPM, and Farnsworth spacing;
• hiss, mains hum and crackle, and a signal that fades in and out;
• a hand key with human, uneven timing, and messages that start with a dash;
• silence, static and a steady tone, where the right answer is “nothing to decode”.

How they listen and look

• Microphone: a bank of 61 filters from 300 to 1,500 Hz, read every 5 ms, finds the tone at any pitch. Audio files are measured the same way, and you can set the tone by hand.
• The speed is learned from pairs of a mark and its gap, which cancels the bias a detector adds to every mark, and it is never taken from the first mark alone.
• Camera: the brightest part of the target circle is tracked and resampled onto a steady 10 ms grid, so uneven phone frame rates don't change the timing.
• Images: ink is separated from paper with Otsu's threshold, and each mark is classed as a dot, dash or slash by its shape. A picture of ordinary letters is recognised and rejected.

Where a decoder can't read a signal, it says why (too quiet, no steady tone, timing too uneven) rather than printing a guess.

The Koch course, drills and review schedule are tested for their scoring and progression: a lesson unlocks only at 90% copy, and characters you miss come back sooner. Every game has a browser test that plays through a round, and any history or facts a game states are checked against a documented source.

Every tool is tested in Chromium and on emulated phones, including iPhone Safari rules for sound (audio only starts from a tap) and narrow screens. We check that pages don't scroll sideways on a phone and that the main controls are visible without scrolling.

Translation, sound, the decoders and text recognition in images all run in your browser; your recordings, camera and pictures are not uploaded. The one exception is speak to Morse, which uses your browser's own speech recognition; some browsers send that audio to their maker's service.

1. 1A change to a table, timing rule or decoder comes with a test that fails without it.
2. 2The full unit and browser suites run before release.
3. 3The tool's “updated” date, given to search engines in our sitemap, moves only when what it does changes.
4. 4If we find we published something wrong, it goes in the corrections log.