Return-Path: Received: (qmail 1261 invoked from network); 18 Dec 2001 14:06:47 -0000 Content-Transfer-Encoding: 8bit Received: from unknown (HELO warrior.services.quay.plus.net) (212.159.14.227) by excalibur.plus.net with SMTP; 18 Dec 2001 14:06:47 -0000 X-Priority: 3 X-MSMail-Priority: Normal Received: (qmail 26060 invoked from network); 18 Dec 2001 14:06:38 -0000 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior.services.quay.plus.net with SMTP; 18 Dec 2001 14:06:38 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from majordom by post.thorcom.com with local (Exim 3.33 #2) id 16GKpX-0001PA-00 for rsgb_lf_group-outgoing@blacksheep.org; Tue, 18 Dec 2001 14:02:51 +0000 Received: from mail2.cc.kuleuven.ac.be ([134.58.10.50]) by post.thorcom.com with esmtp (Exim 3.33 #2) id 16GKpW-0001P2-00 for rsgb_lf_group@blacksheep.org; Tue, 18 Dec 2001 14:02:50 +0000 Received: from LCBD15.fys.kuleuven.ac.be (LCBD15.fys.kuleuven.ac.be [134.58.80.15]) by mail2.cc.kuleuven.ac.be (8.12.1/8.12.1) with SMTP id fBIE1ZQZ112560 for ; Tue, 18 Dec 2001 15:01:35 +0100 Message-ID: <3.0.1.16.20011218145846.2b378612@pb623250.kuleuven.be> X-Sender: pb623250@pb623250.kuleuven.be X-Mailer: Windows Eudora Pro Version 3.0.1 (16) Date: Tue, 18 Dec 2001 14:58:46 To: rsgb_lf_group@blacksheep.org From: "Rik Strobbe" Subject: Re: LF: Re: long haul QSO's In-reply-to: <3C1F2BA3.77F542DE@usa.net> References: <003301c186e8$dabdefe0$9fa1883e@g3aqc> <5.1.0.14.0.20011217162715.00abb350@gemini.herts.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: Hello group, It is a pleasant surprise to see the positive reactions on the suggested "7 tone" coding. To keep things clear, this new coding is not meant to be a replacement for QRSS or DFCW, just as these modes are not a replacement for good old CW. It is just that in the recent transatlantic and transpacific tests we seem to have come to the practical limits of QRSS / DFCW, so to have succesfull QSO's at these ranges we need something more efficient. I believe that using this '7 tone' coding and a 60 sec dotlength a QSO can be completed with a period of 60 to 80 minutes. Now some suggestions : 1. Taking 2 bits/character we can code 49 characters. Beyond the obvious A-Z, 0-9 and space we might need '/' and eventually '?' (39 characters). Further efficiency can be increased is we have special codes for the report (TMO so far), for 'CQ' and for the 'K' and 'SK' at the message end (5 extra codes). For example, assume use special codes for the report 'M' and the terminating 'K' (here shown as '#' resp. '$') the transmitted text BMU TAG MM K (= 12 characters) would become BMU TAG##$ (= 10 characters, spaces before and after the report and before the final 'K' can be omitted). It would also avoid possible confusion for stations with 'MM', 'TT', 'OO', 'SK', 'CQ' etc.. in the suffix. So this comes to 44 codes (39 characters + 5 special codes) leaving still 5 possibilities open. 2. A certain 'time synchronisation' is very usefull since this makes the inter-character spacing redundant (so each character will only take 2 bits instead of 3, a 33% saving !). Assuming the this 7 tone code will be used with dotlengths of 1 minute it should not be so difficult to start a transmision always at an even minute, so any RX station knows that during the even minute the 1st bit is transmitted and during the odd minute the second bit. Alternatively 120 sec/dot can be used, starting at a multiple of 4 minutes. 3. Regarding the coding, apart from the space (= most frequent character) that would get a code that includes both the lowest an highest tone I would keep as certain 'logic' in the other codes. For example (1 = lowest tone .. 7 = highest tone) : A = 11 H = 21 O = 31 V = 41 0 = 51 7 = 61 space = 71 B = 12 I = 22 P = 32 W = 42 1 = 52 8 = 62 report 'O' = 72 C = 13 J = 23 Q = 33 X = 43 2 = 53 9 = 63 report 'M' = 73 D = 14 K = 24 R = 34 Y = 44 3 = 54 report 'T' = 74 E = 15 L = 25 S = 35 Z = 45 4 = 55 'CQ' = 75 F = 16 M = 26 T = 36 5 = 56 / = 66 final 'K' = 76 G = 17 N = 27 U = 37 6 = 57 ? = 67 final 'SK' = 77 The above is just a suggestion, maybe there are good reasons to change this coding. 4. Maybe it is usefull to agree on a certain inter-tone spacing (frequency shift), especially if we want to try machine decoding. Assuming a stability of 0.1ppm over a period of 2 hours, what is not so hard to achieve using a PLL of DDS signal source, this comes to stability of better than 0.02Hz per 2 hours on 137kHz. Further assuming a minimal dotlength of 30 seconds a minimal spacing of 0.033Hz is required. To be on the save side we could agree on a inter-tone spacing of 0.1Hz, making the signal only 0.6Hz wide. 5. In order to do some first tests, all we need it to (temporary) agree on a code, inter-tone spacing and dotlength. Further we need one (or two) brave souls who are able to adapt their transmitters and put some low power tests in the air. (hint to Andy ;-) The rest of us can use Argo or other software and try to copy and decode the test transmisions. Any comments and/or suggestions most welcome 73, Rik ON7YD