<d1b2>
<tnt> Is there an easy way to overlay traces from different triggers ?
<d1b2>
<tnt> My use case is that I don't have enough channels ( or rather not enough probes or enough hands to hold them ). So what I end up doing is choosing a signal that's "stable" as trigger and then I sequentially probe signal 2/3/4/5/6/.... while generating a pattern that repeats.
<d1b2>
<tnt> And ideally I'd like to see 2/3/4/5/6 on the same graph, possibly even running decoder on that.
someone-else has quit [Quit: Connection closed]
bvernoux has joined #scopehal
<azonenberg>
tnt: Better support for pulling historical waveforms onto the display, and even allowing filters to use old waveforms as input, is planned
<azonenberg>
But not currently supported
<azonenberg>
right now you can only view a single trigger's state at once
someone-else has joined #scopehal
<_whitenotifier-1>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JicQR
<_whitenotifier-1>
[stm32-cpp] azonenberg 44d4878 - STM32F777 CRYP support
balrog has quit [Quit: Bye]
balrog has joined #scopehal
<d1b2>
<dannas> Continuing my tiny steps, exploring glscopeclient. Opened the demo scope, null transport and did a small monkey test. Randomly selected the Clock Jitter filter and got a sigsegv. The FlowGraphNode has only one vector of StreamDescriptors has one null channel.
<d1b2>
<dannas> What I'm actually trying to do, is replicated a crash I saw yesterday where the log said something about wayland. I'm curious if there is some part of glscopeclient which doesn't work with my dont-choke-on-glew-errors patch.
<d1b2>
<dannas> I was randomly selecting some filters and now I can't remember which one it was that triggered that wayland-related log message followed by a crash
<d1b2>
<dannas> restarts glscopeclient and continous testing filters on the demo scope waveforms.
massi has quit [Remote host closed the connection]
<d1b2>
<dannas> Oh, there's another crash, but this time in WaveformArea::BinarySearchForGequal. Maybe these kind of errors is not worth mentioning. I guess the demo scope is just there for demonstrational purposes and hasn't been hardened for bad input.
<d1b2>
<dannas> Seems to be the same kind of thing. A StreamDescriptor has a channel that is null. The search for the wayland-related crash continues...
<d1b2>
<dannas> Nope, can't reproduce the crash with the wayland log message.
<d1b2>
<dannas> finds a Rigol MSO1104. Wonder if glscopeclient works with it? Not listed in the manual, but worth a shot.
<d1b2>
<dannas> Oh, one of these kind of days. I can connect to the Rigol MSO1104 over LXI. GLScopeclient enables all four channels and configures them, but before any waveforms has been displayed on the PC, glscopeclient crashes. in AcquireData.
<d1b2>
<dannas> I'm not familiar with the protocol but it looks like the configuration stages goes ok but then it chokes when it's times to retrieve the data.
<d1b2>
<dannas> The len field is 1200. The buffer is supposed to be far larger than that. Oh well, It's probably something very obvious, but I'm just a little hungry and tired right now.
<d1b2>
<dannas> heads home from the office.
<azonenberg>
dannas: the demo scope should work reliably
<azonenberg>
if it does not, it's a bug and should be reported/investigated
<azonenberg>
any crash in general is worth writing up. filters should detect invalid input and produce no output, which is a legal state for the system