Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-di03.r1000.mx.aol.com (Internet Inbound) with ESMTP id BD504380000AD; Sun, 28 Oct 2012 19:40:41 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1TScSJ-00027R-TW for rs_out_1@blacksheep.org; Sun, 28 Oct 2012 23:39:47 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1TScSJ-00027I-F9 for rsgb_lf_group@blacksheep.org; Sun, 28 Oct 2012 23:39:47 +0000 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by relay1.thorcom.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TScSH-0004bo-SG for rsgb_lf_group@blacksheep.org; Sun, 28 Oct 2012 23:39:46 +0000 Received: from freitag.iup.uni-heidelberg.de (freitag.iup.uni-heidelberg.de [129.206.29.204]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id q9SNdiJ5021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2012 00:39:45 +0100 Received: from [129.206.22.206] (pc206.iup.uni-heidelberg.de [129.206.22.206]) by freitag.iup.uni-heidelberg.de (8.12.11.20060308/8.11.2) with ESMTP id q9SNdiVV014283 for ; Mon, 29 Oct 2012 00:39:44 +0100 Message-ID: <508DC23A.40206@iup.uni-heidelberg.de> Date: Mon, 29 Oct 2012 00:39:38 +0100 From: =?ISO-8859-1?Q?Stefan_Sch=E4fer?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <508D86B7.1030001@princeton.edu> <508D92BE.2040500@broadpark.no> In-Reply-To: X-Spam-Score: -1.3 (-) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Joe, LF, Am 28.10.2012 22:31, schrieb Roger Lapthorn: > [...] > Is it possible to develop the JT9 mode to allow both QSO and beacon > modes to co-exist? One of the issues currently is there are, arguably, > too many different weak signal modes. If JT9-x could provide both QSO > modes and beacon modes (with internet database linking), there is a > likelihood that this would become the /de-facto/ digital mode (other > than CW) for all MF/LF purposes. [...] Content analysis details: (-1.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [129.206.100.212 listed in list.dnswl.org] -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: d7907c3bf895ca41e0bedc3fa074f0d4 Subject: Re: LF: JT9 buggy issues Content-Type: multipart/alternative; boundary="------------050705050500080505090909" 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=HTML_MESSAGE 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: 3039ac1da607508dc27920b4 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none This is a multi-part message in MIME format. --------------050705050500080505090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe, LF, Am 28.10.2012 22:31, schrieb Roger Lapthorn: > [...] > Is it possible to develop the JT9 mode to allow both QSO and beacon > modes to co-exist? One of the issues currently is there are, arguably, > too many different weak signal modes. If JT9-x could provide both QSO > modes and beacon modes (with internet database linking), there is a > likelihood that this would become the /de-facto/ digital mode (other > than CW) for all MF/LF purposes. Instead typing "CQ DK7FC JN49" i could type "DK7FC JN49IK". Then i am transmitting in beacon mode, isn't it? If someone is receiving on the band/QRG and decodes the message he sees that it is a beacon, not QSO mode. If the decodes are uploaded and displayed just like in WSPR, it is all fine. Maybe you can define a certain format for beacon modes, like the above (call + locator). This would separate beacon modes from QSO modes within JT9. Would that be possible? 73, Stefan/DK7FC --------------050705050500080505090909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe, LF,

Am 28.10.2012 22:31, schrieb Roger Lapthorn:
[...]
Is it possible to develop the JT9 mode to allow both QSO and beacon modes to co-exist? One of the issues currently is there are, arguably, too many different weak signal modes. If JT9-x could provide both QSO modes and beacon modes (with internet database linking), there is a likelihood that this would become the de-facto digital mode (other than CW) for all MF/LF purposes.

Instead typing "CQ DK7FC JN49" i could type "DK7FC JN49IK". Then i am transmitting in beacon mode, isn't it? If someone is receiving on the band/QRG and decodes the message he sees that it is a beacon, not QSO mode. If the decodes are uploaded and displayed just like in WSPR, it is all fine. Maybe you can define a certain format for beacon modes, like the above (call + locator). This would separate beacon modes from QSO modes within JT9. Would that be possible?

73, Stefan/DK7FC
--------------050705050500080505090909--