For 2.0 (and maybe 1.5) add selective waterfall processing

Walt - KZ1F

For users, it would be valuable to either like the idea or ignore the idea. We can let FRS decide if and how to implement it should there be enough interest. Of course, if they are 'interested' in it, that's really all the motivation they would need.

Sending waterfall packets takes  spacetime. In the remote environment it would be nice if the user could select to not be sent waterfall packets at all. This would mean:
1) selectively less data being sent over a slower network
2) less time lag between seeing important data
3) less time partially processing data that isn't ever drawn (by virtue of pulling the spectrum display view over the waterfall view.

Rick Zach K1RJZ

Sounds good to me especially for WAN use but some may never use it. But what might be useful to 100% of the users 100% of the time would be static cursors that flag the band limits for your particular license class.

Ken - NM9P

Sounds like a great idea, if it doesn't foul up anything else...
Ken - NM9P

Walt - KZ1F

Rich, that is another idea which belongs under it's own thread.
My idea is about what the tile to this thread is. So nobody needs to hijaack it.
BTW, you idea does not take into account MARS and CAPS.

Stu Phillips - K6TU

Walt,

You can get essentially this today by setting the waterfall slider in the display tab to zero.   At 100 on the slider, my current waterfall gives a time span of about 14 seconds and the line update rate is fast.
Sliding the rate to 0 and I see one line update every 10 seconds or so...  at that rate, I think the pan adaptor history will be 10's of minutes long.

The data rate drops dramatically.

You can also slow down the number of frames per second on the pan adaptor and that has a similar reducing effect.

Last but not least, reduce the screen side of the SmartSDR window... the amount of date sent from the rate is dependent on the X and Y dimensions of the pan adaptor windows.

Stu K6TU

VE6KWA

Sounds like a very useful feature. I'm sure some of the software guys will chime in on the  do-ability.

Larry Loen WO7R

Great idea. I use only panadapter and never waterfall.

Walt - KZ1F

Ken, I am a software guy, it is highly doable.

VE6KWA

Well...there you go. You have my "LIKE"

Walt - KZ1F

Stu, to your comment. I want a button to press, much like remote such that I don't have to reconfigure anything if I am operating over a wifi or slow connection, i.e. don't send waterfall packets (period). When I release the button, start sending them. Short of that, in S(er)SDR I can put in the button and just throw away the packet when I realize what it is. That won't avoid the hundreds of thousands datagrams sent with information I don't want. It's a very straight forward implementation and saves the user having to **** around with their settings. However, thanks for that info Stu, I did not realize that.

Thank you Ken.

Larry Loen WO7R

I don't want to clutter the display.  One idea would be to do it by inference.  We can already set the display such that no waterfall is visible.  It would not be terribly hard to detect that we have done this.  If we have done this, then the client software will send a message to the radio (aka server) to stop waterfall transmission until further notice.  Meanwhile, the code that is already noticing there is nothing to display, will have a mild modification to tolerate no input which it might already do if that code is "defensive" enough.  The message could be resent at startup of the client just to be sure.

Stu Phillips - K6TU

With the current approach to persistence you are going to need more than that.

You need a client that allows you to select the connection mode or senses what the available capacity is BEFORE you initiate the connection to the radio or your link will get choked well before you can tell the radio what to (not) send.

This is 2.0 and WAN support as far as I can see and therefore of indeterminate timing.

I was simply trying to point out a solution for you that works now but requires some thought on how its used.

Button pushing doesn't require much thought that's for sure.
Stu K6TU

Walt - KZ1F

I don't have SSDR up right now as the radio is off. Isn't the Remote button on the top view? Being there it is not associated with a pan. Therefore it could be depressed before the pan is instantiated. It's an idea and, as I said at the outset, how FRS choses to implement it should they chose to at all, I will leave up to them. But that is a good suggestion. There is certainly a fair amount of tranffic before the pan gets instantiated. The time betwen a sendReplyRequest and the reply is likely vastly different over a slow link that a fast link . The keepalive request may serve that purpose, or...create another pure rtt request. Actually, now I think about it, that problem has already been solved, via the cell signal indicator. Jolly good show Stu! And thank you.

K2CM

That capability is already there. When I operate remotely with "marginal" internet, I drag the waterfall down so it doesn't show at all, the lower the display rate. Works quit well for me.