Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-db05.r1000.mx.aol.com (Internet Inbound) with ESMTP id 1ACB2380000B4; Sun, 6 May 2012 20:19:14 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1SRBel-0001To-QI for rs_out_1@blacksheep.org; Mon, 07 May 2012 01:18:27 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1SRBel-0001Te-7F for rsgb_lf_group@blacksheep.org; Mon, 07 May 2012 01:18:27 +0100 Received: from smtpout4.wanadoo.co.uk ([80.12.242.68] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1SRBei-00033x-V2 for rsgb_lf_group@blacksheep.org; Mon, 07 May 2012 01:18:26 +0100 Received: from AGB ([2.26.47.14]) by mwinf5d51 with ME id 6oJP1j0040JMiBE03oJPb9; Mon, 07 May 2012 02:18:24 +0200 Message-ID: <2C99889CBE1E4F308F2A3180B7E68E97@AGB> From: "Graham" To: References: <4F97E9C2.9030000@iup.uni-heidelberg.de> <7B23411450514A5CB804E6D2C65A1876@JimPC> <006601cd2ba5$30f197b0$0401a8c0@xphd97xgq27nyf> <007e01cd2bad$7d53e880$0401a8c0@xphd97xgq27nyf> <3348BF8ACE9844469AAF7B2E97C63D98@AGB> <001d01cd2bde$669669c0$0401a8c0@xphd97xgq27nyf> In-Reply-To: <001d01cd2bde$669669c0$0401a8c0@xphd97xgq27nyf> Date: Mon, 7 May 2012 01:18:23 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Antivirus: avast! (VPS 120506-1, 06/05/2012), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Is that CW , A-M or P-M ?? :) (Ante Morse or Post Morse) [...] Content analysis details: (0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.12.242.68 listed in list.dnswl.org] 0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE X-Scan-Signature: 40d35b6fcf8b66e4fec28fa30f99f125 Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.63 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-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:471276992:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d40594fa7150203a4 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none Is that CW , A-M or P-M ?? :) (Ante Morse or Post Morse) -------------------------------------------------- From: "mal hamilton" Sent: Monday, May 07, 2012 12:17 AM To: Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? > Cave Man is also back on the scene !! Just mention Pipe Dreamers (remember > the Band) plus Moon pull at Perigee and he is OFF. > others are sensitive when Windows is mentioned causing sporadic unreast, > not > to mention CW > Back to normal soon when the Moon goes Apogee. > To avoid conflict the following words should be avoided, Windows, CW, > Opera, Panto, Pipe Dreamer, Sense of humour. > > de kev > > > ----- Original Message ----- > From: "Graham" > To: > Sent: Sunday, May 06, 2012 9:50 PM > Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? > > >> From the BBC news , >> >> ''The phenomenon, known as a perigee full moon, means the Moon appears up > to >> 14% bigger and 30% brighter than when it is furthest from the planet.'' >> >> They go on to state :- >> >> ''Scientists have dismissed the idea the perigee could cause strange >> behaviour - like lycanthropy - or natural disasters.'' >> >> As yet another 'Dog fight' breaks out, Obviously are not monitoring >> Black sheep then ? >> >> G.. >> >> >> -------------------------------------------------- >> From: "mal hamilton" >> Sent: Sunday, May 06, 2012 6:27 PM >> To: >> Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? >> >> > Does Pipe Dreamer ring a bell !!!! >> > >> > ----- Original Message ----- >> > From: "Roger Lapthorn" >> > To: >> > Sent: Sunday, May 06, 2012 4:58 PM >> > Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? >> > >> > >> > Mal, you are talking rubbish again. >> > >> > Without frequency locking in SL and very very narrow bandwidths > possible, >> > there is no way I would have been able to copy the EU VLF amateurs last >> > year >> > in this semi-urban noise pool. Not many of us live in v.quiet rural > areas. >> > You may be able to copy VLF DX at QRSS3 but most of us can not at any >> > distance. >> > >> > Regarding VLF activity in the UK, I continue to do earth-mode tests >> > although >> > I have been distracted to NLOS optical comms of late. Not sure if G3XIZ > is >> > planning further radiated tests. Several stations including G3ZJO > monitor >> > EU >> > VLF tests regularly. >> > >> > 73s >> > Roger G3XBM >> > >> > >> > -- Via my 2.4GHz transceiver -- >> > >> > On 6 May 2012, at 17:26, "mal hamilton" wrote: >> > >> >> Andy >> >> All these complications to accommodate the Appliance Operator who > cannot >> >> read MORSE or watch QRSS on a screen. >> >> g3kev >> >> >> >> ----- Original Message ----- >> >> From: "Andy Talbot" >> >> To: >> >> Sent: Sunday, May 06, 2012 4:14 PM >> >> Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ? >> >> >> >> >> >> The problem with USB slippage comes about because of the Isochronos >> >> mode (yes, that is spelt correctly, it is not IsoSYNchronous) - >> >> where it sends puts real time rapid data transfer as more important >> >> than lost samples and sends samples in real time without checking >> >> This is probably just what music and audio people want, but it screws >> >> up using USB based sound cards as precision timed A/D converters. >> >> USB does have other modes with full error checking, albeit with some >> >> latency, but the latency wouldn't matter here. >> >> >> >> While it would be a pretty simple task these days to build an external >> >> A/D converter and interface to USB properly, the resulting data stream >> >> would need a custom driver written, then all the decoding software we >> >> know and love would have to be modified to work with this custom >> >> interface. Then someone else would come along with another design >> >> and we'd have to start again. >> >> >> >> I suspect it is going to be absolutely impossible to use the soundcard >> >> as a guaranteed glitch free A/D converter. >> >> >> >> Joe Taylor K1JT in the WSJT suite has a dead simple pragmatic >> >> solution. Instead of trying to read the data in real time, all the >> >> WSJT modes read the entire transmisisons' worth of data to a .WAV >> >> file, and the software works on that. While WSJT uses the soundcard >> >> to do the job it will suffer from the same slippages (which don't >> >> matter' of course' for those modes) the idea of an intermediate buffer >> >> file would help. >> >> >> >> A custom A/D could send its data in its own format via USB, or serial >> >> COM port or whatever, to software that saves blocks in the format of a >> >> .WAV file. Then the decoding software works on the resulting .WAV >> >> files. It won't be real time any more, but none of these slow data >> >> modes actually are that real time. The speed of reading and switching >> >> (using a pair of ping-pong files if necessary) can make the whole >> >> system pseudo real time - in the same way as WSJT appears to run >> >> continuously. >> >> >> >> Now, any A/D design can be used provided the results are written to a >> >> .WAV file. Wav files can have any sample rate (so long as it is an >> >> integer number of Hz) and do not have to be restricted to 48000, 11025 >> >> or whatever, so custom LF receivers using quite slow A/D converters >> >> and low sample rates are now valid. >> >> >> >> Just throwing that idea into the ring.. >> >> >> >> Andy >> >> www.g4jnt.com >> >> >> >> >> >> On 6 May 2012 16:14, James Moritz >> >> wrote: >> >>> Dear Andy, LF Group, >> >>> >> >>> A bit late, but never mind... >> >>> >> >>>> Has anyone tried using an external USB soundcard with a separate >> >>>> locked clock? Most work from a 12MHz crystal which can be replaces >> >>>> with a GPS locked source without too much effort. But I can't help >> >>>> wondering if there will be subsequent USB synchronisation glitches >> >>>> upsetting the input sampling. >> >>> >> >>> >> >>> >> >>> I can confirm that glitches do occur with USB sound cards. I have > found >> >> this >> >>> to be a perennial problem trying to use such a sound card with the >> > laptops >> >> I >> >>> have available. For 9kHz reception, the relatively rapid temperature >> >>> fluctuations inside the laptop, and resulting cyclic drift of the >> > internal >> >>> soundcard sampling frequency interfere with the operation of DL4YHF's >> >>> ingenious sample rate correction facility in SpecLab, making the >> >>> internal >> >>> sound card unusable for FFT resolution below a few millihertz. I >> >>> found >> >>> my >> >>> USB soundcard solved this particular problem quite well, but > introduced >> >>> glitches that made achieving FFT resolution in the uHz range >> >>> impractical. >> >>> >> >>> Watching Speclab's sample rate correction "history" window, the USB > card >> >>> sample rate typically starts off a few hundred ppm low (much larger > than >> >> the >> >>> actual clock frequency error), but remaining stable to within a few > ppm, >> >> but >> >>> then at unpredictable intervals abrupt jumps in sample rate of a > similar >> >>> order of magnitude occur, with corresponding "blips" on the > spectrogram >> >>> traces. The reported sample rate is always lower than the nominal > value, >> >>> suggesting that some samples are being periodically discarded >> >>> somehow. >> >>> >> >>> The sound card uses a single-chip integrated audio codec and USB >> >>> transceiver, using a single 12MHz crystal. I can't really believe in >> >>> "USB >> >>> slippage" in the hardware - surely losing some of the data would > either >> > be >> >>> handled quietly by the USB error checking, or result in endless error >> >>> messages. The same sound card seems to work in a glitch-free way when >> >>> plugged into my desktop machine, where the reported sample rate error > is >> >> in >> >>> line with the error in the crystal frequency. >> >>> >> >>> Cheers, Jim Moritz >> >>> 73 de M0BMU >> >>> >> >> >> >> >> >> >> > >> > >> > >> >> > >