Envelope-to: dave@picks.force9.co.uk Delivery-date: Wed, 25 May 2005 11:33:11 +0100 Received: by pih-mxcore05.plus.net with spam-scanned (PlusNet MXCore v2.00) id 1DatCE-0008KS-Ca for dave@picks.force9.co.uk; Wed, 25 May 2005 11:33:08 +0100 Received: from post.thorcom.com ([193.82.116.20]) by pih-mxcore05.plus.net with esmtp (PlusNet MXCore v2.00) id 1DatCD-0008Jq-VB for dave@picks.force9.co.uk; Wed, 25 May 2005 11:33:06 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1DatBu-0000Re-M8 for rs_out_1@blacksheep.org; Wed, 25 May 2005 11:32:46 +0100 Received: from [193.82.116.30] (helo=relay.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1DatBu-0000RV-0M for rsgb_lf_group@blacksheep.org; Wed, 25 May 2005 11:32:46 +0100 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by relay.thorcom.net with esmtp (Exim 4.43) id 1DatBs-0002ft-Bb for rsgb_lf_group@blacksheep.org; Wed, 25 May 2005 11:32:45 +0100 Received: from JAYTERMINAL (c-67-177-102-19.hsd1.ct.comcast.net[67.177.102.19]) by comcast.net (rwcrmhc13) with SMTP id <2005052510323701500ftqkqe>; Wed, 25 May 2005 10:32:37 +0000 Message-ID: <001301c56115$24ef57c0$6401a8c0@JAYTERMINAL> From: "Jay Rusgrove" To: rsgb_lf_group@blacksheep.org References: <000001c5605f$4a951110$e6a4c593@RD40002> <011a01c560f7$60b4afd0$1101a8c0@w2ksn> Date: Wed, 25 May 2005 06:33:08 -0400 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.1165 X-SPF-Result: relay.thorcom.net: 204.127.198.39 is neither permitted nor denied by domain of comcast.net Subject: LF: Re: Re: RE: reception with multiple antennas Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-PN-SpamFiltered: by PlusNet MXCore (v2.00) Stewart If you could use recordings from CT just say the word... Would 1pps ticks recorded on the unused audio channel be of any benefit in this system? Jay, W1VD p.s. RX setup here: Harris RF-590 + several HP 3586Cs all GPS disciplined by HP-Z3801A. ----- Original Message ----- From: "Stewart Nelson" To: Sent: Wednesday, May 25, 2005 3:00 AM Subject: LF: Re: RE: reception with multiple antennas > Hi Jim and all, > > > I guess for an initial feasibility study it would only be necessary > > for a number of stations to simultaneously make recordings under > > defined conditions, and then the data could be up-loaded and > > post-processed at leisure. > > Because the files will be quite large, I'll set up an FTP account > for the purpose, and email the login info to the participants. > As a start, we might record 8-bit, 11025 Hz sampling, 135.500 kHz USB, > SSB bandwidth, about half an hour, at a time when it's likely for > DX QRSS to be visible. I'm open for suggestions to change any of > the above parameters. > > > I presume you would have to initially synchronise the recordings > > to within a GRI period for the signals to be combined in this way > > would this require some external timing signal, or is it possible > > to obtain that info from the Loran signals? > > You can obtain some timing information from LORAN. The signals are > synchronized with UTC. For example, consider the signal from > Lessay. Conceptually, the first master pulse group on 6731 was > emitted on 01/01/1958 at 00:00:00, and its first slave pulse on 7499 > 14100 microseconds later. But for the next pulse group pairs, the > difference was 14100 + 2 * 10 * (7499 - 6731). Now, the LCM of 2*6731 > and 2*7499 is 100951538, so the cycle repeats every 1009.5154 seconds. > In theory, if you know what time it is, within +/- 500 seconds, you > could tell the exact time just by looking at Lessay. By including > signals from other chains, you could tell the date and time without > any prior information. One could even write a program that would > analyze a .wav file and tell what frequency was tuned, what time the > recording was made, and of course where the receiver was located. > > In practice, this is not only quite complex, but also very difficult, > because the time difference between 6731 and 7499 can be any multiple > of 20 microseconds. To distinguish them reliably, we would need to > measure the difference within +/- 10 us, requiring each measurement > to be accurate to +/- 5 us. A real LORAN receiver can do that easily, > but when we are limited to SSB bandwidth, getting distorted splatter > signals, and sampling audio every 91 us, it would be very difficult. > So, I'll require that the operator identify the start time of each > recording, with an accuracy of +/- 10 seconds. Then, the program > need only distinguish time differences that are at least 880 us apart. > > > how would you compensate for variations in gain between different > > receiving stations? > > I'd calibrate by using the strength of the reference LORAN signal. > Unfortunately, this is subject to error from skywave interference. > A real LORAN Rx can eliminate skywave by looking at just the first > few cycles of the pulse, but that would be nearly impossible for us, > for the reasons cited above. Of course, if the stations are quite > close together, the skywave signals should be similar. If not, we > could fix the gain using daytime calibration data. If that is also > unworkable, because the Rx gain is unstable, I don't have a good > answer. > > > how would you deal with variations of phase response within the > > passbands of different stations? > > That's a serious problem -- Joe Taylor gave up on coherent detection > for JT65, largely because of the horrible group delay characteristics > of the typical ham transceiver. The S/N of the average LORAN line > in Markus' recording (10 mHz BW) is about 10 dB. I believe that > gating the input with a window for the desired station will improve > that by at least 3 dB. There are about 682 lines in 2400 Hz passband. > If we compute the phase of each of those lines, and apply a little > smoothing, we should have a quite accurate picture of the phase > response. > > That's the good news. The bad news is that there may be random > phase errors caused by inability to lock onto a specific cycle. > I'm still working on that. > > 73, > > Stewart KK7KA >