[RTTY] PSK TURNOVER SPEED...

[Kok Chen]

Phil GU0SUP wrote,

> Whilst I agree that the turnover is far higher using these PSK  
> derivatives,
> I have also found that accurately tuning them in is more difficult,  
> and I
> have usually ended up waiting for them to call CQ again before  
> netting on to
> them.

I used to think that is a problem with PSK31, and like Phil, I used to  
wait for the next CQ.

But I have solved this in cocoaModem back in 2005.

The problem with PSK tuning is that you need to tuned to better than 2  
Hz before you can decode anything.  With FSK, you just need to tune  
within a few dozens of Hz to start copying -- you have a big  
difference in acquisition delay between the two modes.

And as Phil mentioned, by the time you have phase locked to the PSK  
signal, it may have stopped CQ'ing.

My initial solution was to start recording the audio into a buffer  
right when you first click on a PSK signal.  Once I have found phase  
lock, I then play the recoded buffer back at the already locked  
demodulator.  But at much higher speed.  So you don't missed any of  
the signal at all from the time you'd clicked until the present.

I find that playing back at 8x seems to be most visually appealing.   
Most modern computers can play back and decode PSK31 and RTTY at 100's  
of times real time speed, but the message would just pop up all at  
once on your screen instead of arriving as a very fast stream.  So I  
settled with 8x.

I called this the "click buffer" in cocoaModem.

Since then, I have adapted it to be more general and extends even  
before the time you'd clicked on a signal.

The cocoaModem "click buffer" is now a "tape loop" constantly  
recording about 20 seconds of audio; new audio data just replaces the  
data from 20 seconds ago in the buffer -- 20 seconds happens to also  
be the height of my waterfall.  With this I can now click on a signal  
a kc away that has already stopped transmitting.  I am clicking on the  
grin of the Cheshire Cat.  When decoding of the data in the "click  
buffer" (at 8x real time) has caught up with real time audio, I simply  
just decode at real-time speed again.

This same facility is implemented in the RTTY interface in cocoaModem,  
and when I do S&P in a contest, I would move my VFO 2 kc at a time to  
get a new "waterfall" view, and then proceed to click on each signal  
in the waterfall; even those who have stopped CQing.

Some of you may have noticed that I often respond to you with a second  
or two of delay.  It is not because I am operating SO2R, but because I  
just finished looking at some other signals in the waterfall and had  
just found your signal even though you have already stopped CQ'ing :-).

I do the same thing in RTTY pileups to find the QSX of the DX station.

I have one receiver of my FT-1000MP locked to the DX on one waterfall  
in cocoaModem's interface, and I use the second receiver of the  
1000MP, and a separate waterfall, to search in the pile.  There are  
two text buffers, one printing the DX and one printing where I am  
clicking on the second waterfall at all the signals one by one and not  
have to wait until they transmit.  Once I find a QSX, or a hole in the  
spectrum next to the previous QSX, I just transmit there -- cocoaModem  
uses AFSK with agile tone pairs, so I can transmit wherever I'd  
clicked.  If I'd clicked on the DX's QSX, that is where I will be  
calling him.

In cocoaModem, the mouse click is not one dimensional.  Where you  
click horizontally on the waterfall selects the frequency of the  
signal.  How high or low in the waterfall you click at determines how  
much of the "click buffer" is played back.  If I click close to the  
real time signal, I get less of the history played back.  If I click  
further in the past, I get more history played back -- i.e., it is a  
WYSIWYG waterfall.

73
Chen, W7AY