[RTTY] PSK31 is faster (Was FD RTTY Question)

[Kok Chen]

On Jun 30, 2012, at 3:39 PM, Joe Subich, W4TV wrote:

> The real problem is the PSK31
> "preamble" ... almost 2 seconds from PTT to the first real data.

It could be doing that to give the receiver a chance to achieve phase lock? (Unless the modem is trying to transmit an RSID, which is really silly for PSK31.)

Being a phase shift keyed mode, the PSK31 demodulator has to be within about a couple of Hz to even start to get any demodulation whatsoever from a clean signal, and within a fraction of a Hz to get good print from a signal with poorer SNR.

(Even with non-coherent differential PSK demodulation, when you don't have an explicit local oscillator, the data clock will still need to be in decent phased lock to the signal; you cannot defeat mother nature :-).

However, there are tricks around this initial lock "problem," so it really just a basic PSK31 problem.  There need not be any dead time at the start of the transmission if PSK31 modems apply some simple tricks.

What I have done with cocoaModem in regards to phase locking is this: when I first try to acquire a lock, I also record the audio to a memory buffer.  (This is in addition to the click buffer in cocoaModem that also works with RTTY.  The phase locking buffer is unique to the PSK demodulator.)

It typically does take 1/2 to 1 second or so to achieve good phase lock, especially when the signal has poor SNR.  While it is trying to lock, I don't print anything to the screen (since it is probably garbage anyway).

Once lock is achieved, I keep the local oscillator in the modem perfectly fixed, not allowing it to change frequency.  And I play back the buffered audio that I had been recording.  The buffered audio plays back to the demodulator a pretty fast sampling rate, somewhere around 8x real time sampling rate.  

The print that has been delayed now spurts out at the fast rate.  The print finally comes out at the 31.25 bps rate once the buffered audio catches up with real time.

So, there is a delay, but it catches up with real time, and there is no character missing from the print.

As a result, cocoaModem does not require any form of a "preamble " from the transmitter, and it can print from the very first 32 ms that is transmitted.

That being said, cocoaModem does stuff a number of idle varicodes (two straight rails in the waterfall) before sending text from the transmit buffer, precisely to give time for the poorer demodulators the extra time to lock.  If other modems can also copy from the first bit that is sent, it is easy enough to remove the delay.

Speaking of which, for reliability, even RTTY requires a short Mark tone when it starts, in case the receiver was triggered by a false start bit by noise before the transmission starts.  But it does not have to be very long at all; a 130 ms Mark signal will clear the async state.  I have seen some stations transmit a longer initial Mark than that, though.  (Uh oh, the millisecond counters are going to be trying to shave off that initial Mark tone as much as they can now :-) :-).

73
Chen, W7AY