Return-Path: Received: (qmail 37382 invoked from network); 25 Feb 2004 07:40:22 -0000 Received: from unknown (HELO ptb-mxscan01.plus.net) (212.159.14.235) by ptb-mailstore01.plus.net with SMTP; 25 Feb 2004 07:40:22 -0000 Received: (qmail 76982 invoked from network); 25 Feb 2004 07:44:03 -0000 X-Filtered-by: Plusnet (hmail v1.01) X-Spam-detection-level: 11 Received: from ptb-mxcore01.plus.net (212.159.14.215) by ptb-mxscan01.plus.net with SMTP; 25 Feb 2004 07:43:59 -0000 Received: from post.thorcom.com ([193.82.116.20]) by ptb-mxcore01.plus.net with esmtp (Exim 4.30; FreeBSD) id 1Avti3-000JnZ-Av for dave@picks.force9.co.uk; Wed, 25 Feb 2004 07:43:59 +0000 X-Fake-Domain: majordom Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Avtgo-0001Rc-0h for rs_out@blacksheep.org; Wed, 25 Feb 2004 07:42:42 +0000 Received: from [165.254.4.18] (helo=mail.mcf.com) by post.thorcom.com with esmtp (Exim 4.14) id 1Avtgm-0001RT-PO for rsgb_lf_group@blacksheep.org; Wed, 25 Feb 2004 07:42:40 +0000 X-Fake-Domain: w2ksn Received: from w2ksn (192.55.122.104) by mail.mcf.com with ESMTP (Eudora Internet Mail Server 3.2.2) for ; Wed, 25 Feb 2004 02:42:40 -0500 X-Bad-Message-ID: no DNS (w2ksn) Message-ID: <001f01c3fb72$f5156750$687a37c0@w2ksn> From: "Stewart Nelson" To: rsgb_lf_group@blacksheep.org References: <002601c3f93e$478b35a0$6507a8c0@Main> Date: Tue, 24 Feb 2004 23:42:44 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: LF: Re: WOLF development Content-Type: text/plain; charset=iso-8859-1; 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 Hi Alan, Sorry for the slow reply; I was waiting for responses to see what hardware locking ability potential users already had. All but one had the ability to drive their receiver's reference from a GPS-derived frequency standard, so R2 is on the back burner for now, anyhow. The narrow filter reduces the number of "visible" lines, and so degrades the S/N of the locking signal, because it is mixed with band noise and QRM. Careful level adjustment would minimize the problem, but there are many constraints: The impulse resulting from the 1 pps excitation would have to be much larger than the general noise level, but not clip the A/D, while the noise (with buried desired signal) level would still need to be high enough that A/D quantizing noise and other errors did not degrade the signal too much. Your keyed oscillator idea is interesting, but it appears to introduce another unknown. For example, if the 136 kHz oscillator drifted up 0.01 Hz, it would affect the audio in the same way as the receiver LO drifting down 0.01 Hz. One way to resolve this ambiguity would be to digitally divide the 136 kHz into the audio range, and feed that into the sound card, too. Do you have a simpler solution? 73, Stewart ----- Original Message ----- From: "Alan Melia" To: "LF-Group" Sent: Sunday, February 22, 2004 4:08 AM Subject: LF: WOLF development > Hi Stewart, with reference to R2, I suppose the injection of the 1pps into > the RX input with provide some "pseudo-Loran" lines for frequency locking. > If the 1pps was used to "key" a simple 136khz oscillator, this would produce > a comb of 1Hz spaced lines in the right area all locked to the GPS. This > would allow easy control of their level, which is often a problem when > putting a calibration signal up even on QRSS. This is a technique of > frequency synthesis used back in the old days when PLLs occupied a couple of > racks and consumed a few kW. > > The necessity to use an SSB filter width might be a problem in Europe where > there are many strong signals around. I presume that the rise-time with a > narrower filter is the problem extracting accurate enough timing?? Having > got frequency sync data at RF could timing data be put into the soundcard at > audio....possibly on the other channel? > > Great ....I look forward to seeing the final solution. > > Cheers de Alan G3NYK > alan.melia@btinternet.com > > > >