-
Notifications
You must be signed in to change notification settings - Fork 2
Morse playback
Here are some things that need to be considered when playing back a series of code sequences, either received live over the internet or from a prerecorded file.
Consider the case where a T is sent, followed by an H. At 24 wpm, the code sequences would look something like this:
(-150, 150)
(-150, 50, -50, 50, -50, 50, -50, 50)
If the T is played back as soon as it's received, by the time the code sequence for the H is received, 350 ms will have passed (the total duration of the H code sequence minus the 150 ms of the dash in the T). But the delay before the H is supposed to be only 150 ms. So the gap between the T and the H as played back will be 350 ms instead of 150 ms, which is two tenths of a second too long.
To get around this problem, the receiver needs to buffer the incoming Morse before playing it. The amount of buffering should allow for the worst case, which is an E (one dot length) followed by a J (11 dot lengths)—the difference being 10 dot lengths. At 20 wpm, say, the receiver should wait 600 ms (10 dot lengths) before playing the first character received. That ensures that there will never be any jitter if a short character is followed by a long character.
A problem with buffering arises when a remote user first opens the key. You want the local sounder to respond immediately, not delayed by half a second or more. Otherwise, two stations might try to send at almost the same time, and with neither operator being aware that the other has opened their key, an awkward collision might result. The most common scenario for this situation is when a third operator wants to break into a conversation between the transmissions of two other operators.
When one operator stops sending and another starts a new transmission, there's a discontinuity in the code sequences. The first code sequence from the second station will start with a large negative number, reflecting the time since the second operator last sent something. In playing back this code sequence, the large delay should be ignored.
In general, the first code sequence from the new operator will be to simply open the circuit. The code sequence will be in the form (-n, 2), where n is a relatively large number. Since this is a break, the receiver should immediately deenergize the sounder. Buffering should start with the next code sequence received. The pause between the break and the first real character will therefore be longer than was originally sent. Given the tradeoffs, this is an acceptable departure from true realism.
If Internet.read detects a gap in the serial numbers of the received packets, this means a packet has been dropped in the internet. Internet.read indicates this fact by replacing the first element of the code sequence following the gap with the maximum delay -0x7fff. The receiver should reestablish buffering whenever this case arises.
If the receiver is replaying code from a prerecorded file, rather than receiving it live from the internet, then it should use the code sequence's time stamp to determine when to start buffering.
A special situation arises when an operator is sending from the keyboard and pauses between characters. The code sequence will reflect the normal space between characters, rather than the actual space as sent. This doesn't create a problem when playing code received locally in real time or live over the internet, but it is an issue when replaying code that has been captured previously. In this case, the time stamp should be used judiciously to insert extra space during playback.
An L (or zero) can sometimes be long enough that it exceeds the threshold for latching the circuit closed (currently 0.75 sec). The end of the dash will then result in a circuit opening (unlatching) code sequence. As mentioned above in the Break discussion, a circuit opening code sequence should usually be acted on immediately. In this case, however, that would result in truncating the length of the dash. Long dashes need to be distinguished from extended circuit closures and dealt with accordingly.