Dit length (iambic):

ms

Recieve delay:

ms

---

Suggested receive delay:	0 ms
Average round-trip time:	0 ms
Longest recent transmission:	0 ms
Repeater:

---

Errors

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 need a place to practice CW with actual human beings, and I want it to be as close as possible to what I'd experience on a radio. Also, I don't want to make people buy a bunch of radio hardware. Nothing else like this exists on the Internet, as far as I can tell.

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)
• silence duration (milliseconds, optional)
• transmission duration (milliseconds, optional)
• silence duration (milliseconds, optional)
• Repeat as necessary

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.

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)

Make sure your clock is synced with an Internet time server. Accurate time is very important to how Vail works.

• Move to a more permanent URL
• Make this page less ugly
• Arduino program to let you hook up an iambic paddle over USB
• Document the protocol

How can I help?

• Improve the source code
• Email me and let me know you're using it

Neale Pickett kd7oqi