Return-Path: Received: from mtain-mh08.r1000.mx.aol.com (mtain-mh08.r1000.mx.aol.com [172.29.96.220]) by air-md07.mail.aol.com (v129.4) with ESMTP id MAILINMD073-8b8e4ce8191b2ae; Sat, 20 Nov 2010 13:53:15 -0500 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mh08.r1000.mx.aol.com (Internet Inbound) with ESMTP id 2801C3800011F; Sat, 20 Nov 2010 13:53:14 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1PJsXI-0001dK-PV for rs_out_1@blacksheep.org; Sat, 20 Nov 2010 18:51:44 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1PJsXI-0001dB-8t for rsgb_lf_group@blacksheep.org; Sat, 20 Nov 2010 18:51:44 +0000 Received: from out1.ip01ir2.opaltelecom.net ([62.24.128.237]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1PJsXG-0001YQ-Gl for rsgb_lf_group@blacksheep.org; Sat, 20 Nov 2010 18:51:44 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoEANun50xcEYbv/2dsb2JhbACIDIwXjkJxumOFSwSOBg X-IronPort-AV: E=Sophos;i="4.59,229,1288569600"; d="scan'208";a="332894405" Received: from unknown (HELO xphd97xgq27nyf) ([92.17.134.239]) by out1.ip01ir2.opaltelecom.net with SMTP; 20 Nov 2010 18:51:36 +0000 Message-ID: <000f01cb88e3$f3a0b360$0401a8c0@xphd97xgq27nyf> From: "mal hamilton" To: References: <4CE7FC47.21165.4FBFDFD@mike.dennison.ntlworld.com> Date: Sat, 20 Nov 2010 18:51:33 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,none Subject: LF: Re: 136kHz Eu DX frequency - summary Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none 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: 3039ac1d60dc4ce8191a54c1 X-AOL-IP: 195.171.43.25 Content-Transfer-Encoding: quoted-printable I suggest you use 136.320 for unattended Beacons and use 137.7 for th= e QSO attended mode if you must. Watching yourself on grabbers is not the ultimate goal. g3kev ----- Original Message ----- From: "Mike Dennison" To: Sent: Saturday, November 20, 2010 4:50 PM Subject: LF: 136kHz Eu DX frequency - summary There have been 6 comments on whether the Eu DX slot on 136.320kHz is still useful. To summarise: Grabbers: One more Eu station has provided a grabber on 136.320, and one active NA station has stated he is unable to add this sub-band. Only two grabbers are available outside Europe to monitor this frequency - RW3ADB (which is almost always off), and KL7UK on demand. It is therefore difficult for a Eu station to offer an occasional beacon on the Eu sub-band as there=B4s nobody listening. There have been two practical solutions to avoiding local QRM to DX stations. Split-frequency: This was used some years ago when there was lots of Eu DX activity and east coast W/VE stations were monitoring. For instance, Eu transmit on 136.320 and NA transmit on 137.777. Split timing: This was used successfully this year on the JA-VE route. For instance, JA transmit on the hour and half hour, and VE transmit on the quarter and three-quarter hour. A suggested solution has been to use alternate days for Eu and NA. Both of the above solutions are fine but they only work for two locations at a time. If a third location is added to the mix, such as Russia, or both East and West Coast America, the solution breaks down. For instance, Eu transmits on 136.320, UA transmits on 137.777, but NA also transmits on 137.777 and is prevented from receiving the UA stations. A resolution would require at least three DX slots, with every grabber equipped to receive them. The split timing solution would also need additional timing slots which might lead to openings being missed. It is possible to devise a complex solution involving both time and frequency, especially as the hours of darkness move round the world, but it need all operators to cooperate. Is there a real problem? I don=B4t think there is a practical problem at present. Activity is low and most stations are in touch with each other via this reflector. If/when the USA gets an allocation at 136kHz, I can see a real need for some kind of plan, but that=B4s not for a while yet. In the meantime, it is of course important for beacon operators to make every effort to avoid interfering with each other. Frequency spacing is an obvious way, as well as making sure that there are listening gaps between transmissions. It would also help if more grabber operators could open more receive slots. To sum up my own position, I have not found any evidence of propagation research or QSOs being affected by my occasional beacon on 137.7752kHz, so I will continue to use this frequency. I will also use 136.3182kHz whenever I can be sure there is a person or machine available to receive my signals. I will also try to limit beacons in time. As always, if anyone has a practical problem, I am happy to switch off. Mike, G3XDV =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D