<d1b2>
<louis> glscope crashes or bridge application crashes?
<d1b2>
<TiltMeSenpai> yes.
<d1b2>
<TiltMeSenpai> I think glscope crashes and leaves the bridge in a state that's causing it to give up
<d1b2>
<louis> Interesting. I'd be happy to get bug reports / gdb traces for those crashes 🙂
<d1b2>
<TiltMeSenpai> I'll probably do some debugging this weekend or something
<azonenberg>
@louis: so how's your work doing on the thunderscope driver? is that your primary focus right now?
<d1b2>
<louis> I use the DSCope regularly at work and that's pretty stable for me. I haven't used the DSLogic for anything serious since getting it working circa march(?)
<d1b2>
<louis> @azonenberg their C# driver/application didn't have a Linux backend (glue to the xilinx xdma driver), so I wrote one and then encountered some weird Thunderbolt bandwidth limitation issues on the workstation it's plugged into at the office that confounded us for a minute. The Linux backend for their driver seems to work right though tested by someone else. Next will be hooking their C# application up to glscope.
<azonenberg>
Great
<d1b2>
<louis> How exactly that happens is TBD. They have a shmem architecture that is how they wanted to interface it to their client. So we could support that, or we could write a shmem <-> SCPI socket bridge.
<d1b2>
<louis> Needs a control plane either way as I understand it.
<azonenberg>
We'll need to think about what makes sense. and i want network transparency at some point in the pipeline
<azonenberg>
even if we also support a faster local protocol
<d1b2>
<louis> On Linux at least I think it might be possible to preserve zero-copy over a local TCP socket with splice
<d1b2>
<louis> Windows, who knows.
<azonenberg>
Nice. Keep me posted
<azonenberg>
(also see DM)
<mxshift>
azonenberg: let me know if you have any trouble with loading the QSGMII file. We'll have the setup in place until noon tomorrow so we can retake if needed.
<azonenberg>
mxshift: what kind of scope is this from?
<mxshift>
Tek MSO 6 I think
<azonenberg>
Hmm, ok i dont think we have an importer for their native format yet
<_whitenotifier-7>
[scopehal-apps] azonenberg 4c79000 - ScopeSyncWizard: removed inner loop and replaced with a simple divide. Seems to slow things down but keeping in history as a reference point. See #452.
<_whitenotifier-7>
[scopehal-apps] ... and 5 more commits.
<_whitenotifier-7>
[scopehal-apps] azonenberg 2266a8a - ScopeSyncWizard: Refactoring of various correlation implementations out into separate functions. See #452.
<_whitenotifier-7>
[scopehal-apps] azonenberg 72064c3 - Initial AVX512 implementation of correlation. See #452.
<_whitenotifier-7>
[scopehal-apps] azonenberg ea77cc4 - Moved one more check out of inner loop. Fixes #452.
<d1b2>
<louis> Will do. It'll be nice to have that. I was trying to take a 100s low speed capture of something and it was a huge PITA to deal with because of timeouts.
<d1b2>
<louis> A related feature I'd love to see is a button for 'Pull the existing capture off the scope without taking a new one'
<d1b2>
<louis> (I ended up patching my copy of the Tek driver to do that)
<d1b2>
<louis> Since that facilitates my somewhat-common workflow of "OK, I've got the capture set up, time to suck the brains out of this thing and do the analysis in glscope"
<d1b2>
<louis> So does being able to capture to .wfm and import that
<azonenberg>
@louis: i think there is a ticket for that already
<azonenberg>
but there is neither an API nor a toolbar button
<azonenberg>
also, good news: i hear from katharina on twitter earlier
<azonenberg>
she's interested in getting back into things on the gui side
<azonenberg>
i heard*
<azonenberg>
There is also a pending ticket for auto trigger
<azonenberg>
we need a toolbar icon, a button in the gui, and APIs in as many drivers as possible
<azonenberg>
(the challenge is of course how to make it stop etc so we get single snapshots of waveforms)
<azonenberg>
At some point i want to revamp the toolbar icons. the monochrome look makes it hard to distinguish stuff especially if we add more buttons in the future
<mxshift>
From person working on QSGMII debug: Ok so late in the day we found a problem on the board and we can get another capture today which I think will be more fruitful. We were coupling through an esd diode (removed and improved performance) but I’m worried on a very long run we are coupling as well…