Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mb02.r1000.mx.aol.com (Internet Inbound) with ESMTP id 775913800009F; Fri, 31 Aug 2012 03:18:21 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1T7LSv-0001za-10 for rs_out_1@blacksheep.org; Fri, 31 Aug 2012 08:16:29 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1T7LSt-0001zR-Se for rsgb_lf_group@blacksheep.org; Fri, 31 Aug 2012 08:16:27 +0100 Received: from imr-da03.mx.aol.com ([205.188.105.145]) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1T7LSr-0001JU-6i for rsgb_lf_group@blacksheep.org; Fri, 31 Aug 2012 08:16:26 +0100 Received: from mtaout-ma06.r1000.mx.aol.com (mtaout-ma06.r1000.mx.aol.com [172.29.41.6]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q7V7GFcK022226 for ; Fri, 31 Aug 2012 03:16:15 -0400 Received: from White (nrbg-4dbe7cce.pool.mediaWays.net [77.190.124.206]) by mtaout-ma06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id AA9D6E0000F5 for ; Fri, 31 Aug 2012 03:16:12 -0400 (EDT) Message-ID: From: "Markus Vester" To: References: <503EA718.2010301@charter.net> <8CF54D89088EA63-22E8-50D77@webmail-d136.sysops.aol.com> <503FFBAB.7090609@iup.uni-heidelberg.de> Date: Fri, 31 Aug 2012 09:16:02 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1346397375; bh=5KoDgzNGjnotg0rwSTmgSEWmfEt3KiqIV4gcd9lrhO0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Q/Y5R/bq5+0zQzslkyKxWUfMqhkLggFcT+ugMo4FGfvyvB9LL3Lght2nF3zjzbjx/ 5wHki4Au1CS2Pso8gfDNaO/LKUg77rHl14p6ZP1pIFivKL5Y52Q1NqZjLkaqe/xWJD VFH2eFYGLWZB7fcN2QgcPJykQhYG38Q4LqF0LB/A= X-AOL-SCOLL-SCORE: 0:2:478073152:93952408 X-AOL-SCOLL-URL_COUNT: 0 X-Spam-Score: -0.2 (/) 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: Hi Stefan, > If my clicks would be reduced, would then the NB performance come back to 100%? No. These are two separate effects. The keyclicks are actually a part of the transmitted spectrum, wheras the NB artifacts originate in the receive processing. What they have in common is that they create a "near-far" problem by limiting the dynamic range, even if the receiver and soundcard are otherwise perfectly linear. The point I was trying to make is that we should try to separate operating frequenencies of simultaneous local and DX operations by at least one kHz. [...] Content analysis details: (-0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [205.188.105.145 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.2 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: 7574eaf38ab90cf371fa9661dd9329b0 Subject: LF: Key Clicks and Noise Blanker Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CD8759.3DB825D0" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,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 x-aol-global-disposition: G X-AOL-SCOLL-AUTHENTICATION: mtain-mb02.r1000.mx.aol.com ; domain : mx.aol.com DKIM : fail x-aol-sid: 3039ac1d60165040653c649b X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_000F_01CD8759.3DB825D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Stefan, > If my clicks would be reduced, would then the NB performance come back = to 100%? No. These are two separate effects. The keyclicks are actually a part of = the transmitted spectrum, wheras the NB artifacts originate in the = receive processing. What they have in common is that they create a = "near-far" problem by limiting the dynamic range, even if the receiver = and soundcard are otherwise perfectly linear. The point I was trying to = make is that we should try to separate operating frequenencies of = simultaneous local and DX operations by at least one kHz.=20 Now in summer the noise blanker effects (spectral widening of = intrinsically pure carriers due to the chopping, and increase of noise = blanker threshold) are the bigger problem. They could be mitigated by = inserting a software bandpass which excludes the local signal. But if = the frequency of that signal is too close to the desired signal, the = bandpass has to be narrow and steep. This unavoidably prolongs the = spheric impulses and renders the NB less efficient. Even at times = without lightning QRN, the NB is needed here to suppress the nasty FSK = telegram sidebands from our big brother DCF-39. This also doesn't work = well when the pulses are prolonged. =20 To minimize the bandwidth of the transmitted keyclicks, the rampup and = rampdown times should be a significant part (eg. 25%) of the symbol = duration. Eg for Op-32 (8 second dashes) you could make it as long as 2 = seconds, which will contain most of the power within 0.5 Hz. Using a = low-pass filtered com-port signal to modulate a continuous carrier is = certainly a good solution. The filter hardware could be just a couple of = RC networks, preferably with switchable time constants for different = speeds. Software ramps are also a good option, but as Wolf says you will need an = (at least somewhat) linear transmitter. Using SpecLab's signal generator = with an arbitrary waveform modulation produces nice band-limited output. = With the inbuilt samplerate correction you can even produce a = GPS-derived audio carrier. You will have to prepare an ASCII wave file = by editing the Opera 01 sequence for your callsign. As an alternative = standalone option, I have been using Wolf's little SndOutpt tool, which = can upsample an Opera IQ waveform with excellent interpolation. Best 73, Markus =20 From: Stefan Sch=C3=A4fer=20 Sent: Friday, August 31, 2012 1:47 AM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: Opera frequency usage Am 30.08.2012 17:09, schrieb Markus Vester: > [...] > - DK7FC was active on a nearby frequency during most of the night. In=20 > conjunction with the noise blanker the RX is desensitized by the a=20 > nearby strong signal. The problem is exacerbated by high density of=20 > keyclicks in Opera (5 to 8x more than QRSS), and that most seem to=20 > apply hard keying. Trying to interleave operating times (eg. even vs=20 > odd days, or hours) is probably not a satisfactory solution. Sorry for that Markus. You know, the AM modulator is very near to the=20 top of my Todo list and the first half of the circuit is working now=20 (BTW not using a PWM with a TL494 but a VCO using a CD4046. That works=20 well). So it sould be possible for me to reduce key click of signals=20 generated in SpecLab, i.e. QRSS/DFCW/HELL/Beacon-Cw, soon. If my clicks=20 would be reduced, would then the NB performance come back to 100%? However Opera directly keys the PA using the COM port and an external=20 signal generator (SL!). This is one of the main advantages of that=20 software and why Graham calls it CW replacement mode (of course CW=20 cannot be replaced, it is a language for its own). Recently we discussed about transmitting the OP code by playing an image = in slow hell. Or alternatively a file which can be loaded ito the=20 arbitrary waveform generator of SLs signal generator could play the code = in SL. Of course the software could be run simultaneously. Maybe even=20 the Opera TX-button can be virtually pressed by a DOS command so the=20 announcement of that transmission is is sent to the web? The mode and=20 band information must be sent too, to coordinate the software with the=20 actual TX then. That makes it more and more complex. So what might be the solution for those who use an external signal=20 source and just key the PTT by the COM port using Opera software? Maybe=20 a special higher order shaping using hardware, like in a CW HF TRX?=20 Possible! 73, Stefan/DK7FC ------=_NextPart_000_000F_01CD8759.3DB825D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Stefan,
 
> If my clicks would be reduced, = would then the=20 NB performance come back to 100%?
No. These are two separate = effects. The=20 keyclicks are actually a part of the transmitted spectrum, wheras = the NB=20 artifacts originate in the receive processing. What they have in common = is that=20 they create a "near-far" problem by limiting the dynamic range, = even if the=20 receiver and soundcard are otherwise perfectly linear. The point I = was=20 trying to make is that we should try to separate operating frequenencies = of simultaneous local and DX operations by at=20 least one kHz. 
 
Now in summer the noise=20 blanker effects (spectral widening=20 of intrinsically pure carriers due to the chopping, and = increase=20 of noise blanker threshold) are the bigger problem. They could = be=20 mitigated by inserting a software bandpass which excludes=20 the local signal. But if the frequency of that=20 signal is too close to the desired signal, the bandpass has to = be=20 narrow and steep. This unavoidably prolongs the spheric = impulses and=20 renders the NB less efficient. Even at times without lightning QRN, = the NB=20 is needed here to suppress the nasty FSK telegram sidebands from = our big=20 brother DCF-39. This also doesn't work well when the pulses are=20 prolonged.  
 
To minimize the bandwidth of the transmitted=20 keyclicks, the rampup and rampdown times should be a = significant part=20 (eg. 25%) of the symbol duration. Eg for Op-32 (8 second = dashes) you=20 could make it as long as 2 seconds, which will contain most of=20 the power within 0.5 Hz. Using a low-pass filtered = com-port=20 signal to modulate a continuous carrier is certainly a good=20 solution. The filter hardware could be just a couple of=20 RC networks, preferably with switchable time = constants for=20 different speeds.
 
Software ramps are also a good option, but as = Wolf=20 says you will need an (at least somewhat) linear transmitter. = Using=20 SpecLab's signal generator with an arbitrary waveform modulation = produces=20 nice band-limited output. With the inbuilt samplerate = correction you=20 can even produce a GPS-derived audio carrier. You will have to = prepare an=20 ASCII wave file by editing the Opera 01 sequence for your callsign. As = an=20 alternative standalone option, I have been using Wolf's little = SndOutpt=20 tool, which can upsample an Opera IQ waveform with excellent=20 interpolation.
 
Best 73,
Markus

 
From: = Stefan Sch=C3=A4fer =
Sent: Friday, August 31, 2012 1:47 = AM
To: rsgb_lf_group@blacksheep.org=20
Subject: Re: LF: Opera frequency=20 usage

Am=20 30.08.2012 17:09, schrieb Markus Vester:
> [...]
> - DK7FC = was=20 active on a nearby frequency during most of the night. In
> = conjunction=20 with the noise blanker the RX is desensitized by the a
> nearby = strong=20 signal. The problem is exacerbated by high density of
> keyclicks = in=20 Opera (5 to 8x more than QRSS), and that most seem to
> apply = hard=20 keying. Trying to interleave operating times (eg. even vs
> odd = days, or=20 hours) is probably not a satisfactory solution.

Sorry for that Markus. You know, = the AM=20 modulator is very near to the
top of my Todo list and the first half = of the=20 circuit is working now
(BTW not using a PWM with a TL494 but a VCO = using a=20 CD4046. That works
well). So it sould be possible for me to reduce = key click=20 of signals
generated in SpecLab, i.e. QRSS/DFCW/HELL/Beacon-Cw, = soon. If my=20 clicks
would be reduced, would then the NB performance come back to=20 100%?

However Opera directly keys the PA using the COM port and = an=20 external
signal generator (SL!). This is one of the main advantages = of that=20
software and why Graham calls it CW replacement mode (of course CW=20
cannot be replaced, it is a language for its own).

Recently = we=20 discussed about transmitting the OP code by playing an image
in slow = hell.=20 Or alternatively a file which can be loaded ito the
arbitrary = waveform=20 generator of SLs signal generator could play the code
in SL. Of = course the=20 software could be run simultaneously. Maybe even
the Opera TX-button = can be=20 virtually pressed by a DOS command so the
announcement of that = transmission=20 is is sent to the web? The mode and
band information must be sent = too, to=20 coordinate the software with the
actual TX then. That makes it more = and more=20 complex.
So what might be the solution for those who use an external = signal=20
source and just key the PTT by the COM port using Opera software? = Maybe=20
a special higher order shaping using hardware, like in a CW HF TRX?=20
Possible!

73, = Stefan/DK7FC


------=_NextPart_000_000F_01CD8759.3DB825D0--