Return-Path: Received: from mtain-mp06.r1000.mx.aol.com (mtain-mp06.r1000.mx.aol.com [172.29.193.74]) by air-mc08.mail.aol.com (v129.4) with ESMTP id MAILINMC084-a98e4cf6816a144; Wed, 01 Dec 2010 12:10:02 -0500 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mp06.r1000.mx.aol.com (Internet Inbound) with ESMTP id CFF10380001F6; Wed, 1 Dec 2010 12:10:00 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1PNqBE-0003Nm-PM for rs_out_1@blacksheep.org; Wed, 01 Dec 2010 17:09:20 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1PNqBE-0003Nd-AQ for rsgb_lf_group@blacksheep.org; Wed, 01 Dec 2010 17:09:20 +0000 Received: from defout.telus.net ([204.209.205.55]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1PNqBC-0006jL-2s for rsgb_lf_group@blacksheep.org; Wed, 01 Dec 2010 17:09:20 +0000 Received: from edmwaa01.telusplanet.net ([75.157.163.113]) by priv-edmwes26.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20101201170915.WYCA4894.priv-edmwes26.telusplanet.net@edmwaa01.telusplanet.net> for ; Wed, 1 Dec 2010 10:09:15 -0700 Received: from [192.168.1.66] (d75-157-163-113.bchsia.telus.net [75.157.163.113]) by edmwaa01.telusplanet.net (BorderWare Security Platform) with ESMTP id 80C522472799AFD2 for ; Wed, 1 Dec 2010 10:09:14 -0700 (MST) Message-ID: <4CF6813A.7030600@telus.net> Date: Wed, 01 Dec 2010 17:09:14 +0000 From: Scott Tilley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <4CF65D62.21930.96EDB2@mike.dennison.ntlworld.com> <4CF672A2.6040506@iup.uni-heidelberg.de> In-Reply-To: <4CF672A2.6040506@iup.uni-heidelberg.de> X-Cloudmark-Analysis: v=1.1 cv=I2lI1VzzqaJGFKQgDQodY1R/GYLTzUIG2uaZQv6pejs= c=1 sm=0 a=8nJEP1OIZ-IA:10 a=fZJloBWO1wW5k1qUllWWvA==:17 a=aatUQebYAAAA:8 a=ofbS-3XVpKJzHpWdN_kA:9 a=8cwaqBoe8517gm7F6kBh-H4KOP4A:4 a=wPNLvfGTeEIA:10 a=i7WyRwjgY0iNmydQ:21 a=pBEQuRDvyIcqmasK:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam-Score: 1.4 (+) X-Spam-Report: autolearn=disabled,RATWARE_GECKO_BUILD=1.426 Subject: Re: LF: QRSS120 and grabbers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false x-aol-global-disposition: G x-aol-sid: 3039ac1dc14a4cf68168730b X-AOL-IP: 195.171.43.25 X-Mailer: Unknown (No Version) Hi Gents The secret to these long haul QSOs is using fairly fast speeds to=20 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=20 our observations during the QSO and beaconing tests. In fact, I was=20 copying him on an Argo 3sec dot screen with O results during parts of=20 our QSO! However, the big issue is destructive interference and other=20 variations in propagation this is what killed our QSO a couple of times=20 before we where successful. The solution for me was to slow down the=20 final bit of the exchange to 120second dot and watch very closely=20 everytime the TX stopped to see if NI copied my RO. As we are all aware= =20 there is usually a time between two stations when prop will lift to the=20 best of the night, this is usually repeatable from night to night. This= =20 is the time to try and exchange at a higher datarate (ie. exhange=20 calls...) the tough part is pulling together the final bit as often you= =20 will run out of propagation or a deep fade occurs... During our QSO=20 three hours passed before NI copied my RO at 120sec dot DFCW! Beaconing before attempting the QSO helped us determine what would be an= =20 optimum 'data rate' for each station should be and the best time of=20 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=20 is the beginning of a QSO attempt as it provides useful information on=20 what the path will support and how each station's setup performs. Fast=20 dot lengths should be used to try and exchange the bulk of the=20 information and final RO, 73s etc can be pushed out to greater dot=20 lenghts to ensure correct copy even if conditions don't recover to=20 earlier levels during the attempt window. So dynamic TX speed changes are good, and running multiple waterfall=20 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=E4fer 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 >=3D 30? I rember the contact=20 > between VE7TIL and JA7NI but most of the active people are just=20 > transmitting a character (representing their callsign) in beacon mode.= =20 > 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=20 > there is some QSB. As an example, XGJ is monitored very often most of=20 > the nights. If the G would be lost (X_J)and in the next turn the J=20 > would be lost (XG_), anyway everbody would know it't (XGJ).=20 > Furthermore the DX interested OMs gets the confirmation on the other=20 > grabbers. > If a QSO is wanted, i fully agree with your opinion. But a QSO means=20 > that both stations are sitting in front of the PC, so they can change=20 > the RX to the wanted QRSS/DFCW mode. > Anyway, i am providing both QRSS-60 and QRSS-120 for TA and EU, so=20 > 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= =20 > "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 =3Dmaximum=3D 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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 73, Stefan > >