Post Noise Blanker Display and Averaging in SSDR

Tim K8XS

Right now, the the spectrum display does not reflect any benefit derived from the noise blanker. I vaguely remember talk about showing the display post noise blanker as is done in PSDR. What are the plans for that? Also, averaging may be one of those small additions that Steve mentioned; but, where does it fall in the timeline? Thanks

Ken - NM9P

A hearty "Amen," to both suggestions! I would assume that adjustable "averaging" will come with the waterfall/pan-fall. (I hope, I hope). Post NB display is what makes the display actually useful. At this time, my powerline noise has gone away, but a couple weeks ago I had S-9 to +10 hash that the would have made any display useless on my 1500 unless it was post-NB.

Michael - N5TGL

Add another vote to display averaging! Really looking forward to having a display that doesn't look like continuous horizontal lightning.

Ned K1NJ

Some of these small additions have a huge impact on product usability and enjoyment. Improved noise blanker effects and display averaging are just such things. Seemingly trivial to designers focused on large project goals, to the end user they look like basic, important, features that have somehow fallen through the cracks.

N4AB

I could not agree more with these comments. The big picture at the end really looks great but some of the road bumps really do need to be taken care of now. Al N4AB

Steve-N5AC

Noise blanker has initially been implemented in the slice receiver signal chain. Longer term we would like to implement the noise blanker much further up the signal chain as you suggest so that it impacts both the display and the slice audio at the same time. How would you feel about a noise blanker originating at the panadapter level -- in other words we would remove the control from the slice receiver and it would be on the panadapter and any slices on that panadapter would be controlled by a control on the panadapter itself? Independently, we'll do some more display averaging options. Steve

Bill - K7UOP

With NB on the Slice I get the impression it is not as effected by strong adjacent signals as normal noise blankers. Is this true? If the NB is further up the chain would that open the pumping problem from those strong signals? I agree, that the NB should be applied to the panadapter display so you can see the low level signals. But the downside is that waterfall displays show wideband hash from those strong adjacent signals. Is there a way to have the best of all worlds?

Michael - N5TGL

(upon further thought, removed the comment on the pandapter NB) If the NB at the slice level prevents problems from adjacent strong stations, I am All For That. No other radio I know of can do that. The bigger problem at the moment, IMHO is that the NB takes so long to start working again (30 seconds or so) after you stop transmitting. It's no fun to hear a weak signal, make your call and get a big BLAZZZZZZZZZZZZZZ when you unkey. Usually right about the time it takes hold, the distant station has just turned it back over to you and you've missed the whole thing. Steve, *please* do look at display averaging. I find it much, much, much more pleasant with an averaged panadapter display, and others have said the same.

Tim K8XS

Initially, I thought having the NB at the panadapter level would be a problem because a panadapter can be up to 13 MHz wide. I could have several slices within that range. Some might have noise and some may not. However, if that was a problem, I could always create a new panadapter and enable/disable NB as needed. So, I have no problem with that. HOWEVER, as others have said, having it pump because of other strong signals or create massive distortion because of other signals should be the driving factor. Whichever implementation could avoid or minimize the bad side effects should be chosen. Also, if having the NB after the Tracking Notch Filters would help eliminate the bad side effects, then I vote for that too.

Greg

Any noise blanker is going to degrade IMD to a point. Right now when nearby electric fences are on my radio is all but useless for seeing signals. The NB in the 5K did a pretty fair job at taming the display and the rx signal. 73 Greg AB7R

Ken - NM9P

Interesting option. The main thing is "does it work?" A panadapter level might work because it is wide enough to average the noise and signals for smoother reduction> (Do I even know what I am talking about?) I remember a few decades ago a company (Collins or Drake) had a noise blanker that was a separate wideband receiver on another frequency band that caught the noise impulses and used them to blank the noise on the frequency of interest. Perhaps something like this could be done by sampling/averaging the noise pulses in the panadapter and applying them on the slice/slices in that panadapter? (Or is this what you are already doing?)

WA6FXT Mike

What worries me is that the title for this thread "... Averaging in SSDR" The DSP should be done with the HW or DSP processor inside the radio. Let's keep SSDR a Small PIPE. Things done in the Client will have to be ported to any new OS. Keep SSDR lean and mean, and keep the DSP in the Radio Server. Just my $0.02; which, is over priced :^)

Tim K8XS

Mike, When I use the term SSDR, I am referring to the processes inside the radio. I don't know that the app that runs on the PC has a name other than "The thin client". I certainly intended for all the signal processing to be done inside the radio. If I am confused, please straighten me out. 73, Tim

WA6FXT Mike

Tim, You might be absolutely correct, that SSDR means both; however, just in case SSDR *IS* the client, I want my thoughts to be understood. :^) You see, I think it's called SmartSDR because the client DOESN'T do it (hihi) and leaves that to the New Kid (The 6x00 Radio Server - hihi)

K4EAR

If the NB is queued on the slice with less detritus from looking over a wider SCU bandwidth in it's function, I'll vote for that!!!

Greg

Not me. It makes the entire panadater completely useless when dealing with pulse type noise like electric fences.

K4EAR

Let's have a switch for on or off...panadapter wide or slice, then lower the AGC-T, and it might be easier for the NB,NR to work and converge.

Stan VA7NF

Lets bump this forward two years.

Now with the API group activity around panadapter and waterfall data, might it be possible to select/request up to three different sets of data for display?  1) Pre-processing  2) Noise and unwanted synchronous signal suppression and, thinking ahead, 3) Full diversity (that other science project) results, perhaps with two different arrays or different colours on 1 array for the source antenna

Steve, please refresh your comments of two years back.

Steve-N5AC

As we've mentioned in several places, we are in the process of working on a new noise blanker.  The new noise blanker is still in work and I can't yet say when it will be ready.  But, we have been doing internal demos that show it removing noise from both the panadapter and the slice receivers.  We are lucky (unlucky) enough to have a pole-pig near us that is continually arcing.  In the demos I've seen, the spectrum display almost completely cleans up and there is a reduction in noise of 6-15dB and there are only the faintest remnants of the noise present.  The one noise blanker does this for all slices on all bands.  I've watched the demo shown to several people internally and it's fun to watch jaws literally drop.

The way the noise blanker is currently designed, there will be no panadapter/waterfall data with noise available once it is turned on -- it's just going to remove the noise from the panadapters/waterfalls and slices involved.

We're still talking about a more advanced diversity algorithm and some things related to this, but they are not being worked on at the moment.