<d1b2>
<mubes> It is nice to have a 10Msample wave to be able to dig into though, especially when you're looking for protocol stuff.
Degi has quit [Ping timeout: 252 seconds]
<azonenberg>
Yeah definitely try with all the transports. And yes, for protocol stuff deep captures are awesome
Degi has joined #scopehal
<azonenberg>
my scopes go up to 128M points on the analog channels... i don't usually go that high but it's nice on occasion
<d1b2>
<bob_twinkles> fsedano, is there anything suspicious in dmesg or the Xorg logs? I've had issues with Intel drivers in the past where some internal memory barriers/locks were getting in to bad states and bringing down the whole system like that. It's possible glscopeclient is violating some part of the GL spec and thus causing issues, but GPU drivers are certainly not bug-free
<azonenberg>
yeah back when i did CUDA stuff I routinely crashed my x server with bad pointers etc
<azonenberg>
it looks like he's not here right now though
<d1b2>
<bob_twinkles> I think they're on the 1BitSquared discord so should see it eventually
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #329: Protocol analyzer view gets duplicate packets added when changing spectrogram settings - https://git.io/J3nYm
<d1b2>
<mubes> The 100Mpoints sample depth is very attractive but pulling that depth of buffer across four channels over 100Mbit ethernet is going to be unpleasant. I think we're going to need a progress bar and the ability to download the samples post-aquisition (as opposed to directly after a trigger) before that depth is going to be user-friendly on this class of scopes.
<azonenberg>
Yeah probably. maybe some kind of mode that streams decimated samples then pulls full res on demand or something
<azonenberg>
I have a few other things I want to add progress display to, in particular while there's one for *loading* waveforms from a scopesession
<azonenberg>
there is not one for saving
<azonenberg>
(that's already a pending ticket i think marked for v0.1
<azonenberg>
I have a test dataset now with four waveforms of (128M points on one analog channel at 1 Gsps, plus 32M points on 16 digital channels at 250 Msps)
<azonenberg>
the on-disk size of that scopesession is about 9.7 GB
<d1b2>
<mubes> There does appear to be a decimated mode already, but I think the changes to support it might be pervasive though scopeclient so I've not looked at it seriously yet.
<azonenberg>
Yeah file a ticket since it might be nice to have
<azonenberg>
tag it as "tabled"
<azonenberg>
since it's not gonna happen right away but i don't want it forgotten
<azonenberg>
These are the kinds of more sweeping improvements that need to happen before the v1.0 release which needs to be somewhat finalized architecturally
<azonenberg>
but not until after v0.1
<d1b2>
<mubes> Ok
<azonenberg>
development from now to v0.1 should be focused on stability, anything majorly breaking the UX
<azonenberg>
finishing in-progress stuff like half written protocol decodes (MIL-STD-1553 I'm looking at you)
<azonenberg>
getting the currently working drivers to a reasonably useful state but probably not writing too many new ones
<d1b2>
<mubes> It will make the UI 'feel' more responsive, even though you'll still have to grab the full detail to do any analysis.
<azonenberg>
Yeah
<azonenberg>
I think it will definitely help to make the cheap scopes more useful
<d1b2>
<mubes> One issue is I suspect they do a lot of housekeeping on the stop/go, which is slowing them down...need to get into proper conversation with Siglent on this point. I've got a dozen or so questions/observations for them now, but I want to send them in one batch rather than drip feeding, so I'm waiting until most stuff is done (or hits a wall) before I do that. There are some cracking quirks (setting edge trigger level must be followed by at least
<d1b2>
a 50mS delay or it doesn't stick) but certainly no worse than anyone else's implementation in my experience.
<azonenberg>
Yeah definitely working with vendors on stuff like this will be helpful long term
<_whitenotifier-3>
[scopehal] mubes opened issue #443: Heartbeat - https://git.io/J3CRk
<_whitenotifier-3>
[scopehal] mubes opened issue #444: Horizontal trigger line and level - https://git.io/J3CRa
<_whitenotifier-3>
[scopehal] mubes edited issue #439: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3C4Z
<d1b2>
<GenTooMan> @mubes I have stalled on the trigger code, the difference between the scope SCPI API for trigger control between models is significant. The basic function is not quite the same and it is spread across a large number of commands, with far more commands than trigger modes.
<d1b2>
<mubes> yes, it's not a great model I'm afraid
<d1b2>
<mubes> the triggering, at least on the 2KX+, is organised per trigger mode, which makes it a bit untidy to implement
<d1b2>
<mubes> I would advise just concentrating on edge triggering and getting that something like first of all. The other modes are not tested in the current driver either, for exactly that reason
<d1b2>
<GenTooMan> @mubes that makes sense. I spent time pondering and this model came to mind for the function of PullTrigger trigger_mode = get_current_trigger_mode() m_trigger = get_a_trigger(trigger_mode) PullTriggerSource(m_trigger) this is what PullTrigger seems to be doing at least.
<d1b2>
<mubes> Yes, it's basically collecting the trigger info from the scope.
<d1b2>
<mubes> I don't think SCPI was ever written with the intention of being able to easy to use 😕
<d1b2>
<GenTooMan> Well naught can be done about that now. As we who inherit have to clean up the mess left by the predecessors, regardless of what makes sense to us. Having written a few protocols, it's very easy to discover "feature" creep making an initial plan / design a disaster quickly. That appears to be what happened from how the command set changed. The model is simple but what happens to find the trigger mode and get a trigger type is where all the
<d1b2>
complexity ends. The model does move implementation specific details elsewhere, so it partially cleans things up. I was pondering if it made sense to just make a whole new module for the 1K/2K.
<d1b2>
<mubes> My inclination would be to implement the module doing whatever you need to, then we'll look at how best to integrate them....it's quite possible you'll come up with some smarter work-arounds that can be back ported into the 2KX+ module, for example.
<d1b2>
<mubes> So...don't guard the 2KX+ code, just implement yours cleanly. How we merge them later is 'for study' depending on how different they end up really being.
<_whitenotifier-3>
[scopehal] miek opened issue #445: Support for Agilent/Keysight triggers - https://git.io/J3WfU
<_whitenotifier-3>
[scopehal] miek assigned issue #445: Support for Agilent/Keysight triggers - https://git.io/J3WfU
<_whitenotifier-3>
[scopehal] miek labeled issue #445: Support for Agilent/Keysight triggers - https://git.io/J3WfU
Tost has quit [Ping timeout: 252 seconds]
<_whitenotifier-3>
[scopehal-apps] mubes opened issue #330: Horizontal trigger line and level - https://git.io/J3WZ3
<azonenberg>
Re #442
<azonenberg>
This might be OK to do when no trigger is active but it's easy to bottleneck things
<azonenberg>
if a trigger is active it will horribly degrade performance
<azonenberg>
also if you naively flush the cache the next context menu hit will be super slow
<azonenberg>
There is a toolbar button to manually flush the cache if you've made changes on the scope front panel
<azonenberg>
i used to have a timeout where every X seconds it'd flush the cache and pull config from the scope but this made interactive use a lot laggier on fast scopes
<_whitenotifier-3>
[scopehal-apps] mubes opened issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3WZK
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3WZK
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3WZK
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3WZ1
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #330: Horizontal trigger line and level - https://git.io/J3WZ3
<_whitenotifier-3>
[scopehal] azonenberg commented on issue #443: Heartbeat - https://git.io/J3WZj
<_whitenotifier-3>
[scopehal-apps] mubes commented on issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3W0V
deanforbes_ has quit [Read error: Connection reset by peer]
deanforbes_ has joined #scopehal
wbraun has quit [Ping timeout: 246 seconds]
wbraun has joined #scopehal
esden has quit [Ping timeout: 260 seconds]
JSharp has quit [Ping timeout: 250 seconds]
elms has quit [Read error: Connection reset by peer]
elms has joined #scopehal
esden has joined #scopehal
JSharp has joined #scopehal
hlzr has quit [Ping timeout: 258 seconds]
hlzr has joined #scopehal
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #76: Add radix option for displaying digital bus waveforms - https://git.io/J3Wr7
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #127: Allow cursors to be synchronized between viewports - https://git.io/J3WoT
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #325: GPU hang on iris Plus driver - https://git.io/J3k5U