Return-Path: Received: (qmail 8253 invoked from network); 1 May 2001 16:00:44 -0000 Received: from unknown (HELO murphys-inbound.servers.plus.net) (212.159.14.225) by excalibur.plus.net with SMTP; 1 May 2001 16:00:44 -0000 Received: (qmail 18191 invoked from network); 1 May 2001 16:00:40 -0000 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by murphys with SMTP; 1 May 2001 16:00:40 -0000 Content-Transfer-Encoding: 8bit Received: from majordom by post.thorcom.com with local (Exim 3.16 #2) id 14ucLx-0008OV-00 for rsgb_lf_group-outgoing@blacksheep.org; Tue, 01 May 2001 16:46:17 +0100 X-Priority: 3 Received: from bob.dera.gov.uk ([192.5.29.90]) by post.thorcom.com with esmtp (Exim 3.16 #2) id 14ucLt-0008OQ-00 for rsgb_lf_group@blacksheep.org; Tue, 01 May 2001 16:46:13 +0100 X-MSMail-Priority: Normal Received: by bob.dera.gov.uk; (8.8.8/1.3/10May95) id QAA13160; Tue, 1 May 2001 16:49:29 +0100 (BST) Received: (qmail 18170 invoked from network); 1 May 2001 16:20:47 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from gauntlet.mail.dera.gov.uk (172.16.9.10) by baton.dera.gov.uk with SMTP; 1 May 2001 16:20:47 -0000 Received: by gauntlet.mail.dera.gov.uk; id QAA11677; Tue, 1 May 2001 16:16:54 GMT Received: from unknown(10.71.64.31) by gauntlet.mail.dera.gov.uk via smap (3.2) id xma011630; Tue, 1 May 01 16:16:36 GMT Received: from FRN-MAIL-3.dera.gov.uk (unverified) by mailguard.dera.gov.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 1 May 2001 16:33:40 +0100 Received: by frn-mail-3.dera.gov.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 16:26:15 +0100 Message-ID: <65AECDF1F89AD411900400508BFC869F9C047B@pdw-mail-1.dera.gov.uk> From: "Talbot Andrew" To: rsgb_lf_group@blacksheep.org Subject: LF: RE: Re: more Wolf tests Date: Tue, 1 May 2001 16:26:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset=iso-8859-1; format=flowed Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: re Jim's comments : > > I have been thinking along similar > lines for somewhat different reasons. I don't claim to have > expertise in this field, but suppose the data rate of Wolf was > reduced by a factor of 10, ie, to 1 bit per second. What would be > the effects? > I was not proposing just slowing Wolf down, I was arguing the merits of using Uncoded BPSK for the same performance (a-la VE2IQ & Coherent) but at 1 b/s - this would give a few extra dB capability immediately. With Wolf coding as well, this could give 10 dB extra but at 16 minutes for a 15 character message. > -The reduced transmitted data rate should be largely made up for > by the increased SNR possible in the narrower bandwidth, reducing > the number of data frames required to be processed for successful > decoding. So the overall throughput should be little changed. > Although I think you said that here > -The overall amount of data to be processed in a given time would > be reduced by an order of magnitude - this would reduce the time > taken for the PC to process the received data, and so bring > decoding nearer to "real time" without requiring a very fast PC. > -Because each bit period is ten times longer, but the overall > decoding period would be roughly the same, the bit-timing accuracy > required from the soundcard or other interface would be reduced. > The bit timing accuracy needs to be of the order of the bit interval, so at 1b/s 10 times better timing accuracy will be needed, but at this speed it becomes easier to set to UTC ticks - from MSF or GPS etc. > The main drawback would be that increased demands would be > made on TX and RX stability - probably an overall tolerance of > about +/-0.1Hz or 1ppm. While this is easily acheived by equipment > with temperature stabilised or compensated references, it is a bit > much for most amateur HF gear. Perhaps it would be possible to > improve the frequency tracking capabilities of Wolf to cope with > this. > As for frequency stability, 1ppm really ought not to be a problem now - as I've said many times before here. The microwavers have regularly been getting that sort of stability for years when out /P, without even resorting to TCXOs - merely using an overtone crystal in a series resonant Butler oscillator in the region of 100MHz with a clip on crystal heater costing a couple of pounds. (Digital dividers operating at 100MHz to generate LF freqs are straightforward now, 100MHz is no problem for CMOS logic these days). Alternatively small TCXOs are very widely available now, every mobile phone has one, and they are available from all the component suppliers for a few pounds. These lower cost TCXOs are specified at 2ppm, which nearly always means at least 1ppm in practice or else they couldn't guarantee the figure, and many can be trimmed to within 0.2ppm and can stay there for months, even if turned on and off repeatedly. A 5MHz TCXO driving a DDS gives you just about the most versatile LF signal source imaginable 0 to 2 MHz in steps of 0.0012Hz. The clock doesn't even have to be a round value of frequency - anything can be pressed into service for driving a DDS chip. After a concerted effort and much frustration with numbers that turned out to be coded using Octal notation, last weekend finally manage to 'crack' the Wolf coding sufficient to be able to generate code from my own software written in another language which agrees with that from software supplied by Stewart. The next stage is to port to a PIC processor to allow a small beacon generator to be constructed with data that can be changed on the fly. Andy G4JNT -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.