Return-Path: Received: (qmail 11223 invoked from network); 17 Dec 2001 13:49:42 -0000 Content-Transfer-Encoding: 8bit Received: from unknown (HELO warrior.services.quay.plus.net) (212.159.14.227) by excalibur.plus.net with SMTP; 17 Dec 2001 13:49:42 -0000 X-Priority: 3 X-MSMail-Priority: Normal Received: (qmail 1210 invoked from network); 17 Dec 2001 13:49:34 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior.services.quay.plus.net with SMTP; 17 Dec 2001 13:49:34 -0000 Received: from majordom by post.thorcom.com with local (Exim 3.33 #2) id 16Fy6h-0006GT-00 for rsgb_lf_group-outgoing@blacksheep.org; Mon, 17 Dec 2001 13:47:03 +0000 Received: from mail2.cc.kuleuven.ac.be ([134.58.10.50]) by post.thorcom.com with esmtp (Exim 3.33 #2) id 16Fy6d-0006GO-00 for rsgb_lf_group@blacksheep.org; Mon, 17 Dec 2001 13:46:59 +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 fBHDjciK040854 for ; Mon, 17 Dec 2001 14:45:42 +0100 Message-ID: <3.0.1.16.20011217144251.2d379fd6@pb623250.kuleuven.be> X-Sender: pb623250@pb623250.kuleuven.be X-Mailer: Windows Eudora Pro Version 3.0.1 (16) Date: Mon, 17 Dec 2001 14:42:51 To: rsgb_lf_group@blacksheep.org From: "Rik Strobbe" Subject: LF: long haul QSO's In-reply-to: <003301c186e8$dabdefe0$9fa1883e@g3aqc> 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, Recent test on 136kHz and 73kHz have shown that amateur signals can be copied over distances up to 6000km (73kHz) or even 13000km (136kHz). So far most tests have been done using 'traditional' QRSS or a-bit-less-traditional DFCW. These modes have the advantage that they are still based on the CW code (and thus easy to read) but their disadvantage (especially for QRSS) is the rather inefficient data rate. CW code is optimized for copy by ear and transmission of plain text, what we want to do is copy by eye (or even machine) and transmittion mainly callsign where characters appear pretty random. A basic check on common callsign reveals that the average callsign has 1 figure and 4 / 5 letters, so one could assume that a QSO between a LLFLL (or LFLLL) ans a LLFLLL callsign is average (where L stand for a random letter, F for a random figure). Going through the alphabet show that the average letter (including inter-character spacing) has a length of 11.23 dots in CW (QRSS) and 4.15 dots in DFCW. The average figure is 17 dots in QRSS and 6 dots in DFCW. A typical QSO could be (L = random letter, F = random figure) : cq LLFLL k LLFLL LLFLLL k LLL LL mm k LL LLL oo sk sk This QSO would have a length of 519 dots in QRSS and 166 dots in DFCW (eg. assuming 60 sec dotlength the QSO would take 8h39m in QRSS and 2h46m in DFCW) A QSO on sked would be a bit shorter : LLFLL LLFLLL k LLFLLL LLFLL mm k LL LLL oo sk sk This QSO would take 443 dots (7h23m) in QRSS and 149 dots (2h29m) in DFCW. If we want to proceed faster we do have to leave the traditional CW code. A very interesting suggestion was recently done by Stewart, KK7KA : a 7 tone code. This code would allow us to have a set of 49 characters, sufficient for our purpose (A-Z, 0-9, / and ? would do). Using this code each character would only take 2 dots, meaning that the first example (QSO starting with CQ) would only take 94 dots (1h34m at 60sec/dot). This assumes that a character starts at a known time, so no need for inter-character spaces, but at 60 sec/dot or slower this should be no problem (eg. using 60 sec/dot any character would always start exactly at an even minute). Some additional time can be won if we assign special characters for the T, M, O in the report and for the K, SK at the end of a transmission. If the 'M' of the report or the 'K' at the end cannot be mixed up with a M or T in a call we can omit the spaces before and after the report and before the K/SK at the end. This would speed up things a bit, making the QSO on sked taking 68 dots (or 1h08m) long. Remember, in QRSS it would take 7h23m. The main problem of the 7 tone code would be the frequency calibration at the RX side, but using smart coding this could be solved. One way would be by assigning a code that contains the highest and lowest frequency to space (the most frequent character), this would reveal both the base frequency and the frequency shift at least once per transmission. I am well aware that there will be strong objection against leaving the CW code. But there was also a lot of protest against the first QRSS QSO and when DFCW was introduced. Meanwhile both systems proved that they were a significant improvement in weak signal communication. I believe that moving on to a more efficient code is just a mather of the 'state of mind', CW code is just a convention and no convention is secret. Since we now have shown that is technical possible to copy our signals over 10000km and more the time might be right to develop a mode that will allow us to make QSO's over these distances. 73, Rik ON7YD