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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|