<_whitenotifier-3>
[scopehal] azonenberg b1ae9a5 - SPIFlashDecoder: implemented a bunch of commands used by 256+ Mbit Winbond flashes
<_whitenotifier-3>
[scopehal] azonenberg a0e8317 - SPI/QSPI: properly discard partial data at start of capture if CS# is low in the first sample of a waveform
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JOXFT
<_whitenotifier-3>
[scopehal] azonenberg d862b37 - 0x6c is 1-1-4 fast read, not 1-4-4
<azonenberg>
So right now, selecting a packet in the protocol analyzer window takes about 255 ms for my test dataset with 303237 packets
<azonenberg>
That can definitely be improved
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±5] https://git.io/JO1sj
<_whitenotifier-3>
[scopehal-apps] azonenberg 9f6da22 - WaveformArea: Fixed bug where trigger phase wasn't correctly used when displaying decode overlays of complex type
<_whitenotifier-3>
[scopehal-apps] azonenberg 2d58722 - WaveformArea: don't waste time looking at packets if the analyzer isn't shown
<_whitenotifier-3>
[scopehal-apps] azonenberg 090de92 - ProtocolAnalyzerWindow: Massive (~2 OOM) speedups for selecting packets in large protocol databases
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JO1GJ
<_whitenotifier-3>
[scopehal] mubes 5f54b69 - Fix uninitialised variable warning and prettify SWD line reset indicators
<_whitenotifier-3>
[scopehal] azonenberg 51edb97 - Merge pull request #422 from mubes/swd_var_warning Fix uninitialised variable warning and prettify SWD line reset ind.
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #422: Fix uninitialised variable warning and prettify SWD line reset ind. - https://git.io/JOXPX
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO1Gt
<azonenberg>
So one big item on my to-do is figuring out out how to do blending/intensity grading when multiple protocol events occupy a single pixel of width in a view
<azonenberg>
e.g. if you have a whole bunch of packets and you zoom out
<azonenberg>
right now some of them can disappear entirely
<azonenberg>
or worse yet you get nasty aliasing effects
<azonenberg>
so if you're looking at alternating K28.5 D16.2 on an idle 1000base-X link it should show a uniform blue-purple if you zoom out
<azonenberg>
instead you randomly see blue and purple as you scroll/zoom around
<azonenberg>
and it implies structure that's not actually there
<azonenberg>
i think this would be best solved by moving the protocol overlays to GPU rendering
<azonenberg>
rather than trying to do all of this in cairo
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #284: Agilent MSOX2024A - Performance issues and crash - https://git.io/JO1gG
Tost has joined #scopehal
bvernoux has joined #scopehal
sam210723 has quit [Quit: Leaving]
xzcvczx has joined #scopehal
<azonenberg>
xzcvczx: if you havent checked already there's a full list of prereqs and build instructions in the manual
<xzcvczx>
yeah the distro i uses has libgomp-devel as its own package
<xzcvczx>
so still would have missed it :)
<xzcvczx>
ah ok, i was reading hte github readme as well which didn't have the -j for scopehal-apps but did have it for ffts
<azonenberg>
i mean that just parallelizes
<azonenberg>
the two sets of build directions should be in sync
<azonenberg>
if not, i need to work on that
<xzcvczx>
yeah some (bad) software breaks if parallelized builds so i wasn't sure
<azonenberg>
yeah i do full -j on everything but i also have 192gb of ram
<azonenberg>
if you don't, you probably want to set a job limit :p
<xzcvczx>
haha tbh i have never tried it on linux, but on mac it would just destroy the machine
<xzcvczx>
>_< failed to open file
<azonenberg>
ah yes
<azonenberg>
you used a relative path?
<azonenberg>
right now when glscopeclient starts up it chdir's to the build directory because that's where all the data files are located. improving path resolution for that is on the todo list, we have an open ticket for it
<azonenberg>
in the meantime when opening files on the command line you have to use an absolute path
<xzcvczx>
ah lol
<xzcvczx>
ah dang my machine isn't good neough anyways, requires glsl 4.3
<xzcvczx>
well 4.30
<azonenberg>
what graphics card/driver are you using?
<xzcvczx>
its a rather old machine
<xzcvczx>
ivy bridge
<azonenberg>
ah yeah thats on the old side for integrated graphics. throw in any discrete GPU made in the past 5-10 years and it should be fine though
<xzcvczx>
i think its hd 4000
<azonenberg>
unless its a laptop
<xzcvczx>
yup its a laptop
<azonenberg>
yeah sadly older laptops and macs are the two hardware platforms that are ~impossible for us to support because it relies so heavily on compute shaders for rendering
<azonenberg>
(macs running osx, if you dual boot windows/linux they're fine)
<azonenberg>
apple just doesnt have modern drivers
<xzcvczx>
its not a mac, i have switched off apple since i had to file a suit against them
<xzcvczx>
but it is an old laptop
<xzcvczx>
although i have got another one here that will work
<azonenberg>
oh?
<azonenberg>
iirc skylake (~2015) and newer integrated graphics are supported, but on the discrete side i think GTX 400 is the minimum for nvidia. not sure about the corresponding AMD side, my setup at home is all intel+nvidia
<xzcvczx>
i only have integrated
<xzcvczx>
i have 2 machines that are 3rd gen and 2 that are 10th gen
<azonenberg>
so comet lake? those should work just fine
<azonenberg>
I've run glscopeclient on my 2016-era lecroy scope (like, on the scope's OS rather than connecting via usb/ethernet) and that's a skylake... i3 or i5
<xzcvczx>
ok it will take me a few mins to get it installed on here
Tost has quit [Ping timeout: 240 seconds]
GenTooMan has joined #scopehal
<xzcvczx>
does scopehal-apps need ffts git or is it okay with a relased verison?
<azonenberg>
released version should be ok. ffts hasn't really changed in years
<azonenberg>
i've actually thought about taking it over to some extent and maybe updating some of it to use AVX or something
<azonenberg>
it's a pretty old library at this point but to keep the code permissively licensed i can't use fftw or any of the new hotness
<xzcvczx>
that makes sense
<xzcvczx>
building now
<xzcvczx>
unfortuantely unlike some people i dont have 192GB of ram in order ot make it go real quick
<azonenberg>
Lol yeah, on a more reasonable system -j8 or -j16 is probably doable
<xzcvczx>
oh cmon
<xzcvczx>
glew error now
<xzcvczx>
never mind i can probably guess what hte issue is here
<azonenberg>
wayland?
<xzcvczx>
you are smart
<azonenberg>
already known problem, no workaround yet but there's a ticket for it
<azonenberg>
it should work well under X
<xzcvczx>
gah this computer really isn't setup for x
<xzcvczx>
the screen order is messed up
<xzcvczx>
as loathe as i am to, i will probably need to read the manual
<xzcvczx>
you were working on this on christmas day o_O
<azonenberg>
there was a plague going on, what was i supposed to do?
<azonenberg>
not like i was going anywhere
<xzcvczx>
in my defence we have rather avoided the plague
<xzcvczx>
this is mighty fine
<GenTooMan>
I assume you are using the unstable Catch 3 code instead of Catch 2? as the stable version of Catch2.
<GenTooMan>
for building scope_hal that is
<azonenberg>
I've only tested on 2
<azonenberg>
but you can also just disable testing entirely and not worry about it
<azonenberg>
it's only needed for unit tests and we don't have a lot of those yet
<GenTooMan>
it's to be honest somewhat confusing. I suppose the simplest thing is to remove Catch from my system and disable unit testing as you suggested.
<xzcvczx>
ok now at least i dont have to be running xorg to run glscopeclient
<azonenberg>
Making it able to run under full wayland is very much a to-do item though
<xzcvczx>
well at the moment i am just cheating using GDK_BACKEND="x11"
<xzcvczx>
but i want to see if there is a way to specify that in code
<d1b2>
<zyp> I looked into that recently -- eventually it might be possible to use opengl via zink via moltenvk, but zink doesn't support that properly yet
<d1b2>
<zyp> although general vulkan via moltenvk appears to «just work»
<ericonr>
xzcvczx: there is, it's called setenv
* xzcvczx
sets ericonr outside
<azonenberg>
incidentally, right now we use OpenMP but you get bad performance unless you set OMP_WAIT_POLICY=PASSIVE
<azonenberg>
this variable appears to be read by library code prior to main() starting
<azonenberg>
which means you cannot setenv it
<azonenberg>
Figuring out a way to force this is still on my to-do list
<azonenberg>
i think the best option is to check if it's not set, then setenv and exec yourself
<monochroma>
shell script wrapper! :P
<azonenberg>
I'm trying really hard to not turn into Big EDA tools that have shell script wrappers, shipping their own copy of qt, etc
<azonenberg>
two different JVMs for running different subsystems
<azonenberg>
you know the deal :p
<xzcvczx>
i assume there is some way to set it with an api call
<azonenberg>
No
<azonenberg>
there is no API to set that mode
<azonenberg>
I looked for a long time
<xzcvczx>
oh you mean for openmp
<xzcvczx>
my bad
<azonenberg>
it can only be set by environment, and the env var is read by startup code prior to main()
<xzcvczx>
yeah i thought you were meaning gdk_backend
<ericonr>
azonenberg: kinda makes sense, since they avoid the inherent raciness in reading it when the application is already doing something
<ericonr>
java does a re-exec into self trick to set LD_LIBRARY_PATH :D
<xzcvczx>
yes because java is an excellent role model for everything
<ericonr>
oh, I myself prefer the wrapper script
<ericonr>
though it would have to be templated for different install locations and yada yada
<azonenberg>
on that note the higher priority infrastructure fix is the data file location issues
<GenTooMan>
glscopeclient works works but for some reason won't connect to my siglent scope over the network "Resource temporarily unavailable"
<xzcvczx>
works works is important
<GenTooMan>
I suppose I can submit an patch for the base README.md regarding Catch 2/3 along with doc generation, it might not be a complete disaster :D
<GenTooMan>
hmm might be nice to have use of some of the lan scan features I've used to find junk hanging on my land.
<GenTooMan>
land = LAN
<xzcvczx>
if only i had known that i could just use env vars to get it running in both circumstances i thought i was stuffed
<GenTooMan>
So much for the idea of "ignorance is bliss", how about the use of nmap to find stuff on the lan?
<xzcvczx>
GenTooMan: it reminds me of the joke on bash.org about the person who apparently was able to ping a computer in his house but had no idea of where it was physically
<monochroma>
xzcvczx: lol, classic
<GenTooMan>
heh sounds like the USB bus "which USB hard disk is this "My Passport" I've got 3 (no serial #s on the outside either)
<xzcvczx>
GenTooMan: does the vertical cursor mess up for you?
<xzcvczx>
showing weird random voltages
<GenTooMan>
xzcvczx, um what are normal random voltages?
<xzcvczx>
well not decreasing on an incline for one
<d1b2>
<mubes> @GenTooMan which scope do you have?
<d1b2>
<mubes> Current Siglent driver is only 2000X+/5000X/6000 at the moment until I (or someone else) gets their finger out.
<GenTooMan>
hmm SDS1104X-E
<azonenberg>
yeah 1000 series is a different protocol afaik
<GenTooMan>
SCPI and LXI it states
<GenTooMan>
ports available are 80, 111, 969, 5024, 5025
<azonenberg>
yeah its scpi on 5025
<d1b2>
<mubes> There's scpi and scpi :-(
<azonenberg>
the problem is that the command set is incompatible with the 2000 series
<azonenberg>
scpi is about as standard as jtag
<azonenberg>
it specifies how the commands should be formatted, not what they do
<azonenberg>
other than *IDN? to get the ID code
<GenTooMan>
Ok that makes sense then JTAG is the non standard standard.
<d1b2>
<mubes> Yes, runs raw protocol on that port. The spec is available and pressure is building to get support in :-)
<d1b2>
<mubes> The error handling for misunderstood messages comes down to those "Resource Temporarily Unavailable" for now...and the potential for scope crashes. Can you please send me the exact text in response to *IDN? and we can at least add a sensible error to show that the scope isn't supported yet.
<GenTooMan>
Sent "*IDN?" response "Siglent Technologies,SDS1104X-E,SDSMMEBD3R7102,8.1.6.1.33
<GenTooMan>
,IDN-SGLT-PRI SDS1000X-E"
* GenTooMan
wonders why hexchat did that?
<d1b2>
<mubes> Ta.
<azonenberg>
GenTooMan: and yeah i think we have two or three SDS1000XE series owners interested in support now
<azonenberg>
So it's definitely on the todo list
<GenTooMan>
well obviously the first support is to say "not supported" LOL oh well.
<d1b2>
<mubes> It shouldn't be too long, if thats any comfort.
* GenTooMan
logs into github for the first time in 6 months
<azonenberg>
mubes: btw how is performance on your 2000x? in terms of WFM/s
bvernoux has quit [Quit: Leaving]
<d1b2>
<mubes> 1, give or take a little bit
<d1b2>
<mubes> It doesnt really vary too much according to waveform depth, quite a proportion of the time is turnaround. There are some tricks I can play I think to get up a little bit from there though.
<d1b2>
<mubes> Going down to 10Kpoints doesnt' result in the performance improvement you might expect
<azonenberg>
ok yeah when you've optimized more i'd like some more exact numbers from the status bar for my spreadsheet
<azonenberg>
and i've seen this with a lot of the low end scopes
<azonenberg>
high O(1) overhead but good throughput for deep captures
<d1b2>
<mubes> Sure. I want to parallelise the channel processing and capture....that will bring the times in somewhat
<azonenberg>
yeah look at some of the tweaks i did in the lecroy driver
<azonenberg>
It's fairly well optimized
<d1b2>
<mubes> I've got the lecroy code in there but one of the things it does at the moment is collect 4 channels before it starts processing any of them....thats a bit silly
<d1b2>
<mubes> (My code...no idea what the LeCroy code does in that respect)
* GenTooMan
begins looking at the code ... falls asleep code is so dreary wears the hardware gone...
<azonenberg>
Updated with performance stats from my SDA and PicoScope
<azonenberg>
the older LeCroy with a... sandy bridge? CPU performs worse than the modern skylake based ones, unsurprisingly
<_whitenotifier-3>
[scopehal] azonenberg opened issue #423: SPI flash: allow captures to be exported to a raw binary file - https://git.io/JOD20
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #423: SPI flash: allow captures to be exported to a raw binary file - https://git.io/JOD20
* GenTooMan
finds fun in 'lib/scopehal/SiglentSCPIOscilloscope.cpp', "I doubt I can do much so oh well."
<GenTooMan>
Weird my scope returns a "*IDN?" request but the others don't support the request?
<azonenberg>
*IDN? is supposed to be supported by any scpi compatible instrument
<azonenberg>
and i suspect that comment is probably wrong
<azonenberg>
probably what he means is no *OPT?
<GenTooMan>
Ok that makes sense let me check that command.
<GenTooMan>
it doesn't given an error but gives no response either.
<azonenberg>
yeah that one isn't supported on any known siglent scope
* GenTooMan
edits the comment accordingly.
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JODwK
<_whitenotifier-3>
[scopehal] azonenberg b94cc54 - SPIFlashDecoder: added option to dump captured read/write data to files. Fixes #423.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #423: SPI flash: allow captures to be exported to a raw binary file - https://git.io/JOD20
<d1b2>
<mubes> Yeah, should indeed be *OPT? not *IDN? ... brain fart.
<GenTooMan>
hmm stinky brain expulsions happen I guess :D
<azonenberg>
mubes: also please do not put additional comments in the header block up top
<azonenberg>
put them down below, author information should use a Doxygen style @author tag in a separate comment
<azonenberg>
that block should be uniform across the entire project and is actually about to get cleaned up and refactored
<azonenberg>
so i will be doing a mass replacement of that block on every file in the project and any other content in there will be lost
<azonenberg>
(tl;dr making it say libscopehal instead of antikernel because this code is no longer part of antikernel, and updating copyright to say me "and contributors" since you all didn't sign CLAs so you still own copyright to your contributions)
Tost has quit [Ping timeout: 252 seconds]
<d1b2>
<mubes> TBH It can just be deleted anyway. Its from an earlier time when you needed the names in header files to have have a chance of finding out who the hell cooked that cr?? when you're trying to figure out why something has been done the way it has. Nowadays we've got git blame, so we don't really need it.
<d1b2>
<mubes> Had a hard drive fail today, so my loss is your gain, have written the docpage for SWD. Can't submit it until this system is nursed back to life and I can get a supporting graphic.