azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
Stary has quit [Ping timeout: 264 seconds]
Fridtjof has quit [Ping timeout: 264 seconds]
Fridtjof has joined #scopehal
Stary has joined #scopehal
Stary has quit [Ping timeout: 255 seconds]
Fridtjof has quit [Ping timeout: 255 seconds]
Stary has joined #scopehal
Fridtjof has joined #scopehal
bvernoux has joined #scopehal
jevinskie[m] has quit [Quit: You have been kicked for being idle]
josuah has quit [Remote host closed the connection]
irc has joined #scopehal
irc is now known as josuah
<bvernoux> For those interested by VNA eCal my modification/improvements have been merged in https://github.com/jankae/LibreCAL
<azonenberg> Nice :)
<bvernoux> I plan to do small improvements up to end of January before to push the PCB+Assembly(I'm waiting end of Chinese New Year)
<bvernoux> I have pushed the Aluminum cases in FAB too
<azonenberg> Also, for those of you who haven't heard yet, i'm working with a few other people to spin up a nonprofit organization to promote open T&M work (including but not limited to scopehal stuff, my probes, etc)
<bvernoux> The Aluminum case will start in start of February too (because of Chinese New Year)
<azonenberg> the idea is to have an entity that's not just "me" that people can send donations to, establish formal relationships with vendors, etc
<bvernoux> Ha great
<azonenberg> Draft mission statement if anyone has input
<azonenberg> The mission of the Open Test & Measurement Foundation is to promote open source technology in the field of electronics test and measurement.
<bvernoux> Yes amazing initiative
<azonenberg> maybe promote -> support? advance?
<bvernoux> About RF stuff for those who do not know there is an amazing web site https://leleivre.com/rftools.html
<bvernoux> azonenberg, What I would like is to build a 4 Ports VNA with 100dB dynamic range and up to 8.5GHz (or more but that will be hard)
<azonenberg> bvernoux: Sounds fun, although more is always better :p
<azonenberg> i'd like to see a nice open hardware TDR with double digit GHz BW as well
<bvernoux> 4 Ports will be a must have to characterize differential lines too
<azonenberg> Or better yet combo TDR/TDT
<bvernoux> as so far with 2 Ports we are limited ...
<azonenberg> with software support to get s-params out of the TDR/TDT plots
<bvernoux> Yes with TDR/TDT feature of course
<azonenberg> well i meant, actual time domain measurements
<azonenberg> vs frequency with a transform
<bvernoux> Ha yes you means just do a TDR/TDT with sparms export
<azonenberg> i think it might be easier to build, at the cost of dynamic measurements
<azonenberg> dynamic range for measurements*
<azonenberg> TDR/TDT also has much faster update rate which is nice for things like pinpointing impedance matches
<azonenberg> drag your finger or a tool along a trace until it lines up with the dip
<bvernoux> Yes it could be a nice things too cheaper and simpler in theory vs a VNA
<azonenberg> both have their place
<bvernoux> as as it is a bit overkill to validate differential lines with VNA ;)
<bvernoux> like we have on digital boards with SerDes, USB3 ...
<bvernoux> azonenberg, What do you think about Aluminum 7075 + Finish Bead Blast medium-sized beads for Aluminum RF Case ?
<bvernoux> As I have checked lot of different Aluminum Material and some are not non magnetic in fact (or have some effects with RF)
<azonenberg> Why 7075 instead of 6061 (a bit cheaper)? I doubt that your application needs the extra hardness
<bvernoux> 7075 is more resistant to corrosion and stronger
<bvernoux> It is used for aeronautic stuff
<azonenberg> is corrosion a concern for test equipment?
<azonenberg> normally its used in clean, dry lab spaces
<bvernoux> Yes when you touch it ;)
<azonenberg> vs something left outside in the rain 24/7 etc
<bvernoux> It is just for durability
<bvernoux> and to do not see human finger on the aluminum ...
<azonenberg> Rather than bead blasting I'd anodize it
<bvernoux> as it shall be conductive it is why I was selecting Bead Blast
<bvernoux> but maybe there is something better
<azonenberg> you want the exterior conductive?
<azonenberg> I would say anodize except on areas where it's going to be contacting the PCB for shield continuity
<azonenberg> and then put an emi gasket or something on that surface
<bvernoux> It is hard to specify anodizing except on some parts ...
<bvernoux> also bead blast seems better for look & feel
<azonenberg> yeah it requires masking (or machining post anodize). But I just dont like having exposed surfaces on gear be conductive if i can avoid it
<azonenberg> more potential to randomly short stuff
<bvernoux> and add some additional resistance to corrosion IIRC
<bvernoux> But yes in worst case top and bottom can be painted to avoid to be conductive
<bvernoux> in 2nd step
<azonenberg> yes, paint is just less durable than anodizing
<bvernoux> I have just not found how to add in specification to do anodizing only on some parts which seems not really possible in some case in fact
<bvernoux> as that will requires manufacturer add some masking ...
<azonenberg> Yes. It's likely not something you'd get from a random cheap overseas manufacturer
<bvernoux> but yes anodizing with isolation on external surface will be a must
<bvernoux> as there is anodizing which are conductive too
<bvernoux> ha yes interesting
<bvernoux> 7075 is just stronger in fact
<bvernoux> Also more resistant to corrosion but it is not clearly explained in that article
<bvernoux> 6061 is a bit better for thermal conductivity too
<azonenberg> And yes 7075 is a mechanically better alloy in most regards
<azonenberg> but it's harder to machine (slightly) and costs more
<azonenberg> so it makes sense to use when you need it
<azonenberg> I just questioned if you actually did need that
<bvernoux> Maybe not ;)
<bvernoux> I have just launched prod of 5x LibreCAL cases with 7075 to check
<bvernoux> Especially because I want something very clean and resistant to corrosion during years in my lab ...
<bvernoux> and resistant to scratch if possible too
<bvernoux> it is mainly for cosmetic purpose
<electronic_eel> azonenberg: I am in .de. Thanks for suggesting meeting up. Unfortunately Duesseldorf and Bochum aren't nearby, I live in the southwestern part of Germany, near Stuttgart, so that would be about a day of travel back and forth for me.
<azonenberg> aww pl
<azonenberg> ok*
<miek> azonenberg: on the subject of getting s-params out of TDR/TDT plots - do you know of any literature on how to do it? there's tonnes of stuff for going the other way, but i couldn't find anything for that
<azonenberg> miek: Nope. The basic idea as far as i can tell is to just FFT it
<azonenberg> the big challenge afaik is the calibration
<azonenberg> dealing with finite risetime pulses etc
Bird|otherbox has quit [Read error: Connection reset by peer]
_whitenotifier-9 has joined #scopehal
<_whitenotifier-9> [scopehal-apps] mandl commented on issue #565: ngscopeclient: crash on macOS when attempting to use dropdown menu. - https://github.com/glscopeclient/scopehal-apps/issues/565#issuecomment-1383229980
mandl has joined #scopehal
Bird|otherbox has joined #scopehal
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Ping timeout: 260 seconds]
mandl has quit [Quit: Connection closed]
<mxshift> azonenberg: for when you buy that Mac for scopehal CI: https://langui.sh/2023/01/15/ephemeral-gha-m1-runners-with-cidermill/
<_whitenotifier-9> [scopehal-apps] azonenberg edited issue #565: NFDFileBrowser crashes on MacOS - https://github.com/glscopeclient/scopehal-apps/issues/565
<_whitenotifier-9> [scopehal-apps] azonenberg commented on issue #565: NFDFileBrowser crashes on MacOS - https://github.com/glscopeclient/scopehal-apps/issues/565#issuecomment-1383264644
<azonenberg> @johnsel: see above from mxshift
<azonenberg> since you seem to be leading the CI effort at the moment
<d1b2> <johnsel> it's an interesting read, thanks @mxshift
<d1b2> <johnsel> tart is definitely new to me and useful to learn about
<d1b2> <johnsel> I ran into the APIs it uses before, but this is a much better way to talk to them than anything I would coddle together
<azonenberg> Excellent
<d1b2> <johnsel> as for the cidermill part itself it may be interesting too but I'm not sure yet, it looks like it implements some python code that is ran off of a 'new vm requested' webhook, which is an approach I have been considering
<d1b2> <johnsel> either way I have bookmarked it and will better look into it later
<azonenberg> Great. and yeah i file this under "things to look into once we have self hosted linux and windows runners working reliably"
<azonenberg> johnsel: Near term, is a hybrid approach possible?
<azonenberg> self hosted linux/windows + github instances for macos?
<d1b2> <johnsel> certainly
<d1b2> <johnsel> just not for m1
<d1b2> <johnsel> since it doesn't exist
<azonenberg> yes, the github instances are x86 only
<azonenberg> what i meant was, is it possible to mix github and self hosted runners on the same repo
<d1b2> <johnsel> but yeah the CI system is fully compatible with other github runners
<d1b2> <johnsel> either self hosted, regular, or the new premium stuff
<d1b2> <johnsel> I think what you're after is with a custom github runner would you lose any of that
<d1b2> <johnsel> and the answer to that is not if you only use it to kick of a VM which runs a vanilla GH Action Runner
<d1b2> <johnsel> that's also why it's not super straight forward because you need the Runner + environment to be equal to the GitHub/Azure VMs
<d1b2> <johnsel> anyway the short answer is yes sure
<azonenberg> yeah i was just curious about the transitional state
<azonenberg> i.e. prior to moving fully to our infrastructure could we make use of the azure x86 mac runners but our linux/windows
<azonenberg> and it sounds ilke the answer is yes
<d1b2> <johnsel> absolutely, as far as github is concerned it is just runners that can be used, we tag a build process with the self-hosted tag and it will use something self-hosted but if we don't it'll just spawn a github runner. So we can even build both self-hosted and by github at the same time with the self hosted as dry runs that don't produce any downloadables at the end
bvernoux has quit [Quit: Leaving]
<d1b2> <johnsel> that's just a matter of introducing a copy of the build process script with a tag and keeping things
<d1b2> <johnsel> I'm too old in believing it'll go right the first time
<azonenberg> Makes sense. and lol yes