References: <8CEDBB08CDC93E9-6B0-1108@webmail-m065.sysops.aol.com>
To: rsgb_lf_group@blacksheep.org
In-Reply-To: <8CEDBB08CDC93E9-6B0-1108@webmail-m065.sysops.aol.com>
MIME-Version: 1.0
From: Markus Vester <markusvester@aol.com>
Message-Id: <8CEDBC12AC7C316-1D00-24AA@webmail-d130.sysops.aol.com>
Date: Thu, 29 Mar 2012 08:47:00 -0400 (EDT)
X-AOL-SCOLL-URL_COUNT: 0  
X-Spam-Score: 0.3 (/)
X-Spam-Report: autolearn=disabled,FORGED_AOL_TAGS=0.281,HTML_MESSAGE=0.001,UNPARSEABLE_RELAY=0.001
Subject: VLF: DF6NM on 8970.002 - samplerate detector seems ok
Content-Type: multipart/alternative; 
 boundary="--------MB_8CEDBC12B69A162_1D00_7923_webmail-d130.sysops.aol.com"
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=FORGED_AOL_TAGS,
	HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE 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:463540448:93952408  
X-AOL-SCOLL-AUTHENTICATION: mail_rly_antispam_dkim-m011.2 ; domain : mx.aol.com DKIM : pass  
x-aol-sid: 3039ac1db4054f745a402cdc
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


This is a multi-part message in MIME format.
----------MB_8CEDBC12B69A162_1D00_7923_webmail-d130.sysops.aol.com
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"


Just a short update: I tried a quick local test of the SR detector between =
two instances of the latest SpecLab 277 b22. The SR detector engaged, and t=
he generator output followed within seconds. So it seems SpecLab is not the=
 culprit for my transient frequency errors, and it's likely I did something=
 wrong during the transmissions (yes I'm sure I had not ticked "measure onl=
y" box...).

Best 73,
Markus


-----Urspr=C3=BCngliche Mitteilung-----=20
Von: Markus Vester <markusvester@aol.com>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org>
Verschickt: Do, 29 Mrz 2012 12:49 pm
Betreff: Re: VLF: DF6NM on 8970.002 - again tonight


My transmission on 8970.002 went off air at 6:35 this morning, and the ante=
nna was taken down for the next couple of days because of windy wx.
=20
Unfortunately, the LF harmonic showed that again my frequency was not corre=
ct during the first 90 minutes until about 22:30, with a similar behaviour =
as yesterday, and also during an earlier MFSK transmission (see attached). =
Immediately after starting SpecLab, the samplerate detector correctly measu=
red the samplerate versus the DHO reference. The lock indicator turned gree=
n after the first three blocks, and plausible samplerates were displayed at=
 all times. However the corrections were apparently not applied, and the ca=
rrier from the signal generator still drifted with the soundcard crystal. A=
fter more than an hour, the carrier suddenly jumped up by about 2 ppm, and =
within the next 20 minutes settled to the final correctly locked frequency.=
 At first I thought it might be due to some glitch in my LF harmonic measur=
ement or even at DHO38. But it seems to be reproducible so there may actual=
ly be a subtle error in the samplerate tracking function. I was using SL 2.=
77 b08, and will try to look more deeply into this - a simple workaround ma=
y be to start and lock SL a couple of hours before operation.
=20
Thanks again for watching - it's fun to see the Dreamer's band so populated=
!
=20
73, Markus (DF6NM)



----------MB_8CEDBC12B69A162_1D00_7923_webmail-d130.sysops.aol.com
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<font color=3D'black' size=3D'2' face=3D'arial'>
<div>Just a short update:&nbsp;I tried a quick local test of the SR detecto=
r between two instances of the latest SpecLab 277 b22. The SR detector enga=
ged, and&nbsp;the generator output followed within seconds. So&nbsp;it seem=
s SpecLab is <STRONG>not</STRONG> the culprit&nbsp;for my&nbsp;transient fr=
equency errors, and it's likely I did something wrong during the&nbsp;trans=
missions&nbsp;(yes I'm sure I had <STRONG>not</STRONG> ticked "measure only=
"&nbsp;box...).</div>


<div>&nbsp;</div>


<div>Best 73,</div>


<div>Markus</div>


<div>&nbsp;</div>


<div>&nbsp;</div>


<div style=3D"FONT-FAMILY: arial,helvetica; COLOR: black; FONT-SIZE: 10pt">=
-----Urspr=C3=BCngliche Mitteilung----- <br>
Von: Markus Vester &lt;markusvester@aol.com&gt;<br>
An: rsgb_lf_group &lt;rsgb_lf_group@blacksheep.org&gt;<br>
Verschickt: Do, 29 Mrz 2012 12:49 pm<br>
Betreff: Re: VLF: DF6NM on 8970.002 - again tonight<br>
<br>


<div id=3DAOLMsgPart_2_a42041be-430c-49bc-b63e-7bfba05a5c09><FONT color=3Db=
lack size=3D2 face=3Darial>

<div>My transmission on 8970.002 went off air at 6:35 this morning, and the=
 antenna was taken down for the next couple of days because of windy wx.</d=
iv>


<div>&nbsp;</div>


<div>Unfortunately,&nbsp;the LF harmonic showed that again my frequency was=
 not&nbsp;correct during the first 90 minutes until about 22:30, with a sim=
ilar behaviour as yesterday, and also&nbsp;during an&nbsp;earlier MFSK tran=
smission (see attached).&nbsp;Immediately after starting&nbsp;SpecLab, the =
samplerate detector correctly measured the samplerate versus the DHO refere=
nce. The lock indicator turned green&nbsp;after the first three blocks, and=
 plausible samplerates were displayed at all times.&nbsp;However the correc=
tions were&nbsp;apparently not applied, and the&nbsp;carrier from the signa=
l generator still drifted with the soundcard crystal.&nbsp;After more than =
an hour, the&nbsp;carrier suddenly&nbsp;jumped up by about&nbsp;2 ppm, and =
within the next 20 minutes settled to the final&nbsp;correctly locked frequ=
ency. At first I thought it might be due to some glitch&nbsp;in my LF harmo=
nic measurement or even at DHO38. But it&nbsp;seems to be reproducible so t=
here may&nbsp;actually be a&nbsp;subtle error in the samplerate tracking fu=
nction. I was using SL 2.77 b08, and&nbsp;will&nbsp;try to look more deeply=
 into this - a simple workaround may be to start and lock SL a couple of ho=
urs before operation.</div>


<div>&nbsp;</div>


<div>Thanks again for watching - it's fun to see the Dreamer's band&nbsp;so=
 populated!</div>


<div>&nbsp;</div>


<div>73, Markus (DF6NM)<br>
</div>
</FONT></div>
</div>
</font>
----------MB_8CEDBC12B69A162_1D00_7923_webmail-d130.sysops.aol.com--