[Top] [All Lists]

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

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] PSK31 is faster (Was FD RTTY Question)
From: Kok Chen <chen@mac.com>
Date: Sat, 30 Jun 2012 17:01:50 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
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 

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 :-) :-).

Chen, W7AY

RTTY mailing list

<Prev in Thread] Current Thread [Next in Thread>