search

ngscopeclient / scopehal

Test and measurement hardware abstraction library and protocol decodes. This is the library only. Most users should use scopehal-apps.
BSD 3-Clause "New" or "Revised" License
211 stars 94 forks source link

Continuously monitor scope configuration #442

Open mubes opened 3 years ago

mubes commented 3 years ago

In order to keep the UI in sync with the scope, and to be certain of continued connectivity, parameters should be pulled from the scope continually when it is idle. This allows the UI to be kept up to date and tests the link.

azonenberg commented 3 years ago

Any traffic to the scope, especially on slower/high latency instruments (Rigol, VPN access, etc) adds latency before another command can be issued. If done in the UI thread it will hang the UI and if done in the waveform polling thread it will block the trigger polling. Most of the optimizations made in scopehal over the past years have been aggressively minimizing unnecessary communication, not creating more.

If there was a way for instrument firmware to push "settings changed" notifications to the scope, perhaps as part of polling the trigger, then we wouldn't be adding more traffic. (Feature request for responsive instrument vendors?)

There is a "flush config cache" button on the toolbar of glscopeclient that forces all settings to be refreshed and is intended to be manually clicked when scope settings are modified via the front panel. We used to have a timer that automatically refreshed every N seconds but this ended up causing periodic UI stuttering and was removed to improve responsiveness.

mubes commented 3 years ago

I was explicitly intending this for the case where the scopeclient is otherwise idle, because it lets us track any changes to settings the user might make on the scope front panel. There will be some increased latency in the transition from idle to sampling, but hopefully that would only be in the order of milliseconds. We can't use this technique while collecting samples because it would impact on performance, I agree.

azonenberg commented 3 years ago

Yeah, it might be OK then but I've worked with scopes (e.g. Rigol over VPN) in which every single command had a cost of hundreds of ms. If nothing else, there would have to be a preference to disable it.

This might be a UI-side issue better for scopehal-apps, but I'll keep it here until we've figured things out more.