<_whitenotifier-e>
[scopehal-apps] azonenberg 0914fd7 - SCPI console: use queued command API
<azonenberg>
Thoughts on adding a "developer mode" preference setting at some point?
<azonenberg>
basically hide a bunch of menu items like the performance graphs and the scpi console that are not useful to most end users, and primarily interesting to driver devs
<azonenberg>
just to avoid confusing new users
<azonenberg>
I want to do some tidying up of the menus in general, perhaps moving a few things around
<azonenberg>
this would make sense to do as part of that if we want to do it
<_whitenotifier-e>
[scopehal-apps] azonenberg 1a2fb74 - Added recent multimeter menu. Unified a bit of processing for multimeter and other recent instrument menus. Fixes #427.
<d1b2>
<mubes> If you do end up dipping into the GUI, one thing I'd really like is a 'busy' indication. When the scope has triggered and scopehal is collecting data from the far end, there's precious little indication it's doing anything. On a 100K 4 channel sample on the slower scopes that's quite some time to be hanging with no indication anything is happening.
<azonenberg>
There is an open ticket for that but it's nontrivial to figure out how to actually implement
<azonenberg>
for example, during real time streaming from a fast scope like a picoscope
<azonenberg>
you are almost always acquiring in the background, while simultaneously running the filter graph on another waveform and displaying yet another
<azonenberg>
one possibility is to add some kind of timer where if a single waveform download has been in progress more than X time, add a busy indicator
<azonenberg>
but not if many small ones are happening consecutively
<azonenberg>
the other thing is to figure out how to do this with multiple instrument
<azonenberg>
if your scope is busy but not you multimeter
<azonenberg>
or one scope is busy but not the other
<azonenberg>
etc
<azonenberg>
hmmm, interesting and bizarre behavior when using multimeter trend filter plus a scope
<d1b2>
<DanielG> Quick question for the chat: I’m getting a quote for a MDO5 scope. Does the issue called out in the glscopeclient manual still exist: problems with capturing over USBTMC, or using more than 500K points of memory depth? I plan on using LXI so I’m not too concerned with USB support. However, 500K points of memory sounds like a non-starter, considering I’m looking at the scope for its 60+ Mpts of mem depth per channel…
<d1b2>
<DanielG> I tried looking for these issues in scopehal apps and scopehal repos with no avail.