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 w8T9TkwT001084 for ; Sat, 29 Sep 2018 11:29:49 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1g6BVU-0005MJ-EI for rs_out_1@blacksheep.org; Sat, 29 Sep 2018 10:25:48 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1g6BVT-0005MA-Mx for rsgb_lf_group@blacksheep.org; Sat, 29 Sep 2018 10:25:47 +0100 Received: from omr-m007e.mx.aol.com ([204.29.186.9]) by relay1.thorcom.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91_59-0488984) (envelope-from ) id 1g6BVP-0005wu-HZ for rsgb_lf_group@blacksheep.org; Sat, 29 Sep 2018 10:25:46 +0100 Received: from mtaomg-mab01.mx.aol.com (mtaomg-mab01.mx.aol.com [172.26.249.83]) by omr-m007e.mx.aol.com (Outbound Mail Relay) with ESMTP id 5FDF83800087 for ; Sat, 29 Sep 2018 05:25:41 -0400 (EDT) Received: from core-acx10a.mail.aol.com (core-acx10.mail.aol.com [172.27.155.135]) by mtaomg-mab01.mx.aol.com (OMAG/Core Interface) with ESMTP id 1A9F338000081 for ; Sat, 29 Sep 2018 05:25:41 -0400 (EDT) Received: from 188.194.221.221 by webjasstg-vab55.srv.aolmail.net (10.96.25.122) with HTTP (WebMailUI); Sat, 29 Sep 2018 05:25:40 -0400 Date: Sat, 29 Sep 2018 05:25:41 -0400 From: Markus Vester To: rsgb_lf_group@blacksheep.org Message-Id: <16624a5d996-1ec8-1b47@webjasstg-vab55.srv.aolmail.net> In-Reply-To: MIME-Version: 1.0 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: JAS STD X-Originating-IP: [188.194.221.221] x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1538213141; bh=u+Zh61dpDitDRv3XDv7XXcjWLC7fdjl3PQOvDV99cDY=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=07PMPzhIl73wp1oEiPzJ89L/UAAUAr0MVJk4FOt+Qtn7TK58oka7+pIgcT1CD3Sk5 yI5a8tyAq4UfneLqIEBe2w8x0SM3n8HKRk1iok/NMztVi4bYT1KYObgQoKUeXNOlfi Y9U+S6OEXYbPI0kppxkZjQP/S0JWMuxUA69FX3zg= x-aol-sid: 3039ac1af9535baf45154710 X-Spam-Score: 0.0 (/) 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: Yes. As Andy says, if you are using a divider it should run continuously to preserve carrier phase. All modulation (either XOR for EbNaut-PSK, or on-off-gating for Opera) should be applied after the divider stage. [...] Content analysis details: (0.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 [204.29.186.9 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.0 T_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 X-Scan-Signature: edae4bc128aa121544439b7b7cfd26a1 Subject: Re: LF: Signal bandwidth in Op32 LF Content-Type: multipart/alternative; boundary="----=_Part_9614_696727802.1538213140886" 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 ------=_Part_9614_696727802.1538213140886 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. As Andy says, if you are using a divider it should run continuously to= preserve carrier phase. All modulation (either XOR for EbNaut-PSK, or on-o= ff-gating for Opera) should be applied after the divider stage. Best 73, Markus -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Andy Talbot An: LineOne Verschickt: Sa, 29. Sept 2018 10:44 Betreff: Re: LF: Signal bandwidth in Op32 LF If you stop and start a divider, the phase jumps about randomly. Each time= you start the divider, its output signal starts up in a differnet phase to= what it would have been if left running To achieve phase coherent, you must keep the divider running and gate the O= UTPUT separately This issue is a problem with beacons in general that employ FSK keying for = their CW ident. If they adopted on-off keying, then long term integration= cold take place though the keying cycle. But unfortunately, IARU (or what= ever organisation that tries to mandate these things), appear to require FS= K keying. SO most beacon keepers comply. (I don't, the Bell Hill microwa= ve beacons, GB3SCx all use on-off keying) Andy www.g4jnt.com On Sat, 29 Sep 2018 at 09:10, VIGILANT Luis Fern=C3=A1ndez wrote: Hi LF=20 I'm puzzled with the readings of bandwidth at the Op32 correlation detectio= n grabbers As source I'm using a GPS generated signal, which is coherent in phase and = works for EbNaut So I tested this at 20x frequency to drive an small D class PA and modulate= d in Opera32 The OOK was achieved by enabling/disabling a divider by 10 just after GPS Sourprisingly, my decodes at DF6NM and DL0AO varied in width, but always sh= owing width of a non coherent signal 2018-09-24 16:55:09 EA5DOM 1500km 137485.051Hz 71mHz -99.9dBOp 78% 17.6d= B 2018-09-24 15:35:10 EA5DOM 1500km 137485.026Hz 114mHz -99.9dBOp 100% 17.3d= B=20 2018-09-24 14:13:18 EA5DOM 1500km 137485.039Hz 164mHz -37.2dBOp 100% 20.7d= B 2018-09-27 19:08:06 EA5DOM 1536km 137485.013Hz 110mHz -38.3dBOp 94% 18.8d= B Last night I tried without PA. Using just a mosfet driver this time gettin= g about 1W output. The GPS generates the 10x frequency and the OOK is control= led by enabling/disabling the divider by 10. Got a couple of decodes at DF6NM 2018-09-29 02:17:39 EA5DOM 1500km 137485.007Hz 5mHz -46.4dBOp 85% 15.4d= B 2018-09-29 00:37:50 EA5DOM 1500km 137484.986Hz 112mHz -43.2dBOp 100% 19.6d= B So, 5 and 112mHz, for the same signal. I'm thinking that the problem is cau= sed by glitches when the signal goes off. A synchronous off would be needed to cut signal at zero crossing ? Reports to other stations, like SM2DJK, show just 2 to 3mHz Any ideas ? PS: Stefan. Your Op32 correlaton detector is not working actually 73 de Luis EA5DOM ------=_Part_9614_696727802.1538213140886 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. As Andy says, if you are using a divider it should = run continuously to preserve carrier phase. All modulation (either XOR for = EbNaut-PSK, or on-off-gating for Opera) should be applied after the divider= stage.

Best 73,
Markus


-----Urspr=C3=BCngliche Mitte= ilung-----
Von: Andy Talbot <andy.g4jnt@gmail.com>
An: LineOne= <rsgb_lf_group@blacksheep.org>
Verschickt: Sa, 29. Sept 2018 10:4= 4
Betreff: Re: LF: Signal bandwidth in Op32 LF

If you stop and start a divider, the phase jumps about randomly.  = Each time you start the divider, its output signal starts up in a differnet= phase to what it would have been if left running

To achieve phase cohere= nt, you must keep the divider running and gate the OUTPUT separately
<= div class=3D"aolmail_gmail_default" style=3D"font-family: arial,helvetica,s= ans-serif; font-size: small;">
This= issue is a problem with beacons in general that employ FSK keying for thei= r CW ident.   If they adopted on-off keying, then long term integ= ration cold take place though the keying cycle.  But unfortunately, IA= RU (or whatever organisation that tries to mandate these things), appear to= require FSK keying.  SO most beacon keepers comply.   (I do= n't, the Bell Hill microwave beacons, GB3SCx all use on-off keying)
Andy
www.g4jnt.com<= /span>



On Sat, 29 Sep 2018 at 09:10, VIGILANT Luis Fern=C3=A1ndez <= ;luis@vigilant.es> wrote:
Hi LF

I'm puzzled with the readings of bandwidth at the Op32 correlation det= ection grabbers

As source I'm using a GPS generated signal, which is coherent in phase= and works for EbNaut
So I tested this at 20x frequency to drive an small D class PA and mod= ulated in Opera32
The OOK was achieved by enabling/disabling a divider by 10 just after = GPS

Sourprisingly, my decodes at DF6NM and DL0AO varied in width, but alwa= ys showing width of a non coherent signal
2018-09-24 16:55:09 EA5DOM  1500km 13=
7485.051Hz  71mHz -99.9dBOp  78% 17.6dB
2018-09-24 15:35:10 EA5DOM  1500km 137485.026Hz 114mHz -99.9dBOp 100% 17.3d=
B 
2018-09-24 14:13:18 EA5DOM  1500km 13=
7485.039Hz 164mHz -37.2dBOp 100% 20.7dB
2018-09-27 19:08:06 EA5DOM  1536km 13=
7485.013Hz 110mHz -38.3dBOp  94% 18.8dB
Last night I tried without PA.  Using=
 just a mosfet driver this time getting
about 1W output. The GPS generates th=
e 10x frequency and the OOK is controlled
by enabling/disabling the divider by =
10. Got a couple of decodes at DF6NM
2018-09-29 02:17:39 EA5DOM  1500km 13=
7485.007Hz   5mHz -46.4dBOp  85% 15.4dB
2018-09-29 00:37:50 EA5DOM  1500km 137484.986Hz 112mHz -43.2dBOp 100% 19.6d=
B
So, 5 and 112mHz, for the same signal=
. I'm thinking that the problem is caused
by glitches when the signal goes off.=
 A synchronous off would be needed to
cut signal at zero crossing ?
Reports to other stations, like SM2DJ=
K, show just 2 to 3mHz

Any ideas ?

PS: Stefan. Your Op32 correlaton dete=
ctor is not working actually

73 de Luis
EA5DOM
 
------=_Part_9614_696727802.1538213140886--