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: 250 seconds]
Degi_ is now known as Degi
massi has joined #scopehal
bvernoux has joined #scopehal
<azonenberg> miek: I have incomplete support for an undisclosed VNA that isnt merged to master yet
<azonenberg> was waiting on them to publicly release the alpha firmware version i was doing dev against
<miek> ah ok, good to know. i'd be down to write a driver for my agilent vna once some of that gets merged
<azonenberg> Yeah. for the moment i'm assuming you are doing cal on the front panel interface of the instrument, using the vendor firmware
<azonenberg> since that varies so much from device to device
<azonenberg> then basically extending the existing scope APIs to set the sweep range, number of points, and acquire s-param mag/angle waveforms
<azonenberg> as of right now the internal representation for waveforms is dB mag / degree angle, which is optimized for display vs computation
<azonenberg> my thought being that s-param waveforms tend to be small
<azonenberg> so the cost of converting to e.g. complex real/imaginary is minimal
<azonenberg> vs time domain scope waveforms can easily have tens to hundreds of megapoints, vna sweeps are usually a few thousand at most
<miek> yeah, that makes sense. i was wondering about whether to use mag/phase vs complex internally, i guess it depends on what's going to be most commonly used by filters
<miek> i wasn't sure whether it should be derived from Oscilloscope or just be its own Instrument class. i feel like there are enough big differences that it doesn't quite fit into the scope APIs
<miek> one thing i found was that the concept of a channel in most bench VNAs is a bit different to what i was used to. each channel can have its own stimulus settings and calibration, and then it can contain multiple traces for the various s-param measurements
<azonenberg> So right now what we have is each s-param is a channel with a stream for mag and a stream for angle
<azonenberg> but we have to figure out where things ilke power settings fit in
<azonenberg> this is still a WIP
<azonenberg> Filters generally convert to real/complex internally but users usually want to see mag/angle
<azonenberg> as far as deriving vs not, thats a tough question, it may be worth making a new common base class? i dont know yet
massi has quit [Remote host closed the connection]
<_whitenotifier-7> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/glscopeclient/scopehal-apps/compare/9ddca7100a46...d1af0e9acc88
<_whitenotifier-7> [scopehal-apps] azonenberg d1af0e9 - Initial work on filter creation
<azonenberg> oops pushed WIP work from the plane that i forgot wasn't finished
<azonenberg> i'll clean that up shortly
tiltmesenpai has quit [Ping timeout: 252 seconds]
tiltmesenpai has joined #scopehal
tiltmesenpai9 has joined #scopehal
tiltmesenpai has quit [Ping timeout: 268 seconds]
tiltmesenpai9 is now known as tiltmesenpai
bvernoux has quit [Quit: Leaving]
<azonenberg> also just realized we never picked a new time for the dev call, someone had a conflict with the time i originally proposed
<azonenberg> @louis @mughees @johnsel @ehntoo lain miek: how's Friday 09:00 Pacific work?
<azonenberg> that's noon Eastern or 18:00 CET
<azonenberg> oh and balrog ^
<azonenberg> (as usual, tagging active contributors that I hope will attend and am scheduling around, but anyone else in the channel is free to call in if you're available and interested)
<azonenberg> also @aleksorsist if you're interested in seeing what the dev team is up to, you're also welcome to hop in
<d1b2> <louis> should work for me