Hi Gents
The secret to these long haul QSOs is using fairly fast speeds to
exchange calls and timing the exchanges to known periods of good prop.
JA7NI and I felt that faster speeds would have been possible based on
our observations during the QSO and beaconing tests. In fact, I was
copying him on an Argo 3sec dot screen with O results during parts of
our QSO! However, the big issue is destructive interference and other
variations in propagation this is what killed our QSO a couple of times
before we where successful. The solution for me was to slow down the
final bit of the exchange to 120second dot and watch very closely
everytime the TX stopped to see if NI copied my RO. As we are all aware
there is usually a time between two stations when prop will lift to the
best of the night, this is usually repeatable from night to night. This
is the time to try and exchange at a higher datarate (ie. exhange
calls...) the tough part is pulling together the final bit as often you
will run out of propagation or a deep fade occurs... During our QSO
three hours passed before NI copied my RO at 120sec dot DFCW!
Beaconing before attempting the QSO helped us determine what would be an
optimum 'data rate' for each station should be and the best time of
night. NI's TX rate was 30sec dot DFCW and mine was 60 sec dot DFCW.
So the moral of the story on 2200m is that nightly beaconing on a path
is the beginning of a QSO attempt as it provides useful information on
what the path will support and how each station's setup performs. Fast
dot lengths should be used to try and exchange the bulk of the
information and final RO, 73s etc can be pushed out to greater dot
lenghts to ensure correct copy even if conditions don't recover to
earlier levels during the attempt window.
So dynamic TX speed changes are good, and running multiple waterfall
speeds on RX allows you to be very adaptable as well.
73 Scott
VE7TIL CN89dk
http://www3.telus.net/sthed/argo/
On 12/1/2010 4:06 PM, Stefan Schäfer wrote:
Hi Mike,
Yes, some thoughts:
Am 01.12.2010 15:36, schrieb Mike Dennison
I believe the danger is to regard this as the 'optimum' speed for DX
working, simply because the S/N ratio is good.
Is that really a danger?
In practice, there is
another factor in play. There is often rapid and deep fading on a DX
path, often resulting in only parts of letters being received at this
speed, even though the peak signal is quite strong (see many of the
pictures of transatlantic reception regularly posted on this group).
The situation becomes worse if the final aim of experimenting with a
path is to have a two-way DX QSO. Even exchanging minimal
information, a QSO will take several hours, during which time the
conditions must hold up.
When was the last real QSO done in QRSS >= 30? I rember the contact
between VE7TIL and JA7NI but most of the active people are just
transmitting a character (representing their callsign) in beacon mode.
I have never seen a "CQ ... K" in 60 or 120.
So if one just wants to transmit a beacon signal it doesn't matter if
there is some QSB. As an example, XGJ is monitored very often most of
the nights. If the G would be lost (X_J)and in the next turn the J
would be lost (XG_), anyway everbody would know it't (XGJ).
Furthermore the DX interested OMs gets the confirmation on the other
grabbers.
If a QSO is wanted, i fully agree with your opinion. But a QSO means
that both stations are sitting in front of the PC, so they can change
the RX to the wanted QRSS/DFCW mode.
Anyway, i am providing both QRSS-60 and QRSS-120 for TA and EU, so
people may chosse what they like :-)
Take a look at VE7TIL's excellent DCF39
graph to see how short a good DX opening usually is - perhaps an hour
if you are lucky.
...which wouldn't be enough for a (real) QSO in QRSS-60 but enough for
"FC" or "NM" or "NI" in QRSS-120.
The very few who have had transatlantic QSOs have used QRSS30 or at
most QRSS60. I am not aware of a successful two-way involving a
longer dot length.
I would suggest that DX beacons and grabbers use a =maximum= of 60s
dot length (though a second grabber screen could be provided for 120
etc if desired). In my opinion this would be more likely to result in
useful propagation data.
Done.
Any thoughts?
Mike, G3XDV
==========
73, Stefan
|
