<_whitenotifier-b>
[scopehal] azonenberg labeled issue #223: LeCroyOscilloscope: SetChannelCoupling() and SetChannelAttenuation() are unimplemented - https://git.io/JJXEA
<_whitenotifier-b>
[scopehal] azonenberg opened issue #223: LeCroyOscilloscope: SetChannelCoupling() and SetChannelAttenuation() are unimplemented - https://git.io/JJXEA
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #223: LeCroyOscilloscope: SetChannelCoupling() and SetChannelAttenuation() are unimplemented - https://git.io/JJXEA
<azonenberg>
Does anyone have thoughts on requiring GL_ARB_gpu_shader_int64?
<azonenberg>
hmmm seems most intel integrated cards don't support it
<azonenberg>
there goes that idea
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 4 commits to master [+0/-0/±12] https://git.io/JJXw2
<_whitenotifier-b>
[scopehal-apps] azonenberg 7d00bee - WaveformArea: use separate X/Y buffers for rendering (for better SIMD support in the future)
<_whitenotifier-b>
[scopehal-apps] azonenberg ab1bf97 - WaveformArea: moved some math in PrepareGeometry() to GPU
<_whitenotifier-b>
[scopehal-apps] azonenberg 45857e5 - Significant performance improvements to WaveformArea::PrepareGeometry() for large waveforms. Moved some preprocessing to compute shader.
<_whitenotifier-b>
[scopehal-apps] azonenberg 193f0f4 - Removed some needless memcpy's and allocs/frees, pushed more math to render shader
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JJXoU
<_whitenotifier-b>
[scopehal-apps] azonenberg 17fb26c - Continued work on Int64ToFloat
_whitelogger has joined #scopehal
<_whitenotifier-b>
[scopehal] azonenberg pushed 3 commits to master [+1/-0/±4] https://git.io/JJXi0
<_whitenotifier-b>
[scopehal] azonenberg 0cd0a99 - Waveform: use AlignedAllocator for timestamps
<_whitenotifier-b>
[scopehal] azonenberg 28fdea0 - Waveform: use AlignedAllocator for sample data
<_whitenotifier-b>
[scopehal] azonenberg 9edea10 - Merge branch 'master' of github.com:azonenberg/scopehal
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJXi6
<_whitenotifier-b>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±6] https://git.io/JJXQE
<_whitenotifier-b>
[scopehal] azonenberg 85f8409 - Moved feature detection to scopehal. Added AVX2 implementation of some waveform processing in LeCroyOscilloscope.
<_whitenotifier-b>
[scopehal] azonenberg 3b9fc6c - Added AVX2 implementation of Convert8BitSamples()
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JJXQu
<_whitenotifier-b>
[scopehal-apps] azonenberg 2463eb5 - Removed AVX checks as these are now handled in libscopehal
<azonenberg>
Brings back memories of being in grad school writing hand optimized sse2 assembly for password cracking
<azonenberg>
actually no i was an undergrad for most of that
<monochroma>
oh no, the platform specific code begins ;0
<monochroma>
;)
<azonenberg>
I still have a generic implementation
<azonenberg>
scroll up a few lines
<azonenberg>
it's at least 25% faster though. I think that kind of speedup is worth the effort
<azonenberg>
7.25 -> 5.32 sec over 1 minute of run time on 10M point waveforms
<azonenberg>
And i can likely speed that up a fair bit if i was able to assume "pin" was aligned on a 64-byte boundary
<monochroma>
yea
<azonenberg>
right now the memory fetches are inefficient
<azonenberg>
i did write a custom STL allocator that lets you specify alignment
<azonenberg>
but i have to go through and use that for all of the containers i might want to vectorize
<azonenberg>
BTW that function manages to sustain 0.876 CPI according to vtune
<azonenberg>
Which i think is quite decent
<monochroma>
cpi?
<azonenberg>
clocks per instruction
<monochroma>
:o
<azonenberg>
so it's averaging >1 instruction per clock even though there's a ton of memory loads and 256-bit vector math
<azonenberg>
My test case, btw, is one minute of displaying four channels of 10 Mpoint waveforms with no filters
<azonenberg>
I've been averaging just shy of 75 waveforms over that minute
<azonenberg>
So 1.25 WFM/s
<azonenberg>
Limited by the scope, but i'm trying to reduce CPU usage so i can spend more time on filtering or handle faster instruments without bottlenecking
<NeroTHz>
huh, blurb provides an ISBN if you want it for picture books
<NeroTHz>
that´s cool
<azonenberg>
Hmm, looking through more profiling and i see a lot of memory allocations around std::string objects in the socket handling. That can probably be optimized better
<azonenberg>
monochroma: don't you love when you get a shipping email for a board you forgot you made?
<azonenberg>
it's a test fixture with the attenuator string on a short piece of GCPW with SMAs at both ends
<azonenberg>
I'm very interested in seeing how the frequency response there tracks my idealized netlist sims
<NeroTHz>
azonenberg, which connector do you use again?
<azonenberg>
NeroTHz: As of now my current favorite is Amphenol RF 901-10511-3
<azonenberg>
It has one problem, it is a looser fit to the PCB than the Samtec part I've used in the past. That one would friction-fit to the PCB and stay on super tight during reflow
<azonenberg>
This one i haven't figured out how to reflow
<azonenberg>
i have to hold it down with kapton tape on one side, hand solder the opposite side of the ground
<azonenberg>
then remove the tape and solder that side, then switch to finer solder wire and d othe pin
<azonenberg>
but it's the perfect dimensions to straddle a GCPW on my usual stackups
<azonenberg>
It's also $12 instead of $3 like the samtec part
<azonenberg>
So i'd love to at some point figure out how to get good results with it. But my previous tests with that part always had poor matching no matter what i did
<azonenberg>
this one worked almost perfectly my first try and with minimal tweaks performed great
<azonenberg>
Better than -25 dB S11 out to 2.5 GHz and better than -20 out to 4.8, then just barely breaking -20 before dipping down again. And that was on a non-impedance-controlled board
<NeroTHz>
yeah, I´ve used those before, and the center pin was a pain to solder really
<azonenberg>
It's not that bad if you've got a tiny iron, good flux, and a spool of 125 μm solder wire
<azonenberg>
:p
<azonenberg>
Thankfully, i have all of the above lol
<NeroTHz>
it´s possible, but I still find it a pain :p
<azonenberg>
oh so here's a question for you
* NeroTHz
braces
<azonenberg>
The usual S11 of a transmission line looks like a series of humps with a flat top, right?
<NeroTHz>
yes, usually
<azonenberg>
What does it mean if, as frequency goes up, the humps get higher?
<azonenberg>
in the case of my test coupon for this SMA, for example, I have the first one around -25.8 dB at 1.09 GHz
<azonenberg>
the second one is -22.1 dB at 3.1
<NeroTHz>
you mean the depth of the ´dips´, or the height of the ´hills´?
<azonenberg>
then -19 at 5.1
<azonenberg>
Height of the hills is higher with each hump
<azonenberg>
I have three humps from DC to 6 GHz and each one is more reflective than the one before
<NeroTHz>
if it is the height, it just is mismatch getting worse. The dips aren´t your real match, it´s just that at those frequencies your line length happens to be an impedance transformer that just works out to match it well. it´s the ´height´ of the peaks that really indicates your overal match
<azonenberg>
Yes I'm looking at the equivalent impedance curve too
<azonenberg>
from DC to 3 GHz it looks sinusoidal between 5o and about 45 ohms
<azonenberg>
then progressively gets worse, up to 55, down to 48, up to 61, then down to about 55 before being cut off by the edge of my VNA sweep
<azonenberg>
What i'm wondering more is what physical effects cause mismatch to be frequency dependent?
<azonenberg>
And what can i do to improve the matching?
<NeroTHz>
and it usually makes sense that you get mismatch over higher frequency, esp with microstrip and G-CPW: your field distribution changes with frequency, less fields are outside the dielectric in air, and thus your impedance shifts. You also get more current crowing on the edge of your transmissionline which further results in that non-ideal TEM mode behaviors
<azonenberg>
So buried lines have more uniform matching across frequency?
<azonenberg>
since you have the same dielectric above and below?
<NeroTHz>
if you want the absolute very best: CPW (without ground) is usually quite good because it´s ´planar´. Main hassle is keeping the ´common mode´ working. Alternate is slotline, but nobody ever seems to use slotline. Stripline is also better, because as you say, it´s more ´homogeneos´ in a sense
<azonenberg>
What about, i forget the name of it
<azonenberg>
but basically a buried waveguide? a CPW-like structure on an internal layer sandwiched between ground planes
<azonenberg>
with via fences on either side
<NeroTHz>
you mean SIW?
<azonenberg>
not quite, you still have a solid conductor in the middle
<azonenberg>
it's not propagating through the dielectric
<NeroTHz>
ah, like a buried coax
<azonenberg>
Yeah
<azonenberg>
but with a rectangular cross section
<azonenberg>
i know i've seen it but forget the proper term
<NeroTHz>
yeah, I know what you mean. That could also work, main issue is the via spacing. What you could do is just have the vias far enough, so their influence on the impedance itself is low, but they do help for shielding and suppressing parallel-plate modes of your ground planes
<azonenberg>
What i've actually seen is the opposite
<azonenberg>
there was a paper from southwest microwave, i think, that suggested best results were placing the vias as close as possible so you had the smallest fraction of a wavelength between them
<azonenberg>
and having the vias as close to the line as you could get
<azonenberg>
that was in a GCPW but i'd imagine this would have similar properties
<NeroTHz>
oh yeah, you want the gap between vias as small as possible, I agree with that
<azonenberg>
but basically they wanted the vias to approximate a solid vertical conductor
<NeroTHz>
yeah, that makes sense. Another issue with burried lines, though, is that you might get their impedance better, but you actually needa get your signal from the top layer to the burried layer, and that transition itself can be a pain to do well
<azonenberg>
Yes
<azonenberg>
That's why I used GCPW on the probe
<azonenberg>
No vias anywhere except stitching the grounds together
<azonenberg>
the signal is completely planar with edge launch on both ends
<azonenberg>
I'm not made of money, backdrilling isnt an option :p
<NeroTHz>
backdrilling is going out, from what I understand
<azonenberg>
Oh?
<azonenberg>
well i guess the ideal is a blind via
<azonenberg>
or controlled depth drill
<NeroTHz>
yep, and those are becoming more and more common
<azonenberg>
so you have dielectric below
<azonenberg>
For MAXWELL I didn't want to shell out the extra cash for that
<azonenberg>
8 layers of rogers with controlled impedanec and filled via-in-pad was expensive enough
<azonenberg>
So I put all of my long haul signals from the probe ports, and the 10G SERDES links, on outer layers so my vias inherently had no stubs
<azonenberg>
Then for the DDR3 i have stubs but at 1600 MT/s on a relatively short link i figured i could get away with a bit of a reflection
<azonenberg>
Gong blind/backdrilled for that seemed overkill
<azonenberg>
although if i get the sonnet pro demo figured out i'll likely run a sim of a ddr trace with vias and just confirm
<NeroTHz>
I can´t say how it rates back to more general products. But I´ve been told by PCB vendors that people wait too long before considering HDI/blind/burried vias in a lot of applications. The main cost is if you want blind/burried AND all the way through vias, because it´s a many-step procces. But if you can get away without it (pure SMD component board) it was, according to them, often cheaper to go t
<NeroTHz>
he blind/burried route, because (a) you can sometimes get away with less metal layers, and (b) you don´t have to push other design rules as far - making small via-in-pad stuff can be more expensive than just having a blind-via layer
<NeroTHz>
I don´t know where that point of transistion is though, as there is a lot of different ´levels of density´ between the boards you make and a board for a smartphone/smartwatch :p
<azonenberg>
Yeah
<azonenberg>
So in my case i needed 8L anyway to be able to fan out the FPGA, but it was 1mm pitch
<azonenberg>
I mostly went ViP for power integrity reasons, honestly
<azonenberg>
more so than routing density
<NeroTHz>
azonenberg, well, that was one of the examples they liked to give: with blind/burried, they claimed you can sometimes do that fanout with 6 layers because you can stack vias on different layers and so on
<azonenberg>
Being able to have a cap and bga ball literally on the via with no dogbone trace is about the best decoupling possible
<azonenberg>
No
<azonenberg>
I did the math
<azonenberg>
No level of HDI within my price range could get a 676-ball BGA with 95% IO utilization out on two signal layers
<NeroTHz>
okay :p as I said, not an expert, just restating what I was told
<azonenberg>
as is, i had a hard time fanning out from the bga to the proper 50 ohm traces spaced out to minimize crosstalk for the long haul
<azonenberg>
And i needed two power layers
<azonenberg>
there was no way i was fitting my 20+ power domains on one layer
<azonenberg>
So at that point the stackup was fixed at 8L and adding HDI on top of that, while i considered it, seemed like a lot of money for little return
<NeroTHz>
mhm
<azonenberg>
Generally I start thinking about HDI when i'm using 0.5mm or smaller BGAs
<azonenberg>
I did a board a while back with an 0.8mm FPGA (easy peasy) and an 0.4mm 176-ball WLCSP
<NeroTHz>
My issues are usually more along the line of via spacing/via diameter, which is why I was looking at HDI/blind/burried
<azonenberg>
For that, i did 6L with 1-2 and 2-3 blind/buried vias, plus 1-6 full stack
<azonenberg>
The reference design for that chip was 8L with like twice as many HDI layers :D
<NeroTHz>
did you check what the difference was to get a 1-2, 2-3, 3-6 instead of adding the 1-6? or 1-2, 2-5, 5-6?
<azonenberg>
I dont remember, it was years ago
<NeroTHz>
I was told once that adding through-vias are a big cost, but ofcourse, if you need through-hole, you don´t have a choice
<azonenberg>
There was a HDMI connector with through-board mounting holes
<azonenberg>
i think onc eyou're doing that drill+plate step you might as well do 1-6 vias too
<NeroTHz>
it had to do with how they had to mask the existing blind vias during plating or something
<NeroTHz>
but yeah
<NeroTHz>
it´s all complex and I have no fucking clue how any of this stuff works :p I just throw shittonnes of money at the problem and make it happen
<azonenberg>
This was the board. My first >4L design
<azonenberg>
NDA is expired and the company is long out of business so i can show you :p
<azonenberg>
It was a fun design, and hand assembling that as a relative newbie to BGA was a bit exciting
<azonenberg>
actually 2014, i had done a few bga designs by then. but still, 0.4mm WLCSP was more than I had attempted before
<azonenberg>
There were a few bugs in the design, this was also my introduction to inner layer PCB rework lol
<azonenberg>
I got the pinout wrong on a big samtec connector on the back side, most of the pins went to the FPGA and were trivial to remap but i had to move a few
<azonenberg>
This predated my PCB signoff checklist, which has done wonders for reducing bugs escaping into production
<NeroTHz>
we only have one actual optical table though (not counting some of our probestations which are built on top of OEM optical tables)
<NeroTHz>
most of the stuff is just some optical breadboards we build stuff on atop regular lab tables
<azonenberg>
Most of my lab tables here are sheet steel factory tables from uline
<azonenberg>
They're built like tanks, i think the weight limit is like a thousand kilos if you spread it out
<azonenberg>
they're metal so won't build up a static charge, and are sitting on a grounded floor so fairly safe esd-wise
<azonenberg>
then i just slap an esd mat on top to avoid shorting out my DUT (I don't trust the paint to be insulating) and serve as a sacrificial surface i can replace when it gets too beat up
<NeroTHz>
mhm. One of the grips I have with the lab tables at work is that they feel like they vibrate a bit too much. It´s not that they are week, they are really strong, and they are ESD safe and all that, just they flex a tad
<azonenberg>
I have one table that's like that and it's on my list of things to get rid of
<azonenberg>
or turn into household furniture
<azonenberg>
These tables are rock solid
<NeroTHz>
I loved my home lab table
<azonenberg>
i have literally stood on them while pulling fiber optic cables in the trays in the ceiling
<azonenberg>
and it barely moved
<azonenberg>
i did not feel any flex at all
<azonenberg>
my wife was wathcing and said she saw a tiny bit of bend but that was it
<azonenberg>
i've tried to shake them and between the weight of the table and the gear on it, they dont move
<azonenberg>
very happy i got them
<azonenberg>
i thought about the fancy ESD-labeled tables, but they were soooo expensive and it's really just plastic with some carbon mixed in
<azonenberg>
Painted steel isn't gonna tribocharge and a grounded mat on top makes it totally safe
<NeroTHz>
it has a bunch of 19¨ racks on the bottom, and then a nice place to put instrument on top
<NeroTHz>
and it´s quite high, so I can comfortable work at it while standing up
<azonenberg>
Nice
<azonenberg>
I normally work sitting down. My chairs are standard office chairs but i spray the fake-leather cushions down with antistatic spray monthly to minimize charging
<azonenberg>
and since it's my house i normally wear socks and no shoes, so i'm well grounded to the floor via my feet
<azonenberg>
and the table via my elbows
<azonenberg>
never had any ESD issues or observed any signs of charge buildup
<NeroTHz>
I think most modern ICs, esp digital, have decent ESD protection
<NeroTHz>
even our millimeter-wave chips have tonnes of ESD
<azonenberg>
I have only killed one chip via ESD and it was a USB hub
<NeroTHz>
but the stuff like passive mixers and so on in instruments are super delicate, usually literally just thin diodes or single transistors, extremely fragile
<azonenberg>
i was plugging my phone in to charge in the middle of a new york winter, sitting at my desk
<azonenberg>
i saw a visible spark from my finger to the connector
<azonenberg>
and that port never worked again
<azonenberg>
a week or two later there was a second, smaller ESD event that finished the job
<azonenberg>
and the whole hub was toast
<azonenberg>
but i've never had an ESD issue with a board in my lab
<NeroTHz>
damn
<azonenberg>
I also don't work on hard drive read heads though :p
<NeroTHz>
One of the interesting things we see with ESD is coax
<azonenberg>
Which i've heard have a human body model ESD tolerance in the... double digits?
<azonenberg>
like a <100V ESD event is instantly fatal
<NeroTHz>
because the center is never discharged
<NeroTHz>
damn, thats sensitive
<NeroTHz>
some RF stuff is too, rated to 100 V ESD or less
<NeroTHz>
just enough to survive pick&place handling
<azonenberg>
apparently it is, or was, one of the biggest sources of yield loss
<Degi>
Hm yes, kinda worried about the coax thingie too when plugging one into a serdes... Though the cable is probably sufficiently low quality that dielectric leakage would kill ESD on the conductor.
<Degi>
Whats the ESD tolerance of a human
<Degi>
Ooh, the 2 tgables behidn eachother look good
<NeroTHz>
Degi, yea, the coax into high speed serdes is a big problem. Esp since most high-end coax has a PE or PTFE center conductor. Leaky dielectric means lossy dielectric, after all
<Degi>
Leaky dielectric means that I pay 1 € for a cable
<NeroTHz>
so you see special ESD-discharge tools for connectors in some labs. I´ve pointed out you can just use a 50 ohm termination termination or oneo f those ccaps that shorts the center conductor instead
<NeroTHz>
ah I see :p
<azonenberg>
Yeah i was gonna say
<Degi>
Or stick your finger inside
<azonenberg>
why not just use a terminator
<azonenberg>
you dont even need to torque it or anything
<azonenberg>
finger tight would be more than enough to bleed off any voltage
<Degi>
Idk my terminator is in some box somewhere
<NeroTHz>
azonenberg, well, with very high-precision terminators, you risk zapping the terminator. They are often very thin sheet resistors, and zapping could bring them out of cal I guess
<NeroTHz>
azonenberg, yeah, but I try to avoid poking center conductors on our higher-preformance cables :p
<azonenberg>
NeroTHz: yeah thats why you use a cheap one
<azonenberg>
i have some $3 amphenol SMA terminators that i think would be pretty hard to make mismatched more than they are now :p
<Degi>
Y'all with your pricy cables where you won't dare to stick a sweaty pinky finger inside xD
<azonenberg>
Degi: last week i went through my lab and put dust caps on all of my SMA cabling and adapters
<NeroTHz>
azonenberg, indeed. But then I prefer just getting a short, in a big lab, it´s easier to avoid people mixing them up or not doign it properly - by simply telling people to never use a terminator, I avoid them using the wrong terminator and blowing our NIST-tracable 50 ohm standards to bits :p
<azonenberg>
Lol
<azonenberg>
This is one of the nice things about a home lab
<azonenberg>
You don't have to worry about some lunatic doing something stupid :p
<Degi>
Lol
<Degi>
"I made the NIST standard into a lightbulb"
<NeroTHz>
ome to the conclusion they might not need it in a certain situation
<NeroTHz>
that is one of the big things I learned becoming semi-lab manager of a big lab - you can´t rely on common sense ever. You just need one idiot that missed the memo to screw it all up. So instead of saying ´you don´t really need a DC block on that IF port in this case´, you just tell them to *always* use a DC block, no matter what. And the people who are familiar enough with what is going on will themselves c
<NeroTHz>
which is why I tell the absolute newbs to even torque-wrench their DC cables using SMA connectors. Better to get them to do use the torquewrench when they don´t have to, than have them not use it when they should
<azonenberg>
Yeah i've been a stickler for proper procedure in my home lab and am trying to bring that to $dayjob
<azonenberg>
once we get back in there, at least...
<azonenberg>
But like, i actually have weekly/monthly/annual preventive maintenance and cleaning checklists i go through at home
<azonenberg>
Just to make sure i keep the facilities in tip-top shape
<Degi>
Hmh whats the best way to dedustify my room...
<NeroTHz>
yeah. I´m starting to bring that to the lab too. Starting to introduce (bi) monthly cable checks with the guage kits, going thruogh adapters to verify we have enough and the right ones, checking that the matched cables are still in propper set (that is the annoying thing when you have 10 sets of 25 cm matched pairs lol)
<NeroTHz>
similarly, buying way more power supplies to eliminate issues there
<azonenberg>
Yeah once i get a gauge kit i intend to start doing routine inspections of cables and fittings
<azonenberg>
probably annual or so since i'm not a high volume facility like you are
<azonenberg>
the connectors get less wear per unit time
<NeroTHz>
yeah indeed. I also try to every few weeks just go to the drawers with cables, and flip them
<NeroTHz>
or just move them around. In general, trying to avoid the top 20 cables getting 90% of the wear, and the bottom 10% never being used
<NeroTHz>
I have a big list of stuff I need to do once the summer-measurement-rush is over :p
<Degi>
Is there something bad with having an electric field of like 10 kV/m across your room?
<NeroTHz>
seems...excessive?
<Degi>
To keep the dust away
<azonenberg>
loool
<NeroTHz>
if you really want to do it the ´right´ way, the best approach is to just avoid turbulence and have constant laminar flow, preferably top to bottom
<azonenberg>
And HEPA filters on the HVAC supply air
<Degi>
Hm yes, the neighbors below would be happy with fresh air heh
<azonenberg>
and wear bunny suits and hoods and gloves
<Degi>
HVAC? lol
<azonenberg>
oh and sticky mats at the entrance
<NeroTHz>
(which is why if you ever are in a cleanroom, pay attention to how the roof and floors have hunderds of tiny perforations because they just have air flowing from top to bottom always)
<Degi>
Yes ik
<azonenberg>
in all seriousness i try to run my lab as a "cleanish room" just to make cleaning easier and reduce dust buildup on equipment and boards
<Degi>
Hmh theres a ceiling above me, the door is usually locked though. And no idea how thick the floors are. 1 meter?
<azonenberg>
no sticky mats or anything but i have hepa filter cleaners running constantly recirculating the air just to keep dust down
<Degi>
Hitting 30 °C in my room... I should build a cooler based on water vaporization or so...
<NeroTHz>
but how dust-free do you want to make it? just running the right type of filter could already really help. And avoid dust-producers, so no blankets, carpets, sweaters, beds, sofas, etc.
<Degi>
Yes I wanna do that with an electrostatic filter
<azonenberg>
NeroTHz: some snippets of my maintenance records
<Degi>
Did you know that fun stuff happens when IPA is exposed for too long to air
<azonenberg>
Degi: what do you think i have the peroxide strips for?
<Degi>
ahh
<azonenberg>
when i first started testing i found a forgotten bottle, nearly empty, that i had since college
<azonenberg>
it was 400ppm
<Degi>
Haha
<NeroTHz>
azonenberg, I think that is a really good idea
<Degi>
Is 400 ppm bad=
<Degi>
Like thats 0.04 %
<azonenberg>
Normally you discard solvents at 100 and mark them as "don't distill" well below that
<azonenberg>
400 isn't "blows up if you look at it sideways" but definitely raises eyebrows
<Degi>
Ahh yes dont distill ofc
<azonenberg>
I don't use any of my solvents for distillation so my rule is to discard at 100ppm and re-test monthly if any detectable peroxide whatsoever is present
<NeroTHz>
Oh that reminds me, does anyone know of a permanent marker that does not disolve in IPA
<azonenberg>
what are you writing on and does it have to be a *marker*?
<azonenberg>
crayon-type instruments are alcohol resistant
<NeroTHz>
azonenberg, you know the PCB I showed earlier? It had a white box with sample number above it
<azonenberg>
but can be removed with an appropriate solvent
<azonenberg>
For serial numbers i prefer stick-on labels
<NeroTHz>
we use that to write with a permament marker what sample it is
<azonenberg>
i stopped using markers for exactly that reason
<azonenberg>
Google shows some alcohol resistant markers labeled for cryogenic applications
<azonenberg>
So those might be worth trying? cant recommend any from experience though
<azonenberg>
i bought a label maker :p
<NeroTHz>
yeah we have label makers but we like being able to write on samples
<NeroTHz>
like ¨RX1 - VBB high, Ileak out of spec´
<azonenberg>
Somebody on reddit likes the Staedtler Lumocolor F
<azonenberg>
says it's ethanol resistant, no mention of IPA
<NeroTHz>
those are not IPA resistant :p because that is what we use now
<azonenberg>
this is glscopeclient displaying four analog channels with 10M points per channel
<azonenberg>
as fast as the scope can trigger with no analysis or processing
<bvernoux>
Hotspots is a nice tool
<azonenberg>
you can see ScopeThread has a long period of low activity as it polls the scope for triggers and downloads data
<bvernoux>
great
<bvernoux>
You are still optimizing it ?
<azonenberg>
then a big burst including the other three openmp threads as i parallel convert all of the waveforms from raw 8-bit adc samples to float32 volts
<azonenberg>
then right after that finishes there's a burst in the main thread as i render the waveforms
<bvernoux>
I checked the code a bit yesterday i saw there is hardcoded number of core to 8
<azonenberg>
where?
<bvernoux>
maybe there is something better to do
<bvernoux>
let me find it
<azonenberg>
i thought i removed most of that
<azonenberg>
there were some cases in which i found more threads didnt make it better so i capped it
<bvernoux>
Do you have feedback about perf with AMD CPU ?
<azonenberg>
I'll go back and re-evaluate if that's necessary. But i recall having the limit too high actually made it perform worse
<azonenberg>
i'm an all-intel lab so i havent profiled it on anything else
<bvernoux>
Will be intereting to check with a Ryzen9 last gen ;)
<bvernoux>
I will probably do not buy ThreadRipper ;)
<bvernoux>
AS they burn Intel also Xeon ;)
<bvernoux>
Anyway for glscope stuff the most important is probably not the CPU but GPU too
<bvernoux>
I doubt decoder take so much CPU
<azonenberg>
Decoders actually get quite cpu heavy especially for eye patterns and plls
<azonenberg>
but they're hard to parallelize
<azonenberg>
basic math parallelizes well
<bvernoux>
ha yes for such stuff I imagine
<noopwafel>
azonenberg: how is RAM usage btw?
<bvernoux>
also the FFT stuff which shall be definitely tested in GPU
<azonenberg>
FFTs are currently software only but i'm planning to explore pushing them to gpu
<bvernoux>
it will be great to have things not locked to NVIDIA CUDA
<azonenberg>
noopwafel: My current test case, 4 channels * 10M points per waveform, i think keeping the default history of ten waveforms
<azonenberg>
uses about 8GB when running
<bvernoux>
to keep it compatible with both NVIDIA/AMD or Integrated GPU in Intel/AMD
<NeroTHz>
azonenberg, are you doing filtering in time or frequency domain? FFT->multiplication->IFFT might be faster sometimes (with GPU?)? not sure
<azonenberg>
bvernoux: yeah all of the gpu stuff is compute shaders
<bvernoux>
I doubt compute shaders can do FFT but it will be amazing ;)
<azonenberg>
NeroTHz: I don't actually have a any generic filters yet . I use the term "filter graph" just because it's industry standard terminology
<azonenberg>
my de-embedding and CTLE are FFT based
<NeroTHz>
kay
<azonenberg>
the CTLE just is a multiplication with a piecewise linear curve in the frequency domain
<NeroTHz>
yeah, that is what I thought and meant by filter
<azonenberg>
but things like protocol decodes etc are largely time domain
<azonenberg>
bvernoux: actually i found a compute shader fft implementation
<azonenberg>
i have not tried to use it yet
<bvernoux>
ha great
<NeroTHz>
fft is just a bunch of multiplications and additions after all
<NeroTHz>
that is the magic of the fft
<bvernoux>
IIRC CUDA FFT are very fast
<azonenberg>
Anyway, there's a bunch more i want to try optimizing
<bvernoux>
but locked to NVIDIA stuff
<azonenberg>
one thing in particular, there's some fairly expensive math in WaveformArea::PrepareGeometry that i'd like to work on at some point
<NeroTHz>
azonenberg, I remember a quite I think from Dijkstra or Knuth ¨Premature optimization is the root of all evil¨
<azonenberg>
this currently runs entirely sequential, one viewport at a time, single thread
<NeroTHz>
a quote*
<azonenberg>
NeroTHz: Lol. Well this isn't premature, it's in relatively stable code that is becoming a bottleneck at tens of Mpoints
<bvernoux>
azonenberg, do you have compared omp vs pthread ?
<NeroTHz>
azonenberg, makes sense :p I just like keeping it in the back of my mind when doing a design. Try to get the damn thing to work, then start tweaking the performance
<bvernoux>
IIRC pthread provide better performance for some cases...
<azonenberg>
bvernoux: omp calls out to pthreads under the hood
<azonenberg>
i use it as a quick and dirty "throw some parallelism at it"
<bvernoux>
yes it is a good things anyway and if needed it can be rewritten to native pthread ;)
<bvernoux>
I remember pthread stuff are very badly documented with strange effect
<bvernoux>
especially on libairspy to manage the 40MB/s stream of IQ data
<bvernoux>
but at end after lot of headach the performance are just amazing with very little CPU used
<azonenberg>
40 MB/s is only 320 Mbps
<azonenberg>
I'm processing 400+ in this benchmark
<bvernoux>
yes but over USB 2.0 HS ;)
<bvernoux>
you shall do not have some wait state
<azonenberg>
One thing that bothers me right now is that LeCroyOscilloscope::ProcessAnalogWaveform() spends more time in FillWaveformHeadersAVX2 than in Convert8BitSamplesAVX2
<azonenberg>
massively more time, in fact
<azonenberg>
Even though it is - or should be - doing less work
<bvernoux>
challenge was to have realtime streaming very stable at 40MBytes/s over USB 2.0 HS
<azonenberg>
aaanyway i really should get to sleep before my wife wakes up
<bvernoux>
I can say you it is really better than what is available on hackrf lib
<bvernoux>
which cannot sustain 40MB/s on low end PC
<bvernoux>
azonenberg, have good night
<bvernoux>
on an other topic does anyone have checked if it could be possible to use sigrok decoder on glscope in compatibility mode ?
<bvernoux>
until there is the native glscope version of course
<noopwafel>
azonenberg: both functions will be memory-limited and fillwaveforms is writing to two buffers of 8-byte size, while convert is using two buffers of 4/1-byte respectively?
<electronic_eel>
bvernoux: I once asked azonenberg about the sigrok thing, IIRC he said that it would be nice to have, but should be fully optional because licensing
<electronic_eel>
also some people considered some of the sigrok decoders not very high quality
<electronic_eel>
so sigrok integration is something that could be contributed by someone, but azonenberg doesn't want to develop it himself
<bvernoux>
yes I understand that point
<bvernoux>
the advantage is there is tons of decoders
<bvernoux>
and they are GPL so I do not see any issue with license
<bvernoux>
as they are in Python3 and so just used as external plugin which shall not contaminate glscope... licenses
<bvernoux>
a very good news is QucsStudio v3.3.2 is available !!
<bvernoux>
and it include electromagnetic field simulator !!
<bvernoux>
amazing
<bvernoux>
drawback it works only on Windows and it is not open source
<bvernoux>
but it is freely available
<electronic_eel>
bvernoux: azonenberg wants to use a permissive license (BSD), to allow someone like a scope vendor to distribute it together with closed modules
<electronic_eel>
so linking in a GPL module would prevent that. this is why it has to be optional
<bvernoux>
yes but sigrok decoder are not linked
<bvernoux>
they are external python script
<electronic_eel>
hmm, I'm no lawyer, but it might still be considered linking if you call a python script with a dedicated interface
<electronic_eel>
I think it depends on how generic the interface is that you call and what the intention of that interface is
<bvernoux>
I have simulated an interdigital bandpass filter in 30s ;)
<electronic_eel>
re QucsStudio, I don't understand why it is not open source. the developer doesn't seem to plan on selling it
<bvernoux>
using OpenEMS in background without writing one line of script ;)
<bvernoux>
yes QucsStudio is a bit strange towards that point
<bvernoux>
He's the main author/creator of open source qucs
<electronic_eel>
I think there is some strange ham culture of "free, but not open source"
<bvernoux>
but it seems there was some problems in the team of qucs
<electronic_eel>
I don't know where that comes from
<bvernoux>
yes it is a good example of something free but not open source :(
<electronic_eel>
he could always say open source, but I don't want any outside code contributions
<bvernoux>
yes but he closed all ....
<bvernoux>
maybe he plan to sell what he has done at end
<electronic_eel>
but I guess some people just want to be in full control and prevent any forks
<bvernoux>
yes it is clearly the case here
<bvernoux>
it is a hard point on open source license too
<bvernoux>
for hardware I like CC BY NC for that ;)
<bvernoux>
but it just avoid other to gain money
<bvernoux>
and it is still very open and anyone can do derivative
<bvernoux>
but it shall be not used for commercial purpose except by the original author
<bvernoux>
so far I'm using CC BY NC for HydraBus/HydraNFC to avoid to be cloned and loose money on my production
<electronic_eel>
I guess this is not about money, just about power and control and preventing a community
<bvernoux>
but it is planned to be CC BY SA or even fully open when I will release HydraBus v2 ;)
<bvernoux>
yes for open source sw it is different case
<bvernoux>
here it seems more related to "power/control" and not money as there is nothing to win doing open source stuff
<bvernoux>
except some donations ...
<bvernoux>
anyway the OpenEMS integration is very nice
<bvernoux>
amazing in 2 click it do all ;)
NeroTHz has quit [Read error: Connection reset by peer]
<azonenberg>
noopwafel: yeah i want to see if i can optimize it further though. By reducing the amount of memory writes etc. or multithreading, or some combination thereof