<_whitenotifier>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLP9K
<_whitenotifier>
[starshipraider] azonenberg 033018c - Fixed nonexistent layer mentioned in fab notes
<azonenberg>
Just sent the v0.5 AKL-PT2 design off to Multech for a quote. Not going to order until i've done a little bit more testing, but i wanted to at least get a price
<azonenberg>
I'm working on doing some analysis of the glscopeclient performanc edata folks have submitted
<azonenberg>
lain: ^
<azonenberg>
if you could get some data from your old DDA that would be quite helpful too
<lain>
ah
<lain>
cool, I'll poke it when I get some time, probably after xmas as I'm waiting on some adapters before I'll be using the DDA again
<azonenberg>
And just uploaded MSO64 data. While it's the best bandwidth next to the LeCroy's, it's... quite distant
<azonenberg>
it does beat miek's Agilent in throughput at higher memory depths but the O(1) overhead is such that at shallow memory depths performance is mediocre
<_whitenotifier>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLPdp
<_whitenotifier>
[starshipraider] azonenberg 2567439 - Changed export settings to not use gerber x2 (why was this on in the first place?)
<tnt>
Mmm, something is broken in the cmake magic. I specified a CMAKE_INSTALL_PREFIX and it still tries to copy stuff in /usr/lib "/usr/lib/libgraphwidget.so": Permission denied.
<azonenberg>
grep cmakecache for /usr/lib?
<azonenberg>
also possible you have the old value cached and need to just do a clean build?
<tnt>
Well ... looking at lib/scopeprotocols/CMakeLists.txt:install(TARGETS scopeprotocols LIBRARY DESTINATION /usr/lib)
<tnt>
When I zoom in, I can get smaller capture depht, but the triggering is very inconsistent. I get some time as low as 2 WFM and up to 20.
juli966 has joined #scopehal
<agg>
tnt: what sort of settings get you close to 20wfm/s?
<tnt>
1ch 8kS
<agg>
Is that usb or ethernet?
<agg>
Ah I see ethernet
<agg>
What trigger do you have? Wonder why my 3000t wouldn't get above 5
<tnt>
It's the probe just in the probe compensation output of the scope, default setup.
<tnt>
Ok, so apparently my laptop being on wireless what an issue ... I plugged in ethernet cable and now I get a somewhat more stable results at ~ 20 WFM/s
<tnt>
Note that the fw I'm running is kind of ancient ... never felt the need to update and I'm kind of worried I'd loose my options if I did so ...
<azonenberg>
What's the full model number here?
<azonenberg>
i just see 3000x
<tnt>
MSOX3054A
<azonenberg>
also agg: is your 3104T an agilent or keysight brand?
<agg>
keysight
<agg>
the 3000T x-series scopes were released in 2015 after agilent's T&M division became keysight
<azonenberg>
Ok
<azonenberg>
Let me add the T's to the list of supported models under keysight then
<azonenberg>
also spreadsheet updated
<azonenberg>
interesting the T performs so much worse than the older 3000x
<agg>
the SCPI commands are essentially identical to the non-T and I believe almost all are common across the x-series family, the programming manual indicates which are 'core commands' supported across almost all scope families and which are non-core "that provide specific features, but are not
<agg>
universal across all Keysight InfiniiVision oscilloscope models
<azonenberg>
also another thing to think about in the not too distant future is either renaming the agilent driver or aliasing it
<azonenberg>
i'm thinking maybe renaming the driver to "keysight" then aliasing it so you can also use it as "agilent" with the same code
<agg>
makes sense to me
<tnt>
azonenberg: mmm, seems you made a mistake when transcribing in google docs. The number of samples for the 4ch version is always half the one of the 1/2ch version.
<agg>
the -A seems similar performance to the -T at the larger sample depths, so I wonder what's going wrong on mine at low sample depths
<agg>
tnt: i assume that's ch1+3 for two channels?
<tnt>
agg: yes
<azonenberg>
tnt: that look right?
<tnt>
agg: can you control capture depth as a setting ? On mine, AFAICT, I can't ... it's automatic just depending on the horizontal timebase (i.e. I have to zoom)
<azonenberg>
and yeah i suspect what's happening is there is a higher O(1) overhead which is lost in the noise at deeper memory
<tnt>
azonenberg: yup.
<agg>
tnt: do you have 'digitize' as an option under acquire?
<azonenberg>
but with small depths it dominates
<agg>
acquire menu -> digitizer
<tnt>
agg: let me check ...
<agg>
mine is relatively new firmware, could be that a recent firmware has added some overhead
<agg>
or that I'm just not doing something quite right...
<tnt>
agg: nope. acquire just has mode (normal/peak/avg/hires) and segented
<agg>
hmm, I don't think that's a licensed option, might be a T thing or might be a newer firmware thing
<agg>
it lets you just program a specific sample rate and memory depth, instead of basing it on the time division
<tnt>
I have all licenses installed anyway.
<tnt>
agilent shipped the private key along with the public key used to check license files in the first version of the firmware ...
<agg>
not like you even need the keys, as I understand it, you just modify the shortcut file that starts the scope software and add extra options to the argument list
<agg>
mine was a fully optioned refurb anyway so haven't looked really
<agg>
interesting, I just tried 5GS/s 4Mpt 1ch on the default setup with the probe on the cal output and got the same 5WFM/s I was getting last time, compared to your 20 or so, but if I set TCP_NODELAY it goes up to 8.5WFM/s
<agg>
scopehal is still 3.5WFM/s in the same configuration
<tnt>
5WFM/s at 4Mpt ? that's pretty good.
<azonenberg>
> if I set TCP_NODELAY
<azonenberg>
where, in scopehal?
<azonenberg>
or your own code?
<agg>
no, my python script
<azonenberg>
oh
<azonenberg>
i was gonna say scopehal already uses that
<agg>
tnt: sorry, I meant to say 8kpt, to match your fast setup
<azonenberg>
or should anyway
<azonenberg>
with 4M points if you are seeing 3.5 WFM/s instead of 8.5 that's quite a slowdown. You might find it helpful to have a look at timing of packets on the link
<azonenberg>
does it look like scopehal is getting cpu limited somewhere?
<azonenberg>
it's very possible that the waveform download code is unoptimized and horridly slow
<azonenberg>
the lecroy waveform cracking code (raw ADC samples -> fp32) uses AVX2 when possible and is probably going to move to GPU soon
<agg>
glscopeclient is using 9% of one core
<azonenberg>
overall cpu time isnt what matters
<azonenberg>
if i get cpu bound for 50ms then idle for the rest waiting on the network
<azonenberg>
that could still be the cause of the slowdown
<azonenberg>
But its also possible that scopehal has room to optimize more on the scpi side of things. in fact it's practically guaranteed
<azonenberg>
also do a pcap and see if any of the config settings are not being cached and re-polled every frame
<agg>
basically asks for a single trigger, polls until the scope says it's stopped, then asks for channel 1, gets the channel config, gets the channel data, re-triggers
<agg>
from the :SING to the scope saying done is 0.225 seconds
<azonenberg>
agg: So have a look at the lecroy driver to get an idea of some of the optimizations i've done
<agg>
another .141s until the data arrives
<azonenberg>
assuming the scope has an input fifo that actually works (tek, i'm looking at you...
<agg>
it specifically documents that it does and so far my experience is that it does
<agg>
you can send it commands without waiting for a reply or ack and it processes them in order
<azonenberg>
So in that case what I would suggest you try doing
<azonenberg>
is ask for *all* of the preambles up front
<azonenberg>
then all of the data
<agg>
this is with only one channel enabled, so there's only one preamble and one data block anyway
<azonenberg>
ah ok
<azonenberg>
basically minimize round trips as much as you can
<azonenberg>
if you know you have to read two things ask for them both
<azonenberg>
and only then read the replies
<agg>
it takes the scope some 109ms just to respond to :WAV:PRE?
<azonenberg>
If you do this with a tek mso6 it will barf on you because it thinks it's connected to gpib running on a 68k with no ram
<azonenberg>
but a sane, well adjusted scope will just leave the command in a fifo until it's ready
<agg>
so yea, maybe you can shave all that off by sending :WAV:PRE?;:WAV:DATA?
<agg>
if you stick things together with a semicolon it says it processes them "in the same thread"
<azonenberg>
yeah but more to the point you can send the WAV:SOU too
<azonenberg>
so wave:sou, wav:pre, wav:data
<agg>
sure
<azonenberg>
Little things like this add up over time. i forget just how much faster the lecroy driver is now
<azonenberg>
but it was substantial. tens of percent if not double
<azonenberg>
another thing that helped was re-arming the trigger *before* processing the downloaded waveform in "normal" mode
<agg>
but my python script should already be as fast as it can, excluding discovering further oddities like setting TCP_NODELAY, heh
<agg>
hmm
<azonenberg>
so as soon as you have the adc samples
<agg>
how do you ensure you don't have new data overwrite the buffer before you can download it?
<azonenberg>
You download the data, arm the trigger, then in the same thread without releasing any mutexes convert the raw samples to fp32
<agg>
ah, I see what you mean
<azonenberg>
the key is to have the scope be processing the arm command simultaneously with you doing the type conversion
<agg>
yea understood
<azonenberg>
especially on deep waveforms that conversion can take a fair bit of itme
<azonenberg>
time*
<azonenberg>
The scope should always be busy
<azonenberg>
if it's not, your host-side code needs to be faster
<agg>
btw if I change windows back and forth I find glscopeclient's chrome doesn't get drawn until I minimise and re-show the window
<azonenberg>
minimize turnarounds between response from scope and next command that depends on response
<agg>
and is instead now showing most of wireshark, except for the status info bottom-right and the 'run' button
<azonenberg>
and if the next command doesnt depend on the response, send it before you even get the response
<azonenberg>
Interesting. File a bug, include details on gpu setup etc. also is this with waveform captures in progress or halted?
<azonenberg>
also look at wireshark while this is happening, see if maybe it's doing some blocking io call
<agg>
capture in progress, the waveform area is rendered fine
<azonenberg>
interesting so it's only the chrome that's problematic
<azonenberg>
that smells like an opengl bug not restoring some state
<azonenberg>
gtk does compositing in GL
<agg>
it's also 'only sometimes'
<azonenberg>
so if gtk expects some buffer to not be touched and i mess with it by acicdent i could see that being a problem
<azonenberg>
i have seen a few opengl and gtk errors that i havent got tothe bottom of yet
<azonenberg>
this might be related to those?
<agg>
seems likely something along those lines
<agg>
putting :WAV:PRE and :WAV:DATA into the same command works but doesn't make much difference
<azonenberg>
File a ticket and make a screenshot. I'd do it anyway because it might matter more with faster instruments
<azonenberg>
but if its notsignificantly faster i guess you can just hold off
<azonenberg>
and we'll see if it helps on faster, more modern keysight gear
<_whitenotifier>
[scopehal-apps] adamgreig opened issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JLPpp
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JLPpp
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JLPpp
<azonenberg>
Very interesting. never seen that before
<tnt>
What windows manager ? Also wayland or X11 ?
<agg>
awesome wm, x11
<_whitenotifier>
[scopehal-apps] adamgreig edited issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JLPpp
<agg>
I haven't seen this in any other GL apps, though
<_whitenotifier>
[scopehal] adamgreig forked the repository - https://git.io/JLPhF
<tnt>
agg: I use awesome and x11 too so, I guess that's not it.
<agg>
ideally the re-arming trigger would happen slightly before as the floating point conversion still happens slightly earlier but that's a marginally bigger change
<azonenberg>
How about hold off until you've implemented and tested that? then send a PR for both if it looks good
<azonenberg>
Also woo looks like one of my two shapeways orders is out for delivery. It's either the clip or the mold, the other is coming tomorrow
<azonenberg>
lost track of which tracking number is which :p
bvernoux has joined #scopehal
<azonenberg>
woop, just got the install info for sonnet l2 silver (put in the order for the upgrade yesterday)
<azonenberg>
also it appears that klayout can export DXFs in a somewhat sonnet friendly format, experimneting to get the scale factors right
<azonenberg>
Yeah ok i got a valid import
<azonenberg>
it took a little tweaking but this looks like a viable workflow for now. no need to buy the GDS option ordeal with kicad's broken DXF export
<azonenberg>
you can use klayout to import the gerbers, merge overlapping polygons so sonnet doesn't choke on excessively complex geometry, then export to a single multilayered dxf
<noopwafel>
bvernoux: I won't be at home [with code/pico] for a week or so, but I basically just hacked something like AntiKernelLabsOscilloscope together with a more-functional version of the picoscpi bridge on my github
<noopwafel>
so if you're in a hurry / have time now, then I think it's likely easy enough to just redo that, just not worth it for me right now since I don't have the hw to actually try the result
<noopwafel>
(and most of the interesting work is probably the triggers which I definitely did not implement because the framework was not there when I did it)
<azonenberg>
Aaaand of course the very first design i try to simulate in sonnet silver doesn't work. Support ticket time
<azonenberg>
As with when i first bought basic, i started cashing in the support contract before the ink was even dry on my payment :p
<bvernoux>
noopwafel, the idea was to not restart from scratch but I will check what I can do
<tnt>
Oh I didn't know KLayout was used for PCBs ... I've been using it for much smaller stuff :)
<azonenberg>
tnt: i became acquainted with it for silicon work, that's what it's *meant* for
<azonenberg>
(I've never tried using it as an editor, only to view GDS's others created)
<azonenberg>
But it can import gerbers and export DXF
<azonenberg>
during the demo period i was using klayout to convert gerber to GDS (yes, a GDS of a PCB) then importing that into sonnet
<azonenberg>
Which worked, if you had a license for the ~$1K GDS importer
<azonenberg>
the DXF importer is free
<azonenberg>
i either missed that klayout could generate DXFs or i had the settings wrong before
<miek>
azonenberg: lol, going for another xmas eve support ticket response? :p
<azonenberg>
we're gonna find out lol. i actually joked about that in the opening of my email
<azonenberg>
saying i could only dream of what bugs i might encounter in the holidays of 2021
<noopwafel>
bvernoux: yeah, it kind of sucks, but I'm happy to help once I can, if you want to restart from scratch or almost-scratch - don't let me be more of a blocker :x
<bvernoux>
noopwafel, ok at least I can reuse your picoscpi bridge
<bvernoux>
I need to study the performance of picoscpi bridge I'm afraid it have major performance issues
<bvernoux>
between TCP socket to USB 3.0 for big transfer
<bvernoux>
to be checked
<noopwafel>
the one uploaded is also a dumb PoC. the real one is not much better.
<noopwafel>
I didn't find the TCP to be a bottleneck even in streaming mode
<noopwafel>
you do have to be careful not to run out of RAM..
<noopwafel>
there's also the question of how to deal with non-3000 series scopes (is it worth limiting it to just the common API instead?), whether it's worth having a bridge at all, etc
<bvernoux>
yes so far I do not want to investigate on how to support other non-3000 series scope
<bvernoux>
the idea is to do a POC to check how many WFM we have on 3000 series
<bvernoux>
other series with USB 2.0 are not interesting and will be very limited I think and anyway I do not have HW to test
<bvernoux>
so it could be done later by someone with other series ...
<bvernoux>
interesting point so far is to have a usable scope with glscopeclient with at least 10WFM/s I think with GUI decoupled from WFM (slowness of the scope) which is WIP
<bvernoux>
for example Rigol MSO5000 is not very usable so far ...
<bvernoux>
with 1 WFM/s
<bvernoux>
can be useable only not in realtime
<bvernoux>
anyway advantage of Rigol MSO5000 is 8GSSPS and 200Mpts if we could speedup the SCPI stuff to retrieve chan data faster ...
<bvernoux>
maybe it can be hacked with reverse engineering and rewriting a dedicated SCPI/direct mode ... but that will need lot of work and lot of contributors
<noopwafel>
yes it's way way faster than the Rigol haha
<noopwafel>
I mean I often pull >100wfm/s from *python* when doing SCA
<noopwafel>
and it would be nice to have a better UI than the pico one
<bvernoux>
me too I saturated the USB 3.0 link ;)
<bvernoux>
doing SCA
<bvernoux>
with my own realtime algorithm on PC side
<bvernoux>
doing billions of traces ;)
<bvernoux>
which is 10 to 100x times faster than what we can don on High End Scope like LeCroy ...
<noopwafel>
running code on the scope?
<bvernoux>
no I was running the code on PC using Pico SDK API
<bvernoux>
with native C code optimized
<bvernoux>
fully automated to do SCA ;)
<bvernoux>
the main drawback of Picoscope3000 is it have only 2GSPS and 8bits ADC ;)
<bvernoux>
and PicoScope 6 is clearly not very good and the GUI is awfull
<azonenberg>
noopwafel, bvernoux: if you two are interested in building out side channel capabilities in glscopeclient i'd love to have that be another area of focus in addition to the high speed serdes analysis i've mostly been doing so far
<bvernoux>
yes it will be nice to have some sort of Side Channel features
<azonenberg>
$dayjob is interested in getting more side channel capabilities in the seattle lab, our main SCA guy quit and i'm going to have to take his place
<azonenberg>
and i'd like to build a workflow around glscopeclient/libscopehal
<azonenberg>
first i have to learn more of the practical side of SCA though. i understand the theory at a very high level but have never actually tried *doing* one
<bvernoux>
the best for that is to practice on simple target ;)
<bvernoux>
like ATMEGA328P
<bvernoux>
the leak a lot
<bvernoux>
they
<azonenberg>
i was thinking stm32f031 as the initial target. or maybe an 8-bit PIC
<azonenberg>
i don't have an atmega toolchain set up
<bvernoux>
the only easy to use tool so far is QSCAT ;)
<bvernoux>
done by my friend
<bvernoux>
it is done in Qt ;)
<bvernoux>
advantage vs other available tools which are much more advanced is it is visual
<bvernoux>
but there is always a learning curve to understand how that work
<bvernoux>
anyway I started to learn alot on Side Channel using ChipWhisperer
<bvernoux>
with the diff probe ;)
<bvernoux>
state of the art is to do a very clean measurements with ultra low power supply ;) (that avoid to do lot of filtering and to capture tons of traces for nothing)
<bvernoux>
for extreme case I'm using 1uV noise 5V PSU
<bvernoux>
and with such setup you can break/recover 128bits AES with only 16 traces which is world record I think ;)
<noopwafel>
and then you encounter real target and suddenly you need 100k :p
<bvernoux>
yes ;)
<bvernoux>
even more
<noopwafel>
there's definitely some niceties which would be lovely to have in gui directly
<bvernoux>
on some challenge it was required to capture more than 500k traces
<noopwafel>
(I miss Inspector)
<bvernoux>
as there was some counter measure
<bvernoux>
to understand different effect and what is the algorithm/obfuscation used ;)
<bvernoux>
especially when doing that like a black box without any access to firmware
<bvernoux>
as it was heavily protected and impossible to extract easily