[Elecraft] Subject: Re: Calling CQ on PSK-31

[Kok Chen]

On May 11, 2010, at 9:14 AM, Jon Perelstein wrote:

> I have noticed that the longer my CQ string, or the more I repeat it, the more frequently I get a response to the CQ.  I've also noticed a lot of stations that repeat their 3x3 CQs at least two or three times before they get an answer.

With something like PSK31, the receiving station has to achieve phase lock, or at the least frequency lock if it is using a non-coherent demodulator.

Evenn with non-coherent demodulation, the "local oscillator" of the demodulator has to get within 7.8 Hz (90 degree phase resolution at the symbol rate of BPSK31) to get any copy at all, and if your SNR is poor at the receiving end, he really has to get to within 1 Hz.  This means that the receiver could take a large part of a second before it can start decoding you.

Your CQ will have to be at least that long, even assuming that your call sign is the very last thing that you transmit. 

Most PSK31 software today have the capability of multiple demodulating (similar to VE3NEA's Skimmer for CW), and this problem is lessened nowadays.  Many people are watching for CQs using the multiple decoders.

> Just because I can see it on the waterfall doesn't mean that I have any idea if it's a CQ or not.  And if it's a short CQ, by the time I click over to it, it's gone.

I had noticed this many years ago.  People were sending CQs that are too short. By the time I see a signal on the waterfall to click on it, he has already stopped calling.  I had to wait until he calls again.

Because of that, I implemented what I called the "click buffer" in cocoaModem.  Think of it as an old fashion tape recorder's tape loop.  The tape allows you to go back in time to replay the signal back.  When you click on a signal, the demodulator attempts to frequency/phase lock on to that signal.  Once the lock is achieved and the local oscillator is locked and not allowed to change anymore, the "tape loop" is played back to the demodulator.  The loop is played back at a faster rate than the normal system, so the decoding catches up with real time very rapidly.  In cocoaModem, this exhibits itself as a short pause right after clicking on the waterfall, and there will be a fast burst of print on the screen, followed by the normal steady BPSK31 character rate.

I extended this concept later to a general "click buffer" (and also to other modes; even the CW decoder has it) where there is a constant 20 second (the height of cocoaModem's waterfall) tape loop running all the time. 

When you click on the waterfall spectrogram, I collect both the horizontal position of the click (to get frequency information) and the vertical position of the click (to get "time" information) and use the "time" parameter to determine how far back in the tape loop you play back to the demodulator when you first click on the signal.

With this extended "click buffer," you can actually click on a signal that has stopped transmitting, and if CQ has appeared within 20 seconds of the last time you turned the knob of the rig, you can copy what he sent.  I am sure it is disconcerting to the other end to get a reply to their CQ 20 seconds after they issued them, and they might attribute that to a slow operator, HI.

If you watch the cursor in the waterfall in this movie of the VP2MUM RTTY operation with a K3, you can see Tom (DL2RUM) take advantage of the RTTY click buffer in his RUMped program (RUMped use cocoaModem's demodulator for digital modes) quite often to pull people after they have already stopped calling:

http://dl2rum.de/rumsoft/VP2MUM_RTTY.mov

The text buffer and RTTY waterfall are in the bottom right hand window.  Watch his cursor :-).

With a click buffer, you can get run rates to go pretty high since you seldom have to wait for a slow caller to finish identifying itself.  You just jump to a different trace on the waterfall that has already finished transmitting.

73
Chen, W7AY