Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

LF: Key Clicks and Noise Blanker

To: <[email protected]>
Subject: LF: Key Clicks and Noise Blanker
From: "Markus Vester" <[email protected]>
Date: Fri, 31 Aug 2012 09:16:02 +0200
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=
Importance: Normal
References: <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
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. 
 
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.  
 
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

 
Sent: Friday, August 31, 2012 1:47 AM
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
> conjunction with the noise blanker the RX is desensitized by the a
> nearby strong signal. The problem is exacerbated by high density of
> keyclicks in Opera (5 to 8x more than QRSS), and that most seem to
> apply hard keying. Trying to interleave operating times (eg. even vs
> odd days, or hours) is probably not a satisfactory solution.

Sorry for that Markus. You know, the AM modulator is very near to the
top of my Todo list and the first half of the circuit is working now
(BTW not using a PWM with a TL494 but a VCO using a CD4046. That works
well). So it sould be possible for me to reduce key click of signals
generated in SpecLab, i.e. QRSS/DFCW/HELL/Beacon-Cw, soon. If my clicks
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
signal generator (SL!). This is one of the main advantages of that
software and why Graham calls it CW replacement mode (of course CW
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
arbitrary waveform generator of SLs signal generator could play the code
in SL. Of course the software could be run simultaneously. Maybe even
the Opera TX-button can be virtually pressed by a DOS command so the
announcement of that transmission is is sent to the web? The mode and
band information must be sent too, to coordinate the software with the
actual TX then. That makes it more and more complex.
So what might be the solution for those who use an external signal
source and just key the PTT by the COM port using Opera software? Maybe
a special higher order shaping using hardware, like in a CW HF TRX?
Possible!

73, Stefan/DK7FC


<Prev in Thread] Current Thread [Next in Thread>