<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb8i
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #219: Optional new toolbar with shortcut on bottom (or movable) to select quickly measurement/decoder ... - https://git.io/JUAdF
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #277: glscopeclient fails to run on Fedora under Wayland due to GLEW init failure - https://git.io/J3vZ2
<_whitenotifier-3>
[scopehal-apps] azonenberg edited issue #277: glscopeclient fails to run under Wayland due to GLEW init failure - https://git.io/JTb7R
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/JInZu
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/J3vne
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #306: Proposal migrate code from gtkmm to ImGui - https://git.io/JLbD5
<_whitenotifier-3>
[scopehal] azonenberg opened issue #431: Threshold: add option for interpolation to get more exact zero crossing positions - https://git.io/J3vcK
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #431: Threshold: add option for interpolation to get more exact zero crossing positions - https://git.io/J3vcK
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #321: Filter graph editor crashes when the last reference to a filter is removed - https://git.io/J3vuO
<_whitenotifier-3>
[scopehal] azonenberg opened issue #432: Filter graph editor crashes when the last reference to a filter is removed - https://git.io/J3vu3
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #432: Filter graph editor crashes when the last reference to a filter is removed - https://git.io/J3vu3
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #432: Filter graph editor crashes when the last reference to a filter is removed - https://git.io/J3vu3
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3vuE
<_whitenotifier-3>
[scopehal] azonenberg d3ab501 - FlowGraphNode: ensure make-before-break ordering when setting an input that already has something hooked up to it. Fixes #432.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #432: Filter graph editor crashes when the last reference to a filter is removed - https://git.io/J3vu3
<azonenberg>
miek, monochroma, lain, mubes: so question for you all
<azonenberg>
Are there any pain points you've encountered during your use of glscopeclient to date that you think need to be fixed before a first v0.1 release that don't currently have tickets filed and tagged as v0.1?
<azonenberg>
more to the point, if all current v0.1 tickets were done would you have any reservations about calling it release ready?
<azonenberg>
I'm starting to shift focus towards the tickets identified as most important for v0.1, as well as specific features i need for work etc
<azonenberg>
with the intent of getting an official v0.1 release out by some time this summer
<monochroma>
i still need to port my scope back to a working state (iirc the later vbscript additions to the driver killed broke my scope) and see how things are looking
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #324: Save/restore gain/offset config for filters - https://git.io/J3v52
<azonenberg>
Support for every scope under the sun is more of a v1.0 feature than v0.1. but if you need to do it to test, then definitely go for it
<monochroma>
yeah
<azonenberg>
For v1.0 i want every big manufacturer to be reasonably well supported
<monochroma>
a very good thing to say in each realease is the /ACTUAL/ state of every scope that is supported
<azonenberg>
I haven't decided on milestones between 0.1 and 1.0 yet
<azonenberg>
my main definition is that 0.1 is the first release i expect someone who's not a glscopeclient developer to be able to install and use without significant handholding
<azonenberg>
all reasonably core features are present and it's functional, bug-free, and documented enough that people can just start using it
<azonenberg>
1.0 by comparison requires a reasonable level of API stability in libscopehal, support for most/all major scope families, much more complete documentation, more generally polished UX, etc
<azonenberg>
Later 0.x releases will probably have specific goals and be centered around, say, automotive protocols or keysight scopes
<azonenberg>
although of course unrelated bug fixes/feature tickets will be accepted
<monochroma>
so i'm fairly out of the loop on the latest state of things. i think my biggest annoyance was at the time (hmmm maybe close to a year ago now) was lots and lots of mouse clicking and entering data to setup the all the filters for data decode/SI eyechart etc. i'm guessing that is mostly resolved with the filter graph editor ? (and i assume you can save/import filter graphs for quick ability quickly
<monochroma>
bring everything to the state it needs to be for whatever work you are doing?)
<azonenberg>
You can save a scopesession with the filter config than reconnect to the scope and restore the instrument config and filter topology to what you had saved
<azonenberg>
The filter graph editor is not 100% complete. in particular it lets you manipulate connectivity between existing filters and change their properties
<azonenberg>
but it's a little clunky at times, and you cannot create new filters in the graph editor yet
<azonenberg>
that ticket is still open although i think it's tagged as a blocker for v0.1
<monochroma>
oic
<azonenberg>
There's a few other pending items regarding scopesessions
<azonenberg>
some bits of the file format are not currently valid yaml
<azonenberg>
yaml-cpp parses them OK, but they're not spec compliant
<azonenberg>
so i need to figure out exactly what's wrong, fix them, and make sure that said fixes don't break loading of older files
<azonenberg>
but there's tickets for those items already
<azonenberg>
This was more of a "call for tickets"
<monochroma>
hehe
<azonenberg>
i.e. if anything is missing or broken or awkward, i want issues filed sooner rather than later
<azonenberg>
so i can start getting a feel for how close we are to ready to call it a release
<monochroma>
yeah let me see if i can find some time to un bit-rot my scope's driver (and not break your scopes! :P)
<azonenberg>
When i get back to the $work lab i need to do some testing on the wavesurfer 3000
<azonenberg>
there's at least one thing i borked on that too (channel combining)
<azonenberg>
and i need to play with the function generator on it once i build a func gen ui in glscopeclient
<azonenberg>
But yeah really i just feel like the project has gone on long enough with people scratching their own itches and not doing much core functionality
<azonenberg>
i want to fix all of the missing pain points and get it ready for a release
<azonenberg>
Proper path resolution for data files is definitely a key component of that
<monochroma>
oh yeah, do we still have hardcoded /nfs/ (or is it /ceph/ now?) dirs ?
<azonenberg>
No. It's slightly less atrocious
<monochroma>
XD
<azonenberg>
the cmake scripts copy all of the data files to the binary directory
<azonenberg>
and it chdirs to dirname(/proc/self)
<monochroma>
oh right, i think i did that
<azonenberg>
this would work as-is if we stuck it in /opt but not for a normal posix install in /usr/lib, /usr/share, etc
<azonenberg>
it also breaks loading relative filenames on the command line
<monochroma>
yeah
<azonenberg>
It's a bandaid and has always been
<azonenberg>
Just havent had time to make it right
<monochroma>
azonenberg: assign that ticket to me?
<_whitenotifier-3>
[scopehal-apps] azonenberg assigned issue #302: Proper path resolution for data files - https://git.io/JLKUm
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #392: Proper path resolution for data files - https://git.io/JLKUJ
<azonenberg>
There's two - one in libscopehal for adding the function, another in scopehal-apps for calling it from glscopeclient
<monochroma>
(brb)
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/J3fE2
<_whitenotifier-3>
[scopehal-apps] azonenberg 2ebf093 - Initial implementation of horizontal cursors. Shared by all waveforms in a group. Doesn't handle mixed units too well. Fixes #85.
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/J3fyQ
<_whitenotifier-3>
[scopehal-apps] azonenberg bca8768 - Various improvements to appearance of horizontal cursors
Tost has joined #scopehal
promach3 has quit [Quit: Bridge terminating on SIGTERM]
JJJollyjim has quit [Quit: Bridge terminating on SIGTERM]
JJJollyjim has joined #scopehal
<d1b2>
<SleepyOwl Joyce> @azonenberg was saying that he hasn't seen me on the channel yet, so uhhh
<d1b2>
<SleepyOwl Joyce> hi?
<d1b2>
<SleepyOwl Joyce> so I am going to be working on glscopeclient UI stuff in the next few days or so
promach3 has joined #scopehal
<xzcvczx>
sleepyOwl Joyce: very nice
<d1b2>
<SleepyOwl Joyce> I'm just reading the code and getting to know how things are organized, etc at the moment
Famine- has quit [Read error: Connection reset by peer]
Famine has joined #scopehal
Famine has quit [Read error: Connection reset by peer]
Famine has joined #scopehal
<xzcvczx>
azonenberg: well if you have xwayland 'GDK_BACKEND="x11" path/to/glscopeclient'
<xzcvczx>
works
<xzcvczx>
you want me to pr that into the docs?
<GenTooMan>
xwayland loves you..
ericonr has quit [Read error: Connection reset by peer]
ericonr has joined #scopehal
ericonr has quit [Read error: Connection reset by peer]
ericonr has joined #scopehal
<xzcvczx>
o_O
<GenTooMan>
I couldn't have said it better :D
<xzcvczx>
you are odd
<GenTooMan>
no just a bit confused over what to do with git, I have made changes instead of creating a local branch. It has been a bit since I've done much code work. So I need to create a local branch and commit the changes to that. I want to preserve what I've done restore the old code an incrementally test the new code.
<xzcvczx>
git stash
<xzcvczx>
creat the branch then apply the stash
<GenTooMan>
then switch to master?
<xzcvczx>
well applying the stash just changes the workingdir
<xzcvczx>
so you might want to cherry pick ya edits into commits
<xzcvczx>
if you want to be able to incrementally test
<xzcvczx>
oh have you been amking commits up until now?
<xzcvczx>
or just a bunch of code thrown at the wall?
<GenTooMan>
code to the wall. It's just one module however so I probably can commit to a branch. The restore the master, then hopefully do a diff type thing to readd the code.
<xzcvczx>
ah yeah ok i assume its not commited?
<GenTooMan>
right not locally or remote
<xzcvczx>
back to git stash
<GenTooMan>
hmm unlike subversion deleting local code won't force it to refresh the code from the master. So how do I force the local code to match the master?
<xzcvczx>
the git stash should have reverted it
<xzcvczx>
as it should have stashed anything you changed
<xzcvczx>
had you added some stuff to cached?
<GenTooMan>
bleah git is too protective of the code.
<GenTooMan>
well I ended up deleting the entire local repository. git is definitely inferior to subversion in many ways
<apo>
your understanding of git is definitely inferior to your understanding of subversion ;3
<GenTooMan>
that's true as well.
<GenTooMan>
:D
<GenTooMan>
so is the repository for scopehal-apps a superset of scopehal repository?
massi has quit [Quit: Leaving]
balrog has quit [Quit: Bye]
balrog has joined #scopehal
<Degi>
Whats the typical dB/decade attenuation of oscilloscopes?
<GenTooMan>
it's partially dependent on the scope probe being used.
<GenTooMan>
typically 10:1 probes are used but 1000:1 and 1:1 also exist.
<azonenberg>
Degi: it totally depends on the instrument design
<azonenberg>
Most of them do various DSP compensation
<Degi>
Ah well
<azonenberg>
and try to be as flat as possible in the passband with a sharp rolloff after that
<azonenberg>
it's not linear
<Degi>
Hmm okay
<azonenberg>
GenTooMan: scopehal-apps is the main repo for glscopeclient, it includes scopehal and several others as submodules
<GenTooMan>
azonenberg, so if I am modifying scopehal modules do I use scopehal for code and then scopehal-apps for testing?
<azonenberg>
Generally you will want to clone scopehal-apps and have everything under that
<azonenberg>
there should be build instructions in the manual to set up the tree correctly
<azonenberg>
If you're actually doing development rather than just building it, I also recommend setting "git config submodule.recurse true" so that when you pull changes, you get updates to the other repos too
<azonenberg>
Degi: in the case of lecroy, actually, on the higher end scopes you have your choice of three different response curves
<Degi>
Neat
<azonenberg>
fourth order bessel-thomson
<azonenberg>
brick wall optimized for in-band flatness
<azonenberg>
and maximally flat group delay
<Degi>
Hm, so there is a tradeoff between amplitude and delay flatness?
<azonenberg>
No you can tune phase and amplitude separately
<azonenberg>
lecroys actually implement two different fourth order bessel filters
<Degi>
In hardware or is that all in FPGAs etc?
<azonenberg>
one with minimal preshoot and one with flat group delay that has some preshoot and some overshoot
<azonenberg>
I suspect this is all software on the PC side
<azonenberg>
but some might be in FPGA
<Degi>
Like its not the filter before the ADC?
<azonenberg>
No
<azonenberg>
This is postprocessing to correct for nonlinearities in the ADC and frontend
* GenTooMan
removes then cleans up everything and starts from scratch to see what he changed.
<GenTooMan>
I just need to setup a process to build and test after all that.
Tost has joined #scopehal
fsedano has joined #scopehal
fsedano has quit [Quit: Connection closed]
<azonenberg>
woop, we now have an ARINC 429 test waveform corpus
<azonenberg>
So i guess that will be next on my to-do list after I finish putting the finishing touches on the MIL-STD-1553 decode
fsedano has joined #scopehal
<fsedano>
Hello folks - New guy here.
<azonenberg>
o/ fsedano
<fsedano>
I started to use glscopeclient with my RS RTM3000 and found a few unsupported commands that I'll be adding.
<azonenberg>
So yeah as i was saying on twitter, libscopehal filters are strongly typed
<azonenberg>
most of the decodes expect digital inputs
<azonenberg>
So if you have an analog capture you need to apply a threshold filter
<azonenberg>
There will eventually be UI glue to automatically do a 50% threshold when you apply a filter which expects digital inputs to an analog channel
<azonenberg>
but right now you have to do that manually
<fsedano>
I see. Another area I could help with is enabling digital channels on the RTM3000
<azonenberg>
The same is true of higher level decodes: for example the 1000base-X ethernet decode doesn't take an analog waveform as input
<azonenberg>
it takes an 8B/10B data stream
<fsedano>
but I'm facing stability issues with the scope - (today) it completely freezes (no response to ICMP, UI frozen) when we try to access it.
<azonenberg>
the 8B/10B decoder takes a digital waveform for clock and another for data
<azonenberg>
So to go from voltages to ethernet frames you'd threshold the data and apply a CDR PLL filter to it, then feed those two into the 8B10B block, and then feed that into 1000baseX
<fsedano>
And several times glscopeclient crashed my GPU driver
<azonenberg>
Crashing the GPU should not happen, if you can reproduce definitely file a bug and we'll look into it
<fsedano>
I can repro relatively quickly - Which info is good to collect?
<azonenberg>
As much as you can. OS, card, GPU driver version, steps to reproduce, an example scopesession, screenshots, video, whatever you can reasonably provide
<azonenberg>
There are known pathological conditions in which shaders get into long (but bounded) loops if given invalid data as input. These are not true crashes, but can cause the GPU to lock up for an extended time period and might time out in the driver
<fsedano>
ok - I was thinking on some kind of low level debug of opengl calls etc, but no clue. Ptr to open bug?
<azonenberg>
i've tried to detect and abort when possible
<azonenberg>
just open a new ticket on azonenberg/scopehal-apps
<azonenberg>
as far as instrument stability goes, unfortunately a lot of instruments are quite buggy
<azonenberg>
and very picky about exactly what scpi commands are issued and even the timing of them
<azonenberg>
e.g. it might not like you sending one command before you get the reply from the last one
<azonenberg>
We try to work with instrument vendors when possible to fix these bugs but sometimes we just need to come up with workarounds
<azonenberg>
So far LeCroy has been the most reliable firmware, i've only crashed my scopes a handful of times ever
<azonenberg>
I've never crashed a PicoScope but their driver has died on me numerous times
Tost has quit [Ping timeout: 252 seconds]
<azonenberg>
Tek MSO6 is the worst i've personally worked with
<azonenberg>
for such a nice scope their stack is awful
fsedano has quit [Quit: Connection closed]
<azonenberg>
well, i guess he crashed his gpu again :p
fsedano has joined #scopehal
<fsedano>
sorry the driver crashed and I lost the session
<fsedano>
can u send again the link to open the bug?
<azonenberg>
(15:19:17) fsedano left the room (quit: Quit: Connection closed).
<azonenberg>
(15:20:15) azonenberg: well, i guess he crashed his gpu again :p
<azonenberg>
re video: interesting. That does look like it's probably a shader timeout
<azonenberg>
since it said "gpu hang"
<fsedano>
on the video its not obvious but there's screen activity - you have that trembling continuously.
<azonenberg>
Improving render performance with a lot of points on a few pixels, possibly including timeouts or selective decimation, would probably be nice
<azonenberg>
Yeah i do see that
<azonenberg>
i thought that was you scrolling back and forth
<fsedano>
no, it's happening on it's own
<azonenberg>
interesting, i've never seen that
<azonenberg>
what usually happens to me (nvidia blob driver w/ 2080 Ti or quadro k5200) is things stop responding for seconds to minutes, then it wakes up and is fine as long as i kill glscopeclient before it attempts to render another frame
<azonenberg>
The typical trigger is garbage data, like FLT_MAX or NaN sample values
<azonenberg>
the shader is doing exactly what it's supposed to, but trying to plot points out to infinity and taking a really long time doing it
<azonenberg>
i need to figure out how to bounds check to prevent such hangs, while not also hurting performance too much on valid input
<azonenberg>
It's possible your driver has a more aggressive timeout for long running shaders
<azonenberg>
And the flickering you're seeing might be the second-to-last and last frames alternating or something
<fsedano>
It sounds reasonable - If you send me a patch with extra debug happy to run it
<fsedano>
opening the issue as we speak
<azonenberg>
Yeah get the issue open. Short term, if you can reproduce it reliably can you just avoid doing whatever triggers it?
<fsedano>
not really
<fsedano>
performance is sluggish.. so if I do something that takes a little longer time
<fsedano>
it will happen
<fsedano>
but really something simple... Disable channels, change center pos...
<azonenberg>
Interesting
<azonenberg>
so it's not just from zooming out too far
<azonenberg>
Get the bug open and let me have a look at the info you provided. oh, also a glxinfo dump would be nice
<_whitenotifier-3>
[scopehal-apps] fsedano opened issue #325: GPU hang on - https://git.io/J3k5U
<azonenberg>
ok so as a first experiment
<azonenberg>
in src/glscopeclient/shaders/waveform-compute-core.glsl, try commenting out the entire loop on lines 85-199 and rerunning the app. You won't see any waveforms, but does it still crash or no?
fsedano has quit [Quit: Connection closed]
<_whitenotifier-3>
[scopehal-apps] fsedano opened issue #326: Crash if agilent driver is used on RS scope - https://git.io/J3k5p
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #326: Crash if agilent driver is used on RS scope - https://git.io/J3kdk
<_whitenotifier-3>
[scopehal] fsedano opened issue #433: Crash if agilent driver is used on RS scope - https://git.io/J3kdt
<_whitenotifier-3>
[scopehal-apps] fsedano edited issue #325: GPU hang on iris Plus driver - https://git.io/J3k5U
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #433: Crash if agilent driver is used on RS scope - https://git.io/J3kdt
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #433: Crash if agilent driver is used on RS scope - https://git.io/J3kdt
<_whitenotifier-3>
[scopehal] azonenberg commented on issue #433: Crash if agilent driver is used on RS scope - https://git.io/J3kdc
fsedano has joined #scopehal
<azonenberg>
(15:41:06) azonenberg: ok so as a first experiment
<azonenberg>
(15:42:36) azonenberg: in src/glscopeclient/shaders/waveform-compute-core.glsl, try commenting out the entire loop on lines 85-199 and rerunning the app. You won't see any waveforms, but does it still crash or no?
<azonenberg>
Rebuild before running... the shaders are loaded dynamically at run time so a compile isn't needed but the makefile also copies the shaders to the build directory
<azonenberg>
so if you edit in the source tree and don't re "make" they won't update
<fsedano>
I dont see a crash so far
<azonenberg>
Ok, unsurprising
<fsedano>
performance is abysmal however
<fsedano>
like 20 secs to open popup window
<azonenberg>
very interesting
<azonenberg>
with that loop commented out you're basically skipping the entire rendering path
<azonenberg>
at least the time consuming parts of it
<azonenberg>
Ok so it looks like you're having multiple problems
<fsedano>
The invalid coupling value I fixed it - it's a bug on the driver
<azonenberg>
Ok
<fsedano>
I need to reapply the patch
<azonenberg>
I forget if the R&S driver implements any caching for things like volts/div etc
<fsedano>
it does on some
<azonenberg>
if it's polling the instrument every time you open a context menu or render a frame
<azonenberg>
then that will definitely kill performance
<fsedano>
I fixed that - Let me apply my patch and try again
<azonenberg>
Ok
<azonenberg>
This is actually a fairly common situation
<azonenberg>
most instrument drivers don't cache error/invalid values
<azonenberg>
so if it doesnt understand some reply it will poll again the next frame
<azonenberg>
and you end up hitting the instrument every time you do anything
<fsedano>
So coupling is not cached on RS driver.
<azonenberg>
That would explain the context menu being slow
<azonenberg>
because i'm pretty sure it queries coupling to set the radio button in the submenu
<fsedano>
checking that
<azonenberg>
it should be slow once, but not after that
<fsedano>
can I enable debugs of all SCPI commands sendt/rev?
<azonenberg>
Yeah. just add --debug to the command line (if you don't already have that on, it's a good idea to have it by default when doing dev work) as well as --trace SCPISocketTransport
<azonenberg>
assuming you're using the normal socket transport rather than VXI-11
<azonenberg>
We really need to write a developer/debug manual at some point, so far all of the documentation is more end user focused
<fsedano>
k I was using debug but didn't know abt trace. Checking..
<azonenberg>
--trace enables extra verbose output for a class or class::function
<azonenberg>
anything written with LogTrace()
<azonenberg>
you can also control normal verbosity level with --quiet, --verbose, and --debug
<azonenberg>
trace is on top of debug
<fsedano>
that trace is gold
<fsedano>
this is interestin
<fsedano>
[SCPISocketTransport::SendCommand] Sending SING