Return-Path: Received: (qmail 9514 invoked from network); 15 Nov 1999 11:45:51 +0000 Received: from unknown (HELO magnet.force9.net) (195.166.128.26) by guiness.force9.net with SMTP; 15 Nov 1999 11:45:51 +0000 Received: (qmail 25336 invoked from network); 15 Nov 1999 11:55:42 -0000 Content-Transfer-Encoding: 8bit Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by magnet.plus.net.uk with SMTP; 15 Nov 1999 11:55:42 -0000 Received: from majordom by post.thorcom.com with local (Exim 3.02 #1) id 11nKHX-0004Ya-00 for rsgb_lf_group-outgoing@blacksheep.org; Mon, 15 Nov 1999 11:26:47 +0000 X-Priority: 3 X-MSMail-Priority: Normal Received: from mailserv.cc.kuleuven.ac.be ([134.58.8.44]) by post.thorcom.com with esmtp (Exim 3.02 #1) id 11nKHU-0004YV-00 for rsgb_lf_group@blacksheep.org; Mon, 15 Nov 1999 11:26:45 +0000 Received: from LCBD15.fys.kuleuven.ac.be (LCBD15.fys.kuleuven.ac.be [134.58.80.15]) by mailserv.cc.kuleuven.ac.be (8.9.0/8.9.0) with SMTP id MAA09386 for ; Mon, 15 Nov 1999 12:33:51 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <3.0.1.16.19991115132605.22071bd8@mail.cc.kuleuven.ac.be> X-Sender: pb623250@mail.cc.kuleuven.ac.be X-Mailer: Windows Eudora Pro Version 3.0.1 (16) Date: Mon, 15 Nov 1999 13:26:05 To: rsgb_lf_group@blacksheep.org From: "Rik Strobbe" Subject: LF: new visual-CW techniques 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: Thanks to all who responded to my previous mail, it seems that others had similar ideas to increase the transmission speed for visual-CW. For those who also appreciate the 'therapeutic' value of visual-CW and are not interested in speeding up things there is the possibility to increase the 'dot-length' by a certain factor (+/- 3). This will ensure that the duration of the QSO will not be too short and has the advantage that you can make the QSO with less power or cover a bigger distance with the same power. Besides that it is not my intention start a crusade against the 'classic' visual-CW. For those interested in 'optimizing' this visual mode I want to give some insight in my approach to the problem : First I tried to 'analyse' Morse-code and compare it with more classical digital modes that use either ASCII-code or Baudot-code. I came to 2 major differences : 1. Variable code length, the most frequent characters have short code. This is very usefull for transmitting text but rather useless in the visual-CW QSO's where data exchange is mainly limited to calls and reports. But regardless from this even in visual-CW Morse-code has the advantage that we radioamateurs know it and can easily 'read' it (what is not the case for ASCII or Baudot). 2. Where ASCII and Baudot are stricktly binary (on/off or 1/0 or mark/space), Morse-code has 3 different 'components' : dot, dash and space. For classical morse-code detection by ear this 3 'components' are converted to a on/off (binary) system where the dot is represented by a on-off (or 10) sequence, the dash by a on-on-on-off (or 1110) sequence and the space by a off-off-off (or 000) sequence. Characters are created by dash-dot combinations, space is used to separate characters (single space) or words (double space). Next I took the 'pro' and 'contra' of the 3 systems (ASCII, Baudot, Morse) : - ASCII : pro = fixed code length and generally accepted for data-exchange contra = long (8 bit) allowing 256 characters, while in practice we only need about 45 characters - Baudot : pro = fixed code length, widely known and accepted from 'teletype' and shorter than ASCII contra = 5-bit code allows only 32 characters, this is 'fixed' by having a code for 'switch to figure' - Morse : pro = well know by hams, relative short code contra = not only the characters have different length but even the 'components' (dot, dash, space) differ in length. This contra in Morse-code can be eliminated in visual CW if we replace the 'time difference' between dot and dash by a frequency difference. We can represent a dot by transmitting a 'low' frequency during 1 'timeperiod', a dash by transmitting a 'high' frequency during 1 'timeperiod' and a space by no transmission during 1 'timeperiod' (or as alternative by transmitting a 'middle' frequency - but this will increase average power by 50% and bandwidth by 100%). As shown in my previous mail this will shorten time needed to transmit by 300%. Or the other way arround the length of a 'timeperiod' can be increased by 300% to be able to cover the same distance with reduced power or to increase the distance with the same power. Some 'dry tests' (generating code on screen by software) have shown that one can relatively easy 'decode' this kind of CW (for each 'low' you say 'dit', for each 'high' you say 'da'). Only for long characters that have only dots or dashes it is a bit more difficult, but up to 3 same (eg. S or O) it is no big problem (so T,M and O are easily kept apart, so are E,I and S) but distinguising H from 5 takes some exercise on a screen. But this can be easily solved when we can decide on a 'standard timelength' (eg. 3 seconds) and project a grid on the screen where eache 'square' represents 1 timeunit, so your eye has a kind of visual reference. If there is interest I am willing to adapt the QRS software for those who want to do some tests. Testing it in practice will be the only way to find out if this 'alternative' is any good. 73, Rik ON7YD