Return-Path: Received: (qmail 73507 invoked from network); 26 Feb 2004 14:44:46 -0000 Received: from unknown (HELO ptb-mxscan02.plus.net) (212.159.14.236) by ptb-mailstore03.plus.net with SMTP; 26 Feb 2004 14:44:46 -0000 Received: (qmail 17080 invoked from network); 26 Feb 2004 14:44:45 -0000 X-Filtered-by: Plusnet (hmail v1.01) X-Spam-detection-level: 11 Received: from ptb-mxcore02.plus.net (212.159.14.216) by ptb-mxscan02.plus.net with SMTP; 26 Feb 2004 14:44:38 -0000 Received: from post.thorcom.com ([193.82.116.20]) by ptb-mxcore02.plus.net with esmtp (Exim) id 1AwMkg-0004EM-GO for dave@picks.force9.co.uk; Thu, 26 Feb 2004 14:44:38 +0000 X-Fake-Domain: majordom Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1AwMjU-0003eJ-99 for rs_out@blacksheep.org; Thu, 26 Feb 2004 14:43:24 +0000 Received: from [147.197.200.9] (helo=hestia.herts.ac.uk) by post.thorcom.com with esmtp (Exim 4.14) id 1AwMjS-0003e3-MF for rsgb_lf_group@blacksheep.org; Thu, 26 Feb 2004 14:43:22 +0000 X-Fake-Domain: gemini Received: from gemini ([147.197.200.44] helo=gemini.herts.ac.uk) by hestia.herts.ac.uk with esmtp (Exim 3.22 #1) id 1AwKfS-0000qa-01 for rsgb_lf_group@blacksheep.org; Thu, 26 Feb 2004 12:31:06 +0000 X-No-DNS-For: 147.197.232.252 Received: from [147.197.232.252] (helo=RD40004) by gemini.herts.ac.uk with esmtp (Exim 3.33 #1) id 1Avzwr-0004gH-00 for rsgb_lf_group@blacksheep.org; Wed, 25 Feb 2004 14:23:42 +0000 From: "James Moritz" To: rsgb_lf_group@blacksheep.org Date: Wed, 25 Feb 2004 14:23:41 -0000 Organization: University of Hertfordshire X-Bad-Message-ID: no DNS (RD40004) Message-ID: <000001c3fbaa$f819d340$fce8c593@RD40004> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-reply-to: <001101c3f91c$82ba8c10$687a37c0@w2ksn> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-UH-MailScanner: No Virus detected Subject: LF: RE: feedback requested for new WOLF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-PN-SPAMFiltered: yes X-Spam-Rating: 2 Dear Stewart, LF Group, Here are some comments on your new WOLF proposals from my point of view. The LF gear here is basically an RA1792 receiver, plus the TX "Exciter" is an old Racal 9084 signal generator. Both these have PLL synthesisers with internal OCXO references, which give them much better frequency stability than amateur-type rigs; additionally, they can use an external reference, which for last year's PSK tests was a Z3801 GPS receiver/clock, which has both a 1pps output, and a 10MHz OCXO which is continuously calibrated against the GPS signal. For reception, R3 is closest to what I am currently using anyway. For the R1 and R2 options, as others have already said, using an SSB filter for LF receive around here is problematic because of the strong signals that would tend to be present in the passband - I guess these will frequently be 60dB or more over the wanted signal. While a sound card with a halfway decent A/D converter can probably cope with this, as can the RX front end, the RX IF and audio sections were never designed with this in mind. It would be possible to re-design the IF/audio circuits for this purpose, but that would be at least as complicated as providing the external frequency locking for the receiver. An exception to this would be if you were designing a specialised homebrew receiver for this mode - then it could be a quite simple TRF design with a crystal-controlled, fixed BFO frequency. A further problem with R1 concerns using a loop antenna for receive. At my QTH, the optimum orientation of the loop to receive North American signals puts the local Loran station in the loop null, making it difficult to use the Loran signal for synchronisation without degrading the noise rejection of the loop. Using either LORAN or the GPS 1pps to calibrate the receive frequency and the sound card sampling rate would certainly be useful for other purposes too, as well as WOLF reception. On the transmission side, T1 is essentially the method I have used in the past for PSK generation anyway, excepting the use of the GPS 1pps for synchronisation, which was done with hardware. It makes the carrier frequency totally independent of sound card sampling rate error. I have also used method T2 (again without the GPS synchronisation) to generate "Jason" signals. The sound card initial accuracy is not particularly good, so certainly some form of calibration would be needed. T3 sounds like quite a good way of achieving the required results without requiring high quality references in the TX - if the frequency generation for RX used the same sources as TX (e.g. an HF transceiver with a linear transverter to 136k), couldn't this also be used to calibrate the RX frequency? Considering the clock oscillator of a sound card can be quite hard to get at, and may well not be at a particularly convenient frequency, I would think T4 would be no easier than making a frequency source that was locked directly to the 1pps signal. I suspect T5 would run into similar problems as R1 and R2 re bandwidth, unless multiple LF receivers were available. How precise would the frequency of TX and RX need to be? It occurs to me that, even if using precise frequency references, the DDS synthesisers widely used now have a kind of "built-in" frequency error. The tuning increments of the DDS are very small, but are not generally convenient fractions of 1Hz, whereas the tuning display normally does display the frequency as a whole number of Hz, and presumably selects the nearest rounded-off DDS tuning step. This will result in a frequency error which depends on the DDS clock frequency, the phase accumulator length, any PLL multiplying factor, the set frequency, and the way the tuning microcontroller rounds off the frequency display. It would be difficult for the operator to figure out what actual error this would cause at a given frequency. I guess this might come to 10s of millihertz with typical HF receivers. Cheers, Jim Moritz 73 de M0BMU