Delivered-To: daveyxm@virginmedia.com Received: by 10.50.237.98 with SMTP id vb2csp107141igc; Sat, 25 Jan 2014 01:31:52 -0800 (PST) X-Received: by 10.181.13.165 with SMTP id ez5mr5992703wid.56.1390642311349; Sat, 25 Jan 2014 01:31:51 -0800 (PST) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id ka5si2084888wjc.46.2014.01.25.01.31.50 for ; Sat, 25 Jan 2014 01:31:51 -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 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1W6yIr-0007x2-J1 for rs_out_1@blacksheep.org; Sat, 25 Jan 2014 08:09:21 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1W6yIq-0007wp-BS for rsgb_lf_group@blacksheep.org; Sat, 25 Jan 2014 08:09:20 +0000 Received: from cpsmtpb-ews02.kpnxchange.com ([213.75.39.5]) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1W6yIm-0003Y5-Gu for rsgb_lf_group@blacksheep.org; Sat, 25 Jan 2014 08:09:19 +0000 Received: from cpsps-ews14.kpnxchange.com ([10.94.84.181]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 25 Jan 2014 09:09:15 +0100 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews14.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 25 Jan 2014 09:09:15 +0100 Received: from Extensa ([195.241.183.120]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 25 Jan 2014 09:09:14 +0100 Message-ID: <7623FA80501C43E1BD814374B9FE2963@Extensa> From: "PA1SDB, Peter" To: References: <00a409bc5a7144c2b0888933be246758@kabelmail.de> In-Reply-To: <00a409bc5a7144c2b0888933be246758@kabelmail.de> Date: Sat, 25 Jan 2014 08:09:13 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18416 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18645 X-OriginalArrivalTime: 25 Jan 2014 08:09:14.0731 (UTC) FILETIME=[BCA53BB0:01CF19A4] X-RcptDomain: blacksheep.org X-Spam-Score: 1.0 (+) 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: Markus, Uwe, VLF. My 2 "old" ~800 MHz notebooks, with Windows XP installed, produce rainbow trace here to like Uwe was writing about (those 2 have generator setpoint 8270, but generate signal for example at 8269.45 :-( [...] Content analysis details: (1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [213.75.39.5 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: c85c54c8a69efb689a404830ea5bd8f0 Subject: Re: Re: Re: VLF: Transmit phase correction Content-Type: multipart/alternative; boundary="----=_NextPart_000_1A0F_01CF19A4.BC266EC0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_1A0F_01CF19A4.BC266EC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Markus, Uwe, VLF. My 2 "old" ~800 MHz notebooks, with Windows XP installed, produce rainbow trace here to like Uwe was writing about (those 2 have generator setpoint 8270, but generate signal for example at 8269.45 :-( >>Maybe one of those unfriendly cards (like the beast in my Z71m) where the sampling clock for the DAC is >> "slightly different" from the ADC's .. if so, try another one .. >> >>73, Wolf . 2 PC's to go here :-) Impression of my local results at a wire visible around 8269.45 in my grabber. Backyard DX :-) Peter, PA1SDB www.qsl.net/pa1sdb ----- Original Message ----- From: uwe-jannsen@kabelmail.de To: rsgb_lf_group@blacksheep.org Sent: Friday, January 24, 2014 12:14 PM Subject: Re: Re: Re: VLF: Transmit phase correction Yes, Markus, my TX has been ZOA with SpecLab set to phase correction. all grabbers show a vy clean line never seen before. Thanks for that .USR file. But….. I had problems finding a proper soundcard. At last a new sound blaster audigi made it. But not 100%. To get the 1PPS peaks ok, the record amplifier must be set to 100% and no NMEA signs to receive. with SpecLab settings not using the phase correction the soundcard recorder must be set to abt 2% to get the 1PPS peaks and NMEA ok. With other soundcards – like an vy old Sound Blaster, Musen and Generic - the 1PPS and the NMEA signs where ok when the record slider was set to 100%. But obviously no phase correction occurred. Rainbow colours in the trace. Ok, it is all fine now, the trace gleams in lime green, i.e. 180° locked. GL Uwe/dj8wx ------------------------------------------------------------------------------ Von: rsgb_lf_group@blacksheep.org Gesendet: 24.01.2014 10:30 An: rsgb_lf_group@blacksheep.org Betreff: Re: Re: VLF: Transmit phase correction ------------------------------------------------------------------------------ Hi Uwe, wonder if you've been testing the phase correction scheme on air last night? The PA1SDB grabber is now showing a nice narrow peak in 47µHz. I have also run an experiment with two local carriers: 8269.998 from anotherPC running SpecLab with phase correction, and 8270.000 from a decadic syntheziser to check my grabber's integrity. Sometime in the wee hours the amplitude of the SpecLab trace jumped up, presumably to increased leakage from a loose shield connection on the audio cable. But both traces seemed to be glitch-free over many hours. Best 73, Markus (DF6NM) ----- Original Message ----- From: uwe-jannsen@kabelmail.de To: rsgb_lf_group@blacksheep.org Sent: Thursday, January 23, 2014 4:07 PM Subject: Re: Re: VLF: Transmit phase correction since 1407utc I was playing around with the settings. that caused mni "glitches". so I switch the PA off now at 1500utc to make some "dry practices". until later Uwe ------------------------------------------------------------------------------ Von: rsgb_lf_group@blacksheep.org Gesendet: 23.01.2014 13:57 An: rsgb_lf_group@blacksheep.org Betreff: Re: VLF: Transmit phase correction ------------------------------------------------------------------------------ Hi Markus, now since 1238utc ZOA in 1pps_PLL.usr mode on 8270.004Hz we will see GL Uwe ------------------------------------------------------------------------------ Von: rsgb_lf_group@blacksheep.org Gesendet: 23.01.2014 00:24 An: rsgb_lf_group@blacksheep.org Kopie: Paul@abelian.netcom.co.uk Betreff: VLF: Transmit phase correction ------------------------------------------------------------------------------ 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. 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 http://dl.dropboxusercontent.com/u/26404526/VLF_TX_1pps_PLL.USR 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.jpg 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 choose 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 if 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°) within about three seconds. So to get started, - set up the analog loop path and the 1-pps, - load VLF_TX_1pps_PLL.usr, - change the test signal generator frequency from Uwe's 8270.004 to yours, - 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 Sent: Sunday, January 19, 2014 7:01 PM To: Markus Vester Cc: Paul ; Uwe Jannsen 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. 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_1A0F_01CF19A4.BC266EC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Markus, Uwe, VLF.
 
My 2 "old" ~800 MHz notebooks, with Windows XP = installed, produce rainbow trace here to like Uwe was writing = about
(those 2 have generator setpoint 8270, = but generate=20 signal for example at 8269.45 :-(
 
>>Maybe = one of those=20 unfriendly cards (like the beast in my Z71m) where the sampling clock = for the=20 DAC is
>> "slightly=20 different" from the ADC's .. if so, try another one = ..
>>
>>73, Wolf .

 
2 PC's to go here = :-)
 
Impression of my local results at a=20 wire visible around 8269.45 in my grabber.
Backyard DX :-)
 
Peter, PA1SDB
 
www.qsl.net/pa1sdb
 
 
----- Original Message -----
From:=20 uwe-jannsen@kabelmail.de =
Sent: Friday, January 24, 2014 = 12:14=20 PM
Subject: Re: Re: Re: VLF: = Transmit phase=20 correction

Yes, Markus, my TX  has been ZOA with SpecLab set to = phase=20 correction.
all grabbers show a vy clean line never = seen=20 before. Thanks for that .USR file.

But=85..

I had problems finding a proper soundcard. At last a new = sound=20 blaster audigi made it. But not 100%.
To get the 1PPS peaks ok, = the record=20 amplifier must be set to 100% and no NMEA signs to receive. =

with  SpecLab settings not using the phase correction = the=20 soundcard recorder must be set to abt 2% to get the 1PPS peaks and = NMEA=20 ok.

With other soundcards =96 like an vy old Sound Blaster, Musen = and=20 Generic  - the 1PPS and the NMEA signs where ok when the record = slider=20 was set to 100%. But obviously no phase correction occurred. Rainbow = colours=20 in the trace.

Ok, it is all fine now, the trace gleams in lime green, i.e. = 180=B0=20 locked.

GL

Uwe/dj8wx

 


Von: rsgb_lf_group@blacksheep.org
Gesendet: 24.01.2014 10:30
An: = rsgb_lf_group@blacksheep.org
Betreff: Re: Re: VLF: Transmit phase=20 correction

Hi = Uwe,
 
wonder if = you've been=20 testing the phase correction scheme on air last night? The PA1SDB = grabber is=20 now showing a nice narrow peak in 47=B5Hz.
 
I have also = run an=20 experiment with two local carriers: 8269.998 from anotherPC = running=20 SpecLab with phase correction, and 8270.000 from a decadic = syntheziser to=20 check my grabber's integrity. Sometime in the wee = hours the=20 amplitude of the SpecLab trace jumped up, presumably to increased = leakage=20 from a loose shield connection on the audio cable. But both = traces=20 seemed to be glitch-free over many hours.
 
Best 73, =
Markus=20 (DF6NM)
 
----- Original Message -----=20
From: uwe-jannsen@kabelmail.de =
Sent: Thursday, January 23, 2014 4:07 PM
Subject: Re: Re: VLF: Transmit phase=20 correction

since=20 1407utc I was playing around with the settings. that caused mni=20 "glitches".
so I switch the PA off now at 1500utc to make some "dry = practices".
until later
Uwe
Von: rsgb_lf_group@blacksheep.org=
Gesendet:=20 23.01.2014 13:57
An: rsgb_lf_group@blacksheep.org=
Betreff:=20 Re: VLF: Transmit phase correction

Hi=20 Markus,
now since 1238utc ZOA in 1pps_PLL.usr mode on = 8270.004Hz
we will=20 see
GL
Uwe
Von: rsgb_lf_group@blacksheep.org
Gesendet: 23.01.2014 00:24
An: = rsgb_lf_group@blacksheep.org
Kopie: = Paul@abelian.netcom.co.uk
Betreff:=20 VLF: Transmit phase correction

Hi Wolf, Uwe, = Peter,
 
after a = little=20 experimentation, I think I have found a way to set up SpecLab=20 to eliminate transmit phase jumps caused by dropouts in the=20 soundcard output. As a proof of = concept, I generated an 8269.998 Hz=20 audio carrier last night. This happened = to leak from the=20 audio wires to my VLF antenna, and produced a weak but well = defined dash=20 in the 42 uHz grabber window.
 
We can use = SpecLabs=20 GPS tracking to take care of any irregularities in the sound = input path=20 to the ADC. When using the 1-pps reference with phaselock it can = identify=20 and correct short dropouts. Augmented by the built-in NMEA-based = timestamping=20 scheme, SpecLab can in principle even provide a=20 defined absolute phase, referenced to the beginning of the UT = day.=20
 
But the = timing is=20 always relative to the reference seen by the ADC input, and there is = no way to=20 directly sense latency variations in the buffering between the=20 software and the DAC output. Unfortunately on many = machines, buffer=20 underflows or dropouts on the playback side seem to happen fairly = often,=20 especially when the PC is not left alone but is used for other jobs on = the=20 side.
 
The idea is = to feed=20 back a sample of the analog output to the input, using either an = analog=20 loopback (eg the audio mixer, but not a digital loop like VAC). Or set = up a=20 pickup probe to sense antenna current or voltage, which would also = take care=20 of phase shifts from variable antenna tuning. Then SpecLab can do = a phase=20 comparison to a GPS-referenced internal generator, and steer = the frequency of an independent output oscillator to bring = the=20 radiated signal back to the correct phase.
 
If you want = to=20 experiment with this method, you can download the configuration = file=20
= http://dl.dropboxusercontent.com/u/26404526/VLF_TX_1pps_PLL.USR =
which = generates a 8270=20 Hz stabilised signal. To see 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=20 generated by the digimode terminal block, which can be set up either = for a=20 continuous carrier, or for QRSS or Opera modulation if you want. It = feeds the=20 DAC and the power amplifier through L5. The output is brought back to = the left=20 input (L1) and fed to the "E" channel of a colour-DF = spectrogram.=20 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=20 using NMEA timestamps here, but you could choose so if your unit = provides=20 serial data with proper timing.
 
The steady=20 reference frequency is provided by the test signal generator = - this is=20 where you enter your desired output frequency. It is fed to the second = "H"=20 channel of the spectrogram through R5. The colour (azimuth) of the=20 trace gives an indication of the phase difference between L1 and=20 R5.
 
The phase = lock is=20 implemented as a macro in conditional actions: Every 200 ms, it = checks=20 whether there is a valid probe signal at L1, and if so,=20 it shifts the digimode frequency within +-0.18 Hz according = to the=20 phase difference. Check this by turmning the DAC off and = on: The=20 trace comes back on with an arbitrary colour, but it will always = revert=20 to green (180=B0) within about three seconds. 
 
So to get=20 started,
- set up = the=20 analog loop path and the 1-pps, 
- load=20 VLF_TX_1pps_PLL.usr,
- change = the test=20 signal generator frequency from Uwe's 8270.004 to yours, =
- set = the digimode=20 teminal to send unmodulated test tone at TX frequency,
- = enjoy!
 
Hope this may = be=20 useful.
 
Best = 73,
Markus=20 (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,=20 is it?
 
Still=20 wondering about the 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=20 the FIFO buffering eventually be pulled back to the = original lag=20 (probably not)?.
 
I have been=20 pondering a scheme where one audio channel is getting 1pps while the = other=20 is used to sample the transmitter output, eg with a small = pickup=20 loop. That way all phase variations in the transmit chain would be = caught,=20 and the software oscillator could be steered to revert to the = original=20 phase 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=20 you think? If it makes sense, I might try to=20 implement something based on the Sndinput /=20 Sndoutpt combo. 
Yes, certainly. = If there=20 was a drop-out of the audio output, we cannot be sure if the latency = between=20 '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=20 the signal generated by software to get the phase 'back where it = belongs'=20 would be better because it would also compensate phase deviations = caused by=20 the antenna itself.

Have a nice evening,
  Wolf = .

Best=20 73,
Markus
 
------=_NextPart_000_1A0F_01CF19A4.BC266EC0--