Return-Path: Received: (qmail 5775 invoked from network); 27 Jan 2001 14:57:00 -0000 Received: from unknown (HELO warrior-inbound.servers.plus.net) (212.159.14.227) by extortion.plus.net with SMTP; 27 Jan 2001 14:57:00 -0000 Received: (qmail 4555 invoked from network); 27 Jan 2001 14:59:49 -0000 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior with SMTP; 27 Jan 2001 14:59:49 -0000 Received: from majordom by post.thorcom.com with local (Exim 3.16 #1) id 14MWix-0002Ue-00 for rsgb_lf_group-outgoing@blacksheep.org; Sat, 27 Jan 2001 14:53:07 +0000 Received: from mail.ctihk.com ([203.80.96.3]) by post.thorcom.com with esmtp (Exim 3.16 #1) id 14MWiv-0002UU-00 for rsgb_lf_group@blacksheep.org; Sat, 27 Jan 2001 14:53:05 +0000 Received: from dellml (234user182.ctinets.com [203.80.234.182]) by mail.ctihk.com (8.10.1/8.10.1) with SMTP id f0REj0m32499 for ; Sat, 27 Jan 2001 22:45:01 +0800 Message-ID: <001b01c08870$f6b97d80$d400a8c0@scgroup.com> From: "Stewart Nelson" To: rsgb_lf_group@blacksheep.org References: <23564246.980604804777.JavaMail.imail@chilly.excite.com> Subject: LF: Proposed new LF signal format Date: Sat, 27 Jan 2001 06:53:46 -0800 Organization: SC Group MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: I believe that, by using a signal format designed specifically for LF weak-signal operation, it should be possible to communicate at S/N values at least 10 dB below what is typically needed for QRSS. Some recent experiments by Lyle Kohler convinced me that the presently popular modes are far from optimum, and I have written a program to show the potential of a new mode. I call it WOLF (Weak-signal Operation on Low Frequency). A while ago, Lyle comparison tested various systems commonly used for amateur LF communication. Modes tested included conventional CW, QRSS (decoded both visually, and aurally with CRUNCH), and several PSK formats. Using an audio editor, Lyle mixed an attenuated copy of each signal with a "standard" sample of noise recorded from an LF receiver. He measured the maximum attenuation which each mode could tolerate before copy became impossible. The results can be seen on his Web site at http://www.computerpro.com/~lyle/weaksigs/weaksigs.htm . My present software is essentially an off-line demo. The transmit mode creates a .wav file; the receive mode reads a .wav file and attempts to decode the message. So far, it has only been tested by mixing the Tx output with noise downloaded from Lyle's site (I am traveling and have no LF Tx or Rx capability). But the simulated results have been quite encouraging; there is often good copy when the attenuation is 44 dB. This is a signal 11 dB weaker than that which was needed by BPSK at MS1000, and 14 dB below the threshold for 0.4 WPM QRSS. I would greatly appreciate any suggestions for making this system even more robust, and encourage anyone interested to download the software and try it. A simple test would be to mix the Tx output with your favorite QRM or QRN and see how it fares. Much better would be trying it on the air. If you have an SSB rig which can output LF, just play the WOLF output file, feeding the transmitter audio from your sound card. At the receiving end, record a .wav file from the receiver audio, and feed it to WOLF for decoding. If you need a different format file to key your Tx in BPSK, please let me know and I'll try to provide it. Below is a brief description of the WOLF signal; you can find more details, and the software, at http://www.scgroup.com/ham/wolf.html . Some features of this format are: * An explicit reference signal for robust frequency and phase lock * Average Tx power nearly equal to PEP * Coding to minimize number of bits for a given message * Forward error correction with high coding gain * Coherent detection * Matched filter detection (bit clock derived at receiver) * Interleaving (can tolerate gaps in reception) None of these ideas are new; it just seemed logical to combine those features of modern commercial systems which offer performance gains in our environment. Most amateur weak-signal work uses some form of CW or BPSK. It is often said that, for the same PEP, BPSK has a 6 dB advantage (CW transmits only half the average energy, and half of that is carrier with no message content). However, CW's carrier is far from wasted. It enables recovery of the frequency and phase of the incoming signal, even when it is very weak. That's one reason QRSS is so popular! In contrast, conventional BPSK relies on a non-linear process to recover the carrier, and fails to lock when the S/N is very low. Bill de Carle's AFRICA avoids this problem in a clever way -- by matching the phase pattern with all possible transmitted characters. But, this requires that any forward error correction (FEC) coding be applied separately to each character, which limits coding gain. The WOLF signal is BPSK (at MS100), but after each "data" bit, a "reference" bit is added. The reference stream is a pseudo-random sequence which is known in advance by the receiver. The precise frequency and phase can be measured, even when the signal is too weak to decode the message. The reference "channel" also provides robust bit timing and framing information, so the actual message need not include synchronizing bits. The symbol set is limited to 40 (capital letters, digits, space, and 3 punctuation). This permits sending three characters using only 16 bits. A data packet is fixed at 15 characters (80 bits), enough to send two call signs plus some report information. A rate 1/6 convolutional code is applied to the entire packet, resulting in a 480 bit message. Including the reference bits, a frame has 960 bits, so it takes 96 seconds to send. A beacon just sends the frame repeatedly. If the signal is strong enough for conventional CW, someone tuning it in only needs to "listen" for a little more than 16 seconds to see the complete message. If some error correction is required, perhaps a minute will suffice. But if the signal is very weak, the receiving software can integrate over as many frames as needed, until good copy is achieved. For two way communication, one can send a frame, and await an acknowledgement. If not received correctly, the frame is resent, until there is enough information for correct copy. However, I believe that one could design a much more efficient protocol, which should permit a QSO to be completed within one hour, even with a signal 10 dB below the QRSS limit. See the web page for more details. Comments and suggestions welcome. 73, Stewart KK7KA