<_whitenotifier-9>
[scopehal-apps] azonenberg 1cf64d0 - When creating an import filter, immediately open the file browser dialog. Would be kinda pointless to make an import filter otherwise so this saves a step.
bvernoux has joined #scopehal
Stephie- has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
<d1b2>
<louis> I'm also carrying a filter that just drops samples with duration under a configurable limit as a glitch removal filter. Is there something we already have I missed that does this, or should I PR that?
<d1b2>
<louis> and yes: driver error handling: that would also be good for the case where scopes get their SCPI so locked up that manual intervention is required to reset it (but where it's not just borked)
<d1b2>
<louis> oh i have a unrelated UX question, which is that I want the ability to load a session against a scope with a different serial / maybe even different model
<d1b2>
<louis> i have that check just commented out -- how do we want to handle that more generally? flags for --ignore-serial-check and --ignore-model-check? in general I think the serial check probably shouldn't be needed
<d1b2>
<louis> since even having the same serial dosen't guarantee that the saved configuration is still valid in the presence of expiring license options or whatever
<azonenberg>
I dont think we have such a glitch removal
<azonenberg>
and yeah, agreed. In general i want to have some kind of sanity checking
<azonenberg>
so that, for example, we look at the current voltage on a power supply when loading a saved config
<azonenberg>
and if the new voltage is significantly higher, it will ask you to confirm before pushing the change
<azonenberg>
basically i want to make it so that loading the wrong scopesession won't blow out your DUT and a bunch of instrument channels
<azonenberg>
and basically the purpose of the check was to assume that you are reconnecting to the literal same experimental setup you were on before
<azonenberg>
i was even going to add checks for the same active probes on the same channels
<azonenberg>
maybe make it something you can click through rather than instantly failing
<azonenberg>
but it's the kind of thing that you want to be really sure about