On Mar 12, 2008, at 9:30 AM, Dick-w0raa wrote:
> I listend on those spotted frequencies and heard people calling
> them, but they were down about 2 to 5 above their transmit
> frequency. I
> can't say for sure that the false spots were intentional, but I
> moved to 2.5
> up and nailed them on the second call.
I think most spots are real, but they tell you what has happened and
not what is happening.
With the TX5C 30m RTTY one evening, I was watching a (really loud)
local station always lagging a kc or two behind the TX5C's QSX as the
DX was slowing working himself higher up on the band. He'd move with
the DX, but usually a kc or two behind. It was comical to watch
since it was almost like the DX was avoiding him and tuning his
receiver away from the local.
When the TX5C finally stepped down in frequency, the local was
transmitting higher in frequency! I think the OM was going where the
packetcluster spots was telling him to go to, which is where the DX
*was,* not where the DX *is.* (As they say on Wall Street -- a
lagging indicator, HI).
As with other modes, transmitting where the DX operator is not
listening is a pure waste of time and uses up your carbon credits
(:-). A tree falling in the forest with no one to hear it...
IMHO, with a small station, looking for the DX's QSX is the key; the
DX is likely to not hear you in a loud and wide pile even when he
tunes across the frequency you are transmitting at -- you will have to
maximize your chances by estimating where the DX is going to be
listening.
Over the years, I have noticed that the majority of them do not
randomly spin the knob. Many will listen for a split second on his
previous QSX.
As such, I have build in some tools into my home brew RTTY program,
such as allowing wide bandwidths to be watched at the same time on a
waterfall and be able to instantly click to the station in the pile,
together with a agile transmit (dynamic assignment of transmit tone
pairs) that is coupled to this receive click, plus a "click buffer"
that prints signals that have already stopped transmitting.
When the pile is thinner and with many people not bothering to find
the QSX, I try to transmit right at the previous QSX of the DX
station. But when a pile is very messy, with other people also
finding and then calling on the QSX, I would find a hole close to the
local pile at the QSX (a waterfall display is good at that) to
transmit in. It is 50%-50% which direction the DX will tune to get
away from the mess, but it is better than 99%-1% that the DX will hear
me among the loud stations.
That was how I worked the 30m TX5C. I found an empty void just up
from the big QSX pile, and transmitted there.
There are at least two dimensions in a transmission -- the two that
you have control over are the frequency and the time. Transmitting
where the DX is not listening will get you nowhere -- transmitting
*when* the DX is not listening will also get you nowhere. Anyone
seriously doing RTTY DXing should consider two receivers with a
separate modem for each. Many software programs allow you to print
two input signals to separate windows -- this will help immensely with
the case of knowing when to transmit.
There are some RTTY specific things, too. With RTTY, sending your
call a single time may not get you copied consistently. The start-bit
problem rears its head again.
Consider the case where the DX station's decoder has triggered a false-
positive start bit just before you transmit. Your start bit becomes
just a data bit to him, that will be followed by a couple of
characters of cycle slippage before the DX can properly synched to
your start-stop timing.
With my homebrew program, I start by transmitting 11 bits worth (about
1/4 second) of "stop bit" before the first start bit is transmitted.
This makes the other station wait for a start bit instead of
triggering more false-positives starts on your actual data bits. This
step makes sure that even the first character of my transmission gets
a better chance to be printed. 8 bits of 'stop" is probably
sufficient, but the extra time helps the ATC of the RTTY modem settle
down.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|