<azonenberg>
debating whether to have my lab tech make them mon/tues as originally planned, or do it myself now :p
<azonenberg>
should probably wait, i have other stuff to do
<Katharina>
azonenberg hi, I'm the person that wrote you on twitter about the windows build
<azonenberg>
o/
<azonenberg>
So are you primarily a windows dev, linux, or both?
<azonenberg>
do you have a linux box handy you can use for testing to see how things are supposed to behave?
<Katharina>
both. Windows professionally, Linux for private stuff
<azonenberg>
Perfect, you're the exact person we needed then
<azonenberg>
i assume you probably have access to a scope you can test on too?
<Katharina>
we have a few at work, yes
<azonenberg>
What models? I guess the first step is to establish a baseline, get glscopeclient compiling on a linux machine and working on your hardware
<azonenberg>
so you have a golden reference to compare to both on "how things should look/act" and to test for regressions
<Katharina>
we have multiple different rigol models, and a few keysight ones. I'll get the exact models when I get back to the office (corona)
<azonenberg>
So the good news is, you can run glscopeclient offline as well
<azonenberg>
i can supply you with some test data to use
<Katharina>
that would be good for the beginning.
<azonenberg>
you won't be able to test porting of the hardware interface code of course, but even getting it to compile on windows will be a good start
<azonenberg>
this isnt an official mirror or anything but i push updates to it decently often. azonenberg/scopehal-docs is the authoritative LaTeX manual source, there is currently no official PDF release
<Katharina>
thats no issue, I do have texlive installed
<Katharina>
I already have been working on getting it to compile on windows since I wrote you on Twitter, and I have selected MSys2/mingw for this. Mainly because it is fully opensource and has a package manager, so documenting the build will be possible
<azonenberg>
this is an 8 channel acquisition across two LeCroy scopes looking at the RX lane of a gigabit Ethernet RGMII bus, complete with protocol decodes already set up
<azonenberg>
just unzip and run "glscopeclient foo.scopesession" to open the file
<azonenberg>
right now if you run glscopeclient with no args it displays a "connect to scope" dialog and there's no UI to open a file
<Katharina>
thanks. that's good to have, might be months until I can get to real hardware again.
<azonenberg>
Even getting a successful compile, and offline analysis, working on windows would be a major step in the right direction
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfNJi
<_whitenotifier-f>
[scopehal-cmake] azonenberg 130ab39 - Updated to latest submodules
<azonenberg>
Longer term, i would love to be able to run glscopeclient natively on more recent Windows based oscilloscopes
<azonenberg>
newer model LeCroy's should be a good candidate in particular
<Katharina>
so to update you on my current progress: the current roadblock is liblxi. It depends on a library called libtirpc which just refuses to compile on windows
<azonenberg>
my current ones have GPUs that don't support OpenGL 4.3 but there are rumors floating around that they will support a mobo upgrade at some point
<azonenberg>
Katharina: I am OK with you adding ifdefs to make some drivers/transports only be enabled if the driver in question is available
<azonenberg>
Having LXI support be linux only to start is not the end of the world
<azonenberg>
i'd like to have scopehal build without liblxi anyway if it's not installed on the system
<azonenberg>
even on linux
<azonenberg>
so if you can just do a check for liblxi at configure time and disable SCPILXITransport if not found, that would enable you to sidestep that
<Katharina>
Good. You answered my question before I wrote it ;) my first goal is to get a build running, no matter how restricted in terms of drivers/transports
<azonenberg>
Correct
<azonenberg>
At that point, i'll be happy to merge a full PR for offline analysis on windows
<azonenberg>
I will also accept PRs for windows portability to specific subsystems earlier, even if it doesnt build having less code to review per PR would be fine
<azonenberg>
my general rule for merging contributions is a) comply with the posted coding policy, b) does not break existing functionality
<azonenberg>
it's OK if you add new incomplete stuff as long as there's no regressions
<Katharina>
kk
<azonenberg>
We're not even at the 1.0 release stage, windows support was one of the things blocking me even considering that
<azonenberg>
along with much more improvements to documentation
<azonenberg>
so i have no qualms about adding new incomplete/broken stuff
<Katharina>
I will look into getting ffts packages for MSys2 to make the build more straight forward
<azonenberg>
e.g. patches to make one class compile on windows even if the rest doesn't
Degi has quit [Ping timeout: 256 seconds]
<Katharina>
azonenberg: do you prefer big PRs, or smaller ones?
Degi has joined #scopehal
<azonenberg>
Katharina: back, sorry. Smaller ones are easier to review if they're spread out, but i'd rather have one big one than several small ones if you're submitting them all at once
<Katharina>
sure. I actually got it to compile now (I had to exclude a few of the drivers), but over a thousand linker errors presented themselves. Need to investigate further
<azonenberg>
Lol
<azonenberg>
well that's progress
<Katharina>
interestingly, linking libscopehal fails since it cant resolve the symbols in libscopeprotocols, so there might be something wrong with the CMake project (in regards to windows)
<azonenberg>
scopehal should not depend on scopeprotocols
<Katharina>
huh interesting, that might be the issue
<azonenberg>
the intention is that scopehal contains generic base classes, device drivers, etc
<azonenberg>
then scopeprotocols has all of the filter graph stuff
<azonenberg>
if there's unintentional dependencies that might be part of the issue
<azonenberg>
glscopeclient itself depends on both, because i have specialized display code for e.g. eye patterns and FFTs, which use data structures defined in scopeprotocols
<azonenberg>
but scopeprotocols should have a one way dependency on scopehal
<Katharina>
sorry, I mixed up the two targets in my previous message, libscopeprotocol is indeed trying to link to symbols in libscopehal, but that always fails
<azonenberg>
Ok
<azonenberg>
That makes a lot more sense at least
<Katharina>
yes
<azonenberg>
scopeprotocols/CMakeLists.txt:71 did you add scopehal there as a dependency?
<azonenberg>
it wasn't there on the linux build because i guess the ELF linker model didn't require the symbols to be resolved at link time since it's a shared library
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has joined #scopehal
<Katharina>
that might be the issue, yes
<azonenberg>
But the PE linker model requires symbols resolved at link time even in libraries
<azonenberg>
since ELF resolves all symbols at load time and there's no explicit binding of which symbol comes from which module
<azonenberg>
I actually like the PE model better for this
<azonenberg>
having each symbol be module!export
<Katharina>
great, that fixed it.
<Katharina>
the PE linker does choke on your logging library because of multiple definitions, thats the last error for now
<azonenberg>
multiple definitions of what?
<Katharina>
`LogError(char const*, ...)'
<azonenberg>
...oh
<azonenberg>
i think i see what's going on
<azonenberg>
liblog is being built statically and you get a copy in each binary
<azonenberg>
liblog should build a shared library and a static, and the scopehal stuff should use the shared version
<Katharina>
great, both libscopehal and libscopeprotocols do compile and link fine now
<azonenberg>
did you fix log already? that was fast
<Katharina>
yes I did
<azonenberg>
Awesome. Can you send me PRs for this work to date then?
<Katharina>
I will ASAP. I made a local copy of the repo because I had problems with the submodules I never encountered with any other git repo before
<azonenberg>
So that's something i need to play with. I think i can fix that
<azonenberg>
do you not have a github ssh key on this machine?
<azonenberg>
basically the problem right now is that the submodules are cloned via ssh
<azonenberg>
and github wont allow anonymous ssh clones
<Katharina>
I do not, I have to change that later. I already suspected this since it works fine on linux
<azonenberg>
only anonymous via https
<azonenberg>
Yeah
<Katharina>
i kinda treat this windows machine as "not secure" if that makes sense
<azonenberg>
we think this can be fixed by using relative paths
<Katharina>
thats why i didnt have keys on here
<azonenberg>
I know exactly what you mean, i have windows vms i keep off in a sandobx like that too
<azonenberg>
my wife's computer is on a totally separate vlan from everything i care about :p
<azonenberg>
anyway so we think if we reference the submoudules via relative paths you can clone scopehal-cmake via either https or ssh
<azonenberg>
and have it resolve correctly in either case
<azonenberg>
i just havent had the time to test
<azonenberg>
maybe i'll work on that later today
<Katharina>
yea no hurries, I need to do separate PRs for the different repos anyways
<Katharina>
currently, i disabled the plugin loader. I have to rewrite that using LoadLibrary today before i do a PR for scopehal
<azonenberg>
yes, that was the one *known* thing that wouldn't port
<azonenberg>
all of the other stuff you found was new
<Katharina>
interestingly, there were some funky problems in xptools/Socket.h
<azonenberg>
xptools was supposed to be a cross platform abstraction library but has only been used on linux for 5+ years
<azonenberg>
so some bitrotting is to be expected
<Katharina>
yep. One issue I did not manage to solve in an equivalent way is the socket Tx/Rx timeout: windows only has milliseconds precision, your library takes useconds
<azonenberg>
Rounding up to the nearest ms is probably fine for now
<Katharina>
yea, i did that for now
<azonenberg>
i really don't need timing accurate to microseconds for unresponsive hardware anyway :p
<Katharina>
Ill look into building glscopeclient now. There are issues with the gl loader it seems. Windows only has headers for GL1.1
<azonenberg>
Yeah you will probably want to bring in libglew or something similar to fix that
<Katharina>
exactly
<azonenberg>
as well as adding GL version checks during startup
<Katharina>
oh also, I am not trying to get psuclient or reflowmon to compile. Too many problems there, and I kinda regard that out-of-scope of my efforts for now
<azonenberg>
Yes, agreed. Just disable those if no linux for now
<azonenberg>
those aren't core to the project at least for the moment
<azonenberg>
But send me PRs for your work to date first
<azonenberg>
I want to get this merged. This is already a good step forward, because having scopehal+scopeprotocols allows headless data capture and analysis on windows right now
<azonenberg>
even if you don't have the UI working yet
<Katharina>
on it
_whitelogger has joined #scopehal
<Katharina>
xptools PR is up
<azonenberg>
wait, you're in Germany too? i feel like half this channel is there lol
<azonenberg>
there's at least two or three other folks here from there
<azonenberg>
Merged
<Katharina>
the tiny one on graphwidget is also up
<Katharina>
yea Im from Germany :)
<azonenberg>
ah ok. IIRC degi, electronic_eel_, and Pretzel4Ever are all from there. Maybe others i'm missing
<azonenberg>
graphwidget merged
<Katharina>
Great. Ill do a PR on scopehal that will not include any loader changes, but will fix compile bugs in other components
<azonenberg>
Ok
<azonenberg>
just add a #ifndef _WIN32 or something around the loader for now?
<azonenberg>
so it will compile but not load plugins?
<Katharina>
i did that locally, but do you want that to be in the repo?
<azonenberg>
Yes
<Katharina>
ill implement the loader today anyways
<Katharina>
ok
<azonenberg>
I want it to compile, we can then add full windows support later
<azonenberg>
but the earlier it at least is somewhat useful the better. AFAIK nobody is actually using plugins for anything yet
<azonenberg>
and there certainly are no windows plugins yet
<Katharina>
I defined a global macro called `HAS_LXI` btw, if youre ok with that
<azonenberg>
Sure
<Katharina>
I found a MinGW port of the dependency, but i dont trust it yet
<Katharina>
so it might be a possibility for the future
<_whitenotifier-f>
[scopehal] nshcat forked the repository - https://git.io/JfNTg
<Katharina>
Is C++11 ok btw?
<Katharina>
or do you target a lower version
<_whitenotifier-f>
[scopehal] nshcat opened pull request #156: Fixes to allow compilation on Win32 - https://git.io/JfNkk
<azonenberg>
Katharina: right now we are compiling with --std=c++11
<azonenberg>
i'm willing to consider moving to a later revision if there's a good reason
<azonenberg>
right now the minimum system requirement is a 64 bit system (because I rely on the heap being 16 byte aligned for some optimizations, and most 32 bit OSes only have 8 byte alignment)
<Katharina>
Good, C++11 is enough. I had to replace usleep() calls with chrono and threading calls
<azonenberg>
yeah i use C++ threading
<azonenberg>
xptools used to contain a cross platform pthreads/windows threads wrapper
<azonenberg>
i deleted it when i moved to c++ 11
<Katharina>
:)
<Katharina>
the first PR is up now
<Katharina>
it allows scopehal and scopeprotocols to be compiled at least
<azonenberg>
yeah i see it. Have to take care of something else but will review in half an hour or so
<azonenberg>
As a general rule, i would say target win7 and debian stable as the oldest supported platforms
<Katharina>
sure, no hurries.
<azonenberg>
or ubuntu LTS
<azonenberg>
anything out of support, for certain, i don't care about
<azonenberg>
mainstream still supported distros i want to work with, so minimize use of super new OS/library features unless there is a good reason to build from source
<azonenberg>
i'm OK with requiring a newer version of a library than, say, ubuntu 18.04 ships if we have a real need though
<Katharina>
got it
<Katharina>
what I did not make PR for yet is the change of the logging library - in my local copy, I changed it to being a shared library. You wanted it to be compiled as both a shared and a static library, right?
_whitelogger has joined #scopehal
<azonenberg>
Yeah
<azonenberg>
since some other projects use it static
<azonenberg>
the trick is to make sure the windows build always uses the shared version
<azonenberg>
maybe for now, make it default to shared on windows and static on linux
<azonenberg>
then we can think about a longer term solution later on?
<azonenberg>
honestly i would be fine with making it shared only but i think some other projects assume it's static atm
<azonenberg>
Why does the lecroy driver not build on windows?
<azonenberg>
Katharina: skimming the code i dont see anything obviously posix specific?
<azonenberg>
also rather than ifdefing sleep_for or usleep, since sleep_for is in the C++ standard and portable, why not switch to that on linux too?
<azonenberg>
less ifdefs in the code is always better, if there is a C++ standard replacement for OS specific functionality i'd always rather use that than ifdef'd OS calls unless there's a good reason
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #156: Fixes to allow compilation on Win32 - https://git.io/JfNkk
<_whitenotifier-f>
[scopehal] azonenberg pushed 11 commits to master [+0/-0/±25] https://git.io/JfNIV
<_whitenotifier-f>
[scopehal] nshcat 035fb1c - Extended CMake project file to allow LXI to be missing
<_whitenotifier-f>
[scopehal] nshcat 0bf8ab0 - Excluded LeCroyOscilloscope driver from compilation on Win32
<_whitenotifier-f>
[scopehal] nshcat 18980a5 - Replaced usleep() call in Rigol driver on Win32
<_whitenotifier-f>
[scopehal] ... and 8 more commits.
<Katharina>
yea, i was planning to remove the ifdef for usleep, will do that
<Katharina>
azonenberg: The LeCroy driver does not compile since localtime_r isn't available on windows. I thas localtime_s, but i haven researched it yet if its equivalent
<Katharina>
that will also be in the next PRE
<azonenberg>
ah ok. yeah
<azonenberg>
fundamentally the problem is, the lecroy waveform headers give instrument local time of the trigger event in broken-down units
<azonenberg>
separate fields for hours, minutes, seconds, etc
<azonenberg>
and i have to convert that back to a time_t plus fractional seconds, since that's the native scopehal format
<azonenberg>
so basically i assume the scope time zone and the user's workstation are the same since there doesn't appear to be a way to query the instrument for its time zone
<azonenberg>
then i do some very ugly conversions :p
<Katharina>
Ah okay. localtime_s seems to be fine, it only has the quirk that its parameter order is reversed. Also, its optional in C11, but since MS decided to implement it it should be fine for using in Windows
<azonenberg>
If it works on windows + linux that's good enough for me right now. We don't need portability to VMS or whatever yet :p
<Katharina>
thats the issue - i dont think we can rely on it being available on linux. So another ifdef :\
<azonenberg>
Oh
<azonenberg>
Lol
<azonenberg>
lovely
<Katharina>
with windows you know that every stupid thing they do in their library will basically be there forever, they really put emphasis on that
<azonenberg>
Yeah, windows basically never breaks existing functionality. So you have all kinds of stuff marked deprecated, but never removed
<azonenberg>
i wish there would be a "standards compliance mode" in windows that removed all the deprecated stuff
<azonenberg>
like putting a doctype in a html doc to turn off quirks mode
<azonenberg>
either per app or system wide
<Katharina>
the newer C++ compilers on Windows finally do have such a mode for C++
<azonenberg>
but it just is at compile time
<azonenberg>
it won't forcibly stop code that uses the old APIs from running, right?
<Katharina>
it turns off all their stupid C++ language misinterpretations
<Katharina>
yes
<azonenberg>
basically i want the opposite of compatibility mode lol
<azonenberg>
"strict windows 10 mode"
<Katharina>
but then again they also do kinda (in my opinion) annoying things - for example memcpy is deprecated on MSVC
<azonenberg>
why? what do they want you to replace it with?
<Katharina>
memcpy_s
<azonenberg>
how can you make memcpy safer
<azonenberg>
it takes a size
<Katharina>
memcpy_s has a source and destination size
<Katharina>
i dont agree with it either
<azonenberg>
i'm all for banning truly unsafe functions like strcpy or gets
<azonenberg>
but memcpy seems fine
<Katharina>
yea thats what i mean. in a strict "nothing deprecated" mode youd have to use these weird safe versions
<Katharina>
which can be annoyingh
<azonenberg>
i was talking about windows API deprecation though
<azonenberg>
not their own custom dialects of C++
<azonenberg>
since i'm quite sure memcpy is still part of the C++ standard and not deprecated *there*
<Katharina>
ah ok
<Katharina>
well the WinAPI is another beast for sure, i have to deal with it at work a lot and i really dislike its design
<azonenberg>
Yeeeah
<azonenberg>
My favorite example of a function that makes me wonder "what the hell were they smoking" is BlockInput()
<azonenberg>
Which turns off keyboard and mouse input, other than ctrl-alt-del, to (as far as i can see) the entire system
<azonenberg>
not just your application
<Katharina>
what the hell
<azonenberg>
what legitimate application is there for it? you can't use it for a screen locker because ctrl-alt-del lets you break out
<azonenberg>
and that's the only use case i can imagine for it
<azonenberg>
someone, somewhere, decided this was a function windows needed
<Katharina>
at least it needs elevated privileges
<azonenberg>
it does?
<Katharina>
yea
<Katharina>
just tried it
<azonenberg>
my understanding is that any function in the current session can call it
<azonenberg>
at least in vista/7 which was the last time i used windows even somewhat seriously
<azonenberg>
10 may have changed that
<Katharina>
if youre not elevated you get ERROR_ACCESS_DENIED
<Katharina>
on Win10
<azonenberg>
interesting
<azonenberg>
i learned about it when i was taking a class on malware analysis back in 2012 or so
<azonenberg>
one of the samples i was using called it during the unpacking so you couldn't single step the decryptor code
<azonenberg>
if you tried to break at the wrong time your whole system would lock up lol
<azonenberg>
that VM was either xp, vista, or 7 based iirc
<azonenberg>
10 definitely wasn't out yet
<Katharina>
interesting use of the function tho
<azonenberg>
so like i said, hard to think of a *legitimate* use for it
<azonenberg>
lol
_whitelogger has joined #scopehal
<azonenberg>
Katharina: btw, once we get the windows stuff working initially, are you planning to use it on windows on a somewhat routine basis?
<azonenberg>
i.e. will you be actively maintaining it to keep it from bitrotting?
<Katharina>
i was planning to use it at work, yes
<azonenberg>
Great
<Katharina>
so, glscopeclient now compiles on windows, i got a weird GTK error though, maybe you know more. I never worked with GTK before
<azonenberg>
Ok, go on?
<azonenberg>
what's the error :)
<Katharina>
Gtk:ERROR:../gtk+-3.24.20/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/24x24/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
<azonenberg>
Ok, that's not entirely unsurprising
<azonenberg>
So what's happening is, i'm trying to use standard GTK toolbar icons
<azonenberg>
and you don't have a GTK theme installed providing the icon i want, and the "missing image" icon is missing too
<Katharina>
that's funny
<azonenberg>
I've hired an artist to draw a set of toolbar icons specifically for this project since the standard icons i wasn't using aren't really good fits to the purposes of the buttons anyway
<azonenberg>
but i don't have any of those images yet
<azonenberg>
longer term they'll be part of the standard glscopeclient install and we won't be reliant on external theme icons
<azonenberg>
does it still launch, just with garbage/missing toolbar buttons?
<Katharina>
no, its a hard bail-out. I do have an idea tho
<azonenberg>
ah ok
<azonenberg>
if you can install a gtk icon theme, any theme, that should hold you over until we get the custom artwork ready
<azonenberg>
no idea how to do that on mingw though
<Katharina>
I do have it installed, which is interesting.
<azonenberg>
ok that is interesting
<Katharina>
ok i fixed that problem, turns out that GTK uses dynamic loading for its pixbuf image format loaders
<Katharina>
and those twenty libraries need to be present in the binary folder on windows, which sucks
<azonenberg>
lol
<azonenberg>
Lovely
<Katharina>
so the issue was that it didnt understand any image format, and thus couldnt load the theme
<Katharina>
;')
<azonenberg>
oh fun
<azonenberg>
So was the fix code wise, or fixing your broken install?
<Katharina>
well, the latter, but the install isnt broken per-se
<Katharina>
mingw gives you a fake posix file system, and expects your applications to either reside in /bin, or you have to copy all the needed libs to the binary folder when you publish your binary
<Katharina>
i just didnt know i had to copy some GDK pixbuf dlls :)
<azonenberg>
definitely write up some notes on this because we're going to need to have some sort of installer figured out eventually
<Katharina>
yea
<Katharina>
great, the "Connect to instrument" window works when starting without parameters, but the captures just cause the window to flash up for a second and then close itself. Ill try to debug that
<azonenberg>
Also, when you get things more working, i'd like to get the build/install documentation in scopehal-docs split up into separate windows and linux sections
<azonenberg>
if it compiles ,send me a PR for what you have now
<azonenberg>
Just so i have less code to review next time around
<Katharina>
sure
<Katharina>
azonenberg: is the widget WaveformArea instantiated multiple times?
<azonenberg>
Yes. Each plot is its own WaveformArea
<azonenberg>
There's one GL context for each
<Katharina>
what do you think is the best way to init GLEW then?
<azonenberg>
That's a very good question
<Katharina>
there has to be an active context for it to work
<Katharina>
i have been doing it in the on_realize() of WaveformArea
<Katharina>
But I am also not sure if you need to do it _for each_ context, i highly doubt that
<azonenberg>
maybe add a static member and only call it the first time?
<Katharina>
yea
<Katharina>
terminate called after throwing an instance of 'YAML::TypedBadConversion<long>'
<Katharina>
what(): yaml-cpp: error at line 4, column 20: bad conversion
<Katharina>
I suppose that can only be in one of the yaml files of the data sets, correct?
<Katharina>
azonenberg: ah, the value in the yaml "230999999053" is too big for a long value, since long is 4 bytes wide on Windows. Did you assume long to be 8 bytes wide by any chance?
<azonenberg>
timestamps are int64s
<Katharina>
weird. its definitely the problem, its the value for time_psec.
<Katharina>
By hand, i changed the number just to see if its really the width of it, and it works for numbers that fit into 32bit
<azonenberg>
but i might be parsing as long in yaml-cpp
<Katharina>
ill check
<Katharina>
yes you did, I changed it, the program now seems to work fine with the test data. very nice!
<azonenberg>
Great
<azonenberg>
Send me a PR for these changes and we'll go from there, then. I see two missing toolbar icons but that will be a non issue once we get our custom artwork set up
<azonenberg>
This is awesome, having even offline functionality working with just a few hours of work is amazing
<Katharina>
i will first check if the switch to GLEW will cause any issues on linux
<azonenberg>
I did put reasonable effort into making sure things were portable, but i wasn't expecting it to be quite this fast :)
<azonenberg>
Mind if i share this screenshot?
<Katharina>
sure, go ahead
<azonenberg>
Once we reach "no known missing features" meaning all drivers and transports at least compile on windows and everything we've tested works as well on win as linux, we'll close the umbrella "make it work on windows" tickets
<azonenberg>
then create new ones for specific portability concerns later on as they arise
<Katharina>
sounds good
<azonenberg>
also if i see good work from you for a reasonable bit of time, i'm open to adding you to the project on github officially
<azonenberg>
While this does give you commit access, there will be a probationary period first in which you're expected to still submit PRs for review, although you'd be able to merge them yourself once I approve
<azonenberg>
the big thing it would allow is assigning tickets to you, there isn't a good way to assign tickets to users without also giving commit access
<Katharina>
agreed, sounds good
<azonenberg>
Because longer term i see you as becoming the windows maintainer for the project if you're up for it
<azonenberg>
Other than my LeCroy scopes which use embedded windows, and the one windows VM i keep around for work to run client software if they don't have a linux build, i'm pretty much 100% linux
<azonenberg>
as are most of the other devs so far
<Katharina>
yea, i can see that
<azonenberg>
Katharina: so what kind of work do you do that you'd be using glscopeclient for? What protocols or features would you like to see?
<Katharina>
I do basic embedded work; mostly with STM32 chips, and Lattice ECP5 FPGAs. I'm still a junior engineer, but I want to use glscopeclient for I2C, SPI and USB, mainly
<Katharina>
I just think having a desktop program like this is a lot more ergonomic when debugging
<azonenberg>
Well we have i2c, spi, and usb full speed already, miek is actively working on high speed support, and low speed probably works but nobody's tested afaik
<azonenberg>
and i completely agree
<azonenberg>
especially since you can easily save files/screenshots for later analysis, write your own protocol decodes for some custom chip, etc
<Katharina>
exactly
<azonenberg>
Plus, unless you have my kind of budget to buy a scope with a 15" 720p display that's basically a laptop monitor, squinting at a tiny 720x480 or even 320x240 display display to debug stuff is a giant pain
<azonenberg>
and honestly even though i have the nice lecroy's, they can't beat the 40" 4K i have in the office lol
<Katharina>
I'm used to using GTKWave for my FPGA simulation waveform dumps, and glscopeclient is a similar experience, just for "real" data
<azonenberg>
the other thing glscopeclient enables is remote operation
<azonenberg>
since it's full control, not just viewing, if you can get a scope in a lab and VPN into it
<azonenberg>
you can be on an entirely different continent than the thing you're debugging
<Katharina>
thats pretty awesome!
<azonenberg>
i actually wrote the original rigol driver this way, sitting in my house off the coast of seattle and talking to a DS1054Z in Moscow
<azonenberg>
because i didnt have one and whitequark offered up hers. Lol
<azonenberg>
Performance in remote mode is worse obviously, and i havent used it over a VPN/WAN in a while so there might be issues with certain timeout values and such
<azonenberg>
what i may do eventually is have two "performance profiles", one for LAN and one for WAN, with different timeouts, sleeps, etc
<azonenberg>
So you don't hammer a slow connection with 300 polls waiting for the scope to trigger when the scope is a quarter of a light-second away
<Katharina>
how does glscopeview handle multiple data sources at once?
<Katharina>
can it do that?
<azonenberg>
But usability in that environment is an explicit design goal
<azonenberg>
Yes. I can acquire from arbitrarily many instruments
<azonenberg>
the intended workflow at the moment is to have one, designated the primary, as the trigger source
<Katharina>
that's awesome. I do have two identical rigols at my desk at work
<azonenberg>
and trigger output from that instrument feeding into ext trig on the secondaries
<azonenberg>
running them off a common reference clock is strongly preferable but on shorter captures drift is unlikely to be an issue
<azonenberg>
i also have a built in wizard for calibrating out trigger skew between the instruments
<azonenberg>
basically you touch a probe from each to a common point, feed in some kind of non-periodic signal, then it does a cross-correlation to find the propagation delay of the trigger from the primary to each secondary
<azonenberg>
and it will adjust trigger offset on the secondary to match
<azonenberg>
right now, you need to redo this any time you adjust trigger offset on the primary but longer term it will track changes on the primary
<azonenberg>
here's a demo video i shot of doing exactly this
<azonenberg>
the scopes do not need to be identical, the same sample rate, or even the same make
<azonenberg>
i've only tested with lecroy's (waverunner 8000 and HDO9000 series) but any N libscopehal-supported instruments can be combined
<azonenberg>
i intend to do a plugfest at some point with a lecroy, a tek, and a keysight on one bench acting as one twelve-channel instrument
<azonenberg>
in the UI, channel names have "scope qualifications" with the name of each scope, so for example "hdo9:C1" to disambiguate from "wr8:C1"
<Katharina>
:) thats seriously awesome
<azonenberg>
which is what the nickname in the UI is for
<Katharina>
my two primary scopes at work are Rigol MSO5xxx ones, are they supported?
<azonenberg>
you can of course rename these channels for display as you see fit but they're still internally tied to the instrument they came from if you open the channel properties dialog
<azonenberg>
The rigol driver is currently known to work on DS1000Z and MSO5000 series
<Katharina>
how does glscopeview handle the logic analyzer probes?
<azonenberg>
i don't think we have support for the logic probe yet... Degi is i believe the maintainer for that driver so check with her for specifics
<azonenberg>
in general, they just show up as additional channels
<Katharina>
k
<azonenberg>
there is not currently any UI for setting threshold level though
<azonenberg>
so you have to do that on the front panel of the instrument
<azonenberg>
We support the MSO probe on LeCroy scopes, as well as some FPGA based ILA IP's
<azonenberg>
(and i'd love to add more)
<azonenberg>
so architecturally digital channels work just fine, we just don't have code in the rigol driver to pull waveforms off yet. I think
<azonenberg>
also it's glscopeclient, not glscopeview :)
<azonenberg>
since it's a lot more than just a waveform viewer, it has full remote control features as well
<azonenberg>
unlike something like gtkwave
<Katharina>
Haha sorry. Believe, I am going to make that mistake a few times more. Words aren't my strength :)
<azonenberg>
Lol no worries
<Katharina>
So, I wanted to ask you about the organization of the Windows build. I told you earlier about the fact that when publishing a release, we would need to copy all dynamic libraries of the mingw system that glscopeclient links to
<Katharina>
there is a python script i have been using and modifying that does this as part of cmake
<Katharina>
what do you think about having that for the win32 build?
<azonenberg>
As long as it doesn't break the linux build, and you can write up a series of well documented steps that a user can use to make it compile on windows
<azonenberg>
and you do all of the legwork for it
<azonenberg>
That's fine by me
<Katharina>
Sure. It would basically be another build target that only gets executed for windows builds, after the main executable build
<azonenberg>
BTW, is the mingw setup you're using generating 32 or 64 bit binaries?
<Katharina>
64 bit
<azonenberg>
Ok good
<Katharina>
thats where the long issue came from.. windows has chosen that long is always 4 bytes long, all the time
<azonenberg>
Because if you have history mode turned on it's very easy to use gigabytes of memory. And some of the filters rely on 64-bit compatible heap alignment since they use compiler vectorization
<azonenberg>
i have no plans to support 32 bit builds any time soon
<azonenberg>
especially now that even raspberry pi's are 64 bit :p
<azonenberg>
the pi4 also runs GL ES 3.2 and i think it should be possible to run glscopeclient on them as a result
<azonenberg>
obviously not nearly as fast as a PC, but somebody might want to try that eventually
<Katharina>
yea, I have a Pi4
<Katharina>
i am running some of my OpenGL scenes on it as a digital picture frame
<azonenberg>
lol nice
<azonenberg>
i think i may have a few - or are they pi3's? i know i have some 4s i used for work but they're not here anymore
<azonenberg>
they're used as SCADA-type appliances around the house, liek i have one monitoring the water level on my sump pump
<Katharina>
niice, i use STM32 UCs for my home automation
<azonenberg>
well I have a full touchscreen HMI on that one
<Katharina>
ok, thats a bit more advanced than my setup :)
<azonenberg>
was much easier to do in GTK than on a little micro
<Katharina>
my system just monitors hydroponics nutrient and ph levels etc
<azonenberg>
this is how i keep an eye on just how hard my laundry room and office are attempting to become a swimming pool
<Katharina>
That's seriously awesome
<azonenberg>
note that this is the dry season and i'm still leaking something like 100L/day of water
<azonenberg>
during the winter when it rains all the time it's easily 2-3 times that
<Katharina>
may I ask in what region you live?
<azonenberg>
Washington - northwest of the US (not to be confused with washington DC which is in the middle of the east coast)
<Katharina>
Ahh
<azonenberg>
I'm across the water from Seattle
<azonenberg>
We get a fairly normal amount of rain, but it all falls during about a third of the year
<azonenberg>
during the summer 3-6 weeks with no rain at all is not uncommon
<azonenberg>
in the winter, a few days in a row without rain is unusual :p
<Katharina>
ah then the setup makes sense
<azonenberg>
Yeah. We're also at the bottom of a hill and there's clay and rock pretty close to the surface
<azonenberg>
so the water can't soak into the ground
<azonenberg>
it all flows through our neighborhood and if you're in the way, too bad
<azonenberg>
You can't stop it, but with pumps and drain pipes you can divert it away from the house
<azonenberg>
it's basically an underground river
<Katharina>
where i come from, we very, very rarely have to deal with flooded basements. Had it happen once, but the whole city was flooded. Our national guard/FEMA equivalent had to pump the houses dry
<Katharina>
because nobody really has pumps here
<azonenberg>
Whereabouts is that?
<Katharina>
western germany
<Katharina>
we had a flash rain a few years ago, and people in my city where driving little boats in the streets
<azonenberg>
ah ok. I'm not super familiar with the German climate as I haven't been there too often. I've only really spent any time in Bochum when I was visiting Pretzel4Ever's research group at RUB
<azonenberg>
and then i traveled through Weeze and Frankfurt but didn't really do anything but get on a train or airplane
<azonenberg>
I remember it being quite cold as it was almost Christmas time
<Katharina>
the climate did not use to be as extreme as it is nowadays, rain evenly spaced through the year etc
<azonenberg>
I think a little bit of snow
<azonenberg>
Re ECP5 stuff, btw, do you currently use any kind of FPGA-based LA for debugging your design? if so, a Lattice IP or a f/oss one?
<azonenberg>
Because whatever it is, scopehal can support that too :)
<Katharina>
i am using an existing LA a collegue wrote, so yes
<Katharina>
im pretty sure implementing support for it would break NDA tho
<azonenberg>
ah ok. Well, the good news is that scopehal has support for new drivers via plugins
<Katharina>
yep
<azonenberg>
So you can create a proprietary driver and simply not release it
<Katharina>
was thinking about that as well.
<azonenberg>
i have decodes for nda'd protocols already
<azonenberg>
that was the original reason i implemented plugin support
<azonenberg>
capturing a GMII bus inside the FPGA then looking at the RGMII clock and TX_EN signals in the analog domain
<azonenberg>
this was before i had proper sync support so i had to deskew manually
<azonenberg>
This is one of the reasons i went with the BSD license too
<azonenberg>
i wanted it to be easy to integrate into commercial environments
<azonenberg>
you may, but are not required to, contribute back your improvements
<Katharina>
interesting!
<azonenberg>
you just need a GPIO off the FPGA to use as a trigger reference for the external scope
<Katharina>
oh I definitely plan on contributing back. I get 4 hours a week of paid OSS dev time anyways
<azonenberg>
in fact, you could even sync the ILA and *multiple* external DSOs
<azonenberg>
honestly the limit for how many scopes you can chain is a combination of screen real estate and RF loss on the trigger signal
<azonenberg>
and the latter can be solved by using a buffer instead of a passive splitter. Lol
<azonenberg>
So you could combine your ILA and both rigols if you wanted
<azonenberg>
Multi-scope support occasionally misses triggers and i need to debug that, the architecture SHOULD work fine
<azonenberg>
basically i arm all secondary scopes first, send a ping to make sure the command was processed
<azonenberg>
and only then do i arm the primary
<azonenberg>
but sometimes the primary triggers and the secondary doesn't
<azonenberg>
unsure if an issue in the lecroy driver or more general
<azonenberg>
there might be some latency from when the scope gets the trigger arm command and when it actually is armed, i may just have to add a device dependent sleep
<azonenberg>
it might also be possible to query the scope and see whether the trigger is armed or not
<azonenberg>
rather than just a serialization barrier
<azonenberg>
but yes in general the ILA + external scope combination is very much an important use case for me. i'm not aware of any other tool with this level of integration
<Katharina>
:) Im definitely looking forward to using glscopeclient for debugging
<azonenberg>
the other thing you might not be aware of is that this channel isn't just about using scopehal with commercial scope hardware
<azonenberg>
We're also working on building our own custom hardware
<Katharina>
Yea, I have been following your hardware efforts on twitter
<azonenberg>
Well i've posted about stuff that has gone to layout
<azonenberg>
but are you familiar with MAXWELL? that's my main push right now
<Katharina>
Im actually not!
<azonenberg>
It's a 1U logic analyzer with twelve of the MEAD or CONWAY 8-bit logic pods that i was tweeting about
<azonenberg>
for a total of 96 channels
<azonenberg>
92 at 1.25 Gsps, the last four go to SERDES and are sampled at 10 Gsps
<azonenberg>
Kintex-7 FPGA for the bulk of the fun stuff, DDR3 SODIMM for buffering waveform data, then 40Gbit Ethernet to glscopeclient
<azonenberg>
with a 1gbit copper port for those folks who aren't fortunate enough to have 40G to their desk
<azonenberg>
then a STM32F777 for management and the front panel status LCD, a Spartan-7 for some I/O expansion, and some other miscellaneous stuff
<azonenberg>
it's very much a high end piece of gear, there's a precision OCXO as the timebase plus external inputs for 10 MHz refclk and PPS from a GPSDO. So you'll be able to get few-nanosecond-precision timestamps on your trigger events
<azonenberg>
(although of course you can just use the OCXO instead if you don't need GPS time)
<azonenberg>
I'm almost done with the schematic now and will then have to probably spend a week or more on the design review. It's almost 800 components and the board will be about the size of a sheet of A4 paper
<azonenberg>
the schematic is 18 pages
<azonenberg>
It's my largest electronics project ever by probably a factor of two or three
<Katharina>
jesus
<azonenberg>
Yeah. Serious test equipment lol
<Katharina>
definitely
<azonenberg>
but imagine being able to hook it up to a smaller embedded project and see literally every signal on your micro
<azonenberg>
with 4GB of capture memory
<azonenberg>
That's ~340 million points across the 92 channels if you're not using the 10G ones
<azonenberg>
more with compression
<Katharina>
thats a dream for sure
<azonenberg>
this allows what i half-jokingly call the "NSA debug philosophy". Collect everything, then figure out what was interesting later on
<Katharina>
if you capture everything you cant miss anything important ;)
<azonenberg>
imagine simultaneous protocol decodes on every bus in your system, every signal, for 250 ms
<azonenberg>
So yeah, that's the vision. I just need to build it and make it work
<azonenberg>
And not screw up a several thousand dollar board
<azonenberg>
My digikey cart is about $1200 right now and that isn't complete. The PCB will be eight layers on RO4350B the size of a sheet of A4 paper
<azonenberg>
And nobody is paying me to build it
<azonenberg>
So pretty much i get one shot, it has to work
<azonenberg>
The first time
<Katharina>
how much is the kintex-7 part?
<azonenberg>
Nearly $400
<azonenberg>
xc7k160t-2ffg676c
<azonenberg>
i ran out of IOs on it and needed to add an xc7s6-1ftgb196 as an io expander. The alternative was moving the kintex to the ffg900 package which would have meant more pcb layers
<azonenberg>
and a much more expensive fpga
<_whitenotifier-f>
[scopehal] nshcat opened pull request #157: Fixed LeCroy driver to work on Win32 - https://git.io/JfN3B
<Katharina>
azonenberg: jesus thats expensive
<azonenberg>
Katharina: well i mean it's not a small fpga, lol
<_whitenotifier-f>
[scopehal] nshcat edited pull request #157: [WIP] Fixed LeCroy driver to work on Win32 - https://git.io/JfN3B
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #157: [WIP] Fixed LeCroy driver to work on Win32 - https://git.io/JfN3B
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JfN3u
<_whitenotifier-f>
[scopehal] nshcat 4180794 - Fixed LeCroy driver to work on Win32
<_whitenotifier-f>
[scopehal] azonenberg 984ed99 - Merge pull request #157 from nshcat/fix-lecroy_win32 [WIP] Fixed LeCroy driver to work on Win32
<_whitenotifier-f>
[scopehal-cmake] nshcat forked the repository - https://git.io/JfNTg
<_whitenotifier-f>
[scopehal-cmake] nshcat opened pull request #15: Updated CMake project file to exclude incompatible projects on Windows - https://git.io/JfN36
<_whitenotifier-f>
[scopehal-cmake] azonenberg closed pull request #15: Updated CMake project file to exclude incompatible projects on Windows - https://git.io/JfN36
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfN3X
<_whitenotifier-f>
[scopehal-cmake] nshcat e19753e - Updated CMake project file to exclude incompatible projects on Windows
<_whitenotifier-f>
[scopehal-cmake] azonenberg 2684c44 - Merge pull request #15 from nshcat/win32-fixes Updated CMake project file to exclude incompatible projects on Windows
electronic_eel_ is now known as electronic_eel
<_whitenotifier-f>
[scopehal-apps] nshcat forked the repository - https://git.io/JfNTg
<Katharina>
Im going to commit my changes now. Right now, saving is disabled on Windows since I need to rewrite the Posix code in that function after lunch.
<Katharina>
but i dont want this PR to be more massive
<azonenberg>
Fair enough
<azonenberg>
You got it working and displaying saved waveforms in one day though. I'm quite impressed
<Katharina>
so ill do that in a followup PR
<Katharina>
when I post the PR ill mark it as WIP, please dont merge it yet, Ill reboot and check if it still works on linux first
<azonenberg>
Ok
<azonenberg>
I'll need some time for a review on my end anyway
<_whitenotifier-f>
[scopehal-apps] nshcat opened pull request #114: Allow compilation and offline execution of glscopeclient on Windows - https://git.io/JfNsc
<Katharina>
i most certainly fucked up some coding style somewhere, feel free to yell at me
Katharina has quit [Read error: Connection reset by peer]
Katharina has joined #scopehal
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±19] https://git.io/JfNsE
<_whitenotifier-f>
[starshipraider] azonenberg 9921e70 - Finished MAXWELL power supply. Done except for INA233s on PSU rails, temp sensors, and EMI filtering on +12V outputs.
<azonenberg>
i think all of the important parts are done. Passes ERC except for a few things that should be safe to ignore but i'll double check
<azonenberg>
Still have to add a bunch of i2c sensors and some ferrites
<azonenberg>
but that should be quick
<azonenberg>
746 components, expecting >800 once i'm done
Katharina has quit [Quit: Lost terminal]
Katharina has joined #scopehal
<azonenberg>
Katharina: how'd it work?
<Katharina>
azonenberg: Works fine, just needed to change one static casts. The fuckery with different width integer types. Should be fixed in a few minutes
<azonenberg>
so far i have only one piece of feedback, WaveformArea::isGlewInitialized should have a m_ prefix since it's a member variable
<Katharina>
oh yea I was wondering about that, since its static. I normally dont give it prefix, but if thats your style ill gladly change it
<azonenberg>
Yeah. The coding policy doc is a bit young, i only wrote it up when i started getting more contributors to the project
<azonenberg>
Otherwise it looks good
<azonenberg>
let me know when you've fixed that plus your cast and i'll merge
<_whitenotifier-f>
[scopehal-apps] nshcat synchronize pull request #114: Allow compilation and offline execution of glscopeclient on Windows - https://git.io/JfNsc
<Katharina>
its ready
<Katharina>
we should maybe add the GLEW dependency to the readme then
<Katharina>
its super common so everybody should have installed it already, but just in case
<azonenberg>
Yeah. Send a PR to scopehal-docs, that's the authoritative source. I'm actually thinking of removing the build instructions from the readme so we dont have to maintain two sources
<azonenberg>
instead, just have a pointer to the docs
<Katharina>
yea
<azonenberg>
also when you get a chance a PR for scopehal-docs with windows build instructions and notes
<Katharina>
so we dont have duplicated, most likely out of sync info
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #114: Allow compilation and offline execution of glscopeclient on Windows - https://git.io/JfNsc
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 11 commits to master [+0/-0/±21] https://git.io/JfNsb
<_whitenotifier-f>
[scopehal-apps] nshcat 4ec53d8 - Modified CMake project file to include GLEW as well as needed Windows libraries
<_whitenotifier-f>
[scopehal-apps] nshcat 8bfb9c4 - Fixed HistoryWindow using localtime_r not compiling on Win32
<_whitenotifier-f>
[scopehal-apps] nshcat 048dcde - Fixed YAML deserialization code using longs, which are only 4 byte on windows
<_whitenotifier-f>
[scopehal-apps] ... and 8 more commits.
<Katharina>
azonenberg: Is auto okay in C++?
<azonenberg>
Katharina: yes, i use it heavily
<Katharina>
k
<azonenberg>
especially with big template types, iterators in foreach loops, etc
<Katharina>
i dont have to write so many caps-lock WinAPI types then :^)
<azonenberg>
makes code so much more concise
<azonenberg>
Yeah, but if you find yourself calling RtlWriteDecodedUcsDataIntoSmartLBlobUCSWritingContext(), auto won't save you
<azonenberg>
(i wish that wasn't a real windows API... but it is)
<azonenberg>
as of a few years ago it was the longest name in the API
<azonenberg>
ConvertSecurityDescriptorToStringSecurityDescriptorW() is a close second
<Katharina>
WIN32_FIND_DATA is also spicy as a type name
<azonenberg>
oh i remember dealing with that one back when i was using vista as my main dev platform
<azonenberg>
on my 2007 Dell laptop using MFC as my primary gui toolkit
<Katharina>
i still have to do some MFC dev at work sometimes
<Katharina>
go figure
<Katharina>
some legacy programs never die
juli969 has joined #scopehal
<Katharina>
azonenberg: I restricted the plugin loading on windows to .dll files
<azonenberg>
what you dont want to be able to load exports from EXEs, CPLs, or SCRs? you're no fun :p
<azonenberg>
seriously, makes sense
<Katharina>
or .COMs
<Katharina>
:P
<azonenberg>
Lol
<azonenberg>
or OCX, or SYS, or... i've lost track of how many extensions windows has for PE files
<azonenberg>
MSC?
<Katharina>
MSCs are plugins for the system configuration i think
<Katharina>
sys are drivers
<Katharina>
oh excuse me, microsoft calls them "snap-ins" not plugins :^)
<azonenberg>
yeah but i'm pretty sure they're still PEs
<Katharina>
oh yes
<Katharina>
i assume the management console does some LoadLibrary shenanigans with them
<Katharina>
azonenberg: When is InitializePlugins() called by glscopeclient? I cant get it to call the function to test it
<azonenberg>
glscopeclient/main.cpp:236
<Katharina>
thanks
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JfNZi
<_whitenotifier-f>
[starshipraider] azonenberg 567aab5 - Added ferrites to 12V power outputs to improve EMC performance. Fixed incorrect 1V0 hookup for small FPGA. Fixed some other ERC errors
<azonenberg>
Yes. That's a known issue caused by the lack of antialiasing in the waveform rendering. It's most noticeable on ultra sharp edges like digital signals at low zoom, but can happen to analog signals with fast slew and low sample rate when you zoom out
<azonenberg>
The waveform rendering isn't actually done with OpenGL lines or triangles
<azonenberg>
it's rasterized directly from voltages in a compute shader
<Katharina>
interesting
<Katharina>
maybe slapping some FXAA on it would help?
<azonenberg>
I make a list of samples that hit each column of pixels
<azonenberg>
then find the min and max bound for the values
<azonenberg>
sometimes rounding means some edges disappear
<Katharina>
ah I see
<azonenberg>
the proper solution is to consider samples before and after this column as well to ensure you get solid lines
<azonenberg>
and weight pixels by the percentage of the line that hits them, rather than just on/off
<azonenberg>
I've just had so many other things on my plate it hasn't happened yet
<azonenberg>
somewhat surprisingly i dont think i have a ticket for this already?
<azonenberg>
i've known about it but there was never a bug opened
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #115: Add proper antialiasing to WaveformArea rendering shader - https://git.io/JfNnA
<azonenberg>
the overall rendering flow is highly composition driven
<azonenberg>
i software render the background grid and text (Cairo), do another Cairo rendering pass for cursors and other stuff that appears over the waveform
<azonenberg>
push those into textures, draw the waveform to yet another texture
<azonenberg>
then do a final compositing pass to stack them all into the image you see on screen
<azonenberg>
only that last pass uses ordinary opengl polygons, textures, and vertex/pixel shaders
<_whitenotifier-f>
[scopehal-apps] nshcat opened pull request #116: Implemented saving for Win32 - https://git.io/JfNcR
<azonenberg>
i'm gonna add a few more "components" during the signoff review when i put in test points, but i think this is all of the parts that actually do anything
<electronic_eel>
congratulations
<azonenberg>
electronic_eel: congratulate me when we build it and no magic smoke comes out
<azonenberg>
lol
<electronic_eel>
lol
<electronic_eel>
I was busy with other stuff the last few days so I just had a short look
<azonenberg>
Also, this took less time than i thought. the first commit on the MAXWELL main board was the 13th
<azonenberg>
8 days for schematic
<azonenberg>
it felt like weeks lol
<electronic_eel>
100 parts per day ;)
<azonenberg>
Lol
<azonenberg>
anyway, so i guess i'll go take a break for a bit and then start the signoff review checklist. Each line on that list is probably going to take several hours to verify
<electronic_eel>
I plan to have a look at it and do a bit of review over the next few evenings
<azonenberg>
actually before i do that
<azonenberg>
i need to pick exact parts for some stuff like the caps
<azonenberg>
and do footprints
<azonenberg>
my standard process is to do footprint design and component selection prior to the schematic signoff review
<azonenberg>
because some items depend on e.g. the exact resistor i selected for something
<azonenberg>
So we probably have a couple more days before i can start schematic review since there's so many footprints to create
<electronic_eel>
for bigger projects I like to let them lay for a few days. because I get some improvement ideas or find bugs while doing something completely else, like riding bicycle in the woods
<azonenberg>
have to track down step models for all of the dcdc's etc too
<azonenberg>
also the MEAD boards are in, as are the stencils
<azonenberg>
i need to machine the mmcx cutouts slightly wider since they don't fit, and my tech is coming on tuesday tentatively to assemble them
<azonenberg>
so i can spend some time working on MEAD bringup while you do your review
<electronic_eel>
you have a tech to help you work on your private projects?
<azonenberg>
It's a friend of mine, ex SAR
<electronic_eel>
are they here on irc sometime?
<azonenberg>
Retired army truck driver, not super technical, but she can follow orders and do grunt work. And i managed to get her soldering TQFP with only one or two evenings of training having never touched an iron before
<azonenberg>
I trained her up from nothing
<azonenberg>
She does a lot of my lab maintenance work like lubing the mill periodically, cleaning flux vapor residue off the window of the reflow oven, blowing dust out of computers, etc - the boring stuff that keeps a lab working in tip top shape
<azonenberg>
as well as acting as my human pick-and-place
<azonenberg>
$25/hr is cheap for a lab tech and way better than she makes as a pizza delivery driver
<azonenberg>
Once i get the "real" pnp i'll be training her to run it, babysit it when a reel runs out or the leader gets jammed or it mis-picks a part
<azonenberg>
loading parts into the trays that didn't come on tape
<azonenberg>
and then hand placing big stuff and hand soldering pth connectors etc
<electronic_eel>
here in Germany it is a HUGE burden to go from just yourself to the first employee. have to fill out tons of forms, provide 2 gendered toilets, have work safety procedures in place and so on
<azonenberg>
well since i'm paying her as a private person and not a company its a lot simpler, we considered her a contractor since i ask her to come and work on a specific board and do it
<azonenberg>
there's no set hours or anything, she's free to decline a project
<azonenberg>
makes things simpler. but i try to run the lab to osha standards anyway, even before she got involved
<electronic_eel>
you can sorta do something like this here too, but there are strict limits to it, like the contractor needing to have different clients
<azonenberg>
just for my own sake
<azonenberg>
She is free to, i dont think she's doing it for anyone else right now but i wouldn't be upset
<azonenberg>
and actually $dayjob was thinking of bringing her on here and there to do similar stuff for them
<azonenberg>
So she would legitimately be a contractor
<azonenberg>
Calling someone an employee who comes over for one project every couple of weeks seems like a stretch
<electronic_eel>
here there was a lot of misuse of the private contractor thing, like having pizza delivery people being contractors even if they have strict working hours and so on
<electronic_eel>
so they put strict regulations on it
<azonenberg>
Yeah. Our arrangement actually seems to meet the definition of a contractor
<azonenberg>
it's a per project basis, she can and does decline projects if she doesn't want to work on them due to schedule conflicts or something, there's no regularity to it
<azonenberg>
and it's not intended to be exclusive
<azonenberg>
not really any different from having a guy come over to mow your lawn
<azonenberg>
oook so, i have GPU-Z up on my waverunner to get some more info on the graphics capabilities
<Bird|otherbox>
Input is 24V @ 4A or 48V @ 8A. << ?
<azonenberg>
Bird|otherbox: the input is 48V 2A or 24V 4A typical
<azonenberg>
Good catch on the typo
<Bird|otherbox>
ah. I just looked at those numbers and was going "that looks backwards" :p
<azonenberg>
Yeah. Max power draw by actual loads is calculated to be 73.56W adding up max current for each component on each rail
<azonenberg>
I added 20% margin on top of that for conversion losses
<azonenberg>
getting 88.27W as the TDP for the whole system
<azonenberg>
i'll probably actually design for closer to 100 at the thermal level but realistically i dont think i will ever pull that much current
<Bird|otherbox>
one other thing that leaps out -- it's a bit disconcerting to see ground treated as an ordinary named node (i.e. no symbol to denote ground connections)
<azonenberg>
that assumed the ram was in all-banks-active mode 100% of the time, both FPGAs stuffed to the brim with max toggle rate, etc
<azonenberg>
That's how i've always done my schematics in kicad. in part *because* it's just an arbitrary 0V potential
<azonenberg>
also because when you're tying a lot of pins to ground in dense areas it takes up less vertical space than the normal symbol
<azonenberg>
so practical reasons too
<Bird|otherbox>
ah
<azonenberg>
like banks of strap pins
<azonenberg>
tying to vdd or ground in close proximity
<Bird|otherbox>
*nods*
<Bird|otherbox>
C279/C280 -- are those going to be garden-variety X5R/X7R ceramic chips? seems a bit odd to use caps with significant voltco for coupling
<azonenberg>
I havent picked exact passives yet, that was the last remaining step (along with making footprints) before the full signoff review starts. But I was thinking of 1284-1591-1-ND
<azonenberg>
<1 dB S21 through 18 GHz
<azonenberg>
probably overkill but i've got them in stock and a few caps won't break the bank on a multi-$K build
<Bird|otherbox>
in that same vein, what part were you planning to use for C287?
<azonenberg>
Probably NP0/C0G 0402. Haven't selected the exact one
<azonenberg>
but i generally go with that for precision caps in filters etc
<Bird|otherbox>
ah. was thinking 270nF might be a bit hard to find in C0G 0402 :p
<azonenberg>
hmm let me look
<azonenberg>
that is a little large
<azonenberg>
I might have to go X7R for that one. The good news is that the exact value shouldnt be super critical and it's fairly low voltage
<azonenberg>
that's the PLL1 loop filter so if the bandwidth is 10% above or below nominal it's not the end of the world
<Bird|otherbox>
*nods*
<Bird|otherbox>
what does R101 (the 1K resistor in the PLL_SPI_DATA line) do?
<azonenberg>
That was recommended by ST when using bidirectional SPI to protect against bus fights in case your software is buggy and you write when the other side is reading etc
<azonenberg>
the PLL is half duplex spi which is derpy
<Bird|otherbox>
ah
<Bird|otherbox>
that makes sense then
<Bird|otherbox>
also, find the RC PoR network for the STM32 a bit odd -- is there a reason you're not relying on the uC's internal PoR?
<azonenberg>
I might DNP it but pretty sure that was standard practice in the datasheet
<Bird|otherbox>
huh, interesting
oskar has joined #scopehal
<oskar>
Hello
<azonenberg>
o/
<Katharina>
hi
<oskar>
This is my first time using a IRC before, it's quite cool
<Katharina>
i'm also quite new to using it :) youll get into it quickly
<oskar>
That's good :D
<oskar>
I'm getting some issues trying to install scopehal
<azonenberg>
oskar: On what platform?
<oskar>
Ubuntu 20.04
<azonenberg>
Are you following the directions in the manual?
<oskar>
I didn't know there was a manual, I just saw the brief instructions on the cmake github page
<azonenberg>
If you have problems after that, we're here. Katharina has been working on Windows porting the last few hours and may have broke something for ubuntu?
<azonenberg>
It works fine for me on Debian as of a few minutes ago
<oskar>
Interesting, I didn't get it working on windows myself so I'm on ubuntu to test it out
<Katharina>
yea oskar, if you cant get it to work please tell me, we can look into it
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JfN4P
<_whitenotifier-f>
[scopehal] azonenberg c1abe71 - Merge branch 'master' of github.com:azonenberg/scopehal
<oskar>
Okay will do, I'll read the manual and report back if it goes wrong
<Katharina>
for ubuntu that is, i still have to write instructions for windows
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfN4X
<_whitenotifier-f>
[scopehal-cmake] azonenberg 7ed2bee - Updated to latest submodules
<azonenberg>
oskar: i just pushed the latest versions of a few things, try with that
<oskar>
Ok will try now
<Katharina>
azoneberg: it could be outdated submodules, since i changed all modules, right?
<azonenberg>
Katharina: yeah. I literally just pushed updates to all of the submodules a few seconds ago
<azonenberg>
so that should put everything in sync
<Katharina>
yea i see, lets hope that fixed it
<oskar>
Hmm... Weird issue, I keep getting a error saying "Please make sure you have correct access rights and the repository exists."
<oskar>
And the content of docs and a few other folders is blank
<azonenberg>
oskar: It's probably trying to pull submodules via SSH and you don't have a github ssh key set up
<oskar>
Oh ok, I'll go set that up now
<azonenberg>
if you have a github account with an SSH key, that's the easiest fix. We're working on a longer term solution to this, there's an open ticket on the repo
<Degi>
Woo cool schematic finished
<Degi>
Much fun routing that
<azonenberg>
we're a long ways from routing
<Degi>
Well yeah the schematic review, which might take a while
<azonenberg>
need to pick out exact components for the BOM on all passives, make footprints for everything
<azonenberg>
and yes, the schematic review
<Degi>
Do you have a footprint for the fpga
<azonenberg>
I have FTG256, FGG484, and FFG1156. Not sure if I've got a 676, but those are easy to generate with the array tool
<azonenberg>
the QSFP+ cage and all of the DC-DCs will be more work as they're not regular grid patterns
<Degi>
Hmh okay
<Degi>
So its a full BGA then..
<azonenberg>
Yeah it's full array 26x26 1mm pitch
<azonenberg>
27x27mm package size
<Degi>
Tbh thats a pretty nice package
<azonenberg>
i mean compared to FLCGA2304 it's nice, lol
<azonenberg>
or whatever the xcvu9p comes in
<azonenberg>
or even the ffg1156 that the biggest artix comes in
<Degi>
Or the ECP5 which have 0.8 mm pitch and some balls are missing etc., I hope that JLC can do that...
<Degi>
According to my measurements, they barely should be able to
<azonenberg>
oh, lol. yeah for cheap fabs 1mm is as tight as i go on bga
<azonenberg>
which is one of the things i like about xilinx vs lattice
<azonenberg>
1mm is much more friendly to work with on cheap projects
<miek>
i just did one of those on JLC, it was easy enough though i don't have a huge amount of it routed out. they did make my vias square though, which is a new one for me...
<azonenberg>
square pads or drills? ;p
* azonenberg
imagines laser drilled square vias
<azonenberg>
or a releaux triangle bit
<miek>
lol, pads :)
<Degi>
Huh they changed your gerbers?
<azonenberg>
this is also why i like working with multech for board fab
<miek>
yeah
<azonenberg>
They just don't change stuff without telling you
<azonenberg>
if they're going to change anything they tell you, send you a list of suggested DFM changes, and ask for your approval
<azonenberg>
and they send you final gerbers they are actually fabbing with the lot code and everything
<Degi>
I mean last time I ordered something, they told me what to change
<Degi>
nice
<Degi>
But they also cost a few hundred...
<Degi>
dfm?
<azonenberg>
design for manufacturability
<azonenberg>
they've even caught little things like one time i had the edg eof a board not quite square
<azonenberg>
the bottom right corner was 50 microns to one side of the top right
<azonenberg>
but they didnt silently fix it
<Degi>
lol yeah
<azonenberg>
they saw it during their design review and asked me what to do
<azonenberg>
i sent them revised gerbers and everyone was happy
<miek>
they did notice a serpentine that was gonna short with itself and emailed asking what i wanted to do, which was nice
<azonenberg>
the service i get from multech is great. i've worked with much more expensive US fabs that didn't do half the QA they do
<azonenberg>
They send you the resin-embedded cross sections, solderability test specimen, and impedance test strips with every order
<azonenberg>
Not only do you get a 10+ page QA report with every order, you get all the info you need to repeat their measurements if you have any doubts they did the test right
<azonenberg>
because they literally send you the same sample they did the measurements on
<Katharina>
azonenberg: Does glscopeclient currently support Cypress FX2 logic analyzer chipsets or is it a non-goal to support pure logic analyzers?
<azonenberg>
That is a goal, it does not currently support any
<azonenberg>
Patches welcome
<Degi>
Wow they make that individually fore
<Degi>
each pcb and not for a panel?
<azonenberg>
Degi: the QA report is per order
<azonenberg>
since it uses some destructive analysis for cross sections etc
<Degi>
Hmh why wont they do it per panel then
<azonenberg>
but they do visual/electrical inspection of each board
<azonenberg>
If there's multiple panels in th eorder you get multiple impedance test coupons
<Degi>
Like that way if theres like a few different designs on a panel they need to add that to each panel
<azonenberg>
and they just list min/max impedance in the report
<Degi>
*have multiple per panel
<azonenberg>
I've never done a multi design panel with them
<Katharina>
azonenberg: great, I think ill just do that for fun and to get a bit more into the inner workings of glscopeclient. Also, sigrok already shows how to communicate with fx2 devices, so theres reference work
<azonenberg>
only multiples of one unit
<oskar>
Hey I've got a question regarding the Github SSH issue if you don't mind... Github says I've successfuly authenticated but I still can't clone the whole thing, doc is still empty
<Degi>
I mean do they put orders from different people on a panel?
<azonenberg>
oskar: did you clone recursively?
<Katharina>
did you do --recursive?
<azonenberg>
Degi: no
<Degi>
Ohh
<azonenberg>
this is a custom panel made to my spec
<oskar>
Oh No I'll try that, I was using the github ssh link
<Degi>
Huh no wonder its a hundred bucks
<azonenberg>
oh it was more than a hundred
<Degi>
I mean a couple hundred heh
<azonenberg>
i think it was like 700 or so for a batch of 50 probes?
<azonenberg>
after shipping and such
<Degi>
Like at JLC they put as much as possible onto a panel and if your type is seldomly ordered it costs much
<Degi>
Huh
<azonenberg>
Yeah. multech is not a batch service, they're a manufacturer
<oskar>
It worked, thank you!
<azonenberg>
they're relatively cheap compared to a high end US manufacturer but expensive compared to batch
<Degi>
Ahh
<azonenberg>
and the QA is the best i've seen anywhere. at any price
<azonenberg>
maybe high end DoD fabs etc do this, or places making medical devices or something
<Degi>
Wow they measure solder mask diagonally
<azonenberg>
but not for everything
<azonenberg>
this isnt' even like their super special white glove serviec
<azonenberg>
they do this on every order
<azonenberg>
i've done 2 layer fr4 boards with nothing fancy at them
<azonenberg>
and i still got this
<azonenberg>
i mean they didnt measure impedance obviously
<Degi>
Hmh I guess the price isnt really proportional to PCB area? I guess most of it is work cost?
<azonenberg>
most of it is setup costs
<Katharina>
oskar: great :)
<azonenberg>
they have like a $500 minimum for multilayer or something along those lines
<azonenberg>
maybe a bit less, i think i've done $300 range orders
<azonenberg>
Katharina: go for it. Also just for terminology's sake, to avoid confusion between various components of the project
<Degi>
Maybe we should add to the README how to clone it
<azonenberg>
glscopeclient is the user interface only
<azonenberg>
Degi: we have that i think
<Degi>
Ah yes we do
<azonenberg>
Katharina: there should be no scope/driver specific code in glscopeclient at all
<Katharina>
yea i know. it would be implemented in scopehal. but you know im not good with words
<azonenberg>
libscopehal is where all of that lives
<azonenberg>
Just making sure we're using the same words to mean the same thing :)
<miek>
will scopehal work well for devices with one continuous long waveform right now?
<azonenberg>
miek: There has to be an end to a waveform
<azonenberg>
architecturally it expects to acquire data, process it, and display it in blocks
<Degi>
Maybe put something inbetween that cuts it up in pieces
<azonenberg>
if those blocks have no delay between them, that's fine
<azonenberg>
but there needs to be boundaries
<azonenberg>
and there is currently no support for a "rolling" display mode
<Degi>
I'd recommend vigorously mixing epoxy in a round container, instead of carefully mixing it in a square one, if you dont want to have sticky slime in the corners... oops
<azonenberg>
Degi: lol
<azonenberg>
this is why i like the little pre-mixed epoxy packets
<Degi>
Instead of trying to minimize faults in epoxy pouring, maybe I should embrace them as part of the design
<Degi>
Hmh yes this stuff was like 20 bucks for 2 liters tho
<azonenberg>
they're more expensive but allow for no mistakes in measuring, and are easy to mix
<Degi>
It cures in approx 1-2 days but if you heat it to like 200 °C or so it cures in a few mins
<azonenberg>
pre-measured*
<Degi>
Ahh pre measured
<Degi>
I did the measuring very right
<Degi>
But the mixing was meh
<azonenberg>
the ones i use are pricier, like $4 or so for a small packet of 2.5 or 5 grams
<oskar>
Sorry for the constant questions, but I've got another issue now when trying to cmake the scopehal. It gives me the error "Variable 'exec_prefix' not defined in '/usr/local/lib/pkgconfig/ffts.pc'
<azonenberg>
oskar: hmm, that's a new one
<monochroma>
oskar: what distro are you on?
<azonenberg>
that sounds like your FFTS is set up wrong
<oskar>
Ubuntu 20.04
<oskar>
and i did it like the guide says
<azonenberg>
oskar: have a look at that file and see if there's an exec_prefix line
<azonenberg>
if not, try adding "exec_prefix=${exec_prefix}" (without quotes) below the prefix line and see if that solves it
<azonenberg>
that's what my ffts install has at least
<monochroma>
wonder if ffts updated and borked
<azonenberg>
last commit on the github for ffts was june 2017
<azonenberg>
it's a fft library, there isnt really a ton of reasons to update it
<oskar>
Checking now
<monochroma>
azonenberg: tell that to gcc libc ;)
<azonenberg>
lol
<oskar>
mine says "exec_prefix=${exec_prefix}"
<azonenberg>
that's what it should say
<azonenberg>
that's really weird that you're getting that error then...
<oskar>
Yeah very strange
<azonenberg>
the file exists at the location cmake is looking for it?
<oskar>
Yep exact same
<Katharina>
i have never seen this issue before, thats super odd
<Degi>
Is it happening at "sudo make install"?
<oskar>
No, "cmake ../"
<oskar>
Yeah the file is definetely at the right directory with that text in it
<Degi>
Are you in the build directory?
<oskar>
Yup
<azonenberg>
can you pastebin the entire ffts.pc?
<oskar>
Sure 1 sec
<azonenberg>
wait a minute
<azonenberg>
it's not just you i think. let me check something
<oskar>
Oki
<azonenberg>
So i get that error when i run pkg-config ffts --libs
<Degi>
Maybe something on the debian side brok eit?
<azonenberg>
But my build works
<azonenberg>
let me do a new build in the build dir
<azonenberg>
so when i build in a brand new build directory without using the existing cmakecache
<azonenberg>
i get that printed as a warning, however it still finds libffts and the build seems to work
<azonenberg>
oskar: on your system does it abort or does it finish generating the config properly?
<azonenberg>
that may just be a warning
<oskar>
Ah yes, mine finds libffts, however shortly after it says "Could NOT find GLEW (missing: GLEW_INCLUDE_DIRS GLEW_LIBRARIES)"
<azonenberg>
ok, so that is probably a non-fatal problem then. The missing glew is the resuilt of a very recently added and not yet added dependency
<oskar>
At the end it still says configuring incomplete, errors occured
<azonenberg>
not yet documented*
<azonenberg>
install libglew-dev and you should be good to go
<oskar>
Ah great!
<azonenberg>
Katharina added that dependency just a few hours ago
<azonenberg>
and hasn't sent me the PR for scopehal-docs yet :)
<Katharina>
hah i knew it would make problems!
<oskar>
Worked perfectly! Sorry if it's a stupud question, how but do I open it now? Sorry I'm quite a Linux Newbie
<Katharina>
sorry oskar :P
<oskar>
No problemo
<azonenberg>
Katharina: i wasnt expecting new people to be trying to use it quite that quickly lol
<azonenberg>
oskar: just run src/glscopeclient/glscopeclient from the build directory
<azonenberg>
it should pop up a dialog asking you to connect to the scope
<Degi>
Oh it has a dialog now..
<azonenberg>
Yes, that was recently added
<azonenberg>
there's no "open file" option there, though - i still have to add that
<azonenberg>
oskar: nickname can be anything, that's only used if you have more than one scope connected at once
<Degi>
Hmm so I can like select a network connected rigol there... Hmm should fix that driver sometime
<azonenberg>
as far as the rest, what scope are you trying to talk to and how is it connected to your computer?
<oskar>
I'm still a tad confused how I run it, I'm in the src/glscopeclient directory
<azonenberg>
just launch glscopeclient the same way you would any other executable, from whatever shell you compiled the code in
<oskar>
Ah oki
<azonenberg>
(from build/src/glscopeclient, not the source directory)
<oskar>
Ah ofcourse I was confused, I forgot to run "make"
<oskar>
Lol
<azonenberg>
Lol
<azonenberg>
that would help
<oskar>
Yeah I'd assume so :P
<Katharina>
make -j uses all your cores btw
<oskar>
Hopefully some stuff works on my Keysight
<oskar>
I was the guy on twitter who responded to your thing
<azonenberg>
Katharina: is there -j in the build directions?
<Degi>
Hmh maybe we can put that into a script in scopehal cmake
<azonenberg>
oskar: what model are you trying to use?
<oskar>
MSOX2024A
<Degi>
So we can do ./install.sh or something and it does stuff
<azonenberg>
oskar: i think that's actually an agilent model that's now sold under the keysight brand
<Katharina>
azonenberg no
<azonenberg>
but it dates back a fair bit. Good chance it will work
<azonenberg>
for driver obviously you want agilent, for transport use "lan" assuming it is set up for SCPI over TCP instead of LXI or something else
<azonenberg>
then for path use the IP address and port number of the SCPI connection, in ip:port format
<oskar>
Oki will do
<azonenberg>
If you have any issues, adding --debug to the command line for glscopeclient may print more helpful information
<oskar>
Okay great. Thanks :)
<Katharina>
electronic_eel i will in a week haha
<Degi>
vdsl is that thing that comes from the telephone plug?
<azonenberg>
Degi: Katharina wanted to use the rigol driver at some point btw
<electronic_eel>
yeah, from the phone plug into your modem/router
<azonenberg>
so fixing it up fully before she gets back in the office will be nice
<Degi>
Oh then I should get working on it soonish probably
<Katharina>
yea, thats also the reason why i ported the application to run on windows, i want to incorporate it into my workflow at work
<Katharina>
we sadly are stuck with windows machines
<electronic_eel>
shouldn't it be easy to get scopehal to build in WSL, without a native port?
<azonenberg>
electronic_eel: scopehal, the library, yes
<electronic_eel>
the usb interfaces won't work there
<azonenberg>
the UI i'm not so sure about
<azonenberg>
but for maximum usefulness i think we want it native
<Katharina>
i dont think WSL can do GLÖ
<Katharina>
*GL
<azonenberg>
I used GTK and OpenGL with the express intention of windows porting happening down the road, i just didn't want to expend any effort on it
<azonenberg>
The fact that Katharina got it compiling and running on windows in less than a day makes it clear that my efforts to keep the code reasonably portable worked pretty well
<electronic_eel>
yeah, a native port is better of course
<Degi>
Huh did the fan on my scope break
<azonenberg>
Wasn't my code, i swear
<electronic_eel>
lol
<Degi>
There it works
<Degi>
Heh lol
<azonenberg>
Pay no attention to the COOL:FAN OFF in the SCPISocketTransport constructor
<electronic_eel>
Degi: it decided your ears need a break from all the noise
<Degi>
lol
* monochroma
wants glscopeclient on SGI IRIX :<
<azonenberg>
monochroma: good luck finding an irix box with compute shaders
<Degi>
Huh a resettable fuse basically that is fast?
<oskar>
After building glscopeclient, I still can't seem to run it. What command should I be using? Sorry if it's a dumb question
<azonenberg>
oskar: from the build directory, ./src/glscopeclient/glscopeclient
<electronic_eel>
Degi: yeah, sorta, but it is primarily designed to block transients from outside, not overcurrent from a short circuit
<Degi>
huh
<oskar>
I got a error saying no such file or directory
<azonenberg>
oskar: the build completed with no errors?
<electronic_eel>
Degi: and it "only" goes up to 850V, so I combine it with the gas discharge tube
<oskar>
Yep it said it built glscopeclient and quite a few other things
<Degi>
Well as long as they trigger fast enough
<Degi>
But I guess if theyre rated for 150 V, 850 V is enough overdrive to trigger very fast
<oskar>
nevermind I fixed it
<electronic_eel>
Degi: they trigger within a µs, and it really works, I saw it on my scope, the current goes down nearly linear
<azonenberg>
oskar: so it runs now?
<Degi>
Neat
<Degi>
Well microseconds is long time, but I guess stuff on there happens slowly anyways
<oskar>
Yep perfectly! Sorry for the confusion :D
<Degi>
Ooh I should try building the nanosecond pulser again and seeing how fast it is with my scope. IIRC it got destroyed from overvoltage
<Degi>
(Also not sure how to measure it, considering that it EMPs everything within a few cm to a few dozen cm range depending on how big the loop area is.)
<electronic_eel>
Degi: the regular test impulses are 8/20µs and 10/10000µs, so I think assuming µs speeds isn't too far off
<Degi>
Yes exactly, phone lines arent the fastest things
<electronic_eel>
lots of resistance and inductance, unless you have a direct lightning hit
<azonenberg>
oskar: so does it talk to your scope ok?
<Degi>
Hmm kinda wanna test that with the pulser device
<oskar>
Haven't tried just yet, will let you know after I get a snack
<electronic_eel>
Degi: what kind of pulser did you have? do you happen to have schematics?
<azonenberg>
oskar: if your primary platform is windows, give it a few more days and we should have something stable enough for you to try
<azonenberg>
this time yesterday it didnt even compile on windows :p
<Katharina>
ye at least the docs will be done then
<oskar>
Great yeah it is
<oskar>
I look forward to it
<Degi>
Well I glued three sheets of aluminium foil with two sheets of laser printer foil in alternating layers, create a voltage difference between middle foil and outer foils, short one outer foil with middle foil on one side of the sheet, on the other side between the two outer foils there will be a big voltage difference
<Degi>
Needs a few kV, I think I did it at roughly 10-20
<azonenberg>
Degi: so very improvised high voltage capacitor
<Degi>
Well its transmission line ish
<Degi>
But yes
<Degi>
Its cheap and has quite some energy density, can get like a joule
<Degi>
Though the fast discharges dont exactly help the foil life expectancy, especially if there is air inside, since that ionizes and can make hot spots
<electronic_eel>
how did you apply the kV? do you have a high voltage lab supply?
<Degi>
A TV flyback and a ZVS inverter
<Degi>
I've measured the output to 26 kV using 12 V input recently, though back then I think I had a different flyback with similar output
<Degi>
(With 100-200 MOhm load)
<electronic_eel>
and how did you make the pulse?
<Degi>
Ill upload a pic
* monochroma
built a PC control interface for a -60kV spellman years ago
<electronic_eel>
I once thought about building an improvised ESD gun, but I couldn't come up with a proper solution to trigger it, without sparks over a relay or similar
<Degi>
Oh you can trigger spark gaps with a trigger transformer
<electronic_eel>
but doesn't the spark gap wear out fast?
<Degi>
Hmh idk
<Degi>
It actually keeps going for quite a while
<Degi>
The foils wear out rather soon
<electronic_eel>
instead of the foils I'd have used a commercial hv capacitor
<Degi>
So the two pointy things at the left is the spark gap, you apply the HV supply across it
<electronic_eel>
ah, ok, so you just increase the voltage until it sparks over
<Degi>
The thing labelled R is a resistor which can do a lot of volts like a long piece of ESD foam with copper wires attached to it haha
<Degi>
And on the right side the circle with V gets the voltage pulse
<Degi>
If you do it right, the pulse could get quite short since it acts as a transmission line and the spark gap as a switch, though in this case the foils were rather wide (20 cm) and the spark rather narrow (1-2 mm?) so the spark inductance probably kinda limited risetime
<Degi>
If it behaves like a transmission line, output voltage could be 2x input voltage.
<Degi>
The special thing about this setup is, that instead of V you can attach a loop of wire and that will get a high voltage pulse across it. A simple spark gap probably wont perform as well
<electronic_eel>
I have an oldish car ignition coil here, I plan to sometime use it to create powerful pulses
<Degi>
Well it needs a DC supply
<Degi>
Unless your coil can supply like 1-2 J
<electronic_eel>
but I think they have som stuff in there that limits the risetime for emc compliance
<Degi>
Also that image isnt really to scale, the red dielectric somewhat extends over the sides
<Degi>
They have an iron core, right?
<Degi>
That wont get nanosecond pulses...
<Degi>
And the part in the middle is like 500 µm thick while the spark gap is 10 mm...
<electronic_eel>
the really old ones had iron cores, this is a more modern one with ferrite instead
<Degi>
Yeah still
<Degi>
They arent really designed for fast pulses, they probably have a lot of stray inductance too
<electronic_eel>
yeah, taking a flat capacitor is probably better for fast rise times
<Degi>
Heh yes that price is pretty ok, you'll need some glue around the borders though
<electronic_eel>
165 kilovirus / mm?
<Degi>
Youd want like 3-4 cm creepage in air, but hot glue or epoxy helps a lot
<Degi>
Lol
<Degi>
Wel the worst grade has 87 kV/mm
<Degi>
It helps layering dielectrics with inside coated with conductive stuff
<Degi>
Maybe these rescue foils in first aid kits, stacked and pressed together very tightly would make a good dielectric
<azonenberg>
Degi: they have metal on them
<azonenberg>
is that helpful?
<Degi>
Yes
<azonenberg>
i dont know if it's one or two sided
<Degi>
Hmh one side can be removed with acetone
<Degi>
The golden stuff
<Degi>
The rest is acetone resistant
<azonenberg>
oh are you trying to do like... i forget the name
<azonenberg>
the things that they have on the shafts of big van de graaf generators etc
<azonenberg>
to distribute the field more evenly
<Degi>
Hmh?
<Degi>
Corona rings?
<azonenberg>
grading rings
<Degi>
Well its similar
<Degi>
The thing is if you have a big bulk solid dielectric, a fault along the electric field lines would be very bad, but by using thin dielectric layers with metal inbetween, the voltage gets distributed more evenly
<azonenberg>
So yeah it functions like grading rings
<azonenberg>
i'm not sure the film on a mylar sheet would be thick enough for that
<azonenberg>
but i guess try and see
<Degi>
Hmh yeah wonder if its conductive enough
<Degi>
"Dielectric films tend to exhibit greater dielectric strength than thicker samples of the same material." Thats the principle basically
<electronic_eel>
maybe because the conductive material helps distribute the voltage evenly across the whole material, preventing hot spots?
<Degi>
yes
<Degi>
m_transport->SendCommand("WAV:PRE?");
<Degi>
string reply = m_transport->ReadReply();
<Degi>
I get a error there in munmap_chunk()
<Degi>
invalid pointer, I think its something more internal than the rigol class?
<Degi>
...do i need to update libc maybe
<Degi>
Oh wow, 10 GB of updates. whops
<azonenberg>
Degi: run under valgrind and see if you get more details on the failures?
<Degi>
valgrind? Ive been running it in gdb
<azonenberg>
that smells like memory corruption, that code is probably not the problem
<azonenberg>
it's probably freeing an invalid pointer because something earlier on overwrote it
<azonenberg>
valgrind (or asan) are good at finding bad writes at the point of failure, not later on when the symptoms are seen
<Degi>
Huh howd that happen
<Degi>
how do I use that? is that a program
<azonenberg>
yeah, it should be in pretty much any distro package manager
<azonenberg>
the default memcheck mode can be triggered just by doing "valgrind $executable"
<azonenberg>
passing args as needed
<Degi>
Hmh its supposed to be kinda slow right
<Degi>
Wow it works now
<azonenberg>
yeah but do you get any errors printed in the console?
<Degi>
Address 0x9653498 is 0 bytes after a block of size 1,000 alloc'd
<Degi>
Syscall param socketcall.recvfrom(buf) points to unaddressable byte(s) huhh
<azonenberg>
sounds like you have an incorrect size then
<azonenberg>
off by one or something
<Degi>
Oh
<Degi>
Now its clean
<Degi>
Wow
<azonenberg>
you found it?
<Degi>
unsigned char* temp_buf = new unsigned char[maxpoints + 1];
<Degi>
yes
<azonenberg>
valgrind is awesome for finding this kind of bug
<Degi>
Thanks
<azonenberg>
it slows your program to a crawl because it instruments every allocate and free
<Degi>
ahh
<azonenberg>
But it does a great job of not only finding bad pointers, but finding where they came from
<Degi>
How do I change trigger offset in scopehal
<azonenberg>
in scopehal or glscopeclient? there are two very different answers :)
<Degi>
glscopeclient
<Degi>
lol
<Degi>
Dragging the time bar doesnt really seem to do it
<azonenberg>
Because in scopehal, you call Oscilloscope::SetTriggerOffset()
<azonenberg>
In glscopeclient, you don't
<azonenberg>
there's no UI for it yet
<Degi>
Oh
<Degi>
k
<azonenberg>
that's scopehal-apps:#12
<azonenberg>
has been on the tracker since april 2019
<azonenberg>
the API was added fairly recently but the UI to call that API doesn't yet exist
<azonenberg>
I think it will eventually be similar to the trigger stuff
<azonenberg>
where dragging the time bar moves the waveform in the display, but there's a little arrow inside the bar that denotes the trigger position
<azonenberg>
that can be dragged separately
<Degi>
good idea
<azonenberg>
But i've been busy enough doing other stuff that this ticket wasnt the top priority
<azonenberg>
That is one of the last bits of major front panel UI that we don't have controls for in glscopeclient i think
<azonenberg>
the previous major one was memory/sample rate control which are now implemented
<azonenberg>
although at least for lecroy its not as nice as i'd like
<Degi>
How do I get my fork up to current commit, or should I just delete it and redo
<azonenberg>
just do a git pull?
<azonenberg>
you may have to do some merging but i dont think the rigol driver was significantly touched
<Degi>
Oh neat I can git pull a URL
<Katharina>
degi: I only replaced usleep() calls in the rigol driver to make it compile on windows
<Degi>
Yes I see
<Katharina>
while youre at it, you could just remove usleep completely, even on linux - i was overconservative with keeping the old code with the first few changes
<Degi>
Hmh the UI waits for the next sample now though
<Degi>
Well the usleep doesnt seem to change anythingabout that
<_whitenotifier-f>
[scopehal] x44203 opened pull request #160: Add Trigger Offset to Rigol - https://git.io/JfNgJ
<Degi>
Im not very competent with git... Well at least there is git push --force and git reset HEAD~
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JfNgk
<_whitenotifier-f>
[scopehal] x44203 f1bf3c8 - Add Trigger Offset to Rigol
<_whitenotifier-f>
[scopehal] azonenberg 2a24220 - Merge pull request #160 from x44203/master Add Trigger Offset to Rigol
<monochroma>
Degi: be careful, --force is basically the best way to break the repo :P
<Degi>
oops
<Degi>
It said that im commits behind
<Degi>
Which ive deleted before with reset
<Degi>
I mean I dont want the commit history to look ugly~
<azonenberg>
Degi: yeah never force push to a repo other people use
<azonenberg>
if its your own private branch it's ok-ish but still best to avoid
<Degi>
Hmh yes it was my private branch
<Degi>
Well yeah when other people use thats probably not such a good idea
<azonenberg>
the big thing is, forc epush basically takes your working copy and shoves it into the repo
<azonenberg>
overwriting whatever else was there including history
<Degi>
Huh the rigol says something about invalid input+
<miek>
imo it's totally fine to force push branches. it's really only when someone has based commits on it that it'd cause trouble
<azonenberg>
even if somebody has just cloned the branch it's annoying
<miek>
like if a PR flags up some unrelated whitespace changes or something, i'd much rather it was amended & force-pushed rather than an extra fix-commit that'll mess up git blame etc.