TenTec
[Top] [All Lists]

Re: [TenTec] [Orion] Orion II Noise Blankers

To: Discussion of Ten-Tec Equipment <tentec@contesting.com>
Subject: Re: [TenTec] [Orion] Orion II Noise Blankers
From: Lin Davis <linbdavis@earthlink.net>
Reply-to: Discussion of Ten-Tec Equipment <tentec@contesting.com>
Date: Sun, 26 Feb 2006 16:54:30 -0500
List-post: <mailto:tentec@contesting.com>
Well, I did a lot of playing with the NR today and am (stubbornly?) still not 
convinced that selective spectral filtering are part of the NR function, except 
for a broad, low pass filter with a variable but mild skirt slope. I elaborate 
more on this at the end.

Grant Youngman wrote:

>>is different NR code for the Orion I (pre-V2) and that is 
> 
> 
> I agree with you there.  Something is different.  But it isn't clear what.
> The "time constants" for adaption seemed to be different in the 2.x code.
> Maybe other stuff.
> 
> 
>>there just doesn't appear to be any lag at all when NR 1 (as 
>>opposed to NR 2 or 5, etc) is turned on, regardless of 
>>whether there is a weak or strong signal or no signal at all.
> 
> 
> Lower values seem a little slower than higher values.  Big diff between 1
> and 9.  But the lower values are much faster than in 1.371 and prior code.

Interesting, I tried under many different conditions to discern signal change 
after selecting each value. That is, I would set the value, turn the NR off and 
back on again to have it always start from the same condition and I listen very 
carefully if I can hear it adapt and I cannot. It appears to me to be either on 
or off, regardless of value.

> 
> 
>>Another thing the manual description claims is that once the 
>>NR has adapted, changing the NR value will have no effect. 
>>Again, this is contrary to what I've observed. If the NR is 
>>on 1, even for an extended time, then you increase the value, 
>>a difference IS heard; it does have an effect.
> 
> 
> If adaption time is made faster, you will hear something different on any
> signal that isn't just a constant carrier. Higher values WILL sound
> different since it as adapting and re-adapting to changing spectral
> components in the passband at a faster rate.
>  
I tested this using a constant carrier supplied by a crystal calibrator. Using 
a 
Rx BW of 1000 Hz, I tested at an S-9 level, and again at lower and lower 
amplitudes, until the point where I could barely hear it within the noise and 
still could not hear any adaption taking place. I would increase the NR value, 
figuring that if adaption was indeed taking place, it would be faster, then 
upon 
reducing the value, I should not hear a difference, since it has already 
adapted, but I DO still hear a difference. I can only conclude from this that 
there is no adaption component to the NR function, and therefore the NR value 
is 
not controlling an adaption rate, but something else, which sounds to me to be 
an amplitude threshold.

> 
>>Besides, there is no way to filter out random, white noise 
>>within a given passband, 
> 
> 
> Random white noise is the easiest thing to get rid of in the presence of a
> constant signal.  If you know the power spectra of the noise it can be done
> almost almost perfectly.  The trick is to notch out the parts of the
> spectrum which do not contain signal. Virtually all noise reduction
> techniques involve the elimination of junk from the areas in the bandpass
> that are not occupied by signal -- either a CW signal (many), or spectral
> components of a voice signal, etc.  So you eliminate some spectral regions
> -- effectively that is a filter around the regions you want to keep.
> 
> 

I think you misunderstood the point I was making, which was that with a given 
(fixed) bandwidth, there is no way to remove the noise without effecting the 
desired signal. You are talking about changing the bandwidth.
Given a constant signal having a given bandwidth, with random noise added to 
it, 
you cannot spectrally filter out the noise that falls within the bandwidth of 
the signal without also attenuating the signal. This is what I meant above.

The power density per hertz of white noise is uniform. So one could only 
tighten 
down the bandwidth until it started adversely affecting the desired signal. 
What are your options at this point? Spectrally, I believe there is none. This 
is a good time to now employ an expansion circuit :)


>>if the passband is made smaller, a 
>>user listening to a SSB signal would notice the bandwidth 
>>reduction in an instant, 
> 
> 
> Maybe I wasn't clear.  On CW, that's effectively what happens -- you get a
> narrow filter around the signal (or signals, if you have more than one in
> the passband)

I would expect that if the passband was being narrowed around a signal, then 
when I vary the signal intensity, the noise around it would not change. As I 
decrease the signal and approach the noise floor, I instead hear the noise 
level 
come up.

> 
> In the case of SSB, it's going to effectively build bandpass filters around
> the major spectral components of the SSB signal.  So you won't necessarily
> perceive the bandwidth getting narrow on SSB, although there's certainly
> some reduction in high frequency noise if you have the bandwidth set at a
> high value (since there may not be spectral components of the signal up
> there). 

I, too, noticed that the higher frequencies, above 1500 Hz, are reduce with the 
NR on, more so than frequencies below 1500Hz. It seems there is a fixed 
low-pass 
filter put in the signal path when NR is turned on, that has a gentle skirt 
slope beyond the cut off point of around 1200Hz. Also, the skirt slope 
steepness 
increases with increasing NR value. To be clear, it also attenuates signals 
above 1500 Hz, so it isn't attenuating just the noise around the signal.


Take care and 73,
Lin


> Grant/NQ5T
> 
> 
> _______________________________________________
> TenTec mailing list
> TenTec@contesting.com
> http://lists.contesting.com/mailman/listinfo/tentec
> 
> 

_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec

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