<_whitenotifier-b>
[scopehal] azonenberg f150b8e - DeEmbedDecoder: AVX2 implementation of inner loop (forward direction only for now) is 7.8x faster than non-vectorized version
<azonenberg>
well that was a nice speedup
<azonenberg>
7.8x faster than the original even though most of the loop is permute/shuffle instructions because the FFT is dumb and outputs interleaved values instead of a vector of real and a vector of imaginary samples, which is much more SIMD friendly
<azonenberg>
The output loop is still pretty slow but i see room to optimize that too
<Bird|otherbox>
azonenberg: ever given ASan a whirl?
<sorear>
I still don't get why graphics APIs are so closely tied to hardware revisious
<sorear>
nobody goes out and buys CPUs with C++17 support
<azonenberg>
sorear: well back in the old days
<azonenberg>
with the fixed function pipeline
<azonenberg>
they were full on ASICs and if you wanted to add support for a new lighting mode or something, it required a silicon spin
<azonenberg>
When they moved to programmable vector processors instead it became a lot easier to add new features without a new chip revision, but some stuff like say 64-bit integer support may just not be present in the hardware
<sorear>
did mesa lose support for software rendering at some point in the last 15 years?
<sorear>
I did at one point run GL stuff on a video card only supported by the VESA framebuffer driver
<sorear>
and you can compile 64-bit software without 64-bit adders in the hardware, I know you've done mips
<sorear>
doesn't even have an "adc" instruction but compilers manage
<sorear>
floating point is messier and falling back to sw rendering is probably more sensible than trying to do softfloat for unsupported fp widths on a gpu, but why isn't "falling back to sw rendering" a thing
<azonenberg>
i have no idea what the state of mesa software rendering is
<azonenberg>
i think it's mostly the performance issues of copying data on and off the card constantly to run a shader that doesnt support some feature
<azonenberg>
and the hassle of decoding which memory to use and which processor to use dynamically based on which shader is running, etc
<azonenberg>
Bird|otherbox: Yes but asan needs a full recompile
<azonenberg>
so valgrind is more convenient to use for a quick "what of my most recent changes caused a segfault"
<Bird|otherbox>
that is verily true
<azonenberg>
for more extensive debugging i prefer asan actually
<Bird|otherbox>
sorear: no, Mesa can still SWrender
<Bird|otherbox>
I've actually had to use that functionality in anger on occasion recently
<Bird|otherbox>
(for raisins)
<sorear>
does the SW renderer support GL >= 4.5?
electronic_eel has quit [Ping timeout: 265 seconds]
<Bird|otherbox>
no idea
electronic_eel has joined #scopehal
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJMVo
<azonenberg>
Ok i think this is pretty good for an hour or two of work
<azonenberg>
45.248 sec -> 6.242 sec for this test case
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJMwn
<_whitenotifier-b>
[scopehal] azonenberg 9b2c636 - Merged inner loops for de-embedding and channel emulation
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJMwE
<_whitenotifier-b>
[scopehal] azonenberg 3d77e65 - DeEmbedDecoder: fixed bug causing frequency bins to not be recomputed if waveform depth changed
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #224: FFTDecoder: cache plan rather than recreating each waveform - https://git.io/JJMwu
<_whitenotifier-b>
[scopehal] azonenberg opened issue #224: FFTDecoder: cache plan rather than recreating each waveform - https://git.io/JJMwu
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #224: FFTDecoder: cache plan rather than recreating each waveform - https://git.io/JJMwu
<_whitenotifier-b>
[scopehal] azonenberg opened issue #225: CTLEDecoder: cache FFT plan instead of recomputing each waveform - https://git.io/JJMwz
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #225: CTLEDecoder: cache FFT plan instead of recomputing each waveform - https://git.io/JJMwz
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #225: CTLEDecoder: cache FFT plan instead of recomputing each waveform - https://git.io/JJMwz
Nero_ has joined #scopehal
Nero_ is now known as Guest64362
Guest64362 is now known as NeroTHz
<azonenberg>
Status update on probes, all bare probe PCBs that are a) going to the US so no need for customs forms and b) going to people who have sent me a shipping address
<azonenberg>
are packed up and ready to go to the post office
<azonenberg>
Finalizing the datasheet now then gonna start packing up assembled probes
<azonenberg>
Going to try to get all of the domestic shipments sent out tomorrow some time then do the overseas ones later in the week
<Degi>
Ah yes, don't you love it when your package gets delivered to "Geschäft"
<Degi>
Meh there's probably a delivery notice in the post box...
<Degi>
At least they could bother to ring hmh
<NeroTHz>
This is why I used to always have my stuff delivered at work
<NeroTHz>
with my employer having contracts with pretty much every large delivery firm around here they never have excuses like ´nobody home´
<azonenberg>
I load substantially less out to about 2.5 GHz
<azonenberg>
then it's close for a while, then it hits a peak
<azonenberg>
I peak too, but not until past 6 GHz
<azonenberg>
But from DC to 1.5 GHz (their specced performance limit) or 2 GHz (my specced performance limit) I outperform them in pretty much every metric i can measure
<azonenberg>
Flatter response, lower loading, etc
<Degi>
I see, its 20 ohms there not 50, oops misread the graph. Could it have something to do with the metal piece where the tip connects? Or the loop formed by the tip and ground?
<Degi>
Oh nice
<Degi>
And the pico has no swappable cable
<NeroTHz>
azonenberg, check the imaginary response of the impedance. that woudl tell you if it´s behaving capacitviely or not, given your short lengths of line I would imagine if it is behaving capacitively it´s just because you see the parasitic cap
<azonenberg>
this is S21 of my probe vs the Pico one
<Degi>
Wiggly
<Degi>
Did they use bad coax?
<azonenberg>
I have no idea, i dont want to cut into one of my $320 probes to characterize the cable separately from the probe :p
<azonenberg>
NeroTHz: can you believe pico gets away with selling this as a 1.5 GHz probe?
<NeroTHz>
If it´s anything like scopeprobes they might purposefully use those bad coax. And I don´t trust pico as far as I can throw it :p
<NeroTHz>
so not really that surprised no
<azonenberg>
this is their "1.5 GHz" and my "2 GHz" probe measured on the same VNA and test fixtures with the same methodology
<Degi>
Purposefully?
<azonenberg>
I'm selling mine for about the same price range
<azonenberg>
NeroTHz: this is actually a PMK product pico rebrands
<azonenberg>
it's not a pico design
<azonenberg>
Pico's in house probe design is actually far better electrically, i have one of their 6 GHz probes and it blows mine away
<azonenberg>
But it's also a $1K probe
<NeroTHz>
Degi, in probes they sometimes use bad coax to reduce reflection issues. If you have more attenuation and more random reflections all over the place, but can still get decent S21, your measurement error is lower (because you don´t get lots of standing waves in your cable)
<Degi>
Lolll
<azonenberg>
The rebranded PMK probe sells for $320. I sell mine for $250 standard, or $500 fully characterized
<Degi>
I mean the impedance of the coax seems to be not 50 ohm
<NeroTHz>
I say ´bad coax´, its more like ´coax that is purposefully not a low-loss 50 ohm coax´
<Degi>
I mean if you use an ideal 50 ohm coax terminated with an ideal 50 ohm resistor (in your VNA) there shouldnt be ripples...
<azonenberg>
Degi: thats the other nice thing about my probes vs the other competing products. I openly publish things like characterization curves, unit to unit variability
<azonenberg>
performance with each of the supplied ground accessories
<NeroTHz>
Degi, yeah, but if you have a scope probe that goes into a high-impedance scope input or such (like a 10:1 probe) then you don´t have that nice perfect match
<azonenberg>
Mine aren't perfect, but at least you *know* how imperfect they are
<azonenberg>
NeroTHz: The TA061 is a 500 ohm transmission line probe
<azonenberg>
with a SMA output
<azonenberg>
(but an integrated cable vs a removable one like i have)
<Degi>
NeroTHz: Then why get a transmission line probe? You need to 50 ohm that to ground for it to be 10:1
<azonenberg>
Architecturally it's the same as mine. I just have a better implementation
<NeroTHz>
Degi, I think we are misunderstanding eachother here. I was talking specifically about classic scope-probes that are 10:1 and made for a 1 meg input impedance on the scope
<Degi>
Ah
<Degi>
I was talking about the pico probe
<NeroTHz>
and figured that maybe pico was doing something here to for their scope probe, if it is meant to go on a old school scope.
<azonenberg>
No
<azonenberg>
It's specifically a 50 ohm probe
<NeroTHz>
ah okay, I wasn´t sure
<NeroTHz>
I´m still semi asleep
<azonenberg>
NeroTHz: anyway you said look at the "imaginary response"
<azonenberg>
I'm looking at the imaginary component of Zin, is that what you mean?
<Degi>
How long is the pico cable? 1.5 m?
<NeroTHz>
yeah, that is what I meant
<azonenberg>
i think 1m?
<azonenberg>
My measurements are de-embedded to the probe body alone, so there's some additional loss from the cable
<Degi>
Huh it probably resonates shortly below 3 GHz
<Degi>
Since there is low total impedance and the imaginary is 0, so |X_L|=|X_C|
juli964 has joined #scopehal
<NeroTHz>
yeah, indeed. I imagine your parasitic capacitance is being tuned out perfectly by your capacitors at 3 GHz. Below that, you are mostly seeing tha parasitic capacitance, above that, mostly seeing the inductance of your probe pins I think
<azonenberg>
by my capacitors?
<azonenberg>
you mean the resistors?
<NeroTHz>
I meant parasitic capacitors
<azonenberg>
or what
<azonenberg>
oh
<azonenberg>
Which ones? series cap across the resistors, or shunt cap to ground?
<NeroTHz>
the parasitic capacitors of your pads and so on is resonating with the parasitic inductance of your probe tips. Cap to ground
<azonenberg>
Yeah that's kinda what I suspected (tip pad capacitance)
<azonenberg>
I cut out the ground under the pad which seems to have helped vs previous versions
<azonenberg>
but maybe i need to go further
<azonenberg>
it's not like i need an exact 50 ohm match at the tip, it's about to have a huge reflection off the 450 ohm resistor
<azonenberg>
Final draft with data from characterizing the production probes
<azonenberg>
Might add a paragraph or so about changing probe tips etc but otherwise i think it's good
<Degi>
Oh nice
<azonenberg>
any other comments?
<Degi>
Maybe add SMA torque in newton-meters too
<azonenberg>
i have that already
<azonenberg>
did i miss it in another section?
<Degi>
Safety information
<azonenberg>
Fixed
<NeroTHz>
space between 30 and VRMS
<Degi>
dB's are pretty much always in power, right?
<Degi>
And between 450 and 50 Ohm too
<Degi>
There is the siunitx package
<NeroTHz>
Degi beat my to it, was wrting ´There is the siunitx package...¨
<Degi>
lol
<NeroTHz>
dB is always power (10log10(ratio)), but it just works out that in a fixed-impedance system, you can just use 20log10(ratio) if your ratio is of voltages or currents
<azonenberg>
Reuploaded
<azonenberg>
also added a note under safety information reminding the user that probe tips are sharp
<azonenberg>
Because people are dumb :p
<NeroTHz>
I always forget that SMA and 3.5/2.92 technically have different torqu specs
<azonenberg>
This is the torque spec for brass SMAs
<azonenberg>
a lot of the metrology grade connectors are stainless and are designed for i think 8 lbf-in
<azonenberg>
but those are normally $$$$ screw-on ones like the southwest microwave stuff bvernoux likes
<NeroTHz>
Depends too, R&S/rosenberger both advise 1Nm, which is more like 9 lbf-in I think?
<azonenberg>
pretty much any solderable SMA will be rated for 5
<Degi>
Maximum temperature of 95 °C is below glass transition temperature of housing?
<azonenberg>
Degi: i think that actually was the limiting factor
<azonenberg>
the PCB and components are good out to ~1225
<azonenberg>
~125*
<Degi>
Heh
<azonenberg>
it wasn't Tg though, it's a thermoplastic
<azonenberg>
that was the point at which it's lost most of its mechanical integrity though
<azonenberg>
let me check?
<Degi>
Dont thermoplastics have Tg too? Like PMMA at 80 °C or something?
<azonenberg>
ok here we go
<noopwafel>
azonenberg: I have definitely stabbed myself with a probe tip before
<Degi>
Haha, also the pico has 2 % DC tolerance and this one has 0.5 %
<azonenberg>
Tensile strength at ambient is 48 Mpa
<azonenberg>
At 95C that drops to 1.82, at 175 it drops to 0.45
<azonenberg>
It melts at 187
<azonenberg>
Degi: actually the 0.5% is quite conservative lol
<Degi>
48 MPa is like hanging a 4.8 kg load from a 1 mm² wire of it hmh
<azonenberg>
anyway the exact rate of fall-off is unspecified in the material datasheet but i figured at 1.82 Mpa it's soft enough i wouldn't want to go any higher
<Degi>
hm yes
<azonenberg>
but if not being squished, it should survive
<Degi>
ye
<azonenberg>
So i declared that the upper limit
<Degi>
Would be ouchy to use it too
<azonenberg>
Yes :p
<azonenberg>
but in like an environmental chamber
<azonenberg>
the probe should survive that if you're not stressing it much
<NeroTHz>
its one of these things where you just need a number
<azonenberg>
Yeah
<azonenberg>
that's the absolute max. Recommended range is up to 45 and i calculated the tolerances including resistor TCR out to those extremes
<NeroTHz>
like, our newest VNA being rated up to an altitude of 4650 meters or somethin glike that
<Degi>
uh yes actually its 0.022 %
<azonenberg>
Degi: even *that* is conservative, the resistors are rated for 0.1%
<Degi>
hmh isnt that way below 0.1 %
<azonenberg>
but i built in some margin for TCR etc
<azonenberg>
let me see
<azonenberg>
The datasheet limits for DC resistance are 449.75 to 450.75 ohms
<azonenberg>
across the entire probe including connectors and pcb copper
<Degi>
Oh nvm I miscalculated
<Degi>
That is 0.2 % not 0.02
<azonenberg>
Actual characterization extrema were 450.23 to 450.39
<azonenberg>
measured at 21-22C
<Degi>
Thats 0.036 %
<azonenberg>
Yes
<azonenberg>
I was *very* conservative with that tolerance :p
<azonenberg>
but i measured with a 5 3/4 digit R&S DMM with a current nist traceable cal
<azonenberg>
And across almost 20 probes the numbers varied by only a few tens of milliohms
<azonenberg>
So i'm pretty confident in them
<azonenberg>
I baked in a lot of margin because the actual resistor tolerance from vishay was 0.1% but my probes seem to be nowhere near hitting that limit
<Degi>
hm <yes
<azonenberg>
I actually considered speccing a tighter tolerance and just binning them myself if one of the resistors was too close to the tolerance limit lol
<azonenberg>
But i dont know about e.g. lot to lot variation between the resistors or something
<azonenberg>
actually, i do
<azonenberg>
i used two lots of resistors for this batch
<azonenberg>
and i still had a spec this tight
<azonenberg>
well two separate purchases
<azonenberg>
they may well have come off the same reel upstream
<azonenberg>
NeroTHz: any comments on the datasheet?
<azonenberg>
certainly more complete than the competition
<Degi>
I wonder if you could make a probe where the ground is a tube around the tip with a spring...
<azonenberg>
The datasheet limits for DC resistance
<Degi>
And maybe add a newline between the end of sentence and table
<NeroTHz>
Same with ´Design Files´ at 1.3
<Degi>
I think shifting the text slightly to the right or the title slightly to the left could look better too
<azonenberg>
Hmm ok i'll try that. I was mostly looking for feedback on the content rather than the formatting at this point though :)
<Degi>
Okay
<NeroTHz>
azonenberg, will get to you on that later :p busy with other work now
<Degi>
There's some numbers on page 6 (and maybe others) missing a space between unit and number. What does replacement P/N mean?
<Degi>
The content looks fine
<Degi>
Maybe put the s2p files on your website instead of github? Or is there a reason for github like versioning etc?
<azonenberg>
Part number
<azonenberg>
And i was a bit split on that
<azonenberg>
I guess i can host them myself
<Degi>
For s2p graphs I'd suggest eps or similar vector formats if that is possible (and doesnt make the PDF too laggy)
<azonenberg>
I dont have a good tool for that
<azonenberg>
so for now i'm just doing screenshots
<Degi>
Okay
<electronic_eel>
azonenberg: nice probe manual, would love to get something with this level of detail for all test equipment
<azonenberg>
And i havent even added the photos yet
<azonenberg>
did you look at the pico manual for comparison?
<electronic_eel>
azonenberg: chapter 6.4, the parameter names G500, G1000 and so on are not fully subscript
<electronic_eel>
I didn't look at the pico one yet
<Degi>
Huh, Pico has weird tables
<Degi>
Maybe add a warning to not drop the probe, in case mechanical shock is a problem
<electronic_eel>
ok, did take a look at the pico manual now. spec wise it is a big dissapointment, no nothing about insertion loss and so on
<Degi>
They dont even have one single measured graph
<electronic_eel>
what is nice is their accessories overview schematic
<azonenberg>
yeah that is straight from PMK lol
<electronic_eel>
also they have a section about how to properly change the tip. I think that should be added to the AKL-PT1 manual to
<azonenberg>
already working on it
<azonenberg>
taking photos as you said that
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+7/-0/±2] https://git.io/JJMxh
<_whitenotifier-b>
[starshipraider] azonenberg caa5e09 - Updated manual with additioanl figures and text
<azonenberg>
electronic_eel: Reuploaded
<azonenberg>
Degi: yeah pico's datasheet isn't much of a *data*sheet lol
<Degi>
More like an IKEA manual tbh
<azonenberg>
lol
<azonenberg>
meanwhile i actually have (figure 9) details on unit to unit variation etc
<NeroTHz>
You know what I love about summer
<NeroTHz>
Nobody at work does heavy simulation, because everyone is in the measurement-crunch now
<NeroTHz>
so all the servers are there for me to whip into submission
<Degi>
Hehe
<NeroTHz>
which is good cause now my simultaions take 1/10th the time
<NeroTHz>
just 30 minutes for the entire frequency sweep
<azonenberg>
lol
<Degi>
Oh well they havent given a delivery notice yet... Will probably get that tomorrow .-.
<juli964>
Hey Guys, I'm trying to install glscopeclient on Windows 7. Actually I get an error on Building xptools/UART.cpp:75 it says invalid conversion from 'int' to 'FILE_DESCRIPTOR' aka 'void*' -fpermissive do you already know about the error?
<azonenberg>
juli964: the uart code was pretty recently added
<azonenberg>
it may not have been tested on windows yet
<azonenberg>
noopwafel wrote it i think
<azonenberg>
Windows support in general is still a bit iffy because katharina is our only real windows dev and she's been out for a while thanks to covid
<azonenberg>
most likely there needs to be some more ifdefs to change the type of the file handle from int on linux to HANDLE on windows, or similar
<miek>
we're ok linking lgpl code right? i wonder whether it's worth pulling in libserialport? they've already solved all the cross-platform gotchas
<noopwafel>
oh yeah maybe you need INVALID_HANDLE instead for windows
<azonenberg>
miek: gtk is lgpl, but if we can fix xptools easily enough that's the better choice
<azonenberg>
noopwafel: INVALID_HANDLE_VALUE i think is the actual macro?
<azonenberg>
been a while
<electronic_eel>
azonenberg: one more idea for the manual: describe which socket on the probe does what
<electronic_eel>
I think everybody using it should know, but I think it is better to describe it
<azonenberg>
I was going to add a mechanical drawing and such
<azonenberg>
with dimensions and annotations for the sockets
<electronic_eel>
ah, with dimensions is even better
<monochroma>
ooo yeah that would be good
<azonenberg>
also i poked sonnet support a little while ago and just got an emai lwith a new license file
<azonenberg>
it seems to have solved the issues and they extended the trial by a few days to make up for the time i didn't get to use the demo with the broken license
<azonenberg>
So i should actually have a month to try it out now
<azonenberg>
ok first crack at this sim wanted to use 32 GB of memory and hundreds of thousands of mesh cells
<azonenberg>
let's see if i can shrink THAT...
<monochroma>
yay
<azonenberg>
ok now i'm at 2.8 GB of memory and 18.9K cells. This is just a little bit too big to fit into L3 Gold, but if i used slightly coarser meshing woudl fit
<azonenberg>
all of the other features i'm using i think are doable on gold
<azonenberg>
I'm modeling basically the whole tip region of the probe including the full resistor string with actual s2p models of the passives
<azonenberg>
The goal here is to see if i can reproduce that dip at higher freqs due to reflections between the resistors
<azonenberg>
The 32-threaded solver is *nice*
<azonenberg>
i definitely want it one day
<azonenberg>
But realistically i think gold is enough for ~8% of the stuff i want to be simulating in the nearish term
<azonenberg>
80%*
<azonenberg>
about the only thing it won't be good for is modeling complex multilayer structures like a via transition changing reference planes on an 8-layer board
<azonenberg>
Which would be nice to do but isnt super duper critical (yet)
<juli964>
azonenberg, noopwafel: thanks, INVALID_HANDLE_VALUE seems to be the right macro. I added an ifdef there, but there were some more errors. I'm actually working through. Should I write them down or create issues for you or Katharina?
<noopwafel>
I can make more suggestions for potential fixes, but making an issue is also fine/great
bvernoux has joined #scopehal
<juli964>
ok I think I will create some issues when I got it working. For the other errors, I used the Compiler's suggestions till now ;)
<juli964>
Currently he does not find the ffts.h the CMake script says it finds libffts but not package ffts but I build and installed ffts in the first step any suggestions for that?
m4ssi has joined #scopehal
<Degi>
This 0.5 mm solder looks waaay thinner than the 0.8 mm one
<monochroma>
but how does it taste?
<Degi>
It doesnt smell good... Accidentally ordered water washable
m4ssi has quit [Remote host closed the connection]
m4ssi has joined #scopehal
NeroTHz has quit [Read error: Connection reset by peer]
m4ssi has quit [Remote host closed the connection]
bvernoux has quit [Quit: Leaving]
juli965 has joined #scopehal
juli964 has quit [Ping timeout: 256 seconds]
<azonenberg>
juli965: It seems like some systems look for ffts/ffts.h and some look for ffts.h
<azonenberg>
change the include paths to specify/not specify the subdirectory
<azonenberg>
We need to properly fix this, i think its a bug in the cmake script
<azonenberg>
but i had to do that on my windows test build too