<azonenberg>
The HML01 series resistors are essentially special order no matter what
<azonenberg>
Meaning i might be able to get them in 450 ohm
<azonenberg>
and make an AKL-PT5 that is essentially just a SMPM breakout
massi has joined #scopehal
_whitelogger has joined #scopehal
<Degi>
\o/
bvernoux has joined #scopehal
someone-else has joined #scopehal
<someone-else>
azonenberg: single HML01 probe performance will depend on the quality of the resistor they use since it becomes more important with higher resistance values
<someone-else>
e.g. reactance which is not noticeable @ 100 ohm resistance might be problematic @ 450
<someone-else>
I tested some (larger) axial resistors and they show this behavior
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
<azonenberg>
someone-else: Yes, correct. And this is a definite unknown until I test
<azonenberg>
But i dont think there is any way to know without doing the experiment
<someone-else>
yep
<someone-else>
HML01s are Vishay Techno, not Dale/Sfernice so there is a high chance they use their own resistor design
<someone-else>
so there is a chance, I think, that an encapsulated ch0201 with wires soldered/welded on might actually outperform a 450ohm HML01
<azonenberg>
I'd use a fc0402 probably not a ch02016. but the point of looking at the hml01s was to get a ready made solution
<azonenberg>
Because custom soldering leads to a ch02016 and figuring out a way to encapsulate something that tiny would be a giant pain in the butt
<azonenberg>
for that matter, given the white paint markings on those lead-attached-to-0402 parts
<azonenberg>
i think those were made by an actual passive company, not a lecroy internal hack job
<azonenberg>
they look too fancy
<someone-else>
actual passive company: could be Vishay even
<someone-else>
wrt ch02016 lead soldering: true, but perhaps a wirebonding shop which does power assemblies/thicker wires (igbt modules etc) can take this job
<someone-else>
encapsulation could be as simple as a putting drop of epoxy on each, for small batches at least
<azonenberg>
Yeah the hardest part would be prototyping without spending four or five digits up front to test
<azonenberg>
in any case the first step is to finish characterizing the setup i have now
<azonenberg>
and figure out why performance is not as good as i expected
<Degi>
Hm, maybe we can spot weld the wries
<Degi>
*wires
<Degi>
(Maybe a bit hard with 0201 but you could have two electrodes with a tiny gap between them, then put a wire (nickel?) sideways against the part and press the spot welder against it, which then hopefully welds the wire to the part without any current flowing through the part itself)
<azonenberg>
Soldering would be fine
<azonenberg>
You'd just need to encapsulate after
<Degi>
Hmm, won't that be a problem when you solder the wires to the DUT and then the solder melts and maybe expands and cracks the epoxy or something?
<azonenberg>
CTE of the epoxy would be a consideration. but also the wires are long and skinny
<azonenberg>
if you do it right there wont be a ton of heat flow down them
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
balrog has quit [Quit: Bye]
balrog has joined #scopehal
river has joined #scopehal
massi has quit [Remote host closed the connection]
<river>
driver and transport are completely independent?
<azonenberg>
river: yeah pretty much. a transport just describes how to move data to the instrument
<azonenberg>
there's a few drivers like the pico driver that do make assumptions about the underlying transport being a socket, since the pico driver actually uses two sockets
<azonenberg>
i plan on making that a bit cleaner at some point by having an explicit dual-socket transport
<azonenberg>
where one is scpi and one not
<river>
I want to make that sound card driver. would that mean adding both a driver and a transport?
<azonenberg>
So, instruments that don't connect via SCPI are kind of a special case in that regard
<azonenberg>
You probably will want to use the "null" transport for that
<azonenberg>
i.e. a placeholder since every driver has to take a transport, that is used for drivers like the demo scope that don't actually need one
<azonenberg>
But i need to overhaul a bit how argument passing to the driver works
<azonenberg>
in particular right now there is no way to supply arguments to the driver, only to the transport
<azonenberg>
so there is no way to say what sound card you want to use or what input
<azonenberg>
you can make one now that will work with the default system audio input device
<azonenberg>
or hard code a certain device
<azonenberg>
but doing better will require some refactoring. Which needs to happen anyway