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