For 2.0 (and maybe 1.5) add selective waterfall processing

  • 10
  • Idea
  • Updated 4 years ago
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.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes

Posted 4 years ago

  • 10
Photo of Rick Zach

Rick Zach

  • 19 Posts
  • 5 Reply Likes
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.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
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.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 222 Posts
  • 33 Reply Likes
Great idea. I use only panadapter and never waterfall.
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4175 Posts
  • 1331 Reply Likes
Sounds like a great idea, if it doesn't foul up anything else...
Ken - NM9P
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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
Photo of Ken ve7kwa

Ken ve7kwa

  • 103 Posts
  • 32 Reply Likes
Sounds like a very useful feature. I'm sure some of the software guys will chime in on the  do-ability.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
Ken, I am a software guy, it is highly doable.
Photo of Ken ve7kwa

Ken ve7kwa

  • 103 Posts
  • 32 Reply Likes
Well...there you go. You have my "LIKE"
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
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 screw around with their settings. However, thanks for that info Stu, I did not realize that.

Thank you Ken.
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 222 Posts
  • 33 Reply Likes
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.
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
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.
Photo of K2CM

K2CM

  • 265 Posts
  • 18 Reply Likes
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.