azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal, https://github.com/azonenberg/scopehal-docs | Logs: https://freenode.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
<miek> it's so nice to be able to bring up a scope fft side-by-side with when debugging radio stuff https://i.imgur.com/E6tfuCw.mp4 :D
Famine- has joined #scopehal
Famine_ has quit [Ping timeout: 244 seconds]
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #scopehal
<azonenberg> miek: nice
<azonenberg> have you tried the waterfall display mode yet?
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
<azonenberg> NeroTHz: so i'm working on more modeling of my probe design trying to figure out if i can track down the source of that dip at ~2.25 GHz
<azonenberg> Right now i'm in a rather interesting state with a broken sonnet license file where half the software thinks i'm using my purchased L2 Basic edition and the other half thinks i'm using a 30 day demo of the full pro version
<azonenberg> And the current (incomplete) simulation is acting... weird. There are four distinct ranges of frequencies (roughly 1.35, 6.3, 6.45, and 8.65 GHz) where the simulated S21 is *positive*
<azonenberg> this is for an entirely passive network, gain should not be possible
<azonenberg> oh and 4.3 GHz too
<sorear> well if the licensing status is inconsistent in space that can act as a gain medium,,
<azonenberg> lol
<azonenberg> basically right now the status is that the solver thinks i have the full edition
<azonenberg> but the GUI thinks i have basic
<azonenberg> So i can create and simulate arbitrarily large designs using the 32-thread solver until september 7th
<azonenberg> (well 64 but i only have 32 cores)
<azonenberg> But I cannot use more than 2 layers or any of the other limits enforced in the editor
<NeroTHz> azonenberg, passivity errors are common when you simulate stuff without high enouhg meshign resolution
<NeroTHz> it´s essentially compounding numerical errors causing gain
<azonenberg> Makes sense. You think the overall shape of the curve is still valid though? or is this total garbage?
<NeroTHz> it can be. hard to say really :p
<azonenberg> this sim is already using like 5GB of ram and ran for several hours lol
<azonenberg> Not looking forward to turning up the resolution
<NeroTHz> Welcome to the wonderfull world of high-resolution EM simulation :D
<azonenberg> several hours on 32 threads
<azonenberg> Lol
<azonenberg> i mean i'm modeling an entire scope probe at 50um cell size
<azonenberg> this was also on, i think, the medium control for mesh coarseness
<NeroTHz> do you have adaptive meshing? this is the kind of stuff where adaptive meshing pays for itself
<azonenberg> Yes sonnet has adaptive meshing even in the basic version
<azonenberg> They have a slider for 3 settings of mesh resolution
<azonenberg> coarse with no edge meshing, coarse with edge meshing, and fine with edge meshing
<NeroTHz> ah they don´t use delta-s to control it?
<azonenberg> i'm using coarse with edge meshing
<azonenberg> Internally it has all kinds of tuning knobs for things like min/max grid cells per mesh cell etc
<azonenberg> but the slider is what i normally use for rough control
<azonenberg> I was trying to get my original direct gerber import that wanted ~40GB of RAM down to something that would simulate in a feasible amount of time
<azonenberg> So i did a bunch of simplifications like turning my individual vias in the fence into a long rectangular via, etc
<azonenberg> i'll be testing each of the simplifications to see what kind of effects they have separately
<NeroTHz> The 3D solvers I usually use have a delta-S system. They mesh, and then at one or more frequency points of your choosing, it solves. It then compares that with the previous results, and if the delta in s-parameters is larger than som threshold, it looks where the fields where most different and strong, and then adds meshing there, redoes the whole thing
<NeroTHz> yeah, simplifying PCB layouts is one of those things you get a feel for with experience
<azonenberg> i've done a bunch of it already to squeeze stuff into basic
<sorear> computational requirements would be much lower if you could put your scope board in a 2-dimensional universe
<azonenberg> And interesting. no, i think sonnet normally does the meshing once before starting the run
<NeroTHz> technically speeking sonnet already does 2-D solving :p
<azonenberg> it takes into account corners and other predicted areas of high field gradient
<azonenberg> But it won't go back and tune the mesh size ex post facto
<NeroTHz> azonenberg, it could be the way that MoM works. I don´t know if ADS/Momentum does adaptive meshing
<NeroTHz> I can look into it actually. can you manually add meshpoints?
<azonenberg> I've never tried
<azonenberg> i've always drawn geometry and let it decide how to mesh
<azonenberg> this is what i have so far, it's not done running
<azonenberg> blue trace is actual vna data of real probe including tip and connector but with fixture and cable de-embedded
<azonenberg> red is the incomplete sim output of the probe body with the attenuator resistors shorted
<azonenberg> so it should ideally be just a transmission line
<azonenberg> separate vertical scales of course
<azonenberg> I also have a slightly higher fidelity idealized sim (netlist only, no field solver geometry) of just the attenuator queued up for whenever this one finishes
<azonenberg> The red trace is using what sonnet calls "adaptive band synthesis" which is a fancy way of saying it searches for inflection points and sharp curves in the response then evaluates more frequencies around them
<azonenberg> and does less work in areas where the response curve is pretty flat
<azonenberg> then ultimately fits a curve to the response vs the piecewise linear approximation it shows when sim is still running
<NeroTHz> yeah, that is adaptive frequency point solving which pretty much every solver these days have and they all give it a fancy name to try and make it seem like theirś is special
<NeroTHz> Do you have s-parameters from vishay for the reistors?
<NeroTHz> ah but you can´t add a bunch of ports can you
<NeroTHz> your limited because of your specific license
<NeroTHz> the way I did some simulations in the past was just add a port for every SMD component padd, and then after I get the PCB S-paramters, just hook up the s-parameters for the devices to the correct pads in a schematic sim
<azonenberg> Yes. I've done exactly this for small designs
<azonenberg> more specifically 2-port networks with up to 2 internal components
<NeroTHz> that is also how we do final verification of IC stability in ADS; we have huge simulations with 80+ ports, every port connects to transistors or so on
<azonenberg> Internally, when you have higher end sims that include s2p data file components, this is exactly what it does
<NeroTHz> and then we put them in our Cadence SPICE tool and hook up the different transistors to each of the ports
<azonenberg> it just does the circuit theory modeling for you
<NeroTHz> makes sense
<azonenberg> and shows you overall s-parameters and current density
<NeroTHz> I´ve actually been meaning to look at something related to that when you put caps in parallel
<NeroTHz> There is this patent from Dell that suggests that putting caps in parallel gives significant error (so you would expect C_total = C1 + C2 + C3, but it is actually lower) because the ´skin-effect´ causes less current to flow through the center capacitors, and so you ¨don´t see them¨
<azonenberg> I know i've seen suggestions to, when you have closely spaced decoupling caps
<azonenberg> flip them around
<NeroTHz> yes
<NeroTHz> that is also their suggestion
<azonenberg> vs having all of the vdd at one side and vss at the other
<azonenberg> but i havent done any modeling myself to see how big a dea lit is
<azonenberg> i normally do it if possible because i figure it probably wont hurt
<NeroTHz> but I wanna measure this or simulate it, but to simulate it you really need to include the insides of the caps
<azonenberg> Yeah makes sense
<azonenberg> sonnet pro, actually, could probably model a full MLCC stack if you wanted to lol
<NeroTHz> hmm interesting. The problem with ADS/Momentum is that you can´t simulate finite dielectrics
<azonenberg> Sonnet allows "dielectric bricks"
<NeroTHz> every dielectric layer is considered infinite in width and length
<NeroTHz> hah, that is cool
<azonenberg> they also support anisotropic dielectrics like sapphire
<azonenberg> both, of course, only in pro
<NeroTHz> I just realized that I´m wearing a tshirt that has sonnet-branding on the back (the IMS goodie-bag tshirt from 2018)
<azonenberg> lol
juli964 has joined #scopehal
<azonenberg> ooook so, some new updates
<azonenberg> I think i'm on the right track with my new modeling. There seem to be two different mechanisms causing non-flatness
<azonenberg> The first one is dominant from DC to about 2.25 GHz and appears to be located in the resistor array. My netlist model of s-parameter resistors connected by ideal transmission lines 1.6mm long tracks measured data quite well
<azonenberg> this is assuming ideal transmission lines with no dielectric/conductor losses, but actual s2p models of the resistors
<azonenberg> The attenuator string is flat to nearly 10 GHz if you string the s2p's together with zero electrical length between them, but if you add even 1.6mm of transmission line between them, as i have now, you get this
<azonenberg> And as you shrink that line, you get better results
<azonenberg> Around 2.25 - 2.5 GHz this sim and reality begin to diverge, suggesting there is a second effect i play
<azonenberg> in*
<azonenberg> Which i have not yet identified
<monochroma> :o
<azonenberg> This is good already though
<azonenberg> It suggests room for improvement
<azonenberg> By moving the resistors closer, or using less of them
<azonenberg> this is what i get for 0.8 instead of 1.6mm between the resistors (including pad size)
<azonenberg> This would require the resistors to be physically overlapping by 0.3mm so it's not possible to do with the current string
<azonenberg> But clearly the electrical length between the resistors is extremely important
<azonenberg> And the 0.5mm gap between the resistors, despite being an apparently negligible fraction of a wavelength, has a massive effect
<monochroma> azonenberg: hmmmm what happens if you interleave them?
<azonenberg> interleave?
<NeroTHz> I wonder if what you are seeing is more of a capacitive effect or such
<azonenberg> NeroTHz: this is a purely s-parameter based model
<NeroTHz> ah
<azonenberg> The field solver model is separate and i'm still working on getting the whole probe into sonnet, like i said before i'm fighting issues with the demo liecnse
<NeroTHz> so just idealized transmissionline lengtsh
<azonenberg> Correct
<azonenberg> but out to 2.5 GHz it matches very well
<azonenberg> suggesting it's the dominant effect out to that point
<azonenberg> Then something else starts happening
<azonenberg> This is 200-200-50 ohms with 1.35mm of electrical length between them including terminals
<azonenberg> which translates to 0.25mm between resistor bodies instead of 0.5mm
<azonenberg> At 2 GHz it's only down about half a dB, and you hit -3 at around 6.3 GHz. So that's a hard limit on performance using that resistor geometry assuming zero dielectric/conductor losses and elimination of whatever that thing happening at 2.5 GHz is
<monochroma> azonenberg: instead of them being back to back in series in the X plane, have the pads between resistors vertical so you have basically 2 resistors per pad ?
<azonenberg> you mean just in an s-curve?
<azonenberg> oh
<azonenberg> that's an interesting idea to reduce the electrical length
<azonenberg> allowing sideways current flow
<azonenberg> hmmmm
<azonenberg> I might think about that for v1.1. But before i do another board spin two things need to happen
<azonenberg> first, understanding this second effect better
<azonenberg> second, shipping the current boards to my backers
<azonenberg> they meet the original performance target so i'm shipping them
<azonenberg> i now know for a fact i can do better, so i intend to continue improving
<NeroTHz> consider alternating the lengths between resistors
<azonenberg> you mean unequal lengths?
<NeroTHz> yep. 0.4 between first two, then 1, then 0.8 or whatever
<azonenberg> so you get two smaller reflections at different freqs instead of one bigger one?
<azonenberg> interesting idea
<NeroTHz> yes
<azonenberg> although i also am thinking of dropping from 6 resistors to 3 which will greatly reduce this effect too (the -3 screenshot shows a 3-resistor string)
<azonenberg> i originally planned the 6-res string based on inaccurate modeling that assumed no electrical length between the resistors
<NeroTHz> Its something they do in coaxial cables too, ´dither´ the wrappign overlap length of the foil ground
<azonenberg> I falsely assumed that an 0.5mm gap at 2 GHz, being <1/100 wavelength, would be negligible
<azonenberg> but first, it's 1.6mm not 0.5 because of the size of the terminals on the resistors themselves
<azonenberg> and second, when you have several the overall stub lengths increase
<NeroTHz> the models you have likely dembedd the pads right? really need to include those. Sometimes you can do it as differen width microstrips in simulation
<azonenberg> So the next step is modeling the entire attenuator string with actual imported gerber geometry and s2p models
<azonenberg> this was supposed to be today's after-work project
<azonenberg> but until sonnet support figures out why half the tools think i have a 30-day demo of pro and half think i have a full version of basic, i can't do that
<azonenberg> I think, looking at the flexlm file they sent me, they missed the demo on one component and accidentally sent me a license for basic instead
<azonenberg> Normally they give demos to customers who havent bought the tool at all
<azonenberg> but you can also request one if you're considering an upgrade
<azonenberg> Which is the case for me
<azonenberg> So my license file is kind of a hybrid with both basic and pro in it and different expirations etc
<azonenberg> NeroTHz: and my understanding is that the vishay s2p models have the entire pcb de-embedded, but include the component-side pads and resistive element
<azonenberg> I'm unclear on which side of the component pad the reference plane is
<NeroTHz> usually it´s at the end, I think.
<azonenberg> i.e. is the port at the inner edge of the pad where it touches the resistive element or the outer end?
<NeroTHz> outer end
<azonenberg> Hmm
<azonenberg> So there is some overlap between the pcb land and the component pad
<NeroTHz> but in my experience, models always came with a ´readme.txt´ to clarify this
<azonenberg> and sonnet wants a port to be at the edge of a polygon
<azonenberg> i wonder if i could play some tricks with ref extension on the port to move the port virtually into the middle of the pad
<azonenberg> That should be doable
<azonenberg> Clearly even that fraction of a millimeter makes a huge difference :p
<azonenberg> actually, wait a minute. I think it might be the inner edge of the pad
<azonenberg> Because that was the closest match for my ideal transmission line model vs the measured overall system freq response
<azonenberg> Maybe i should make a test board with just one of these resistors and some sma's and calculate how it should behave...
<NeroTHz> I´d personally send a request to Vishay and ask them to clarify
<NeroTHz> I don´t know about Vishay, but Murata have been super nice when I asked them for info in the past
<NeroTHz> even though my volume is like <100 parts
<azonenberg> I'll worry about that once i've got my current geometry actually simulating
<azonenberg> Which hopefully i can get figured out tomorrow because otherwise i wont be able to do sim work all weekend while they're out of the office
<azonenberg> NeroTHz: Any guesses on what could be causing that knee in the curve?
<azonenberg> And do you agree with my assessment that there are two different effects going on here?
<NeroTHz> sorry, what knee are we talking about
<NeroTHz> 404
<NeroTHz> okay
<azonenberg> reuploaded
<azonenberg> So blue/pink traces are actual VNA data off of my probes
<azonenberg> Red is s-parameter netlist sim of vishay resistors with idealized 1.6mm transmission lines between them
<azonenberg> It seems like a fairly close fit to the measured data
<azonenberg> Right out to about 2.25-2.5 GHz
<NeroTHz> does your simulation include TL line losses and so on?
<azonenberg> at which point the observed data starts suddenly curving down
<NeroTHz> though it seems really really steep for loss
<azonenberg> No. This is an idealized model of just the attenuator
<azonenberg> I should not be having that kind of loss in coplanar waveguide on silver-plated copper on ro4350b
<azonenberg> From 2.68 to 3.34 GHz i lose 5 dB
<azonenberg> that is not TL losses
<NeroTHz> there is 3 options: loss, Reflection, or radiation
<NeroTHz> Loss seems unlikely - too high
<NeroTHz> radiation seems too wideband (and you would see it with a near field probe I think), though it´s possible given all your discontinuities
<NeroTHz> reflection, I don´t know, could be.
<NeroTHz> but you can get much higher loss than you expect when things start resonating and reflecting back and forth
<azonenberg> Yes. That is what i'm suspecting. But where would i be having a resonance?
<NeroTHz> because your power is bouncing around, the ´effective´ length of lossy transmission line it sees is larger
<azonenberg> I've already validated the SMA launch transition on another board
<azonenberg> https://www.antikernel.net/temp/oshpark-thru-2.png this is on a FR408HR + ENIG test coupon so higher loss than the actual probe which is rogers + silver
<azonenberg> but same geometry, same connector. That looks like just TL losses to me with no mismatches at the connector
<NeroTHz> yeah that is what you would expect
<azonenberg> i forget if i've mentioned but i like using 408hr for cheap prototyping
<NeroTHz> yes
<azonenberg> because oshpark provides it readily, priced per area with no setup fees
<azonenberg> and Er is 0.04 away from 4350b
<NeroTHz> because it´s very similar to the brand of rogers you use
<azonenberg> yeah
<azonenberg> Higher loss but basically a drop in replacement
<azonenberg> anyway, althoguh i have not done a test coupon on rogers specifically with this connector launch and CPW geometry only
<azonenberg> that data seems to strongly suggest it's well matched
<azonenberg> None of my sonnet models have included the tip itself, i've at best modeled signal+ground ports at the tip of the PCB
<azonenberg> and i havent figured out a good way of characterizing the actual pin or socket
<azonenberg> (independent of the launch)
<azonenberg> So it's possible something is going on there
<NeroTHz> yeah, couldf be
<azonenberg> The distance from probe tip to first resistor is something like 8mm so that would put a quarter wave null around 8 GHz
<azonenberg> from the reflection off the first resistor
<azonenberg> But i wouldnt expect to be seeing effects of that just yet
<azonenberg> let me actually try modeling that, add a ~8mm stub from first resistor to the 50 ohm termination i'm measuring across
<NeroTHz> if you want you can actually figure out the impedance of that stub
<NeroTHz> by using a lader-line calculator
<azonenberg> Let me focus just on the electrical length for the moment and assume it's matched
<azonenberg> then we'll go from there
<NeroTHz> kay :p
<azonenberg> Dont want to change too many variables at once
<NeroTHz> yeah that makes sense
<azonenberg> and again still an idealized circuit theory model right now
<azonenberg> no field solver geometry, no parasitics from resistors to board, etc
<NeroTHz> yeah, but you could just figure out the impedance of the stub, it´s not gonna actually be a 50 ohm line, that´s all I meant
<azonenberg> Thaaat is interesting
<azonenberg> I think my test fixture is partly at fault?
* azonenberg grabs caliper
<azonenberg> So it looks like with the current fixture i might be probing as much as 10mm away from the actual termination
<azonenberg> this is with an 18mm lossless 50 ohm stub between the first resistor and the termination at the load
<azonenberg> assuming 8mm from resistor to first probe tip and 10mm from tip to termination
<azonenberg> (my current test fixture is probing center pin to shell of a SMA at the solder side, with a terminator cap screwed into the threaded side)
<azonenberg> i had a fancy soldered test fixture that had problems and had to be abandoned
<azonenberg> i might want to respin that so i'm probing more directly across 50R
<azonenberg> This is the closest model yet to the behavior i'm seeing, the exact frequencies are a little bit off but the general shape of levelish, big drop, leveling off, then another drop seems right?
<NeroTHz> yes
<azonenberg> So at this point i think at a high level i understand both of the problems with the current design
<azonenberg> I need to refine my modeling to figure out the specifics, but a) my current test fixture is giving false performance degradation due to the long distance between termination and probe
<azonenberg> and b) i need to tighten up the resistor string to be shorter and have less elements
<NeroTHz> Ideally you wanna spin an LTCC divider chain or something to really do it well :p no discrete components, embedded resistors!
<azonenberg> I looked into printed resistors actually
<azonenberg> Was cost prohibitive at the volume i'm doing
<NeroTHz> yeah, I would imagine it is
<azonenberg> But it was an option i seriously considered
<NeroTHz> It might almost be easier to do a run with a MPW on a old technology
<azonenberg> lol
<NeroTHz> like, you can do .35um CMOS runs for like 700 dollars/mm2 area
<azonenberg> austriamicrosystems via CMP?
<NeroTHz> like, design area, you get 50 or 100 samples
<azonenberg> C3B4 something process iirc
<azonenberg> that number is familiar to me :p
<NeroTHz> ooh AMS
<NeroTHz> yeah, AMS is a common one
<azonenberg> i actually looked into what it might take to do a custom scope/LA frontend on an older cmos process
<azonenberg> i need to learn a lot more before i could attempt it
<azonenberg> Too many projects, not enough time :p
<NeroTHz> Maybe once that goolge tech thing starts including analog models
<azonenberg> so sky130 is cool but likely to be a lot more expensive than 350
<azonenberg> they haven't announced, afaik, pricing yet
<azonenberg> since the first prototype runs will be paid for by google
<azonenberg> but that gives you zero idea of what doing a chip in the future on that process will cost
<azonenberg> for a MPW
<monochroma> how long have we been wanting to do an MPW project azonenberg ? :P
<NeroTHz> tbh, the biggest problems with MPW runs is packaging
<azonenberg> monochroma: for as long as we've known MPWs existed?
<NeroTHz> and software
<azonenberg> NeroTHz: $dayjob has a wirebonder
<monochroma> hehehehe
<azonenberg> for prototyping i could probably negotiate access to it easily enough
<NeroTHz> sure, you can build your own chip, but actually simulating it and so on often requires $$$ software
<azonenberg> Oh
<azonenberg> So that is the other thing the google project is trying to do
<azonenberg> they're funding the open toolchains to do digital design with entirely f/oss tools
<NeroTHz> Oh, you wanna design in TSMC? well, either you gonna shell out for 1mil Cadence licnes, or 200k Keyisght licenses, and pester TSMC for 4 months to give you the keysight models
<NeroTHz> yeah, there is a lot there for digital already, which is good
<azonenberg> Analog is going to be a lot harder obviously
<monochroma> laser trim a sputter coated resistive material directly on to the PCB? :P
<azonenberg> lol
<noopwafel> don't give azonenberg ideas
<monochroma> i might do that :P
<azonenberg> fib trim? :p
<azonenberg> i'd need more digits on my multimeter to characterize that though...
<monochroma> lol that would take forever
<monochroma> but precise! ;)
<NeroTHz> azonenberg, how would you place 50um solderballs on a die?
<NeroTHz> seems like easyspheres is the only provider I can find of <100um balls
<azonenberg> NeroTHz: how many per die and how many dies?
<NeroTHz> this would be research/prototype volumes, so handfull of dies, usually just a few dozen pads per die
<azonenberg> what's the metal stack look like? i assume there's nitride or polyimide cap over them?
<azonenberg> how thick is the overglass layer?
<NeroTHz> I´m not sure. I have to look into it
<azonenberg> if it's at least a few um thick the balls might actually self-center nicely in the openings
<azonenberg> especially if it's like thick polyimide
<azonenberg> what's the ball pitch?
<azonenberg> and did you work out your aluminum problem?
<azonenberg> honestly, if you have steady hands and good tweezers, i think it would be viable to freehand. I'd actually be more worried about how to flux it
<azonenberg> and how to not have the ball stick to your tweezer after you tried to release it
bvernoux has joined #scopehal
<azonenberg> A relatively low res micropositioner might work well too
<azonenberg> Although... 50um is pretty small
<azonenberg> NeroTHz: so i just did a little test in my lab
<azonenberg> got my tiniest tweezers and an old beat up microscope calibration slide
<azonenberg> with a bit of practice i was able to reliably hold the tweezer tip between two graduations 50um apart
<azonenberg> But tighter than that was hard
<azonenberg> So nudging a ball into place without some mechanical linkage would be difficult
<azonenberg> a 100um ball should be doable freehand i think
<azonenberg> but a 50um ball you'd want +/- 15-20 um of worst case misalignment for it to self center properly and i had a hard time getting my jitter that low
<azonenberg> that's a 1mm long scale, coarse ticks are 100um pitch, smaller ones are 50, the super fine ones the microscope barely resolves are 10um
<azonenberg> I'm hollding the tweezers as steady as i can
<azonenberg> trying to hit, for example, the tip of one of the lines
<azonenberg> and experimenting with different ways of holding the
<azonenberg> them*
<NeroTHz> damn
<NeroTHz> crazy
<NeroTHz> wondering if it is easy to adapt the bondingmachine to place balls
<NeroTHz> maybe they offer a head that does that
<azonenberg> but i'm somebody who does crazy fine pitch rework, can pluck bond wires off a chip by hand, and hand solders 0201 for breakfast :p
<azonenberg> If you dont have a lot of practice doing this your hands are probably gonna shake more than mine
<azonenberg> I dont think you will be able to place solder balls with the bonder per se
<azonenberg> however, you might be able to use the reduction-geared table to position the die
<azonenberg> then have a fixed head with the ball stuck to the end of a needle in a jig or something, held in place pneumatically?
<azonenberg> just an idea
<NeroTHz> azonenberg, I don´t mean with a default bonder attachement, but maybe they have some suction-cup attachement?
<azonenberg> My experienec with bonders is that they're pretty single purpose
<NeroTHz> nah, our bonder is superflexible, targeted specifically at prototype labs
<azonenberg> oh? what model
<azonenberg> I've mostly worked with old K&S ones
<NeroTHz> I think it´s an F&S Bondtec 58
<azonenberg> $dayjob has a K&S 4522
<monochroma> "It's bondtastic!"
<azonenberg> and then in grad school we had a similar model K&S, forget the number, but it was a wedge bonder not a ball
<azonenberg> apparently they have a K&S 4524 ball bonder in the cleanroom too? i've never used it though
<NeroTHz> going by the F&Sbondtec website, it seems like it does have a lot of heads, but only for different types of bonding
<NeroTHz> There are also options with ´stencils´ it seems. I´m sure I´l figure something out
<monochroma> yeah BGAs are usually reballed with stencils
<monochroma> but usually not at that pitch, so not sure what stencils are available
<NeroTHz> Most of our silicon now has 160um pad pitch - 80umx80um pad, with 80 um gap
<NeroTHz> but also cause we don´t BGA, we only have a row of pads on the outside, because we can´t put pads near our RF stuff because it will make it not work
<monochroma> if you have the cash, there are laser reballers that might do what you want
<NeroTHz> in long term, yeah, but right now this is just a pet project of mine
<NeroTHz> if it turns out to work, money usually isn´t too big of an issue
<monochroma> hehe
<NeroTHz> https://pbs.twimg.com/media/EeryonRWkAAPM0P?format=png&name=medium Shahriar flexing his home lab live @IMS
<monochroma> lol
<NeroTHz> Oh btw it turns out there is an NGM202 powersupply on the way to my worklab
<NeroTHz> excited
<monochroma> :D
_whitelogger has joined #scopehal
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
<NeroTHz> I love some of the head-in-the-clouds research presented
<NeroTHz> ´Yeah, air-filled substrate-integrated-waveguides. You just have to like mill out these super preceise paths in the middle substrate layers of your 10 layer PCB to build them, no biggie you know!¨
<monochroma> lol
<NeroTHz> Presenter works at Thales defense and aerospace. makes sense he has a hazy grasp with mass-production costs
<monochroma> 'What is this... too expensive you speak of?"
<NeroTHz> It´s not even necessaraly the absolute cost
<NeroTHz> but if you are building 5 of something, and your tooling cost is 10k, then you don´t care about 500 bucks extra because they needa mill your SIW lines, esp if it saves you 5k on rigid metal waveguide parts
<NeroTHz> but that doesn´t make it a viable mass-production technique, which is what the presenter is trying to sell this shit as
<bvernoux> I'm neogitiating my future SCope ;)
<bvernoux> a refurbished Tek Serie6 ;)
<bvernoux> It clearly seems totally amazing ;)
<NeroTHz> wooooo nice!
<bvernoux> let keep finger crossed ;)
<bvernoux> It will be amazing to have it and to support glscope
<bvernoux> over Gigabit Ethernet ;)
<vup> azonenberg: how would one go about feeding a stream of digital values from a "logic analyzer" into glscopeclient?
<vup> (in particular one that doesn't support triggering, but just streams the values all the time)
<vup> also do you think glscopeclient / the tmds decoder will be able to handle ~300MB/s of data?
<noopwafel> would also be nice to be able to stream scope data (without breaking the decoders)
<NeroTHz> I know I´m usually the go-to RF guy, but does anyone have experience comparing mating-lifetime of MCX vs SMB vs MMCX?
<monochroma> i have used MCX and MMCX a lot, but havn't worn any out (noticeably anyways)
<NeroTHz> We have a few of those 20/40 channel DAQ multimeters from keithley
<NeroTHz> but nobody uses them because it´s a pain to hook them up
<NeroTHz> so I was thinking about making a PCB that just hooks to the back of the meter with 1 or 2 big cables, and then ´fans out´ the cables to a bunch of MMCX or MCX or SMB or SMA connectors
<NeroTHz> I would use 4mm banana, but those get bulky fast if you need to put 2x40 of those on a PCB
juli964 has quit [Quit: Nettalk6 - www.ntalk.de]
<bvernoux> NeroTHz, SMA is clearly the best
<bvernoux> in all case SMA is better when you need lot of connection/disconnection cycles
<bvernoux> It is why it is the standard ;)
<NeroTHz> nah, SMA is actually kinda trash. It´s just the least trash which is why we all use it all the time :p but it was never meant as a test-equipment connector with hundreds or thousands of mating cycles
<NeroTHz> it´s arguably not even the least trash, it´s just the thing everyone uses so everyone else also uses it for compatibility
<bvernoux> I really doubt there is any existing connector which go to more 6GHz which can be connected/disconnected more than 500times
<bvernoux> I do not speak about USB C ;)
<NeroTHz> 2.4 and 1.85 mm :p
<bvernoux> for me it is like SMA ;)
<bvernoux> but for microwave ;)
<NeroTHz> those are not SMA because of one key difference
<bvernoux> it is same category
<bvernoux> same type of connector
<bvernoux> if you prefer ;)
<NeroTHz> I mean, then all other connectors that are coaxial are the same too
<bvernoux> no
<bvernoux> the plug is just same
<NeroTHz> it is not
<bvernoux> with smaller size
<NeroTHz> the main flaw of SMA is that the center pin mates before the outer shield/metal structure ensures alignment. So you can easilty have the male center pin poking the female center contacts while the entire thing is at an anlge.
<bvernoux> yes except for that detail ;)
<NeroTHz> this was fixed when they switched to 2.4 - the center conductors cannot touch before you have one or two revolutions of the threads engaged
<NeroTHz> but that is a *vital* detail
<bvernoux> for example TypeN is an other type for me
<bvernoux> 3.5mm, 2.4mm are evolution of SMA for microwave
<bvernoux> as SMA is dirty cheap ;)
<NeroTHz> 3.5 and 2.92 are. 2.4 and 1.85 are entirely new connectors
<bvernoux> yes but it is in same category ;)
<NeroTHz> Arbitrary categories are arbitrary
<bvernoux> of course you cannot use SMA for 40GHz ;)
<bvernoux> so you use the right one
<NeroTHz> I don´t think you understand why I don´t like SMA
<NeroTHz> it has nothing to do with the amount of GHZ
<bvernoux> SMA is used for cheap things
<bvernoux> else you switch to 3.5mm or 2.92mm
<NeroTHz> it´s just that SMA/3.5/2.92 has a fundamental design flaw, which it does not share with 2.4/1.85
<bvernoux> which are compatible
<bvernoux> it is why I say they are in same category
<bvernoux> you can mate 2.92mm to SMA
<NeroTHz> no, you said 2.4 is in the same category
<NeroTHz> I agree that 2.92 is, but 2.4 is not
<bvernoux> 2.4mm is for even higher freq ;)
<NeroTHz> nevermind
<NeroTHz> just whatever mate
<bvernoux> for me category is similar mating
<bvernoux> TypeN is different
<bvernoux> so an other category
<bvernoux> UFL is an other category
<bvernoux> and it is clearly cheat ;)
<bvernoux> when you complain on SMA try UFL and connect/disconnect 10times ;)
<bvernoux> if it work after you are lucky ;)
<bvernoux> if done correctly it shall work of course ;)
<NeroTHz> How is typeN different? what fundamental difference is tehre? Male connector both have the threaded outer nut. Threaded outer nut is separate and free from the inner RF parts of the connector. female connector sticks out
<bvernoux> TypeN connector is a bit different
<bvernoux> I do not like TypeN personally ;)
<bvernoux> Also BNC is an other story ;)
<NeroTHz> also, just because UFL is even worse does not invalidate my coment on SMA. SMA is a fragile connector that really wears out fast. 3.5 and 2.92 do better because they have better designed female center contacts, but they still suffer the same design flaw that SMA has that I stated earlier.
<bvernoux> faster to connect than SMA but definitely not good to exceed 1GHz ...
<bvernoux> NeroTHz, yes but you compare high end with low end ;)
<NeroTHz> no I don´t
<bvernoux> NeroTHz, 3.5mm & 2.92mm is more expensive
<NeroTHz> I never claimed otherwise
<bvernoux> and you need to be careful do not destroy them with bad cable ;)
<bvernoux> and so they are ultra expensive at end
<NeroTHz> You do realize I work at a millimeter-wave lab right?
<NeroTHz> like, we literally have 300 2.92 mm cables
<bvernoux> You need Connector Gage Kit which are pretty expensive ;)
<bvernoux> also for SMA in theory ;)
<bvernoux> ha yes for mm-wave lab 2.92mm is a must
<noopwafel> NeroTHz: <insert envy here>
<NeroTHz> I´m just gonna minimize this window for a bit because I am getting confused and frustrated lol
<bvernoux> I only have SOuthWest Microwave connector with 2.92mm ;)
<bvernoux> as it depends on needs for a cheap RF board I will never use 2.92mm ...
<NeroTHz> noopwafel, just go ask bram to play around in their lab
<bvernoux> NeroTHz, the fun is the price of 2.92mm cable ;)
<bvernoux> male / male ;)
<NeroTHz> I´m still confused what you are trying to achieve here. As I said, I´m intimately familiar with all these things, as it is literally my $dayjob
<bvernoux> I was just saying SMA is good for cheap stuff ;)
<bvernoux> not for metrology stuff microwave of course
<noopwafel> I think "least trash" is a good description
<bvernoux> if you prefer yes ;)
<bvernoux> up to 18GHz for no critical stuff SMA is good ;)
<noopwafel> and I mean what would be the fun in life if you didn't waste days trying to work out what's wrong before remembering to check your connector under a microscope
<bvernoux> yes clearly ;)
<NeroTHz> Weve all been there, noopwafel
<bvernoux> and check continuity ;)
<bvernoux> after soldering ;)
<NeroTHz> I don´t know if it was here that I mentioned we at some point had to throw out >40k EUR worth of 1mm connector stuff because a broken cable had resulted in pretty much all of our 1mm connectors going bad
<monochroma> D:
<bvernoux> Very funny ;)
<bvernoux> NeroTHz, has yes it is very bad :(
<NeroTHz> (also, 1mm has to take the cake as absolute most garbage connector design ever)
<bvernoux> NeroTHz, if you do not check carefully with microscope those cable female and male before mating such horrible things can arrive
<bvernoux> I think even more with 1mm cable ;)
<bvernoux> The margin shall be very thin to destroy it ...
<NeroTHz> I´m really not sure what you are trying to achieve here
<NeroTHz> but okay
<bvernoux> Maybe to participate to a more open HW/SW world
<bvernoux> especially for instrument stuff which are very closed
<bvernoux> Anyway I'm not planning to play with THz so far
<bvernoux> I will be happy to have instrument reaching >26.5GHz so far
<bvernoux> sharing microwave test also
<bvernoux> as we do not see a lot on web ...
<bvernoux> all is so closed
<bvernoux> I need to finish the validation of my latest TRL board with SouthWest connectors 2.92mm from Ebay ;)
<NeroTHz> it´s not so much it´s closed, it´s that the people who can afford the equipment tend to not spend a lot of time talking about it
<NeroTHz> (I don´t mean that as a dismissive thing)
<bvernoux> yes
<bvernoux> Does I have said that buying cheap SouthWest 2.92mm connector on Ebay is not the best idea ;) ?
<NeroTHz> it´s not that we have to keep our mouth shut, but it´s a small group, and a lot of my colleagues are not the kind of people who hang out on the internet. Esp because we tend to get tired of ham radio guys telling us we don´t know how to do our jobs
<NeroTHz> We have only had bad experiences with Southwest connectors
<bvernoux> ha really ?
<NeroTHz> so I would never buy them again, new or old
<bvernoux> me too ;)
<bvernoux> But I was suspecting it is because they are not new
<bvernoux> but they do not mate correctly on PCB in fact
<NeroTHz> yeah, we ordered good number at some point, and all the centerconductors were a bit out of center. Southwest just went´ they are in spec´
<bvernoux> ha very interesting
<bvernoux> and they act like filter at end ?
<NeroTHz> but we could clearly see that they were of much poorer quality than our Rosenberger and Hirose connectors
<NeroTHz> We never mated them, not worth the risk
<NeroTHz> just tossed them out and went back to hirose
<bvernoux> yes it is why I see guys which solder the center pin too ...
<bvernoux> But the interest of those connector was to avoid soldering anything
<bvernoux> So interesting feedback from your side especially with brand new connector
<NeroTHz> one of the common connectors we use now for 2.92/3.5 mm is the HK-LR-SR2 from hirose
<bvernoux> On my side I search something very good up to 26.5Ghz which is also cheap ;)
<NeroTHz> smaller, reusable, good enough for most applications
<bvernoux> ha very interesting
<bvernoux> do you have KiCad footprint for that one ?
<NeroTHz> nah, we don´t use kicad, and I make footprints for each stackup separately
<NeroTHz> you need to really 3D EM simulate the connector footprint for your application to get good performance
<NeroTHz> also really wanna try these guys https://www.mouser.be/Search/Refine?Ntk=P_MarCom&Ntt=155011596
<bvernoux> so far i do not use 3D Em simu as it is too expensive
<bvernoux> so I do trial and errors ;)
<bvernoux> using Qucs
<bvernoux> Qucs-RFlayout is interesting as it integrate OpenEMS simulation now
<bvernoux> for 3D EM
<bvernoux> So it is the next step
<bvernoux> as Sonnet is not usable in demo version
<NeroTHz> I´ve never used sonnet, azonenberg does use it though
<NeroTHz> sonnet is also not 3D EM
<bvernoux> But any feedback with open source sw is welcome
<NeroTHz> you need a proper 3D solver for connectors, because you need to be able to include the parasitics of the pin and metal sidewalls of the connector
<bvernoux> So far i'm using the ref design constructor provide
<bvernoux> so it is clearly not optimal but my need is to go up to 18GHz so far
<NeroTHz> the reference design of 2 connectors I tried had S11>-10 dB above 10 GHz when not using the exact same substrate
<bvernoux> So far I can test only up to 6GHz with my VNA
<bvernoux> to have Full S2P
<bvernoux> as my main purpose is to build things for Sub-6GHz
<bvernoux> microwave test is for fun as I do not have the instrument
<bvernoux> I can check signal up to 26.5Ghz but very bascically with my SA
<bvernoux> It can be good enough to just see attenuation
<bvernoux> for some basic radar esperiment
<bvernoux> but clearly need 3D EM simu to reach an other level ...
<bvernoux> NeroTHz, If you have things to share you are welcome
<bvernoux> It is rare to have feedback on microwave stuff ...
<bvernoux> I'm doing all from scratch on my side caracterizing connectors (up to 6GHz with VNA and more with SA/SigGen)
<NeroTHz> I mean, I can talk for hours or days about millimeter/microwave stuff :p
<bvernoux> Do you have a website/github or something to share ?
<NeroTHz> yes and no. Unfortunetly, my dayjob is all secret and NDA´ed up
<NeroTHz> I can get away with dropping breadcrums about it here on IRC, but I cannot afford to put details on a personal website
<bvernoux> ha ok :(
<bvernoux> Industry is crazy with NDA stuff ...
<NeroTHz> but I can answer any questions you might have if you have any
<NeroTHz> yeah, it makes sense when you look at the investments needed to do anything though
<bvernoux> It is just awfull as because of that everyone is reinvent the wheel of RF stuff
<bvernoux> reinventing
<bvernoux> open source hardware on RF stuff is far ;)
<bvernoux> the 1st one is HackRF ;)
<NeroTHz> eh, it´s not to bad really. Within the industry there is a lot of people who know what to do and so on
<NeroTHz> I think the main issue is that microwave/millimeter-wave gurus are not hte type of person that gets into opensource
<bvernoux> yes
<bvernoux> and anyway instrument to do that are crazy expensive for amateur ;)
<NeroTHz> in my experience, most open-source electronics is developed from people with a software background trickeling into hardware. but as it really take 10+ years to really ´get´ RF and so on, those people don´t ´make it´ to RF. There are exceptions, but it´s much harder to do
<bvernoux> I'm pretty sure there is tons of hw which could be hacked to fill this gap ;)
<bvernoux> But it requires lot of knowledge
<NeroTHz> I´m not sure really. they solved a lot of stuff ages ago, but you need special techniuqes and hardware. connectors are expensive because they are a pita to make, not because of R&D cost (at least not for SMA/3.5 mm)
<bvernoux> yes and RF PCB are expensive too ;)
<NeroTHz> you can see now that as ICs which packege a bunch of stuff in one become available, people do more with it - first HackRF, now you have all those open-source cheap VNAs
<NeroTHz> yeah but they are not expensive just because RF, but because they are physically expensive to make
<bvernoux> yes it is that point I'm interested in
<bvernoux> to use ready to plug chipset for that
<bvernoux> as doing filter on PCB take lot of area it is amazing to do not find such excellent BandPass filter found on old HP SA on today chipset
<bvernoux> maybe 5G will help ;)
<bvernoux> also to find some very small tunable filter
<NeroTHz> IC stuff is generally not as good
<bvernoux> yes so far they are not ...
<NeroTHz> metalwaveguide/dielectric resonator >> PCB resonator >>> LTCC package filter >>> IC filters
<NeroTHz> don´t expect that changing any time soon, it´s just the nature of the substrates used and packaging and processes
<bvernoux> maybe 5G will help for that
<bvernoux> as it clearly need such tiny chipset like in WiFi-6
<bvernoux> with lot of band which requires tunable filter integrated ...
<NeroTHz> nah, they never use in-built filters anymore for those things. They rely on the fact that you can pretty much not have blockers at all, and then use a zero-IF architecture
<NeroTHz> The problem right now is all packaging and PCB related. The ICs can do it no problem, designing 60 GHz circuits on nanometer CMOS is almost become ´trivial´.
<NeroTHz> but getting your 60 GHz in/out of your silicon is the proble
<bvernoux> hehe yes I imagine the challenge to go outside with transition on PCB ;)
<NeroTHz> at 60 GHz, and with something narrowband like WiFi in the 60gig band, you can still get decently good results with just some matching capacitance to resonate out your bondwires and package inductance, but for higher stuff you really need some high amount of expertise and IC/package/PCB codesign to get good performance (which is my job)
<bvernoux> yes it is very interesting
<bvernoux> I would like to test 60GHz stuff ;)
<bvernoux> They are producing chipset for that for ADAS/Car
<bvernoux> where all is integrated even multiple antenna
<bvernoux> it is 77GHz now
<bvernoux> do you have played with that too ?
<NeroTHz> I am mostly playing above that right now
<NeroTHz> 110-170, 340, 660, 1 THz
<bvernoux> what is the applications @1THz ?
<NeroTHz> I´m in research, so 77 is ´industry problem´ now
<NeroTHz> right now mostly sensing
<bvernoux> because 1THz shall be ultra small range
<NeroTHz> imaging, sensing, radar. Maybe data? hard to say
<NeroTHz> yeah, but you can get decent range with high-gain antennas
<bvernoux> I imagine Air block it ?
<NeroTHz> nah
<bvernoux> the physic behind shall be very interesting
<NeroTHz> after all, optical is like 400 THz, but you can still do line-of-sight optical over many kilometers or more
<bvernoux> yes it depends of power of course
<NeroTHz> not just power but gain
<bvernoux> Do you work in Bell Labs or something similar ?
<NeroTHz> nope, but I do know a few people there and have worked there in the past
<bvernoux> As I doubt there is tons of R&D Lab doing that ;)
<NeroTHz> you´d be surprised actually
<bvernoux> I think 77Ghz yes for ADAS as it is a huge market
<bvernoux> all car shall communicate with that and it will be a real mess ;)
<NeroTHz> it´s just that the community of people doing that is not very vocal about it. IC design in general, it´s a totally different community than the more general PCB-level electronics
<bvernoux> Do you know if there is some planned "cheap" PCB for RF microwave ?
<bvernoux> like RO4350B but cheaper and better ?
<NeroTHz> nah, it´s just not gonna happen
<bvernoux> as It is one of the issue for the price for prototypes ...
<NeroTHz> the problem is that all the materials that perform well are either an absolute pain to work with (alumina, ceramic, PTFE) or super finiky about the process (megtron, isola, etc)
<NeroTHz> or both!
<bvernoux> Does there is other solution ?
<NeroTHz> yeah, integration
<bvernoux> except integrating all in chipset without PCB for things which exceed 20GHz ;)
<NeroTHz> what they are doign now - just put everything on the chip
<NeroTHz> There are some other things that are interesting - dielectric waveguides, both PCB-integrated, and printed/external, SIW, etc, but all of those things really require a lot more expertise to work with compared to just a microstrip. You can´t just plug stuff in a online calculator and have a working thing come out
<bvernoux> Are you using ADS for 3D EM stuff ?
<NeroTHz> ADS momentum is only 2.5 D. I use EMPro/HFSS/Comsol for 3D EM
<bvernoux> Do you design some ultra wide band antenna ?
<bvernoux> It is what is missing ;)
<NeroTHz> yes, I´ve done that before, more than once
<NeroTHz> 110-180 GHz
<bvernoux> but for something like 1Ghz - 26GHz ;)
<NeroTHz> ah no
<bvernoux> I know I will never work outside 26GHz ;)
<bvernoux> except maybe some fun test with ADAS chipset @77GHz
<NeroTHz> key to wideband is just to use a non-resonant design, but that usually requires a end-fire antenna. Something like a vivaldi and so on
<NeroTHz> but they are electrically long (more than a wavelength in side) which is no problem at 100 GHz, but is a problem at 1 GHz
<bvernoux> it will be great to design such stuff with open hardware design ;)
<bvernoux> some small good antenna from 2GHz to 26GHz will be a must have
<NeroTHz> there is plenty of literature out there. Fractal antennas, spirals, vivaldis, leaky-wave, etc
<bvernoux> Yes I have read some
<bvernoux> main issue is it requires lot of time to experiment on such stuff without good knowledge
<NeroTHz> yeah, not just that, but it just is a fundamentally different way of thinking
<NeroTHz> it´s not impossible to learn it after years of ´regular´ electronics, but looking at all the top designers I know have been thinking in transmission lines and waveguides and impedances from within their masters education
<bvernoux> Anyway it is very interesting if you can share you expertise on open hardware stuff
<NeroTHz> sure
<bvernoux> maybe doing some review ...
<NeroTHz> I´m already discussing azonenberg´s designs a lot, though I don´t know how much help my input is there :p
<bvernoux> the idea here is to design instrument open hw/open source ;)
<bvernoux> the best possible for not too crazy price
<bvernoux> for me I will try to do serious stuff with sub-6Ghz
<bvernoux> but it is a long road ;)
<bvernoux> as there is tons of things to learn
<bvernoux> I'm trying to buy a good Scope for the next step ;)
<bvernoux> refurbished Tek-6 serie ;)
<bvernoux> NeroTHz, Do you use some big oscilloscope ?
<NeroTHz> now and then, yes
<bvernoux> It can be great to compare them as there is absolutely no any review online except the blog from TheSignalPath
<bvernoux> NeroTHz, maybe you are using more some big VNA/SA/SigGen ?
<NeroTHz> my main tool is the VNA. but I use SAs, generators, AWGs too
<bvernoux> what do you think about the old E4405B ?
<bvernoux> mine has worked 2 days ;)
<NeroTHz> never used them. My lab is mostly R&S
<NeroTHz> only keysight things we have are AWG, a few PSG´s, and the highest-speed scopes
<bvernoux> great
<bvernoux> NeroTHz, are you doing some project on RF stuff out of your job ?
<NeroTHz> I used to, but right now my home lab is in a state of non-existence because I´m renovating and don´t have room for it
<bvernoux> so maybe soon ;)
<bvernoux> my lab is already too small with a 12 square meter room ;)
m4ssi has joined #scopehal
maartenBE has quit [Ping timeout: 240 seconds]
m4ssi has quit [Remote host closed the connection]
maartenBE has joined #scopehal
<azonenberg> noopwafel, vup: as of now there is not any way to do realtime streaming without a gap between waveforms. Everything needs to be a set of trigger events
<azonenberg> however, it would be possible to design an instrument in which the "trigger' was just dividing a data stream into blocks
<azonenberg> bvernoux: yeah i have about 37 m^2 of home lab space
<bvernoux> hehe nice ;)
<azonenberg> Plus another 18 of office/conference room
<azonenberg> There are not a lot of conferences happening there thanks to the plague :p
<bvernoux> I need to build an other house if I want bigger Lab ;)
<kc8apf> azonenberg: my visit earlier this year wasn't intended to be my only visit ;)
<azonenberg> kc8apf: yeah i would love to collaborate more once the 'rona is out of the way
<azonenberg> i'm not even done setting it up
<azonenberg> still have to buy a projector for that screen, a whiteboard to go behind it
<kc8apf> there's been renewed interest in MachXO{,2,3,3D} from a few folks
<azonenberg> I still have the devkit but havent opened it yet lol
<azonenberg> when things got crazy and your $dayjob wasnt supporting it it kinda fell by the wayside
<kc8apf> exactly
<kc8apf> a few folks at adafruit are planning a few machxo2 based boards
<noopwafel> azonenberg: thanks, good to know
<azonenberg> noopwafel: there is a ticket for realtime streaming support
<azonenberg> so far zero work has been done on it
<azonenberg> i think segmentation into blocks a la gnuradio is the best option anyway
<azonenberg> which will fit into the trigger infrastructure
<noopwafel> right, was just wondering in case you had insights re: integration with decoders
<noopwafel> but .. for later I guess
<_whitenotifier-b> [scopehal] smunaut opened issue #222: Streaming devices support/integration - https://git.io/JJXch
<azonenberg> noopwafel: #222
<azonenberg> so i guess the issue would be, how do we handle decodes where a symbol/packet crosses boundaries of waveform blocks
<noopwafel> was doing usb captures with pico the other day, it either just fails to decode in the middle of packages, or else tries re-decoding all collected waveforms every time it gets a new one
<noopwafel> erm, packets
<azonenberg> pico's software or glscopeclient?
<noopwafel> pico's sw :)
<azonenberg> Oh
<noopwafel> so that's what brought this issue to mind for me
<azonenberg> So right now glscopeclient will attempt to decode each waveform as a unit and assume there's no contiguous data from one to the next
<noopwafel> (why did I end up with important packets straddling the boundary of 1s traces? my usual luck, I guess, and I think not a very common occurance outside my distortion field.)
<azonenberg> I think the fundamental thing that will need to happen is having the decode function take an optional pointer to the previous waveform
<noopwafel> right. I was looking at UART as a simple example, and it aborts when it fails to finish a byte, which would work well for this
<noopwafel> some 'this is the point where I gave up' state might help. but I will leave it until I'm .. closer to maybe trying something.
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 246 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<azonenberg> noopwafel: yes, that level of state persistence would be perfect for this
<azonenberg> but it would require refactoring work on a lot of decodes
<azonenberg> basically anything that works at >1 sample granularity
<azonenberg> and likely some breaking API changes, etc. So nontrivial
<azonenberg> Would make the scopehal flowgraph more like gnuradio
NeroTHz has quit [Read error: Connection reset by peer]
electronic_eel_ is now known as electronic_eel
<bvernoux> It is called a portable ThreadRipper ;)
<bvernoux> I'm not sure glscope will use so much thread/physical cores ;)
<bvernoux> I have not checked if it is multi-thread in fact
<azonenberg> bvernoux: we make heavy use of openmp
<azonenberg> and if you have multiple filters active i'll run each one in its own thread as long as there's no data depencneis
<azonenberg> large, complex filter graphs use them well
<bvernoux> ha great
<bvernoux> I was not sure it was implemented
<bvernoux> does each decoder is in it's own thread ?
<azonenberg> I walk the dependency graph and find as many decodes as i can evaluate in parallel
<azonenberg> then use a #pragma omp parallel for
<azonenberg> so it will use as many threads as you have up to the # of filters
<azonenberg> then i sometimes will parallelize within decodes too
<azonenberg> Longer term i want to push FFTs and some other heavy stuff to the GPU
<azonenberg> vup, noopwafel: also re processing a few hundred MB/s of waveform data, the short answer is, i have no idea
<azonenberg> None of my current instruments can exceed ~300 Mbps of waveform data
<azonenberg> So i've never been able to push enough data into the app to really hit those limits
<azonenberg> I think more parallelization and optimization will be needed to scale really well at that point
<azonenberg> But that is very much a design goal given that i'm building test equipment for glscopeclient with 10G/40G ethernet on it
<azonenberg> i need the software to be able to at least handle >1 Gbps of data :p
<noopwafel> but 300mbps or so works?
<azonenberg> noopwafel: mega*bits* per second? yeah
<noopwafel> oh
<azonenberg> that's about the most bandwidth i've managed to pull off one of my lecroy's
<azonenberg> They have a gig-e pipe but can't saturate it
<azonenberg> let me try and get some more exact numbers, sec...
<noopwafel> ok, I've exceeded that already with glscopeclient
<noopwafel> don't have scope here for numbers
<azonenberg> So right now i am pulling 1Mpoints/4ch @ about 10 WFM/s off my waverunner
<azonenberg> my cpu graph is nowhere near maxed out
<azonenberg> and iftop shows 270 Mbps of dataflow
<azonenberg> this is scope side limited primarily i think
<azonenberg> I get about 1.4 WFM/s @ 10M points/ch
<noopwafel> hehe I need to make a youtube video tomorrow :D
<azonenberg> Now pushing 354 Mbps
<azonenberg> 384*
<azonenberg> yeah i dont think i can break 400 mbps with this scope
<vup> azonenberg: interesting, how big can one currently make one trigger event?
<azonenberg> vup: hmm, i've never tried to test the limit :P with 10M points per waveform on my current workstation it gets a little laggy when scrolling but i think that can be optimized
<azonenberg> in particular i think i can push more compute to the GPU than i am now
<vup> I want to stream data from a 'logic analyzer' implemented with a fpga and a usb 3 fifo chip (ft601), so atleast getting the data into the computer at ~300MB/s is not that hard
<azonenberg> Makes sense. out of curiosity why no triggering on the fpga side?
<vup> I want to push all the decoding to the computer :)
<azonenberg> well i'll be interested in hearing your results
<azonenberg> If it's digital that will change things vs analog in terms of what code paths are hit
<azonenberg> If you do basic RLE compression that will make it much faster to stream and use much less scopehal resources
<azonenberg> that much is for certain
<azonenberg> This is profiling results of 1 minute of running glscopeclient against my waverunner with 4 analog channels @ i think 10M points per channel as fast as i could trigger, no processing
<azonenberg> You can see the ping-pong where ScopeThread uses lots of CPU preprocessing the waveform from the scope, then goes idle until the scope triggers again, then right when waveform processing finishes glscopeclient starts to use lots of cpu
<azonenberg> From this i conjecture that, given an infinitely fast scope on this hardware hitting the same code paths, my hard limit on performance would be around 800-900 Mbps of waveform streaming
<azonenberg> And to go faster we'd need to optimize more
<vup> Not sure how much basic RLE will help with TMDS / a HDMI feed, which is what I am trying to look at
<azonenberg> vup: depends on how much you are oversampling it
<vup> No oversampling
<azonenberg> Hmmm
<azonenberg> So what you might want to consider is doing the TMDS decode on the FPGA
<azonenberg> then pushing raw bytes to the host? that might save a little bit of bandwidth
<azonenberg> All waveforms in scopehal are strongly typed
<azonenberg> so in theory you should be able to create a specan in which the native output type is an analog waveform with x axis units of hz and y of db
<azonenberg> or a sampling scope in which the native output type is an eye pattern
<azonenberg> etc
<azonenberg> having a scope where the native output type is TMDS samples would fit into the object model just fine
bvernoux has quit [Quit: Leaving]
<azonenberg> Whether it would actually save bandwidth is another question, but doing the phy layer decode on the fpga and then only upper layer in scopehal would likely save CPU time
<vup> Yeah basic decoding on the fpga is what I want to try if streaming it raw doesnt work
<azonenberg> The other thing you could do is, use hsync as a trigger for when to break waveforms going to upper level protocol logic
<azonenberg> so send one scanline, or a few scanlines, as a block
<azonenberg> that way the upper level protocol decode doesnt have to keep state across scanlines
<azonenberg> Using scopehal with a protocol analyzer, vs a LA/scope, as the capture device is actually a very interesting idea i hadn't thought of before but i see no reason why it can't be made to work
<azonenberg> also as a FYI, right now we only have TMDS and DVI rendering/decoding
<azonenberg> not the upper HDMI protocol layer, although that would be fairly easy to build i think
<azonenberg> The other thing that needs optimization for this volume of data, i think, is that right now analog and digital waveforms are GPU accelerated but i software render the text and "bubble" overlays for protocol decoding
<azonenberg> if you want to push several Gbps of HDMI data that might become a bottleneck
<_whitenotifier-b> [scopehal] azonenberg closed pull request #213: Rigol: basic support for DS1000D/E - https://git.io/JJwla
<_whitenotifier-b> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±5] https://git.io/JJX8r
<_whitenotifier-b> [scopehal] noopwafel 0b777fa - Rigol: basic support for DS1000D/E
<_whitenotifier-b> [scopehal] noopwafel 6b2d6a7 - Rigol: fix voltage/time for DS1000D/E
<_whitenotifier-b> [scopehal] azonenberg 1461e18 - Merge pull request #213 from noopwafel/rigol-ds1000de Rigol: basic support for DS1000D/E
<azonenberg> vup: anyway let me know if you have trouble, i'm very interested in hooking up less conventional instrmentation to scopehal and glscopeclient
<azonenberg> you'll be the first to attempt it so i want to see how it works :p
<vup> azonenberg: breaking the stream along scanlines sounds like a promising idea
<vup> Do I understand correctly that scopehal also doesn't support protocal decoders that break up a waveform into multiple smaller ones?
<vup> azonenberg: Yes i will keep you updated, I am also very interested in how scopehal work for this application
<azonenberg> vup: Filters (the new term i'm trying to move towards, as they can do more than protocol decodes - lots of stuff has to be refactored to use the new name still) must output a single waveform although they can take arbitrarily many inputs
<azonenberg> however that waveform can contain arbitrarily complex datatypes in the output
<azonenberg> So you could write another filter to pull one field out or something of the complex type
<azonenberg> reducing extra copies would be nice and i'd like to imprvoe efficiency of this
<azonenberg> better multi output support would be nice but it would be nontrivial as right now i treat a filter as equivalent to a scope channel