azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
_whitelogger has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
maartenBE has quit [Ping timeout: 264 seconds]
maartenBE has joined #scopehal
<miek> in the scope trigger type api, what are "change" or "dontcare"?
<miek> on the agilent i've got "alternating" and "either" - would those be the equivalents?
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<azonenberg> miek: those are for logic inputs
<azonenberg> change = any edge, dontcare = this bit is not used in the trigger at all
<miek> ah right
<azonenberg> SetTriggerForChannel() should be left unimplemented for now
<azonenberg> I plan to retool that API at some point soonish
<azonenberg> it needs to become more generic to support pattern/qualified triggers, protocol triggers, etc
<miek> i'm just doing SetTriggerType atm
<azonenberg> So in that case just do rising/falling/change
<azonenberg> and ignore any other inputs
<azonenberg> The APIs for complex trigger controls are known incomplete
<azonenberg> i havent had time to do a proper survery of what's out there
<miek> ok
<miek> and i figure just return "complex" if it's anything other than those?
<azonenberg> Yeah
<azonenberg> for set, there will be additional functions
<azonenberg> triggers will likely become a polymorphic class long term
<azonenberg> with some kind of dynamic creation and UI like protocol decodes have
<azonenberg> where each trigger type can define fields for configuring it
<azonenberg> right now the UI and APIs are really only set up for simple level triggers
<azonenberg> SetTriggerForChannel is a vestige from decades old code working with an fpga ILA core that no longer exists, and the UI to invoke it is gone too
<miek> is there any UI for SetTriggerChannelIndex yet?
<azonenberg> Yes. If you right click on a channel in the GUI under the trigger submenu
<azonenberg> you can specify rising/falling/both edge
<azonenberg> the channel you right clicked on is the implied source
<miek> ahh, right
<azonenberg> There will probably be a trigger config dialog at some point for setting up more complex trigger conditions too
<azonenberg> But that's how it is called right now
<_whitenotifier-b> [scopehal] miek opened pull request #215: Agilent driver improvements -
<miek> a lot more usable now :) i've left off attenuation/coupling/bw limits for the moment as some don't quite fit into the api. also, all of my probes are automatic so i can never set coupling/atten manually :p
<miek> only major outstanding one is setting sample rate/depth, but i need some sleep before tackling that
<azonenberg> miek: perfect
Famine_ has joined #scopehal
Famine- has quit [Ping timeout: 260 seconds]
m4ssi has joined #scopehal
_whitelogger has joined #scopehal
<noopwafel> azonenberg: do you have ideas about the trigger API yet, or pending a survey?
<azonenberg> noopwafel: Basically i havent had time to sit down and think about it
<azonenberg> i've been too busy working on smaller, more well defined tasks like bug fixes or new protocol decodes
<azonenberg> rather than grand API work. Although that is just as necessary
<noopwafel> *nod*
<azonenberg> I'm trying to simultaneously wear the hardware engineer hat with maxwell/mead/blondel, the hardware engineer and manufacturing supervisor hat with the probes
<azonenberg> then be the lead software guy for glscopeclient and libscopehal
<azonenberg> and then project manager for scopehal on top of that
<azonenberg> So i'm stretched pretty thin :p
<noopwafel> to be clear: definitely not intended as any kind of criticism :D
<azonenberg> Yeah i'm just explaining the facts
<noopwafel> I was just asking because I've been wondering about how to do it myself
<_whitenotifier-b> [scopehal] azonenberg labeled issue #216: Redesign of trigger API -
<_whitenotifier-b> [scopehal] azonenberg opened issue #216: Redesign of trigger API -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #216: Redesign of trigger API -
<azonenberg> noopwafel: i made that ticket so we can log notes
<azonenberg> if you have any thoughts you want to leave there or discuss here
<noopwafel> thanks!
<azonenberg> There's a bunch of large scale things i want to work on that i'm saving for when i have more time, probably post MAXWELL going to fab
<azonenberg> most notably #179 and #132
<_whitenotifier-b> [scopehal] azonenberg closed pull request #215: Agilent driver improvements -
<_whitenotifier-b> [scopehal] azonenberg pushed 6 commits to master [+0/-0/±8]
<_whitenotifier-b> [scopehal] miek 200eebb - AgilentOscilloscope: cleanup lock usage
<_whitenotifier-b> [scopehal] miek ae9e470 - AgilentOscilloscope: tidy up reply parsing
<_whitenotifier-b> [scopehal] miek 77918c6 - AgilentOscilloscope: implement Get/SetTriggerType
<_whitenotifier-b> [scopehal] ... and 3 more commits.
<azonenberg> The trigger system redesign, btw, needs to consider the complex pattern trigger capabilities on MAXWELL too
<_whitenotifier-b> [scopehal] noopwafel commented on issue #216: Redesign of trigger API -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #217: Consider changing base time unit from ps to fs -
<_whitenotifier-b> [scopehal] azonenberg opened issue #217: Consider changing base time unit from ps to fs -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #217: Consider changing base time unit from ps to fs -
<_whitenotifier-b> [scopehal] azonenberg commented on issue #216: Redesign of trigger API -
<noopwafel> hm yes that maybe sounded a bit snobby :P
<noopwafel> I really mean 'aaaaa this is impossible to get right, at some point you/I/someone will suggest something not-good-enough, so let me try to piece together what might be nice to have in that'
<_whitenotifier-b> [scopehal] azonenberg commented on issue #216: Redesign of trigger API -
<_whitenotifier-b> [scopehal] azonenberg edited a comment on issue #216: Redesign of trigger API -
<azonenberg> noopwafel: how's that sound?
<azonenberg> i think it's the most futureproof option in terms of avoiding a second large-scale refactoring
<azonenberg> we do this once then all further improvements can be either adding a new trigger type, or changing the sematics of one
<azonenberg> both are far less invasive and don't change the Oscilloscope API whatsoever
<azonenberg> although obviously breaking changes to a single trigger type require updates to all affected drivers
<azonenberg> The advantage of this approach is that we can define a new trigger type in a plugin that adds a new scope driver
<azonenberg> and it will just drop into glscopeclient as long as it doesn't need any first-class GUI changes
<azonenberg> Maybe we could have trigger objects take multiple channels as inputs like a protocol decode, and have some filter logic to say whether they want analog, digital, or either
<azonenberg> etc
<noopwafel> agreed, this seems lightweight enough that it can just be tried
<azonenberg> Gonna be a little while before i have time to sit down and do it though
<noopwafel> sorry, this is not at all a request for you to code things :)
<azonenberg> Lol
<noopwafel> today I am a bit busy with work already myself (hence lag time)
<azonenberg> also your nick is making me want stroopwafels now
<azonenberg> lol
<noopwafel> they are delicious
<azonenberg> When I was in Den Haag a year or two ago i got a few packs at the local grocery stores but i was really hoping to find like a specialty candy store or something that made them super fresh
<azonenberg> ok maybe it was 3 years ago... my sense of time is awful :p
<noopwafel> the super fresh ones tend to be sold *right there*, there are a couple of locations in the middle of shopping streets in the centre of Den Haag
<azonenberg> Yeah that's what i was looking for
<azonenberg> I wasn't able to find them
<noopwafel> if you're ever in .nl again, do ask for directions :-)
<azonenberg> Oh i definitely will
<azonenberg> Last time I was there I had a phone which didn't support european LTE bands so i couldn't even just buy a local SIM
<azonenberg> i had no data whatsoever unless i connected to public wifi
<azonenberg> So this made google maps etc difficult
<_whitenotifier-b> [scopehal] noopwafel commented on issue #216: Redesign of trigger API -
<noopwafel> often I end up on GPRS/EDGE due to bands in .us, which means google maps is never going to load .. but it could .. if I wait a few minutes more
<azonenberg> lol
<azonenberg> What i'd do to navigate in europe was pre-cache my planned route on hotel wifi
<azonenberg> if i had a change of plans, try to find a store or something with a public AP i could connect to
juli964 has joined #scopehal
<azonenberg> Just ordered an experimental MEAD enclosure from 3dhubs in black anodized 6061 aluminum
<azonenberg> Gonna see how i like the feel and thermal performance of it, as compared to the 3d printed nylon, then make a final decision for the first production batch
<azonenberg> Will also compare EMC performance. I don't have any way to measure absolute field strength but i can measure relative strength outside the enclosure with my nearfield probes at various frequencies
Nero_ has joined #scopehal
Nero_ is now known as Nerothz
Nerothz is now known as NeroTHz
<azonenberg> NeroTHz: any idea how automated equalizer coefficient searches normally work?
<azonenberg> I'm experimenting with my homegrown CTLE trying tuning parameters by hand but is there a standard algorithm or is it basically just sweep everything in a nested loop and see what works best?
<_whitenotifier-b> [scopehal] azonenberg opened issue #218: Eye pattern: fix weird vertical bars (probably timebase rounding issues) -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #218: Eye pattern: fix weird vertical bars (probably timebase rounding issues) -
<azonenberg> NeroTHz: this is the best i've managed to do with it so far
<azonenberg> the transfer function is 0 dB from DC to 3.25 GHz, linearly ramps to +6 dB at 6 GHz to 12 GHz, then brick-walls after 12 GHz to avoid amplifying noise
<azonenberg> This is a FFT based equalizer, not a FIR, and is intended to model an analog CTLE
<azonenberg> I plan to build FIR and DFE equalizers at some point
<azonenberg> Right now the transfer function is linear because i'm having trouble wrapping my mind around how the curved transfer functions of "real" CTLEs work
<azonenberg> given that it's fft based it's trivial to evaluate anything if i have S21 of the equalizer, but calculating that response curve is where i'm getting confused
<_whitenotifier-b> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-b> [scopehal] azonenberg a8472ab - EyeDecoder2: refactoring, moved UI width to capture and made it a float
<_whitenotifier-b> [scopehal] azonenberg fe28a7d - Merge branch 'master' of
<_whitenotifier-b> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [scopehal-apps] azonenberg 43e8776 - WaveformArea: show UI count and bit rate in eye pattern infobox
<NeroTHz> azonenberg, not that sure. I´ve seen adaptive equalizers in some courses before, but that´s a long time ago
<NeroTHz> usually has to do with minimizing errors (obviously) through some MSE algorithm
<azonenberg> NeroTHz: Does my waveform at least look like it's doing something resembling an equalizer? :P
<NeroTHz> yeah, that does look how I would expect something to look like after CTLE
<NeroTHz> open eye, peaking on transitions for 1-1/0-0 transitions
<azonenberg> also i improved the infobox a bit
<azonenberg> so you know how much you accumulated etc
<NeroTHz> that does look decent
<azonenberg> Working on mask testing now
<azonenberg> Was supposed to be doing some testing for $dayjob tonight but the client never sent me account information
<azonenberg> kinda hard to test their thing if i cant log into it
<NeroTHz> hehe
<NeroTHz> NI changed their website and it is horrible
<azonenberg> As far as performance goes, btw, I'm currently doing this test case (subtract two channels, CTLE on that, then separate CDR and eye pattern on each waveform) at about 40 WFM/s with 80 Kpoints/wfm @ 40 Gsps
<azonenberg> looking at the UI counter i'm getting a little bit under 1 MUI/sec. maybe 1M UIs every 2-3 sec
<azonenberg> (just clocked it, 11M UIs in 15 sec)
<azonenberg> That's without any de-embedding or channel emulation
<azonenberg> I would probably get higher performance using deeper memory on the scope but when doing dev i prefer high WFM/s to high throughput in terms of points/sec
<azonenberg> And yeah eventually i want to support automated tuning for all of my eq filters so it will calculate response/tap values to be optimal for your channel and eq config
<azonenberg> But that's a ways out
<NeroTHz> fking NI and their 10 mA outputs on analog voltage sources
<azonenberg> as in 0-10 mA current loop outputs? or max 10 mA drive?
<NeroTHz> 10 mA drive
<NeroTHz> I want to get rid of these annoying bias boards everyone makes which is just a bunch of variable LDOs with a trimmer
<NeroTHz> but either I need to get a bunch of supplies, which is bulky (nobody makes supplies with more than 3-4 channels) and overkill (we pretty much never need more than 150-200 mA drive current), or you get these analog voltage modules from national instruments or Keysight which is say a 32 channel 16 bit voltage source
<NeroTHz> but then you only get 10 mA drive, which is not enough for supplies, only for bias voltages
<azonenberg> so basically what you want is a PSU that with a huge number of very low power outputs?
<NeroTHz> Yes
<NeroTHz> but nobody makes them
<azonenberg> Lol
<azonenberg> Sounds like a project i'd be interested in building at some point, although not in the immediate future because i have my hands full with other stuff
<NeroTHz> Right now I´m just thinking about making a board with like 16 unity-gain high-current outputs
<azonenberg> but it would be nice to add to my portfolio of test equipment
<azonenberg> if i were to do it, it'd be ethernet scpi controlled
<azonenberg> a couple of 8-channel dacs driving vref of variable ldo's
<azonenberg> and then a bunch of front panel banana jacks or something
<NeroTHz> yeah, that is pretty much what we need
<NeroTHz> problem with variable LDOs is output noise I htink
<NeroTHz> but I don´t know just how low-noise modern LDOs are getting
<NeroTHz> just thinking about something like this made for audio, but with 500uV offset it could be fine for us
<azonenberg> at a few hundred mA a power opamp might work
<azonenberg> I was thinking also something like an LT3042
<NeroTHz> That is what we are using on our biasboards
<NeroTHz> the LT3042
<azonenberg> but you'd need to get a dac with compatible current outputs, or set up a transistor in linear region to act as a resistor or something
<NeroTHz> thing I prefer about unity-follower idea I´m having (at least when using with an off-the-shelf generation of refernce voltages) is that it doesn´t require any offset-compensation
<azonenberg> yeah i like the lt3042 for low noise stuff, I have like three of them on my scope AFE characterization board
<NeroTHz> Can combine it with a 100 mOhm resistor between the opamp output and the feedback to allow current meeasuremetn while I´m at it
<azonenberg> INA199 or similar?
<azonenberg> or INA233 if you wanna go fancy and have the dac built in
<azonenberg> adc*
<NeroTHz> Maybe what I can do is just use two or three 3-channel PSU modules in conjunction with an analog output module
<azonenberg> what PSUs do you use out of curiosity?
<NeroTHz> a bunch of different types
<NeroTHz> Thing is that since almost everyone uses bias boards, we just use whatever supply to give those 9 V
<azonenberg> I got rid of all of my el cheapo "pot and 7 seg display" ones a while ago
<azonenberg> right now all i have is a pair of R&S HMC8042's
<NeroTHz> we still have a bunch of those pot-and-7-seg
<azonenberg> We use those at $dayjob a lot since generally precision isnt needed
<azonenberg> you just need to be able to pretend to be a wallwart or pc
<NeroTHz> we have shtitonnes of E3620 series from keysight
<NeroTHz> now also a number of E36300´s
<_whitenotifier-b> [scopehal] miek edited a comment on issue #14: Add Agilent scope driver(s) -
<NeroTHz> and a few of those DC power analyzer things
<_whitenotifier-b> [scopehal] miek edited a comment on issue #14: Add Agilent scope driver(s) -
<_whitenotifier-b> [scopehal] miek edited a comment on issue #14: Add Agilent scope driver(s) -
<_whitenotifier-b> [scopehal] miek edited a comment on issue #14: Add Agilent scope driver(s) -
<NeroTHz> I´m looking at R&S supplies to as we are mostly an R&S lab, but they only recently started offering interesting stuff again
<azonenberg> this is what i use, but the 2-channel variant
<NeroTHz> I really love their NGL/NGM series, and wish they made the NGP in a more-output-lower-power version
<azonenberg> this is a Hameg product R&S bought
<NeroTHz> I am told we have some NGL´s on the way but am not sure
<azonenberg> It's a linear+SMPS hybrid
<azonenberg> and is quite small, two of them fit side by side in 2U
<azonenberg> I have one of these plus a DMM in the same form factor (HMC8012) on each of my lab benches
<azonenberg> the spec is 450 uV rms / 4 mV p-p ripple from 20 Hz to 20 MHz
<azonenberg> which isn't LT3042 level, but is pretty decent for a bench supply i think
<azonenberg> and quite high resolution setpoint/readback, 1 mV voltage resolution and 1 mA current at higher ranges, i believe you get 100 uA current below an amp
<azonenberg> They're dead on accuracy wise... when i cal'd one of mine the display said 28.800V at 90% full scale and my bench meter reported 28.8029
<azonenberg> at 3.2V it put out 3.20059V
<NeroTHz> Those do look nice
<azonenberg> PC controllable, i already have a C++ API for them in scopehal
<NeroTHz> ethernet?
<azonenberg> via either usb, ethernet, or optional gpib
<NeroTHz> that is a requirement for us
<NeroTHz> ah okay that is good
<azonenberg> Yes, ethernet is a requirement for me too
<azonenberg> they also have overcurrent shutdown which is a really nice feature when driving nonlinear loads like SMPS's
<azonenberg> vs going into current limiting and having the two feedback loops fighting each other :p
<azonenberg> They come in 1/2/3 channel versions, with i believe 100W total capacity
<azonenberg> They even have remote sense and some other fancy features
<NeroTHz> yeah. I do think if we were to get R&S supplies it would be the NGL/NGM series
<azonenberg> Those look nice for sure, but have a few more digits than mine :p
<NeroTHz> (The NGL looks identical but is single-quadrant instead of two-quadrant)
<azonenberg> and cost 4x as much lol
<azonenberg> But your employer is clearly not worried about a $4K vs $1K psu
<azonenberg> given the stuff i've seen on your benches :p
<NeroTHz> The NGL is like 1.9k I think for the base model, so it´s in between but yes
<NeroTHz> IT´s not even about being worried, it´s also ´is it worth ¨cheaping out¨´
<azonenberg> > $1200 bench supply
<azonenberg> > cheaping out
<azonenberg> lol
<NeroTHz> (also keep in mind we get these things with insane discounts cause we and R&S are good buddies)
<azonenberg> Fair point
<NeroTHz> azonenberg, when I spend about 30-40k a month on random small equipment here in the lab, yeah :p
<azonenberg> lol
<azonenberg> that's... not quite my annual lab budget
<azonenberg> but close
<NeroTHz> I also think that our new VNA has a lot of built-in functions to control the R&S supplies
<NeroTHz> don´t know which exactly
<NeroTHz> but like use 4-wire functionality to measure power-added-efficiency right in the VNA
<azonenberg> ooh
<NeroTHz> you can plot stuff like drain-current-vs-input-power just like any other trace on the VNA, stuff like that
<NeroTHz> really convenient
<azonenberg> meanwhile i'm here in poor man's land with my picovna that just has dinky little bias tees and you're on your own for whatever plugs into them
<azonenberg> of course my entire VNA probably costs less than one of your phase matched test cables...
<NeroTHz> possibly, those phase matched cables aren´t as expensive as some people like to pretend. They ain´t cheap, ofcourse, but the majority of the cost is just in the assembly and measurement - they don´t go up a lot in cose when you go up in length/frequency
<NeroTHz> matched pair, 40 GHz, 1 meter: 3 kEUR. Matched pair, 40 GHz, 2 meters: 3.7k. matched pair, 67 GHz, 2 meter: 4.5k
<azonenberg> My vna, two N-to-SMA test leads, and a SMA cal kit cost me about $8K with tax, shipping, and cal certificate included
<azonenberg> so ok, one of your cables only costs half as much as my vna :p
<NeroTHz> :p
<NeroTHz> It frustrates me how little some of my colleagues understand that our lab budget is not ´standard´
<NeroTHz> and that it´s rather rare to just go ´Oh yeah, we can do VNA measuremetns up to 1.1 THz´
<azonenberg> My budget for lab equipment is probably higher than $dayjob
<azonenberg> And my lab at home, while very nice by home lab standards, is nothing compared to what you've got going on
<azonenberg> i was at a lab at a major aerospace company when i was in high school that still had analog scopes floating around some of their benches
<azonenberg> and i mean this was like 2005 or so, so not SUPER recently, but DSOs were very much a thing by this point
<NeroTHz> that is not uncommmon. Like, we still have some analog scopes laying around too, though I don´t recall seeing them on benches
<NeroTHz> but still a lot of gear that is HP branded
<azonenberg> 1.1 THz analog scopes? :p
<azonenberg> i remember reading about the world's fastest analog scope, i think it was like 1 GHz bandwidth or something crazy
<NeroTHz> yeah, that sounds about right
<azonenberg> they had to use a microchannel plate in the crt to amplify the signal because the dwell time on the screen was so short
<NeroTHz> afaik a bunch of super-high-impedance stuff to drive it fast
<NeroTHz> anyho, enough dreaming for the mornin, time to get back to work
<lukego> (Here I am still kicking myself for gratuitously spending $250 on that second soldering iron... :-))
<lukego> though I pro-rata my annual lab budget month-to-month, and I've been relaxing with the kids this summer, so I have a small spending backlog and maybe it's a good time to start thinking about my first oscilloscope :)
<NeroTHz> lukego - I have the luck of working at a IC research group. I still refuse to spend a lot of money on private tools xd
<lukego> cool to be a fly on the wall hearing even that such high-end kit exists :)
<lukego> I'd like to find a lab power supply that's reasonably safe for kids to play with. I'm not sure how realistic that is :). I'd only be powering relatively small things like fpga dev boards.
<NeroTHz> most supplies that are <25 volts are probably perfectly safe. Unless they stab themselves with electrodes in the heart, that voltage is unlikely to pose much threat
<NeroTHz> and there are even lower voltage supplies out there
<lukego> Thanks for the tip. On I'm seeing a few cheap and cheerful 15V lab supplies.
<lukego> This one seems like an enthusiast crowd pleaser programmable which is nice. goes up to 30V but unlikely to both crank it up there /and/ stab yourself in the chest at one time, and perhaps 30V even being more or less on the safe side
<lukego> I think that for my purposes I need to learn OpenEMS before choosing a scope. Getting bogged down in software sure does save hardware budget :)
<miek> the latest commit isn't building for me:
<lukego> Hey - sorry, n00b, haven't done homework - are any of the "top 3" or other entry-level scopes here relevant to / usable with glscope software? generally any tips on picking a first scope for someone who doesn't really know what they will do with it exactly yet (besides "wait" :-))?
* lukego asks a question and then promptly disappears to walk the dog..
<miek> lukego: people are working on the rigol at the moment, but my impression is that it may not be possible to get it performing well. i don't think a lot of testing has been done on siglents yet
m4ssi has quit [Remote host closed the connection]
maartenBE has quit [Ping timeout: 265 seconds]
maartenBE has joined #scopehal
NeroTHz has quit [Read error: Connection reset by peer]
bvernoux has joined #scopehal
<azonenberg> miek, lukego: we have done a bunch of work on siglents
<azonenberg> still fine tuning
<azonenberg> some of them are lecroy protocol compatible, or almost so
<azonenberg> we have a driver tverbeuere and error_404 were working on that seems to be making good progress
<_whitenotifier-b> [scopehal] azonenberg opened issue #219: Add JESD204 protocol decoder -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #219: Add JESD204 protocol decoder -
<_whitenotifier-b> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-b> [scopehal-apps] azonenberg ee991ea - Fixed WaveformArea to handle new eye width API
bvernoux has quit [Quit: Leaving]
juli964 has quit [Quit: Nettalk6 -]
<azonenberg> lukego: yeah i generally consider a 30V supply to be touch safe. The only way it could potentially be an issue is if you either stabbed yourself with it or if you hooked both channels in series at max range in which case you get 60V
<azonenberg> and even 60V DC is not super dangerous unless you get really unlucky, but i probably wouldn't intentionally work live on it
<azonenberg> honestly the bigger hazard is probably not electrocution, it would be thermal burns if you have a high-resistance short
<azonenberg> 30V into 1 ohm is 30W which is enough to burn you
anuejn has quit [*.net *.split]
noopwafel has quit [*.net *.split]
agg has quit [*.net *.split]
<azonenberg> But if the kids are old enough to understand electronics, they should be able to understand basic safety rules like "don't touch any exposed terminals if the supply is putting out more than ~24V"
<azonenberg> or "wear safety glasses when powering up an experimental hardware in case you pop a part"
anuejn has joined #scopehal
noopwafel has joined #scopehal
agg has joined #scopehal
<azonenberg> which is IMO my #1 rule. In typical low voltage (not mains powered) electronics the risk of electrocution is near zero and if you have a reasonable current limit the thermal burn hazard is, while not zero, quite low
<azonenberg> But it doesn't take a lot of power to pop an led and send chunks of plastic flying high enough to get in your eye
<azonenberg> That is honestly the biggest way to hurt yourself in an electronics lab other than soldering-related incidents
maartenBE has quit [Ping timeout: 264 seconds]
<azonenberg> either a chunk of wire flying when you cut a pin or something, or a part popping
<smkz> unless youre fucking with mains electricity i worry more about Pb than about electrocution tbh
<smkz> or about burning myself
<azonenberg> Yeah
<azonenberg> But you should be using RoHS solder in this day and age
<azonenberg> In which case the heavy metal risk is minimal, all you have to be concerned about is extraction of flux fumes
maartenBE has joined #scopehal
<Degi> I once made clouds of tin oxide from solder haha
<azonenberg> Degi: what were you soldering with, a flamethrower?
<smkz> (i dont have any sort of pacemaker or ICD or other implanted electronic device; if you do i imagine things might be different, i know i would be a bit more careful around electricity)
<Degi> A few hundred amps and graphite electrodes
<Degi> Well I heated a blob of solder to incandescence till it started boiling
<azonenberg> Degi: lol
<azonenberg> that... is not something you are likely to do by accident with a typical soldering iron
<sorear> if your soldering iron doesn't have a rated lifespan against tip sublimation in an inert atmosphere, are you even trying?