Repeaters
Local Practice
volume_off

keyboard c , Enter
gamepad Bottom button Right button
keyboard . x keyboard / z
gamepad Left Button LB gamepad Top Button RB
Second mouse button: Dah

Send CK (check) to the repeater, and play when it comes back.

Notes

Alphabet

E . I .. S ... H .... 4 ....-
V ...- 3 ...--
U ..- F ..-.
2 ..---
A .- R .-. L .-..
W .-- P .--.
J .--- 1 .----
T - N -. D -.. B -... 6 -....
X -..-
K -.- C -.-.
Y -.--
M -- G --. Z --.. 7 --...
Q --.-
O --- 8 ---..
9 ----.
A .- B -... C -.-. D -.. E . F ..-. G --. H .... I .. J .--- K -.- L .-.. M -- N -. O --- P .--. Q --.- R .-. S ... T - U ..- V ...- W .-- X -..- Y -.-- Z --..
0 ----- 1 .---- 2 ..--- 3 ...-- 4 ....- 5 ..... 6 -.... 7 --... 8 ---.. 9 ----.
End of transmission .-.-. Over -.- Correction ........ ? / Say Again ..--.. Speak Slower --.- .-. ...

Knobs

Dit length (iambic): ms

Receive delay: ms


Suggested receive delay: 0ms
Average round-trip time: 0ms
Longest recent transmission: 0ms
Your clock is off by: ??ms

Documentation

This is a CW repeater, named after Alfred Vail, who may or may not have invented what's called "Morse code", but clearly had some role in it.

Just like a radio repeater, anybody can connect and start transmitting stuff, and this will broadcast it to everyone connected.

Why Does This Exist?

I needed a place to practice CW with actual human beings, and I wanted it to be as close as possible to what I'd experience on a radio. I also didn't have a lot of money to spend on equipment, but I did have a computer, phone, and gamepad. Nothing else like this exists on the Internet, as far as I can tell.

What does "local" mean next to the repeater name?

It means this repeater doesn't repeat anything: nothing you key in will be sent anywhere. These are to help people practice and learn, without worrying about anyone else hearing them fumble around.

Why do I hear a low tone?

This is the "drop tone", and will be accompanied by an error.

This means the packet arrived so late, it can't be played in time. In technical terms: the timestamp of the packet plus the receive delay is less than the current time. It can't be scheduled to play, because we can't go back in time.

This could be happening for three reasons:

  1. You (the person hearing the drop tone) need a larger receive delay
  2. The receiving computer's clock is in the future (running fast)
  3. The sending computer's clock is in the past (running slow)

Vail attempts to correct for clock differences, but making sure your computer has correct time, down to the millisecond, can help with reliability.

How can I help?

  • Improve the source code
  • Email me and let me know you're using it
  • Vail costs me 50¢ a year to run: you could buy me a cup of coffee every 5 years or so to offset the expense

Who made this?

Neale Pickett kd7oqi

The Internet isn't exactly like radio waves: it still goes at near the speed of light, but there are multiple hops between endpoints, which buffer up transmissions, and multiplex them onto a single uplink connection. These repeaters (routers) are also allowed to just drop things if they need to. It's the responsibility of the communicating parties to work out whether something needs to be retransmitted. Because of this, there's no telling how long it will take for a transmission to get to a destination.

Each Vail transmission (packet) consists of:

  • timestamp (milliseconds since 1 Jan 1970, 00:00:00 in Reykjavík)
  • transmission duration (milliseconds)

The repeater does nothing but broadcast everything it gets to every connected Vail client, including the one that sent the packet. When your client gets back the exact same thing it sent, it compares the current time to the time in the packet. This is the round-trip time: the time it takes for a packet to get from your computer to the repeater and back.

When the client gets a packet it didn't send, it adds the receive delay to the timestamp, and schedules to play the tones and silences in the packet at that time.

By adding the maximum round-trip time to the longest recent transmission (the length of a dah, hopefully), your client can make a guess about how much time needs to be added to a received timestamp, in order to have it play back in the future at the time it comes in. This is just a guess. If you're communicating with somebody with a higher round-trip time than you have, you'll need to raise your receive delay to account for it.