Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x5JCONjG003272 for ; Wed, 19 Jun 2019 14:24:24 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1hdZQh-0004mT-SU for rs_out_1@blacksheep.org; Wed, 19 Jun 2019 13:11:07 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1hdZQb-0004mK-Tq for rsgb_lf_group@blacksheep.org; Wed, 19 Jun 2019 13:11:01 +0100 Received: from mout01.posteo.de ([185.67.36.65]) by relay1.thorcom.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hdZQZ-00083M-Ml for rsgb_lf_group@blacksheep.org; Wed, 19 Jun 2019 13:11:00 +0100 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 112A216005E for ; Wed, 19 Jun 2019 14:10:57 +0200 (CEST) X-DKIM-Result: Domain=posteo.de Result=Signature OK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1560946257; bh=02vVZpZ7FmBSQpCQSnOaK4Oyoujj2peY90n5CvqCVHA=; h=Date:From:To:Subject:From; b=BAc4rLpOqa9PjkLdsrSJu7xihvecDWMiGFGrEWQdPe39GHs3Oe3Kn5Lyj3qpOTt33 ff1uGI36QsryVX83xRgv7WiwgY6wsIFNfQ/YrQFZIYlw+yKSJaVF7+OlswakB2G+am P2q6nJjRYHhff09y62CZGehMOT04C/2j9sFSwF0TuiDlpsiV/eXohaJ1UC/ST9Fjfv LwZNe3Q15bSf+9REIh3XYpWUAB0xeiylihqG2JNlsehhCiQ2Z/pHj4KEA7rAG5P0U8 3+JmILglXTqnRpnxjpTiHrEO8OTDY+pBkZhwauOfBB6/+B9R8k4em9AM1U8AgKporx pXfVyf6xmdYeA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 45TP1D34yJz6tm8 for ; Wed, 19 Jun 2019 14:10:56 +0200 (CEST) Message-ID: <5D0A2650.3050800@posteo.de> Date: Wed, 19 Jun 2019 14:10:56 +0200 From: DK7FC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <5D090874.4070805@posteo.de> <1661234464.2572111.1560890591920@mail.yahoo.com> In-Reply-To: <1661234464.2572111.1560890591920@mail.yahoo.com> X-Spam-Score: -2.5 (--) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi Markus, Thanks. Seems you are right. The problem seemed to occur when generating the spectrogram from a stream. But now i've extracted the same time period from the database and produced the spectrogram from [...] Content analysis details: (-2.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [185.67.36.65 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.0 DKIMWL_WL_MED DKIMwl.org - Whitelisted Medium sender X-Scan-Signature: f1284eec928b6c66f973fc41cf683e42 Subject: Re: SLF: Sidebands arround ZEVS in 1 mHz Content-Type: multipart/alternative; boundary="------------090107050804020600050406" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,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 This is a multi-part message in MIME format. --------------090107050804020600050406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Markus, Thanks. Seems you are right. The problem seemed to occur when generating the spectrogram from a stream. But now i've extracted the same time period from the database and produced the spectrogram from a (timestamped) .wav file. Fortunately it looks perfectly sharp! I'll investigate... I'm trying if a stage 'vttime -m none' stage will help... 73, Stefan Am 18.06.2019 22:43, schrieb Markus Vester: > Hi Stefan, > > it seems these sidelines are about 10 dB down at +- 6 mHz. If they > were real, we'd surely see them in 424 uHz at DL0AO, but there's > nothing there. > > What is strange ist that the main carrier is shown 2 mHz below the 82 > Hz tick, wheras in reality ZEVS is only 10 uHz below nominal. So I > suspect that the real input samplerate is around 24 ppm higher than > what SpecLab thinks it is. This may cause periodic buffer overflows, > where samples are lost and phasejumps occurs. The sideline spacing > indicates that this is happening every 1000/6 seconds (~ 3 minutes). > > 73, Markus > > -----Ursprüngliche Mitteilung----- > Von: DK7FC > An: rsgb_lf_group@blacksheep.org > Verschickt: Di, 18. Jun. 2019 17:53 > Betreff: SLF: Sidebands arround ZEVS in 1 mHz > > These days i'm calibrating the colours and angles in my ELF...VLF > spectrograms. The colour of ZEVS is now calibrated to deviate less than > 3 deg. However producing a spectrogram in 1 mHZ FFT bin width, i can see > sidebands of ZEVS. > Did someone else observe a similar effect? > In a first thought i would assume it is my timing system that causes the > problem. But maybe it is ZEVS itselfe? Or even propagation? > > 73, Stefan > > PS: Capture attached. > --------------090107050804020600050406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Markus,

Thanks. Seems you are right. The problem seemed to occur when generating the spectrogram from a stream. But now i've extracted the same time period from the database and produced the spectrogram from a (timestamped) .wav file. Fortunately it looks perfectly sharp!
I'll investigate... I'm trying if a stage  'vttime -m none'  stage will help...

73, Stefan


Am 18.06.2019 22:43, schrieb Markus Vester:
Hi Stefan,

it seems these sidelines are about 10 dB down at +- 6 mHz. If they were real, we'd surely see them in 424 uHz at DL0AO, but there's nothing there.

What is strange ist that the main carrier is shown 2 mHz below the 82 Hz tick, wheras in reality ZEVS is only 10 uHz below nominal. So I suspect that the real input samplerate is around 24 ppm higher than what SpecLab thinks it is. This may cause periodic buffer overflows, where samples are lost and phasejumps occurs. The sideline spacing indicates that this is happening every 1000/6 seconds (~ 3 minutes). 

73, Markus

-----Ursprüngliche Mitteilung-----
Von: DK7FC <selberdenken@posteo.de>
An: rsgb_lf_group@blacksheep.org <rsgb_lf_group@blacksheep.org>
Verschickt: Di, 18. Jun. 2019 17:53
Betreff: SLF: Sidebands arround ZEVS in 1 mHz

These days i'm calibrating the colours and angles in my ELF...VLF
spectrograms. The colour of ZEVS is now calibrated to deviate less than
3 deg. However producing a spectrogram in 1 mHZ FFT bin width, i can see
sidebands of ZEVS.
Did someone else observe a similar effect?
In a first thought i would assume it is my timing system that causes the
problem. But maybe it is ZEVS itselfe? Or even propagation?

73, Stefan

PS: Capture attached.

--------------090107050804020600050406--