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.
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.
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.
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?
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.
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.
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 :^)
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.
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)
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.
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.