Delivered-To: daveyxm@virginmedia.com Received: by 10.50.237.98 with SMTP id vb2csp332008igc; Wed, 22 Jan 2014 15:46:56 -0800 (PST) X-Received: by 10.194.63.228 with SMTP id j4mr4275043wjs.34.1390434415265; Wed, 22 Jan 2014 15:46:55 -0800 (PST) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id wv8si7888918wjb.32.2014.01.22.15.46.54 for ; Wed, 22 Jan 2014 15:46:55 -0800 (PST) Received-SPF: neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) client-ip=195.171.43.25; Authentication-Results: mx.google.com; spf=neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) smtp.mail=owner-rsgb_lf_group@blacksheep.org; dkim=pass header.i=@mx.aol.com Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1W67AQ-0006hj-Vp for rs_out_1@blacksheep.org; Wed, 22 Jan 2014 23:25:06 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1W67AP-0006ha-TH for rsgb_lf_group@blacksheep.org; Wed, 22 Jan 2014 23:25:05 +0000 Received: from omr-m08.mx.aol.com ([64.12.222.129]) by relay1.thorcom.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1W67AM-0006Na-Ss for rsgb_lf_group@blacksheep.org; Wed, 22 Jan 2014 23:25:04 +0000 Received: from mtaout-mac01.mx.aol.com (mtaout-mac01.mx.aol.com [172.26.222.205]) by omr-m08.mx.aol.com (Outbound Mail Relay) with ESMTP id 4D48F70199120; Wed, 22 Jan 2014 18:24:59 -0500 (EST) Received: from White (95-91-238-155-dynip.superkabel.de [95.91.238.155]) by mtaout-mac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 3E2F9380000B6; Wed, 22 Jan 2014 18:24:56 -0500 (EST) Message-ID: From: "Markus Vester" To: Cc: "Paul" References: <7A4CDE1B603646609121E5084A1DB819@White> <52DC07A8.2030302@abelian.netcom.co.uk> <1832FDD622264BCA8A17992206AB8366@White> <52DC1304.1010609@freenet.de> Date: Thu, 23 Jan 2014 00:24:52 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390433099; bh=OOykXdO8rxUeRCnsjyG8SKB6dQtUqdbvObNz975Djuc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=OFL7L6Ef3vaD04EJCaPPsyXN/vKLMFBCHKWjiLBBoFJWn0QTuNuETm2t/C4wvnBnH XGdoJDDbI6bJdpEsPUdFnpyo9/3n7HGfQQ+n7h2lLVl/Zj3fiMXt8bihiqvv/Pxyku EIASoPjjNKFeb+Nds/M2Nrt2RRckQKS6dGey68LY= x-aol-sid: 3039ac1adecd52e053486d29 X-AOL-IP: 95.91.238.155 X-Spam-Score: 0.4 (/) 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: Hi Wolf, Uwe, Peter, after a little experimentation, I think I have found a way to set up SpecLab to eliminate transmit phase jumps caused by dropouts in the soundcard output. As a proof of concept, I generated an 8269.998 Hz audio carrier last night. This happened to leak from the audio wires to my VLF antenna, and produced a weak but well defined dash in the 42 uHz grabber window. [...] Content analysis details: (0.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [64.12.222.129 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (markusvester[at]aol.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 1.0 FREEMAIL_REPLY From and body contain different freemails X-Scan-Signature: af51d4375c088ae0fd739df304e30189 Subject: VLF: Transmit phase correction Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CF17D1.88E115D0" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, 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 Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_000D_01CF17D1.88E115D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wolf, Uwe, Peter, after a little experimentation, I think I have found a way to set up = SpecLab to eliminate transmit phase jumps caused by dropouts in the = soundcard output. As a proof of concept, I generated an 8269.998 Hz = audio carrier last night. This happened to leak from the audio wires to = my VLF antenna, and produced a weak but well defined dash in the 42 uHz = grabber window. We can use SpecLabs GPS tracking to take care of any irregularities in = the sound input path to the ADC. When using the 1-pps reference with = phaselock it can identify and correct short dropouts. Augmented by the = built-in NMEA-based timestamping scheme, SpecLab can in principle even = provide a defined absolute phase, referenced to the beginning of the UT = day.=20 But the timing is always relative to the reference seen by the ADC = input, and there is no way to directly sense latency variations in the = buffering between the software and the DAC output. Unfortunately on many = machines, buffer underflows or dropouts on the playback side seem to = happen fairly often, especially when the PC is not left alone but is = used for other jobs on the side. The idea is to feed back a sample of the analog output to the input, = using either an analog loopback (eg the audio mixer, but not a digital = loop like VAC). Or set up a pickup probe to sense antenna current or = voltage, which would also take care of phase shifts from variable = antenna tuning. Then SpecLab can do a phase comparison to a = GPS-referenced internal generator, and steer the frequency of an = independent output oscillator to bring the radiated signal back to the = correct phase. If you want to experiment with this method, you can download the = configuration file=20 http://dl.dropboxusercontent.com/u/26404526/VLF_TX_1pps_PLL.USR=20 which generates a 8270 Hz stabilised signal. To see how it works, take a = look at the circuit diagram in: http://dl.dropboxusercontent.com/u/26404526/screenshot_VLF_TX_1pps_PLL.jp= g The output signal is generated by the digimode terminal block, which can = be set up either for a continuous carrier, or for QRSS or Opera = modulation if you want. It feeds the DAC and the power amplifier through = L5. The output is brought back to the left input (L1) and fed to the "E" = channel of a colour-DF spectrogram. The right channel (R1) gets the 1pps = signal from the GPS which is used for samplerate lock. Lacking an = appropriate GPS unit, I'm not using NMEA timestamps here, but you could = chose so if your unit provides serial data with proper timing. The steady reference frequency is provided by the test signal generator = - this is where you enter your desired output frequency. It is fed to = the second "H" channel of the spectrogram through R5. The colour = (azimuth) of the trace gives an indication of the phase difference = between L1 and R5. The phase lock is implemented as a macro in conditional actions: Every = 200 ms, it checks whether there is a valid probe signal at L1, and is = so, it shifts the digimode frequency within +-0.18 Hz according to the = phase difference. Check this by turmning the DAC off and on: The trace = comes back on with an arbitrary colour, but it will always revert to = green (180=B0) within about three seconds.=20 So to get started, - set up the analog loop path and the 1-pps,=20 - load VLF_TX_1pps_PLL.usr, - change the test signal generator frequency from Uwe's 8270.004 to = yours,=20 - set the digimode teminal to send unmodulated test tone at TX = frequency. - enjoy! Hope this may be useful. Best 73, Markus (DF6NM) From: wolf_dl4yhf=20 Sent: Sunday, January 19, 2014 7:01 PM To: Markus Vester=20 Cc: Paul ; Uwe Jannsen=20 Subject: Re: DJ8WX 8270.004 Hz - transmit phase correction? Hello Markus and all, Am 19.01.2014 18:43, schrieb Markus Vester: 30 dB ...not too bad, is it? Still wondering about the nature of those transmit glitches. Assuming = perfect GPS sync, all possible interruptions in the input data stream = could be detected by the timestamp identification. But there is still a = chance for undetected buffer underruns in the sound output. Would that = affect the phase permanently? Or would the average fill state of the = FIFO buffering eventually be pulled back to the original lag (probably = not)?. I have been pondering a scheme where one audio channel is getting 1pps = while the other is used to sample the transmitter output, eg with a = small pickup loop. That way all phase variations in the transmit chain = would be caught, and the software oscillator could be steered to revert = to the original phase within a few seconds. With timestamping, we could = even prescribe absolute phase, allowing comparative measurements across = different sessions many days apart. Wolf what do you think? If it makes sense, I might try to implement = something based on the Sndinput / Sndoutpt combo.=20 Yes, certainly. If there was a drop-out of the audio output, we cannot = be sure if the latency between 'application' and the arrival of the = sample at the D/A-converter remains exactly the same. Observing the = phase of the *radiated signal* and steering the signal generated by = software to get the phase 'back where it belongs' would be better = because it would also compensate phase deviations caused by the antenna = itself. Have a nice evening, Wolf . Best 73, Markus ------=_NextPart_000_000D_01CF17D1.88E115D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Wolf, Uwe, Peter,
 
after a little experimentation, I think = I have=20 found a way to set up SpecLab to eliminate transmit = phase jumps caused=20 by dropouts in the soundcard output. As a proof of=20 concept, I generated=20 an 8269.998 Hz audio carrier last night. This happened=20 to leak from the audio wires to my VLF antenna, and = produced a=20 weak but well defined dash in the 42 uHz grabber=20 window.
 
We can use SpecLabs GPS tracking = to take care=20 of any irregularities in the sound input path to the ADC. When using the = 1-pps=20 reference with phaselock it can identify and correct short = dropouts.=20 Augmented by the built-in NMEA-based timestamping scheme, SpecLab = can in=20 principle even provide a defined absolute phase, = referenced to=20 the beginning of the UT day.
 
But the timing is always relative to = the reference=20 seen by the ADC input, and there is no way to directly sense latency = variations=20 in the buffering between the software and the DAC output. = Unfortunately on=20 many machines, buffer underflows or dropouts on the playback side = seem to=20 happen fairly often, especially when the PC is not left alone but is = used for=20 other jobs on the side.
 
The idea is to feed back a sample of = the analog=20 output to the input, using either an analog loopback (eg the audio = mixer, but=20 not a digital loop like VAC). Or set up a pickup probe to sense antenna = current=20 or voltage, which would also take care of phase shifts from = variable=20 antenna tuning. Then SpecLab can do a phase comparison to=20 a GPS-referenced internal generator, and steer = the frequency of=20 an independent output oscillator to bring the radiated = signal back to=20 the correct phase.
 
If you want to experiment with this = method, you can=20 download the configuration file
= http://dl.dropboxusercontent.com/u/26404526/VLF_TX_1pps_PLL.USR =
which generates a 8270 Hz stabilised = signal. To see=20 how it works, take a look at the = circuit diagram=20 in:
http://dl.dropboxusercontent.com/u/26404526/screenshot_VLF_TX_= 1pps_PLL.jpg
 
The output signal is generated by the = digimode=20 terminal block, which can be set up either for a continuous carrier, or = for QRSS=20 or Opera modulation if you want. It feeds the DAC and the power = amplifier=20 through L5. The output is brought back to the left input (L1) and = fed to=20 the "E" channel of a colour-DF spectrogram. The right channel (R1) = gets the=20 1pps signal from the GPS which is used for samplerate = lock.=20 Lacking an appropriate GPS unit, I'm not using NMEA timestamps here, but = you=20 could chose so if your unit provides serial data with proper=20 timing.
 
The steady reference frequency is = provided by=20 the test signal generator - this is where you enter your desired = output=20 frequency. It is fed to the second "H" channel of the spectrogram = through R5.=20 The colour (azimuth) of the trace gives an indication of the phase=20 difference between L1 and R5.
 
The phase lock is implemented as = a macro in=20 conditional actions: Every 200 ms, it checks whether there is a valid = probe=20 signal at L1, and is so, it shifts the digimode frequency = within=20 +-0.18 Hz according to the phase difference. Check this by turmning the=20 DAC off and on: The trace comes back on with an arbitrary = colour, but=20  it will always revert to green (180=B0) within about three=20 seconds. 
 
So to get started,
- set up the analog loop path and = the=20 1-pps, 
- load = VLF_TX_1pps_PLL.usr,
- change the test signal=20 generator frequency from Uwe's 8270.004 to yours,
- set the digimode teminal to send = unmodulated=20 test tone at TX frequency.
- enjoy!
 
Hope this may be useful.
 
Best 73,
Markus (DF6NM)
 

From: wolf_dl4yhf
Sent: Sunday, January 19, 2014 7:01 PM
To: Markus Vester
Cc: Paul ; Uwe Jannsen
Subject: Re: DJ8WX 8270.004 Hz - transmit phase=20 correction?

Hello Markus and all,

Am 19.01.2014 = 18:43,=20 schrieb Markus Vester:
30 dB ...not too bad, is = it?
 
Still wondering = about the=20 nature of those transmit glitches. Assuming perfect GPS=20 sync, all possible interruptions in the input data stream = could be=20 detected by the timestamp identification. But there is still = a=20 chance for undetected buffer underruns in the sound = output. Would=20 that affect the phase permanently? Or would the average fill = state of the=20 FIFO buffering eventually be pulled back to the original lag = (probably not)?.
 
I have been = pondering a scheme=20 where one audio channel is getting 1pps while the other is used=20 to sample the transmitter output, eg with a small pickup = loop. That=20 way all phase variations in the transmit chain would be caught, and=20 the software oscillator could be steered to revert to the = original phase=20 within a few seconds. With timestamping, we could even=20 prescribe absolute phase, allowing comparative = measurements across=20 different sessions many days apart.
 
Wolf what do you = think? If it=20 makes sense, I might try to implement something based on the = Sndinput / Sndoutpt combo. 
Yes, = certainly.=20 If there was a drop-out of the audio output, we cannot be sure if the = latency=20 between 'application' and the arrival of the sample at the D/A-converter = remains=20 exactly the same. Observing the phase of the *radiated signal* and = steering the=20 signal generated by software to get the phase 'back where it belongs' = would be=20 better because it would also compensate phase deviations caused by the = antenna=20 itself.

Have a nice evening,
  Wolf .

Best = 73,
Markus
 
------=_NextPart_000_000D_01CF17D1.88E115D0--