azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #scopehal
<d1b2> <louis> Am I missing an obvious button or is there no way to export SPI protocol capture data?
<azonenberg> @louis: you should be able to export to CSV
<azonenberg> file | export
<d1b2> <louis> thanks! i was missing an obvious button 🙂
<d1b2> <louis> i was confused by no protocol analyzer option
<azonenberg> @louis: also what's the status of the "don't turn on every channel at startup" change?
<azonenberg> Do you have that pending?
<azonenberg> (i'm trying to keep your forks from diverging too badly)
<d1b2> <louis> Oh
<d1b2> <louis> That (for Tek) is buried with the chunked CURV? patch on a work machine since our tek has actually been in use
<d1b2> <louis> It's pretty minor
<azonenberg> Also, another pain point i want to address
<azonenberg> right now we have inconsistencies wrt autoranging filters
<azonenberg> some filters autorange, others can be adjusted in vertical range/offset
<azonenberg> what i think makes sense is, the first refresh after a filter is created, and then again when requested by the user (say, middle click on Y axis)
<azonenberg> do an autorange
<azonenberg> but do not autorange every refresh
<azonenberg> and definitely do not have autoranging code duplicated in 20+ filter classes
<azonenberg> anyway, i'm about to start work on the filter name refactoring. Which will eliminate SetDefaultName() from normal filter classes
<azonenberg> (it will still be possible to override in special cases but this should not be done by default)
<d1b2> <louis> The only glscope-wide change for the don't turn them all patch is diff diff --git a/src/glscopeclient/OscilloscopeWindow.cpp b/src/glscopeclient/OscilloscopeWindow.cpp index f86b6b5..22adeb9 100644 --- a/src/glscopeclient/OscilloscopeWindow.cpp +++ b/src/glscopeclient/OscilloscopeWindow.cpp @@ -489,6 +489,10 @@ void OscilloscopeWindow::CreateDefaultWaveformAreas(Gtk::Paned* split, bool nodi if(!scope->CanEnableChannel(i))
<d1b2> continue; + //Defer to the scope for which channels to show/enable + if(!scope->IsChannelEnabled(i)) + continue; + //Put time and frequency domain channels in different groups bool freqDomain = chan->GetXAxisUnits() == Unit(Unit::UNIT_HZ); WaveformGroup* wg = NULL;
<d1b2> <louis> Then changing TektronixOscilloscope::DetectProbes to remember what was enabled to start with before enabling them all to detect
<d1b2> <louis> and restoring that state after
<azonenberg> Ok i'll work on that
<azonenberg> i have a few other things i want to refactor around the same time
<d1b2> <louis> my Tek chunked download WIP is in my fork's branch tek_stability
<azonenberg> What is stopping that from being upstreamed?
<azonenberg> if anything?
<d1b2> <louis> Chunking changes are half-done and unusable on non-analog channels
<d1b2> <louis> Also, the whole chunking thing currently imposes overhead on smaller transfers that are only in one chunk that should be dealt with for usability
<azonenberg> ah ok
<d1b2> <louis> I'll sync it with head and PR it sooner or later when the Tek is no longer hooked up to a 1-st order project and I finish it
<azonenberg> Ok great
<azonenberg> and yeah billables come first
<d1b2> <louis> finish it = apply those changes to digital channels and deal with the overhead issue
<d1b2> <louis> I think I can avoid chunking entirely (or have many fewer chunks) by increasing the socket rx timeout
<d1b2> <louis> seems like the scope might be transcoding the entire CURV? buffer before sending the first byte and this is what's causing the timeouts and desyncs on large transfers (don't quote me on this)
<azonenberg> Yeah. the timeout was mostly to keep glscopeclient from hanging outright on the (frequent) occurrences in early driver dev
<azonenberg> when the scope would drop a command and never reply
<azonenberg> (have you noticed that?)
<d1b2> <louis> I haven't noticed that, the only desync's i've seen are induced by large queries
<azonenberg> seems anything even slightly malforme, or coming at the wrong time, it just discards
<azonenberg> are you using the windows or linux firmware?
<d1b2> <louis> pffff... linux? I assume?
<azonenberg> as in, the embedded firmware not the external ssd with windows
<azonenberg> on the mso67
<azonenberg> mso6*
<d1b2> <louis> So yes, I assume
<d1b2> <louis> Unless I'm hugely confused 😛
<d1b2> <louis> I've never booted it to the windows image i guess
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<_whitenotifier-e> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±228] https://github.com/glscopeclient/scopehal/compare/c911666c2982...7967adb6f709
<_whitenotifier-e> [scopehal] azonenberg 7967adb - Changed Filter::SetDefaultName() to produce sane defaults for almost all filters. Still overridden in a few specialized cases. Fixes #281.
<_whitenotifier-e> [scopehal] azonenberg edited issue #281: Figure out some means of shortening filter names so they don't grow out of control - https://github.com/glscopeclient/scopehal/issues/281
<_whitenotifier-e> [scopehal] azonenberg closed issue #281: Figure out some means of shortening filter names so they don't grow out of control - https://github.com/glscopeclient/scopehal/issues/281
<_whitenotifier-e> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal-apps/compare/ada8dc97f2c0...850d419f9eed
<_whitenotifier-e> [scopehal-apps] azonenberg 850d419 - Updated submodules
<azonenberg> Ok. that's one annoyance down
<azonenberg> @louis: I think we are going to end up doing a fair bit of refactoring on the Filter class in general just because it's been around for so long
<azonenberg> as the project has evolved
<azonenberg> it likely also will need some cleanup just to make the code more readable, better commenting, etc. but only after we've done the main refactoring
benishor has quit [Quit: tah tah!]
benishor has joined #scopehal
Ekho has quit [Ping timeout: 246 seconds]
Ekho- has joined #scopehal
Ekho- is now known as Ekho
<azonenberg> Next refactoring in progress: removing NeedsConfig(), it's not hard to write a sane default
<_whitenotifier-e> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±226] https://github.com/glscopeclient/scopehal/compare/7967adb6f709...76d4f4598c97
<_whitenotifier-e> [scopehal] azonenberg 76d4f45 - Refactoring: created default implementation of Filter::NeedsConfig() and deleted redundant overrides in filter classes
<azonenberg> Ok, that's progress
<azonenberg> @louis: what's left to do on the dslabs driver? can we close https://github.com/glscopeclient/scopehal/issues/452 yet?
<azonenberg> so, going to sleep shortly. but tomorrow I want to implement vertical autoscaling on request
<azonenberg> for filters, at least (probably not for analog channels)
<azonenberg> when you middle mouse on the Y axis. it will adjust the channel gain/offset such that the channel completely fills the plot vertically
<azonenberg> this refactoring will also unify gain/offset control for filters
<azonenberg> and remove all of the per filter autoranging code
<d1b2> <louis> Yeah, probably go ahead and close #452. We can have a separate issue for flow control improvements (I've been using them locally, but still a little unstable and haven't cleaned up to PR) and any issues that arise with the DSLogic (haven't been back to test since getting it working.)
<_whitenotifier-e> [scopehal] azonenberg closed issue #452: DreamSourceLab DScope driver - https://github.com/glscopeclient/scopehal/issues/452