azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/Β±1]
<_whitenotifier-3> [scopehal] azonenberg 22d4e03 - Waterfall: don't discard frequency bins that aren't at an integer pixel position. Fixes #472.
<_whitenotifier-3> [scopehal] azonenberg closed issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel -
<azonenberg> Sooo I'm working on, data file path resolution
<azonenberg> Search paths:
<azonenberg> /ceph/fast/home/azonenberg/code/scopehal-apps/lib/scopeprotocols
<azonenberg> /ceph/fast/home/azonenberg/code/scopehal-apps/src/glscopeclient
<azonenberg> /home/azonenberg/.glscopeclient
<azonenberg> /home/azonenberg/.scopehal
<azonenberg> /usr/local/share/glscopeclient
<azonenberg> /usr/local/share/scopehal
<azonenberg> /usr/share/scopehal
<azonenberg> /usr/share/glscopeclient
<azonenberg> Does this look like a reasonable set of search paths for POSIX platforms? first two are relative to the source directory at compile time
<azonenberg> then the user's home dir, then system paths
<azonenberg> Also, windows folks - what should the system dirs to check be?
<azonenberg> long term we probably want to have the install directory specified in a registry key or something so we can find it?
<d1b2> <Darius> make it easy to change πŸ™‚
<d1b2> <Darius> eg for macports it would be /opt/local/share
<azonenberg> short term this will work for running the windows build from the source directory
<azonenberg> Darius: it's a vector<string> that the data file search functions will go through
<azonenberg> You can add new entries to it at run time but this is the stock list initialized at startup
<d1b2> <Darius> I mean it should be something that can be configured at compile time
<d1b2> <Darius> eg a configure arg (or cmake or whatever you build with)
<azonenberg> i'll add that one, although we're a ways from being able to build and run on OSX because of opengl issues
<azonenberg> And a compile time addition wouldnt be hard to do, but is a bit more work
<azonenberg> short term i'm trying to get rid of the chdir glscopeclient does at startup so that relative paths work
<azonenberg> and work towards proper packaging for v0.1
<d1b2> <Darius> OK
<azonenberg> in fact i would say packaging is probably the #1 pending to-do item for v0.1
<d1b2> <Darius> the deprecation of OpenGL by Apple is highly annoying πŸ˜•
<d1b2> <Darius> There is MetalANGLE but that only gets you GL ES
<xzcvczx> does gl es vsomething-or-other not have the required extensions?
<monochroma> yeah we need compute shaders and such
<d1b2> <Darius> I think the latest ES can do it
<d1b2> <Darius> but the Metal backend for ANGLE only does ES2 so..
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/Β±6]
<_whitenotifier-3> [scopehal] azonenberg 5f491c4 - Added proper path searching for data files. Fixes #392.
<_whitenotifier-3> [scopehal] azonenberg closed issue #392: Proper path resolution for data files -
<xzcvczx> o_O
<xzcvczx> that was much quicker than i expected
<xzcvczx> any reason for macport support but ignoring brew?
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/Β±6]
<_whitenotifier-3> [scopehal-apps] azonenberg 3725e50 - Updated submodules
<_whitenotifier-3> [scopehal-apps] azonenberg 05bb70f - Added proper data file path resolution. Removed copying of data files to build directory and chdir to build directory. Fixes #302.
<_whitenotifier-3> [scopehal-apps] azonenberg closed issue #302: Proper path resolution for data files -
<d1b2> <Darius> I thought Brew installed in /usr/local
<azonenberg> xzcvczx: i dont know anything about osx, i put that directory in at darius's request
<d1b2> <Darius> that was in the list
<azonenberg> It wont run on mac yet, or at least glscopeclient won't
<azonenberg> I would be interested to see if headless libscopehal code will
<azonenberg> i have no reason to believe it would have problems
<azonenberg> so ATE-type code on osx should work now
<xzcvczx> whats the problem on mac? just the opengl stuff?
<azonenberg> Yeah
<d1b2> <Darius> I could try building it
<azonenberg> We need GL 4.2 plus a bunch of extensions including GL_ARB_compute_shader
<azonenberg> latest osx gl drivers i know of are 3.3
<xzcvczx> i assume a couple of the bsd fixes might be needed too
<azonenberg> But really, nobody has ever tried building on osx because we know it won't run
<azonenberg> so it would not surprise me if there's more issues :p
<xzcvczx> darius: i assume that Socket.cpp, UART.cpp will be the main issues you run into
<d1b2> <Darius> wonders how to build
<azonenberg> Long term it would be great if we had OpenCL and compute shader renderers so it could run on older GL as long as you had an OpenCL implementation available
<xzcvczx> neither of which is a particularly hard fix
<azonenberg> And it would be great if we had CUDA and OpenCL builds of all the accelerated filters and ffts
<azonenberg> But again, manpower issues - there's only one me
<azonenberg> and not enough other people contributing to that part of the code yet
<azonenberg> I do have a friend who is getting a m1 mac in the near future so i might bug her to try and work on porting there :p
<d1b2> <Darius> heh
<xzcvczx> do you know what gen of intel igpu that opencl actually got good?
<azonenberg> but basically all the compute shaders will have to be rewritten
<azonenberg> I have not tested opencl on an igpu yet
<azonenberg> only on my nvidia cards
<xzcvczx> oh ok
<azonenberg> It might work, i wouldnt know
<azonenberg> Insufficient time and resources to test :
<d1b2> <Darius> wonders what cmake is smoking
<d1b2> <Darius> -- Could NOT find Boost (missing: program_options) (found suitable version "1.71.0", minimum required is "1.33.0")
<d1b2> <Darius> 1.71.0 > 1.33.0 πŸ˜•
<d1b2> <Darius> also this code is a bit funky:
<d1b2> <Darius> if( &envelope == NULL )
<azonenberg> ok, that's done... next on the agenda is WAV import which will hopefully be fairly quick
<GenTooMan> That's what they always says...
<xzcvczx> what about mp3 import mp3 is now patent free so surely its better than wav being nice and compressed and all
<azonenberg> lol
<azonenberg> you can convert mp3 to wav if you really want
<azonenberg> but the intended use case here is cheap sound card "oscilloscopes"
<xzcvczx> i was trying to use audacity before you gave me the wonders of glscopeclient so head to deal with it as wavs there
<xzcvczx> s/head/had/
<d1b2> <Darius> hmm I am having some trouble with ffts
<d1b2> <Darius> had to modify to add the include dir but now it's complaining about double_t
<xzcvczx> darius: sse3?
<xzcvczx> oh ok
<xzcvczx> nvm then
<d1b2> <Darius> ffts_trig.c:884:11: error: unknown type name 'double_t'; did you mean 'double'? const double_t *FFTS_RESTRICT hs;
<d1b2> <Darius> changing to ffts_double_t worked..
<xzcvczx> you using stable ffts or master?
<d1b2> <Darius> oh master..
<xzcvczx> odd i didn't run into that on bsd
<d1b2> <Darius> I just cloned and tried to build it
<azonenberg> At some point we're probably going to end up repackaging ffts and maybe even updating it for AVX
<azonenberg> it seems to have been largely abandoned
<azonenberg> but there arent a lot of good non-GPL fft libraries
<xzcvczx> darius: are you using cmake or ./confogure?
<xzcvczx> i assume configure due to am
<xzcvczx> the scopehal-apps repo recommends cmake
<xzcvczx> but that was broken for me on bsd
<d1b2> <Darius> oh I am using configure
<d1b2> <Darius> didn't realise it had cmake
<d1b2> <Darius> ahh that works πŸ™‚
<xzcvczx> did it moan about sse3 for you?
<d1b2> <Darius> no
<d1b2> <Darius> [ 0%] Building CXX object lib/graphwidget/CMakeFiles/graphwidget.dir/Graph.cpp.o clang: error: unsupported option '-fopenmp'
<d1b2> <Darius> lolz
<xzcvczx> you will also want to disable tests if you have catch2 installed
<xzcvczx> hmmm odd i didn't get that
<d1b2> <Darius> how do I disable the tests?
<xzcvczx> oh are you up to scopehall-apps now?
<d1b2> <Darius> ys
<xzcvczx> cmake -L ../ <rest of args you want to pass it>
<d1b2> <Darius> OK
<xzcvczx> and it will show you the -DDISABLE_TESTING=OFF i think it is
<d1b2> <Darius> clang does not grok -Wunsafe-loop-optimizations either so I removed it from teh args
<d1b2> <Darius> but you might want to test for it with cmake
<xzcvczx> that was only a warning for me so i ignored it
<d1b2> <Darius> although clang just emits a warning
<xzcvczx> touche
<xzcvczx> darius: if you cant be bothered modifying socket.cpp and uart.cpp yourself let me know and i will get the mods i needed for it
<xzcvczx> as i will be very surprised if you dont need them
<xzcvczx> and filesystem.cpp
<azonenberg> We've only tested building on gcc, so i'd be interested to hear how clang handles it in general
<azonenberg> they're normally fairly compatible
<d1b2> <Darius> I fixed soket already
<d1b2> <Darius> that wa replacing #ifdef WIN32 with #ifdef TCP_QUICKACK
<xzcvczx> azonenberg: i will dump a build log at some point
<d1b2> <Darius> uart is a bit harder
<xzcvczx> just change termios2 for termios
<d1b2> <Darius> I dunno what asm/termios.h is for
<d1b2> <Darius> OK
<d1b2> <Darius> that was my next question
<xzcvczx> and asm/termios.h for termios.h
<xzcvczx> and remove | BOTHER
<xzcvczx> and i changed the ioctls for tcgetattr/tcsetattr
<xzcvczx> the TCGETS2/TCSETS2 ioctls
<xzcvczx> one of each
<d1b2> <Darius> OK
<d1b2> <Darius> what is the 2 stuff about though?
<xzcvczx> custom bauds
<xzcvczx> which bsd/mac does anywyas
<xzcvczx> does/supports
<d1b2> <Darius> yeah you can call cfsetspeed I think
<xzcvczx> nah the baud rate defines are just stored as numbers so you can specify any value you want
<xzcvczx> yo udont need to go through the api
<xzcvczx> aka B38400 is just integer value 38400
<d1b2> <Darius> right
<d1b2> <Darius> /Users/oconnd1/projects/scopehal-apps/lib/scopehal/scopehal.h:63:10: fatal error: 'CL/cl2.hpp' file not found
<d1b2> <Darius> what's that part of?
<xzcvczx> opencl is a clusterfuck on macos
<xzcvczx> i never got it working so gave up
<d1b2> <Darius> ah right
<d1b2> <Darius> probably need to specify the framework
<xzcvczx> can't help ya there sorry
<GenTooMan> mp3 is not patent free ogg vorbis is also mp3 uses psycho acustic compression so it is extremely lossy.
<GenTooMan> I suggest FLAC
<xzcvczx> GenTooMan: the patents i think have expired though
<GenTooMan> xzcvczx, you want to loose your waveform put it into an MP3 ...
<xzcvczx> why not alac :)
<xzcvczx> then it can be drm'd :)
<GenTooMan> xzcvczx, DRM - Digitally Ridiculously Managed.
<d1b2> <Darius> looks like OSX doesn't have OpenCL bindings for C++ πŸ˜•
<xzcvczx> haha that doesn't really surprise me
<azonenberg> what? those are khronos standard afaik
<azonenberg> GenTooMan: I'm only supporting wav, users with sound card data in other formats can convert it
<xzcvczx> azonenberg: apple is amazing at following standards
<xzcvczx> #opengl #vulkan
<GenTooMan> xzcvczx, right like "That's a standard" "yarp" "ok lets walk behind it at a distance"
<xzcvczx> reminds me of
<d1b2> <Darius> they have C bindings at least
<xzcvczx> you just gonna def out all the cl stuff?
<azonenberg> You should be able to just detect no opencl at cmake time
<azonenberg> it's already optional
<azonenberg> the problem is that the cl detection assumes having opencl at all implies having C++ bindings for it
<azonenberg> so we need to fix that
<xzcvczx> yeah i will try and work out what it is thats demanding avx today
<xzcvczx> at buildtime
<d1b2> <Darius> oh hmm, I thought it needed opencl so I gave up πŸ™‚
<azonenberg> darius: no, the opencl SDK is detected at build time and only enabled at run time if you have a compatible GPU. AVX2/AVX512 support is required in the compiler until we add ifdefs for non-x86, but again only enabled at run time if supported
<d1b2> <Darius> OK
<azonenberg> the main hard system requirement is opengl 4.2 plus compute shaders
<azonenberg> which on a non-braindead OS means "any GPU made in the past 10ish years"
<azonenberg> but apple is apple :p
<xzcvczx> intel igpu back to ivy bridge
<d1b2> <Darius> how do I disable opencl?
<xzcvczx> azonenberg: so windows is braindead OS? :P
<azonenberg> xzcvczx: windows supports opengl 4 on almost all compatible hardware
<azonenberg> the one difference between windows and linux support is really old intel igpus, i think windows only supports gl4 in intel drivers starting around haswell or broadwell?
<GenTooMan> I thought it support OGL4 through an emulation layer.
<xzcvczx> but i *think* a few of the older intel igpus only get compute shaders under mesa on linux/bsd
<azonenberg> Correct
<azonenberg> that is the only different i'm aware of
<azonenberg> any nvidia or amd card that does gl4 on linux will work just fine on windows
<xzcvczx> then again windows must be braindead seeing as its not even posix
<azonenberg> well thats a different issue :p
<xzcvczx> i am rather surprised a lot of hte userland bsd code has become a whole lot cooler than its linux equivalent, i would have figured it would be the opposite
<xzcvczx> like cmp is soooo much better on bsd...... hex ftw f*** octal and decimal
<azonenberg> i mean i'm used to linux file modes at this point, it barely even registers that the numbers are actually octal
<d1b2> <Darius> BSD has SIGINFO, so nice πŸ™‚
<xzcvczx> azonenberg: nah cmp compares files, gives differences in octal and offsets in decimal
<xzcvczx> with a 1 index
<azonenberg> wuut
<azonenberg> i've never used it
<xzcvczx> bsd offers an option to 0 indexed hex everywhere
<xzcvczx> on linux you need a damn ugly awk thing to fix it
<d1b2> <Darius> how do I tell cmake to not use OpenCL?
<d1b2> <Darius> or should I just hack up CMakeLists.txt to not look for it?
<azonenberg> darius: There's currently no way to opt out at compile time
<azonenberg> if it sees it, it will try to use it
<d1b2> <Darius> OK
<azonenberg> The bug is that FindPackage(OpenCL) doesnt understand we need C++ bindings
<azonenberg> comment out that line and it should avoid trying to use it
<d1b2> <Darius> OK I just hacked it out for now
<azonenberg> Let me file a ticket for that so we dont forget
<xzcvczx> maybe just do a sanity check for CL2.hpp or whatever it is
<_whitenotifier-3> [scopehal-apps] azonenberg opened issue #341: FindPackage(OpenCL) reports found even if no C++ bindings installed -
<azonenberg> I tagged that as v0.2 for now, it's not critical for v0.1
<azonenberg> but again, feel free to work on it sooner
<xzcvczx> i am still surprised it ran on bsd
<xzcvczx> (on this machine)
<azonenberg> the version milestones are really for a) me to figure out how close we are to being able to release something and b) so people interested in helping with the release can focus efforts on stuff blocking it
<azonenberg> nothing stops you from working on untagged or later-version tickets
<azonenberg> also for the apple folks (darius, lain, anybody else): scroll down to "OpenGL 4.1"
<azonenberg> so it seems that apple actually updated the M1 GPU so now it.s 4.1 rather than 3.3
<azonenberg> it does not have GL_ARB_compute_shader but it's a lot closer to what we need
<azonenberg> And the M1 supports compute shaders in Metal
<azonenberg> So it's architecturally possible, there's just no driver support for it
<xzcvczx> how different is the metal implementation?
<azonenberg> A full metal backend would be difficult, among other things there's no equivalent of GtkGlArea for metal accelerated rendering in GTK
<azonenberg> that's one of the reasons i didnt use vulkan
<xzcvczx> ah the wonders of gtk
<xzcvczx> its really rather limited in crossplatform
<azonenberg> GTK is very good for cross platform, it just can't do a lot of super advanced stuff yet
<azonenberg> apparently GTK4 has more vulkan support though
<azonenberg> So when we migrate to GTK4 we can look at the potential of switching rendering to vulkan if that looks like an improvement
<xzcvczx> there is also ?moltenvk? for macos
<azonenberg> Near term, i think the best route for getting it working on mac is to make an alternate version of the compute shaders in OpenCL
<azonenberg> then use OpenCL to render waveforms to bitmaps
<azonenberg> Then use the existing OpenGL renderer otherwise unmodified
<d1b2> <Darius> I have an intel MBP, no M1 [yet]
<xzcvczx> azonenberg: btw does gtk not provide standard path crap?
<azonenberg> Not to my knowledge... why would it? it's not a full app framework, it's a gui library
<xzcvczx> hmm i still thought it did
<azonenberg> qt wants to own everything, they even have their own string class
<xzcvczx> as it needs ot know about ~/.config and blah blah blah
<azonenberg> well ok it does some stuff internally
<azonenberg> but i dont think it has any externally visible stuff for end user data file location
<d1b2> <Darius> might be a glib thing rather than gtk
<xzcvczx> yeah but i thought it presented that
<xzcvczx> ah yeah you right
<xzcvczx> thanks darius
<d1b2> <Darius> BTW it doesn't seem to check for libomp
<azonenberg> darius: on any linux platform we've tested, i'm pretty sure openmp is part of the gcc installation so you can't not have it
<azonenberg> it's like testing for libm
<azonenberg> or libpthread
<d1b2> <Darius> apparently not..
<d1b2> <Darius> I installed
<azonenberg> but feel free to file a ticket and/or send a PR for detecting openmp
<xzcvczx> azonenberg: hes probably using clang not gcc
<d1b2> <Darius> yeah I am using clang
<d1b2> <Darius> I could use GCC
<azonenberg> Any issues building with clang should also be filed as separate tickets
<d1b2> <Darius> currently stuck on this one -
<xzcvczx> odd i didnt get that
<xzcvczx> which clang?
<d1b2> <Darius> Apple clang version 12.0.5 (clang-1205.0.22.9) Target: x86_64-apple-darwin20.4.0
Degi_ has joined #scopehal
<d1b2> <Darius> I'll try with GCC 9 (with MP support)
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<d1b2> <Darius> possibly my glib is too old
* xzcvczx is sorta glad he left macos before the cluster that is macos 11
<d1b2> <Darius> meh
<d1b2> <Darius> doesn't seem much better or worse than other things, just different
<xzcvczx> well i stayed on the last version to support 32bit as i still had a few things that needed 32bit
<xzcvczx> and used homebrew rather than macports
<xzcvczx> but homebrew has rather gone to crap recently
<d1b2> <Darius> bummer
<d1b2> <Darius> WRT checking for libomp - perhaps it should check the compiler has MP support?
<d1b2> <Darius> cmake has FindOpenMP
<_whitenotifier-3> [scopehal-apps] DanielO opened issue #342: Compiler should be checked if it is built for OpenMP -
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/Β±2]
<_whitenotifier-3> [scopehal-apps] azonenberg 096f6c1 - Added some comments to top level CMakeLists
<_whitenotifier-3> [scopehal-apps] azonenberg 055b19d - Verify compiler supports OpenMP at configure time. Fixes #342.
<_whitenotifier-3> [scopehal-apps] azonenberg closed issue #342: Compiler should be checked if it is built for OpenMP -
<azonenberg> darius: can you confirm that works?
<d1b2> <Darius> @azonenberg OK I tested it and it does barf correctly, thanks πŸ™‚
<d1b2> <Darius> (and doesn't barf when using gcc-mp-9)
<xzcvczx> is marcan the friend you mentioned earlier azonenberg?
<azonenberg> xzcvczx: No
<azonenberg> although if marcan wants to work on glscopeclient stuff too i won't object
<azonenberg> pretty sure he's got his hands full at the moment though
<xzcvczx> fair enough
Tost has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/Β±2]
<_whitenotifier-3> [scopehal] azonenberg 4c3a723 - Initial version of WAV file import. Fixes #226.
<_whitenotifier-3> [scopehal] azonenberg closed issue #226: WAV file import -
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/Β±4]
<_whitenotifier-3> [scopehal-apps] azonenberg f76ec02 - Refactored import code so common code was in a function instead of replicated. Added WAV import support.
<_whitenotifier-3> [scopehal] azonenberg opened issue #473: Add ALSA driver -
<_whitenotifier-3> [scopehal] azonenberg labeled issue #473: Add ALSA driver -
<_whitenotifier-3> [scopehal-apps] azonenberg commented on issue #234: Allow adding a new instrument to an existing session -
<azonenberg> Bird|ghosted: around?
<Bird|ghosted> azonenberg, was snoring, am around, what's up?
<azonenberg> Bird|ghosted: you were helping out with some build stuff on scopehal a while back
<azonenberg> Any interest in getting back to that? i finished the data file resolution code
<azonenberg> so in theory it should be possible to make "make install" and binary packaging work now
<Bird|ghosted> I might be able to, we'll see how much of a bite things take out of me these days
bvernoux has joined #scopehal
<bvernoux> just for information latest trunk => src/glscopeclient/OscilloscopeWindow.cpp => void OscilloscopeWindow::PopulateToolbar()
<bvernoux> base_path is broken on Windows (I think also on Linux)
<bvernoux> so no icons are displayed
<azonenberg> It works fine on my linux systems
<azonenberg> FindDataFile() is probably giving wrong results on Windows?
<bvernoux> yes
<bvernoux> base_path = base_path.substr(0, base_path.length() - testfname.length());
<bvernoux> does not work like expected
<bvernoux> I have traced
<bvernoux> FindDataFile() icons base_path before: "/fullscreen-enter.png"
<bvernoux> FindDataFile() icons base_path after: "/"
<bvernoux> in source
<bvernoux> string base_path = FindDataFile("icons/" + to_string(size) + "x" + to_string(size)) + "/" + testfname;
<bvernoux> base_path = base_path.substr(0, base_path.length() - testfname.length());
<bvernoux> LogWarning("FindDataFile() icons base_path after: \"%s\"\n", base_path.c_str());
<bvernoux> LogWarning("FindDataFile() icons base_path before: \"%s\"\n", base_path.c_str());
<azonenberg> FindDataFile() should return an absolute path
<azonenberg> to the icon
<bvernoux> yes it fail
<azonenberg> So OscilloscopeWindow.cpp isnt the problem
<bvernoux> in fact for default install it shall find in current directory
<bvernoux> I think it is the best for Portable Install
<bvernoux> to have all in same dir
<bvernoux> as it is not a good practice to install files in System or Program Files
<azonenberg> um, what?
<azonenberg> all of these data files should be under program files in a full installation
<bvernoux> yes the actual code for path is wrong with hard coded path
<azonenberg> they're never written once it's created
<bvernoux> before it was working as it worked in current directory
<azonenberg> Have a look in scopehal.cpp:644 and so
<azonenberg> InitializeSearchPaths() should search in the current source directory at compile time
<azonenberg> and bake that path into the binary as the first search path
<bvernoux> yes the new searchpath is not working on Windows
<bvernoux> I'm checking to add things
<azonenberg> Look in the generated config.h
<azonenberg> what is SRC_DIR?
<bvernoux> by default there shall have a rule to check in current dir
<bvernoux> and not SRC_DIR ...
<azonenberg> We removed the chdir
<azonenberg> because it breaks relative paths
<bvernoux> I have added g_searchPaths.push_back(".");
<bvernoux> but it does not work for icons
<azonenberg> Don't bandaid it, figure out the root cause
<azonenberg> Why is it not finding the files in the source dir?
<bvernoux> yes i'm trying to figure out why only icons fail ;)
<bvernoux> it works for shader dir
<bvernoux> example of trace I have added
<bvernoux> ReadDataFile: "./shaders/waveform-compute-head.glsl" fp=-42849520
<bvernoux> so FP is ok
<bvernoux> issue for icons
<bvernoux> FindDataFile: "./icons/48x48" fp=0
<bvernoux> of course 48x48 is a dir
<bvernoux> so fopen return 0
<bvernoux> it is probably the issue here on Windows
<azonenberg> It's not supposed to be searching icons/48x48
<azonenberg> ... oh
<bvernoux> it does following search
<bvernoux> FindDataFile: "./icons/48x48" fp=0
<bvernoux> FindDataFile: "C:/msys64/home/Ben/glscopeclient_build_release/icons/48x48" fp=0
<bvernoux> FindDataFile: "C:/msys64/home/Ben/scopehal-apps/lib/scopeprotocols/icons/48x48" fp=0
<bvernoux> FindDataFile: "C:/msys64/home/Ben/scopehal-apps/src/glscopeclient/icons/48x48" fp=0
<azonenberg> ok yeah 365 is the bug
<azonenberg> Parentheses is too early
<azonenberg> sec
<bvernoux> I have added that
<bvernoux> void InitializeSearchPaths()
<bvernoux> #ifdef _WIN32
<bvernoux> g_searchPaths.push_back("C:/msys64/home/Ben/glscopeclient_build_release");
<bvernoux> {
<bvernoux> g_searchPaths.push_back(".");
<bvernoux> #endif
<azonenberg> No, delete that
<bvernoux> it was for test ;)
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/Β±1]
<_whitenotifier-3> [scopehal-apps] azonenberg fffbd4a - OscilloscopeWindow: fixed typo in path resolution
<azonenberg> Try that
<bvernoux> the aim is to add nothing and it shall search in current path of where the exe is started correct ?
<bvernoux> example when I build glscopeclient I have a new dir
<bvernoux> glscopeclient_build_release
<bvernoux> I copy in it glscopeclient.exe with dll ...
<azonenberg> No
<azonenberg> It will search in the directory you compiled it
<azonenberg> the source directory
<bvernoux> and the directories icons, gradients, masks, shaders, styles
<azonenberg> you dont have to copy anything
<azonenberg> as long as you don't move the source code it will work
<bvernoux> I simulate a root dir with glscopeclient.exe and dependencies
<azonenberg> Longer term the windows packaging will include an installer that sets a registry key to point to the install dir
<azonenberg> so it can find the data under program files
<azonenberg> it will probably also look under %appdata%/glscopeclient or similar
<bvernoux> the aim is to build a directory with exe and files like a PortableApp
<bvernoux> without any path dependencies
<bvernoux> I think it is better to avoid such RegEdit cheat
<bvernoux> and think about current dir for install
<azonenberg> The directory of the executable is not the same as the current working directory
<bvernoux> like that it can be like a PortabeApps and can be also installed in Program Files ....
<bvernoux> for me it is
<azonenberg> yeah but you cant assume that
<bvernoux> why ?
<azonenberg> But we can have it check the executable dir on windows. On POSIX unless you go in /opt the data is rarely near the binaries
<bvernoux> yes but posix is not standard
<bvernoux> MACOS work like that too
<bvernoux> only Linux want cheat everywhere ;)
<bvernoux> opt or other path ... which i clearly do not like as when you want to remove an app you have files which will be never deleted
<azonenberg> ISO and IEEE would disagree with you re posix not being standard :p
<bvernoux> in case of all in same dir you remove the dir and all is removed you do not have some parts somewhere in System ...
<azonenberg> The only things i've found that install stuff under opt are proprietary software that doesn't integrate with distribution package managers
<azonenberg> you're not supposed to just randomly delete files, you're supposed to uninstall the package
<d1b2> <zyp> that can be the same thing πŸ™‚
<bvernoux> I'm ok with custom install like that
<azonenberg> Distros will not accept that in their repositories
<azonenberg> They expect you to install things in the standard locations
<bvernoux> but I think we shall support by default "PortableApp" current dir search of dir/files
<bvernoux> which can work on Linux too
<azonenberg> If you want to do that on windows, sure. you can pull the code from src/glscopeclient/main.cpp a few commits back that finds the binary dir
<bvernoux> if you unarchive all in a dir as you want to check a new version without replacing the stable ones installed in opt ...
<d1b2> <zyp> I'm a fan of macos' app bundles -- the whole thing comes as a bundle that you can run as is or Β«installΒ» by copying it to /Applications
<d1b2> <zyp> and uninstalling is then a matter of deleting the bundle from /Applications
<bvernoux> yes like zyp say it is the point to keep that simple for any OS ;)
<bvernoux> archive with everything you extract and it run from the dir without install
<d1b2> <zyp> I disagree there
<bvernoux> like it is natively done on MacOS
<bvernoux> and have option to do the "crappy" posix install in opt lib .... ;)
<d1b2> <zyp> while I prefer the macos way, that's only suitable on macos
<azonenberg> anyway, it doesnt run on osx
<azonenberg> so let's ignore osx and focus on getting windows and linux packaging working soonish :p
<azonenberg> My top priority is a working debian package that installs to standard distro locations
<azonenberg> second priority is a windows install exe that sticks it in program files
<bvernoux> yes here the idea is just to support basic current dir execution with dependencies (dir) in same place as exe
<azonenberg> third is packaging for other distros like arch and redhat based
<d1b2> <zyp> that sounds reasonable to me
<azonenberg> as a minimum debian and windows packaging are on my v0.1 requirements list
<bvernoux> you can check other project like sdrpp
<bvernoux> all is done like that
<bvernoux> just an archive you extract and it runs from dir without install by default
<bvernoux> and it works on MacOS, Windows and Linux
<bvernoux> you can easily test and package like that and huge advantage is you can have different version at same time
<azonenberg> That's why the source code directory is the first search location
<bvernoux> It is why I push this warning now
<azonenberg> so your dev version takes precedence
<bvernoux> no
<bvernoux> the exe shall not check src dir
<bvernoux> it shall be independant
<bvernoux> Let see how I do my package
<bvernoux> cd ~
<bvernoux> cd ./scopehal-apps/build
<bvernoux> cp C:/msys64/mingw64/bin/libstdc++-6.dll ~/glscopeclient_build_release/
<bvernoux> mkdir glscopeclient_build_release
<bvernoux> cp ./src/glscopeclient/glscopeclient.exe ~/glscopeclient_build_release/
<bvernoux> cp -r ../src/glscopeclient/gradients ~/glscopeclient_build_release/
<bvernoux> cp -r ../src/glscopeclient/icons ~/glscopeclient_build_release/
<bvernoux> cp -r ../src/glscopeclient/masks ~/glscopeclient_build_release/
<bvernoux> cp -r ../src/glscopeclient/shaders ~/glscopeclient_build_release/
<bvernoux> cp -r ../src/glscopeclient/styles ~/glscopeclient_build_release/
<bvernoux> cp ./lib/graphwidget/libgraphwidget.dll ~/glscopeclient_build_release/
<bvernoux> cp ./lib/log/liblog.dll ~/glscopeclient_build_release/
<bvernoux> cp ./lib/scopehal/libscopehal.dll ~/glscopeclient_build_release/
<bvernoux> cp ./lib/scopeprotocols/libscopeprotocols.dll ~/glscopeclient_build_release/
<d1b2> <zyp> as long as the src dir reference is relative so it still works if it's moved without being rebuilt, that sounds reasonable to me
<bvernoux> I do the same for build_debug in an other directory ...
<bvernoux> and I can test multiple version in //
<azonenberg> zyp: the source dir reference is absolute
<azonenberg> it's literally ${CMAKE_SOURCE_DIR}
<bvernoux> for me the final build dir shall be independant like in my "packaging" script
<azonenberg> the idea being that in the source tree, data files arent next to the binary
<azonenberg> and the executable directory could be anywhere since cmake does out of tree builds
<azonenberg> but you know where the data files are relative to the source dir
<bvernoux> yes to package it
<bvernoux> but for execution you shall not have dependencies on src...
<azonenberg> The source dir check has to be ahead of system directories because you dont want to use the system-wide install when developing
<d1b2> <zyp> have you considered just copying the data files to the build dir?
<azonenberg> We did that before, then chdir'd to the build dir
<azonenberg> that broke opening files by relative paths
<azonenberg> i guess what we could do instead is go back to copying files to the build dir
<azonenberg> but have path resolution search dirof self
<azonenberg> rather than the source dir
<d1b2> <zyp> yes
<azonenberg> then if not found start searching system dirs
<azonenberg> We have all of the code for that a few commits back
<azonenberg> shouldnt be too hard to set up
<bvernoux> yes exactly
<bvernoux> support self and other system dirs in 2nd steps ...
<bvernoux> liek that it is compatible with both world ;)
<bvernoux> like
<bvernoux> simple package relative or installation in system opt ...
<bvernoux> azonenberg, it is ok ?
<bvernoux> I think it is the best for everyone (not just me)
<bvernoux> especially for nightly build it is very easy to package like that without doing an installer ...
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/Β±2]
<_whitenotifier-3> [scopehal] azonenberg b686bf8 - Changed search paths to include bin dir instead of source dir
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/Β±2]
<_whitenotifier-3> [scopehal-apps] azonenberg aea1fd3 - Re-added copying of resources to build directory since new path resolution requires that
<azonenberg> How's that work on windows?
<bvernoux> as of today i have all files in the same directory
<bvernoux> I keep directories of course
<azonenberg> no i mean does the latest version work for you? and find icons?
<bvernoux> I have just uploaded my package version to show you what I'm doing
<bvernoux> let me update with your code
<bvernoux> the issue was only with icons in fact
<azonenberg> yeah that was a separate problem
<azonenberg> there was a misplaced parenthesis and it searched for the wrong path
<azonenberg> on posix it worked as fopen on a directory succeeds
<azonenberg> which hid the bug
<bvernoux> yes the code seems good like that let me test it
<bvernoux> yes it was just to clarify that for future
<bvernoux> to keep in mind it is a good stuff to keep a simple current dir (PortableApps style) for nightly build ...
<bvernoux> You can check the expected result for nightly build package here
<bvernoux> with my how to build and create it in msys2 mingw64
<bvernoux> woo I have never checked but libscopeprotocols.dll and libscopehal.dll are huge ;)
<monochroma> (is there an advantage to mingw etc, now that WSL can display graphics, or are we still stuck with opengl issues there?)
<azonenberg> Yeah they're not small
<azonenberg> monochroma: it produces native windows binaries afaik
<azonenberg> that we can package normally
<bvernoux> msys2 mingw64 is very easy to build native Windows things
<balrog> azonenberg: first problem:
<bvernoux> and it is not for tomorrow that WSL2 will work with OpenGL+GUI with Linux bin ;)
<balrog> would have to turn off intrinsics
<azonenberg> balrog: Yeah we're a ways from having a usable system on arm
<azonenberg> long term i might have to write my own optimized fft library / fork ffts
<bvernoux> for information I have fixed scopehal-pico-bridge to build for Windows ;)
<bvernoux> with things "merged" for Pico3000A from noopwafel
<bvernoux> it is a but a mess as noopwafel and actual scopehal-pico-bridge are not synchronized
<azonenberg> Well it should clean up soon
<azonenberg> i'm working on my digital channel support too
<azonenberg> hopefully that will be done in a day or two
<bvernoux> I confirm your fix is fine great
<bvernoux> I have just pushed latest version here
<bvernoux> Upload in progress
<bvernoux> realtime spectrogram is fun ;)
<bvernoux> it is very smooth and stable
<bvernoux> I'm playing with latest version with Demo ;)
<bvernoux> Doing FFT on the Ramp signal ;)
<bvernoux> scaling in FFT is very nice and intuitive
<balrog> azonenberg: looks like most of the "good" fft libs out there are GPL
<ericonr> ?
<ericonr> or is it not "good"?
<azonenberg> ericonr: It's GPL
<azonenberg> That's the problem, scopehal and glscopeclient are permissively licensed to allow interop with commercial tooling
<azonenberg> so any GPL is out of the question
<azonenberg> LGPL is OK as long as dynamically linked
<azonenberg> FFTS was the only suitably licensed fft lib i was able to find. I may have to write one
<azonenberg> and/or do a major updating of ffts for AVX and ARM64
<ericonr> ah, this is what I get for skimming
<ericonr> The FFTW package was developed at MIT by Matteo Frigo and Steven G. Johnson.
<ericonr> I saw MIT and thought it was the license
<ericonr> > We could instead have released FFTW under the LGPL, or even disallowed non-Free usage. Suffice it to say, however, that MIT owns the copyright to FFTW and they only let us GPL it because we convinced them that it would neither affect their licensing revenue nor irritate existing licensees.
<ericonr> ouch :/
<ericonr> is BSD, at least... FFTS (if you meant seems kinda dead
<azonenberg> Yes, I mean FFTS
<azonenberg> it was the least bad non-GPL FFT library i could find
<azonenberg> And it's generally abandonware
<azonenberg> it still works fine, but has not been updated for modern intel CPUs with AVX/AVX2/AVX512 instructions so it could probably be made massively faster
<ericonr> an avx512 backend would seem overkill to me
<ericonr> avx2 would probably be worth it, though
<azonenberg> I'd want to do some measurements
<azonenberg> honestly, i think for multimillion point FFTs avx512 would really shine
<azonenberg> that's the kind of big number crunching it was designed fore
<azonenberg> for*
<ericonr> oh, they added avx512 to rocketlake unconditionally
<ericonr> I was considering it overkill because few CPUs would even have it; given that it's a tad more widely available now, it makes a lot of sense :)
<azonenberg> My main workstation is xeon 6144s
<azonenberg> (dual socket)
<azonenberg> and i work with huge data all the time. if it can save me time i'll do it :p
<ericonr> nice
<azonenberg> this suggests FFTW benefited quite substantially from AVX512
<azonenberg> i would expect FFTS would too
<ericonr> azonenberg: I think the only remaining issue with avx512 is that it downclocks the rest of the CPU, so if you're doing other things simultaneously, it can suck a bit :/
<azonenberg> ericonr: Only if you do a lot of avx512 at a time. but even avx2 and other stuff does that, just not as much
<azonenberg> there's actually some fairly complex power/thermal management algorithms in play
<bvernoux> azonenberg, what is the comande line for Pico ?
<bvernoux> I see my build/patch of ps6000d is working on my Pico3406DMSO
<azonenberg> on the glscopeclient side? nickname:pico:lan:localhost:5025
<azonenberg> assuming your bridge is on the same host as you're connecting from
<bvernoux> thanks i have found it
<bvernoux> i was confused as does not work
<bvernoux> and shall be replaced by localhost
<bvernoux> but it work now with localhost
<bvernoux> it works ;)
<bvernoux> working at about 10WFM/s ;)
<bvernoux> even 20
<bvernoux> when I zoom as the issue is definitely on number of points displayed with my GFX card
<bvernoux> with 2Chan 1Mpts it runs at >20WFM/s
<bvernoux> but the limiting factor is clearly my GFX card I need to zoom to speed up WFM ...
<azonenberg> Yeah. I'm going to be working on a less pretty but faster shader soon
<azonenberg> that you can swap out
<azonenberg> or possibly different settings on this one
<azonenberg> but i want to have some speed/render quality tradeoffs
<bvernoux> ha nice
<bvernoux> because her I can reach >40WFM/s if I zoom out
<bvernoux> It is first time I can check that realtime aspect in fact
<bvernoux> as with my Rigol and 1WFM/s it is hard to see such limit ;)
<bvernoux> Anyway it is very good Pico works congratulations !!
<bvernoux> it is quite stable
<bvernoux> I do not understand the frequency ;)
<bvernoux> it seems buggy
<bvernoux> Math->Measurements->Frequency Graphs seems crazy
<bvernoux> even on a Threshold with clean square wave
<azonenberg> You might just be seeing aliasing
<azonenberg> it's a cycle by cycle measurement
<bvernoux> I was expecting to see 5KHz
<azonenberg> You'll actually get better results measuring frequency on the analog waveform
<bvernoux> it is same on analog WFM
<azonenberg> because that will interpolate the zero crossing
<azonenberg> the threshold filter doesnt
<azonenberg> Send me a screenshot?
<bvernoux> it is just basic 5Khz test signal on ChanA & B
<bvernoux> but Frequency show very strange freq
<bvernoux> hmm the same for FFT in fact
<azonenberg> Interesting
<azonenberg> Let me test...
<azonenberg> i was about to say maybe its a regression in the new shaders
<azonenberg> but that's impossible
<azonenberg> the y axis on the graph is wrong too
<azonenberg> ... OH
<azonenberg> Zoom in on the rising edge
<bvernoux> I'm testing latest trunk
<azonenberg> this is a 5 kHz squarewave sampled at 625 Msps
<azonenberg> If you didn't put hysteresis on the threshold filter you're probably getting bounce
<bvernoux> Zoom on Rising edge
<bvernoux> nothing seems crazy here
<azonenberg> And the filter is correctly reporting frequency of the bouncing
<azonenberg> Zoom in more
<azonenberg> I see exactly what i expect to see
<azonenberg> looks like multiple edges
<azonenberg> on the threshold
<azonenberg> The analog frequency filter should probably use some hysteresis by default
<bvernoux> more zoom
<azonenberg> Yeah
<bvernoux> yes it seems it check the little noise
<azonenberg> Look at the threshold
<azonenberg> Put like 50 mV hysteresis on the filter and see if it does what you expect now
<azonenberg> oh the other problem is
<bvernoux> yes digital threshold is badly set
<azonenberg> i looks like you have the threshold really low not the midpoint
<azonenberg> So thats the other problem
<bvernoux> but I take the Freqency of A not Threshold(A)
<azonenberg> Yes, that is... not a bug per se but a not-great design
<azonenberg> in that right now the analog threshold filter doesnt do hsyeresis
<azonenberg> with really slow rising signals it will multi trigger on noise
<azonenberg> Try something with a faster edge, or reducing the scope sample rate a lot
<bvernoux> ha yes because the rising is too slow interesting
<azonenberg> Also the 312 MHz tone in the FFT is noise at nyquist in the LSBs of the signal. again unsurprising
<azonenberg> also BTW not sure if you saw this yet but you can double click the info box on the FFT
<azonenberg> to change the window function, number of peaks it looks for, and minimum spacing for the peak search
<bvernoux> yes
<bvernoux> the issue is not really the FFT
<bvernoux> but more Frequency(A)
<azonenberg> Yeah. That's the really slow edge
<azonenberg> the edge is so slow you have multiple consecutive adc samples with the same value
<azonenberg> then noise causes false triggering
<bvernoux> yes rising edge is 400us
<bvernoux> so for such case we need to filter the signal
<bvernoux> let me check
<azonenberg> Lots of options - you can do a FIR low pass to smooth it out, you can apply a decimation filter, or you can reduce the scope sample rate
<azonenberg> or you can put hysteresis on the threshold filter
<azonenberg> that is probably the simplest
<azonenberg> you want at least a few LSBs worth
<bvernoux> maybe it will be great to have threshold on Frequency() option
<bvernoux> to avoid that
<bvernoux> as there is no parameter in fact
<bvernoux> it is ok with => Frequency(LPF(A, 1 MHz))
<bvernoux> issue is with noise with freq > 100MHz ;)
<bvernoux> LPF(A, 100 MHz) is ok
<azonenberg> default for freq filter on analog is 50% threshold with no hysteresis. yeah its not configured yet
<bvernoux> ha ok that explain all
<bvernoux> so it is not a bug in fact
<bvernoux> do you have some hint to speed up old GFX card shaders ?
<bvernoux> as here I see the limit with 1Mpts and 4 chan for example when zoomed out I think there is too much vertex or something like that
<bvernoux> I do not even speak on test data 100Mpoints ;)
<azonenberg> nothing you can really do short of writing more shader code :p
<bvernoux> other strange things
<bvernoux> the stats are wrong
<bvernoux> Maximum 10.1208 kHz is not on screen
<bvernoux> we see the curve is flat
<bvernoux> it is strange it does not go until end anywa
<bvernoux> it stop at 1ms
<azonenberg> So that's a quirk in the shaders i havent tracked down
<azonenberg> the last few points in the waveform never render
<azonenberg> the frequency plot is hit hard because the points are so far apart
<azonenberg> with fast sample rates you dont notice as much
<azonenberg> It's on my list of bugs to chase
<azonenberg> My guess is, you've got another glitch of some sort on that last rising edge at the very end of the waveform
<azonenberg> and it picks up that partial cycle as being a 10 kHz pulse
<azonenberg> The stats code is super simple, whatever is wrong is probably not the stats
<azonenberg> it's likely that there actually is a 10 kHz not-rendered point in the curve
<bvernoux> yes interesting
<bvernoux> with slow signal with noise we can catch interesting things ;)
<bvernoux> and my GFX card has crashed ;)
<bvernoux> overheat I think
<bvernoux> the Nvidia driver crashed with recovery ;)
<bvernoux> Anyway it is very smooth even on my crappy GFX card ;)
<bvernoux> It is first time it can be used correctly as with Rigol the Rigol SCPI is too slow (so far) to do anything interesting
<azonenberg> yeah rigols are definitely not fast
<azonenberg> what card do you have?
<bvernoux> ontext: OpenGL 4.2 compatibility profile
<bvernoux> GL_VENDOR = NVIDIA Corporation
<bvernoux> GL_SHADING_LANGUAGE_VERSION = 4.20 NVIDIA via Cg compiler
<bvernoux> GL_VERSION = 4.2.0 NVIDIA 425.31
<bvernoux> GL_RENDERER = GeForce GT 650M/PCIe/SSE2
<bvernoux> Initial GL error code = 0
<bvernoux> GL_ARB_gpu_shader_int64 = supported
<bvernoux> the demo works at 20WFM/s
<bvernoux> but I do not see any effect when I zoom in/out as it is not too impacted with 100 kS
<bvernoux> it start to be slowed down with 1M pts
<azonenberg> Yeah. My 2080 Ti handles 1M points just fine. 128M points it only manages about 6 FPS on one waveform
<bvernoux> ha interesting
<bvernoux> how many FPS do you have with Demo ?
<bvernoux> FPS => WFM/s
<bvernoux> I call that FPS ;)
<azonenberg> Not the same thing
<azonenberg> FPS is rendered frames per second, WFM/s is waveforms coming off the scope
<azonenberg> WFM/s can exceed FPS if you have a really slow GPU and they start to back up in the driver code
<azonenberg> FPS can exceed WFM/s if you scroll around between waveforms, or pause the trigger
<bvernoux> yes I know ;)
<bvernoux> it is just WFM/s are linked to FPS with interaction
<azonenberg> I get about 23 WFM/s on the lab box i'm sitting in front of. i think the main workstation is a fair bit faster
<bvernoux> when WFM/s is very slow right click or anything in the UI is also very slow
<bvernoux> ha ok interesting as demo is a bit same speed on your lab box or my PC
<azonenberg> The demo is pretty CPU limited IIRC
<azonenberg> i think i also added some sleeps so it didnt hog too much compute time for no real reason
<azonenberg> But it's totally unoptimized too
<azonenberg> there's no point
<bvernoux> but it is clearly different when there is lot of points especially starting at 1M points zoom out max 4 Chan here
<bvernoux> yes it is why it is interesting to test with a real instrument as it is different than with demo
<bvernoux> I have pushed everything here if some guys are interested to test on Windows Picoscope3000/6000
<noopwafel> no crash yet? :)
<bvernoux> GFX card crash mainly ;)
<bvernoux> because it is old and it overheat ;)
<bvernoux> noopwafel, I have updated your code with latest azonenberg code for PicoBridge for test purpose
<bvernoux> noopwafel, will be interesting to merge it I have not tested the Linux side but it shall always build
<bvernoux> a nice things will be to change memory size ;)
<bvernoux> on Pico it shall be quite fast with 100k especially because my GFX card suxx ;)
<bvernoux> also why not rename dir ps6000d to something like pico-bridge ?
<azonenberg> bvernoux: That's planned
<azonenberg> originally i was going to have a common library and a server for each device family
<bvernoux> yes it is just GUI/option I see it is already managed in the pico-bridge
<bvernoux> yes a good refactor could be done to manage Pico family with switch case when required
<bvernoux> and use common API
<bvernoux> it is a shame Pico have not standardized that a bit more for common function ...
<bvernoux> they could have done basic features with HAL with same API for all Pico
<azonenberg> Yes that would have been a lot nicer
<azonenberg> i'm going to push them to do that in the future
<azonenberg> i've already had some chats with their engineers about various potential improvements
<bvernoux> ha great
<bvernoux> and also doing an open source driver with libusb on their side to avoid blob ;)
<bvernoux> I have asked that to SignalHound too ;)
<bvernoux> I do not know what they want to protect with their closed source API ...
<azonenberg> long term i would like if pico used libscopehal as their official API and provided a libscopehal -> libusb driver
<azonenberg> but we don't yet support all of their features so that isnt possible yet
<bvernoux> yes but it will be nice
<bvernoux> glscopeclient even in actual state is already 1000x better than Picoscope 6 GUI/App ;)
<bvernoux> even if it miss some interesting advanced triggers ;)
<azonenberg> Still need to finish MSO support and a few other things to really be where i want it
<azonenberg> and yes, all of the nice triggers
<bvernoux> yes MSO is clearly a must have for something fully usable
<azonenberg> what i really want is protocol triggers
<azonenberg> for things like 100baseTX
<bvernoux> ha yes it will be amazing
<azonenberg> They dont have that
<azonenberg> but i think the hardware is capable
<bvernoux> or even on UART/SPI...
<azonenberg> would need new fpga firmware
<bvernoux> ha yes to do that in HW (FPGA) will be very nice
<noopwafel> yeah, it would be dreamy to get some more hw triggers
<noopwafel> but just running them in streaming mode might be better than nothing
<azonenberg> Yeah the other thing i want to do with the high update rates on the picoscope is make something along the lines of lecroy wavescan but probably better :p
<azonenberg> to start one thing i would find useful is filtering for waveforms that meet a certain criteria in a decode
<azonenberg> so streaming tens to hundreds of WFM/s and only displaying/saving in history ones with (say) a bad CRC
<azonenberg> I also want to add a software post-trigger feature
<azonenberg> where you can capture waveforms with a simple edge trigger
<azonenberg> but then it will time-shift them based on a decode
<azonenberg> so that a given protocol event happens the same time in each waveform
<azonenberg> so for things like 8b10b that you cant trigger on natively without the scope having a serdes trigger
<azonenberg> being able to have all the frames start at a given cursor position would be nice
juli9611 has joined #scopehal
Tost has quit [Ping timeout: 260 seconds]
Tost has joined #scopehal
bvernoux has quit [Quit: Leaving]
juli9611 has quit [Quit: Nettalk6 -]
Tost has quit [Ping timeout: 240 seconds]