search

kpreid / shinysdr

Software-defined radio receiver application built on GNU Radio with a web-based UI and plugins. In development, usable but incomplete. Compatible with RTL-SDR.
https://shinysdr.switchb.org/
GNU General Public License v3.0
1.07k stars 115 forks source link

Alternative UI for remotely settable values #121

Open quentinmit opened 5 years ago

quentinmit commented 5 years ago

Some exported values, like rotator azimuth/elevation and AGC gain, have the property that they can be set from the client, but their value also changes on the server side. Right now it's hard to use these controls - clicking the azimuth slider, for instance, causes a jump to the new position but as soon as the mouse is released it jumps back to the current position.

It would be better if the UI could separately show the last-set value and the current value for these controls. Az/el are especially interesting because the "set" position may or may not be active, if e.g. the rotator was commanded to move at a constant velocity instead.

I'm opening an issue instead of a pull request because I don't really have any good ideas for how to design this UI.

kpreid commented 5 years ago

There's already special support for the period between clicking on a control and the value being updated on the server (the client ignores new values until the server sends a done message in response to the set message from the client; this is ReadWriteCell's inhibitCount on the client). I don't think this is a good strategy in general for more than network latency handling, though.

In the case of the rotator, I think it makes to have separate target and current values, and a custom UI for the purpose, because there is an actual application state involved here that's currently implicit or unsupported (rotator is rotating to a specified target, and also could be told to stop).

quentinmit commented 5 years ago

Unfortunately the rotctld protocol doesn't expose anything about the target state of the rotator (target azimuth, move/stop/park, etc.), so we would have to keep track of the most recent command sent from the client-side. That also means if any other rotctld clients control the rotator we have no way of knowing what state they put it in.

I think designing a "proper" rotator UI probably involves trying to solve that problem too.

quentinmit commented 4 years ago

I found some interesting prior art for rotator control here:

https://github.com/dh1tw/remoteRotator

They have some JS components that look like they would make a great web UI for rotator control, and they're also trying to define a new network protocol for rotator control. I haven't looked too hard at the protocol to evaluate whether it has all the missing features, but maybe it's a starting point.