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 w8TAAtZe001401 for ; Sat, 29 Sep 2018 12:10:57 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1g6C97-0005c4-0U for rs_out_1@blacksheep.org; Sat, 29 Sep 2018 11:06:45 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1g6C96-0005bv-HT for rsgb_lf_group@blacksheep.org; Sat, 29 Sep 2018 11:06:44 +0100 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91_59-0488984) (envelope-from ) id 1g6C93-00065t-8h for rsgb_lf_group@blacksheep.org; Sat, 29 Sep 2018 11:06:43 +0100 Received: by mail-wm1-x335.google.com with SMTP id y3-v6so3450021wma.1 for ; Sat, 29 Sep 2018 03:06:41 -0700 (PDT) X-DKIM-Result: Domain=gmail.com Result=Good and Known Domain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:reply-to:message-id:to:subject:in-reply-to:references :mime-version:content-transfer-encoding; bh=wseOITccfzV4vWaiR1rqilksXTOWB/HQ9Bz7JOrCwek=; b=jEfBP5hA3f4/7JnG4VAkiQoNRgQMTCRsnnUJwvzK2bkaHovmDe+GdcEr/5VvHue4WS THKsdyXwJr8N/OXC2RSM4o6/Bpyle1y67hMFp6sUi1UctH5Zne9vRTS0wgRLNiEEGhWx u421YgNoCe1QYWrJHwYh4yCR6rllq/qNSnSB1xcfahfs01UrmVquteNuHoL3ibvd+5Bq CtyWppcMY0WVnrUBcw0bo/K+i0NvT9745aci33ieqK65XMC9Ll4UymqzaYTU/kxJ+oJx 7zs/akKaQJBZwLG9DvYdvyi1wsqTV4UnBZ5xcxcse6XY0qGS5ofjckpRkpCEvBRbFV5L plyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:reply-to:message-id:to:subject :in-reply-to:references:mime-version:content-transfer-encoding; bh=wseOITccfzV4vWaiR1rqilksXTOWB/HQ9Bz7JOrCwek=; b=QmxnVC7VMoDoaVlsigjKxrYsd/Qrzg+NXJ7UkEhXbY4m1JtibcD4cJdv/QErSHI9jN 57W1Hr7pqSm1A5rezPQZpdhITMbhj0d6FayG2UP02+7VLJ79t5v67lNJEnFnEFGQ8AkE tgp7x53zhrmctyGelxAFf8xrdkYUT5BzgFEBVSdp33yuwgvGRNaZBIL1mlwRB0Gjz9hy Ut8pb4/JUltv3Y3knLsynwRkHSEmfpVUJ64FuiCm/qU7xbkjy8ly7v45LeJnBMntGAqa XIOVzsV/vVqn4X5n5xIFdwLUTsQ02Z7u/7E92LBm4+uG0dhwkfAvvHXYpf9H5huFXQlX wTEQ== X-Gm-Message-State: ABuFfoiXmpcAPEQs/XpPJhUgKel8gMrUcwlJHK/VhLbU/dnchFYBd9rk pyo0XRPPJZkjnkWWmoO6gKF2Wt55 X-Google-Smtp-Source: ACcGV62HFhqW/PrCnXfUCzrIihpWFu5CGlvhHdm85/dzrBlDv/ag3vViKJ3lBeU1b2RDJxUGgTcEsg== X-Received: by 2002:a1c:9692:: with SMTP id y140-v6mr3983920wmd.82.1538215599983; Sat, 29 Sep 2018 03:06:39 -0700 (PDT) Received: from OfficeWin7.lan (82-70-254-222.dsl.in-addr.zen.co.uk. [82.70.254.222]) by smtp.gmail.com with ESMTPSA id 200-v6sm8733998wmv.6.2018.09.29.03.06.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 29 Sep 2018 03:06:39 -0700 (PDT) Date: Sat, 29 Sep 2018 11:06:37 +0100 From: Chris Wilson X-Priority: 3 (Normal) Message-ID: <1491423438.20180929110637@gmail.com> To: Andy Talbot In-Reply-To: References: <6DB8451D7F3D3947A5918808A59621EA08642503@servigilant.vigilant.local> MIME-Version: 1.0 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: Hello Andy, Could this in any way supply a reason for me seeing the odd dead FET when running OPERA and never when running WSPR? I always had the feeling that the fact OPERA stops and starts so many times in 32 mode that it was a cause of an occasional glitch that blew the FETS in my Class D amp... To be honest it's the main reason I rarely TX with OPERA on LF. The amp is permanently powered, the exciter, normally my U3S then stops and starts whatever mode is selected. With OPERA I think a FET will usually go at the START of one of the TX cycles, not at the end. [...] 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 [2a00:1450:4864:20:0:0:0:335 listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dead.fets[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Scan-Signature: 33d261536bb1467bb13d5764461d5ec4 Subject: Re: LF: Signal bandwidth in Op32 LF Content-Type: text/plain; charset=utf-8 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=PRIORITY_NO_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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by klubnl.pl id w8TAAtZe001401 Hello Andy, Could this in any way supply a reason for me seeing the odd dead FET when running OPERA and never when running WSPR? I always had the feeling that the fact OPERA stops and starts so many times in 32 mode that it was a cause of an occasional glitch that blew the FETS in my Class D amp... To be honest it's the main reason I rarely TX with OPERA on LF. The amp is permanently powered, the exciter, normally my U3S then stops and starts whatever mode is selected. With OPERA I think a FET will usually go at the START of one of the TX cycles, not at the end. Thanks. 2E0ILY Saturday, September 29, 2018, 9:42:10 AM, you wrote: > 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 OUTPUT 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 whatever organisation that tries to mandate > these things), appear to require FSK keying.  SO most beacon keepers > comply.   (I don't, the Bell Hill microwave beacons, GB3SCx all use on-off keying) > Andy > www.g4jnt.com -- Best regards, Chris mailto:dead.fets@gmail.com