<azonenberg>
So I'm slowly making progress with this refactoring
<azonenberg>
for some stuff like power supplies and multimeters it will be easy as no combo devices exist, or if they do the channels are the same
<azonenberg>
function generators will need more work since that will change channel numbers
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
jacekowski has quit [Ping timeout: 248 seconds]
jacekowski has joined #scopehal
whitequark has quit [Ping timeout: 256 seconds]
jevinskie[m] has quit [Ping timeout: 260 seconds]
sajattack[m] has quit [Ping timeout: 252 seconds]
fridtjof[m] has quit [Ping timeout: 260 seconds]
mikolajw has quit [Ping timeout: 264 seconds]
<d1b2>
<johnsel> I think you forgot something though azonenberg
<azonenberg>
johnsel: ?
<d1b2>
<johnsel> the gpus!
<d1b2>
<johnsel> haha
<azonenberg>
no i didnt forget lol
<d1b2>
<johnsel> did you do it?
<azonenberg>
every time i think about getting to them, the kid is just about to / just went to bed
<d1b2>
<david.rysk> > i want to allow live data to be pauseable
<azonenberg>
and wife will kill me if i shut off the baby camera :p
<d1b2>
<david.rysk> I guess it's worth noting that not every device will have an internal buffer 😛
<d1b2>
<johnsel> aww, well, ping me when you do get to it?
<azonenberg>
Streaming / pausing is a separate discussion that i think will be made easier when we have a unified object model
<d1b2>
<david.rysk> so while there is the distinction between "scalar" and "vector", some software based processing to turn "scalar" data into quasi-"vector" data would be useful
<azonenberg>
That is planned
<azonenberg>
basically, right now trending of e.g,. meter data is done via a separate gui widget independent of scopehal plotting
<d1b2>
<david.rysk> Or in other words, abstract the difference away from the processing
<azonenberg>
moving forward, there will be a filter that turns a scalar into a trend vector with configurable buffer depth
<d1b2>
<david.rysk> Yeah, ideally by the point of data being plotted into widgets it would be a unified vector format
<azonenberg>
how and when to sample the scalar data is another question
<d1b2>
<david.rysk> which sounds like the planned design
<azonenberg>
and one i will be addressing in a couple of days
<azonenberg>
there will also be the opposite
<d1b2>
<david.rysk> I think that depends on how the data is received
<azonenberg>
a filter to extract the Nth element of a digital or analog vector as a scalar
<d1b2>
<david.rysk> e.g. some devices will allow you to sample while others will just stream a buffer at a given sample rate
<azonenberg>
Yes
<azonenberg>
we might add some concept of callbacks triggered when a data source updates or something, i'm not sure yet
<azonenberg>
So basically, there's two phases to this refactoring
<azonenberg>
first is the channel unification itself
<azonenberg>
the second is replacing all of the opaque getters in APIs that return scalar data with a method to pull that data from the instrument and update the scalar stream with the latest value
<azonenberg>
and then adding a helper function that returns the current scalar value and, optionally, pulls the latest from hardware (otherwise returning cached data)
whitequark has joined #scopehal
<miek>
maybe it's just me, but i think that saying 'scalar' to refer to instruments that return a single measurement is going to get really confusing given how scalar/vector is already used in test equipment for VNAs, vector voltmeters, etc.
<d1b2>
<johnsel> I concur, especially if at some point we get I and Q
jevinskie[m] has joined #scopehal
<azonenberg>
miek: can you think of a better name?
<azonenberg>
now is the time to change it if you want
<d1b2>
<johnsel> a series of X
<azonenberg>
and well to me, I or Q in isolation *is* a scalar :)
<azonenberg>
(a single measurement of either that is)
<d1b2>
<johnsel> sure, but the time series of the I and Q vector will become a vector of vectors?
<azonenberg>
Yes it gets messy :)
<d1b2>
<david.rysk> wouldn't that be similar to having 2 channels (I / time, Q / time), and then bringing them into an analyzer that combines/processes them?
<azonenberg>
internally "waveform" is the general term we use in the API
<azonenberg>
a "stream" is a single thing coming off an instrument
<azonenberg>
a stream can have a waveform or no waveform associated with it at a given time (i.e. if data has been acquired or not)
<azonenberg>
a "waveform" can be a series of analog values, a series of digital values, a series of protocol values, an eye attern, etc
<azonenberg>
the plan is to add single points as a new type of waveform
<azonenberg>
so a stream can output a single analog value
<azonenberg>
which represents the value as of the most recent reading
sajattack[m] has joined #scopehal
<d1b2>
<johnsel> I understand the dilemma, I guess if it is user-visible we can conclude it's best not to call it a vector since it is is confusing, if it's internal/dev use only then you can debate if since we're the customer we care about it. They are vectors after all. But List<> or Series<> or some other related term can suffice as well without having the confusing term usage
<d1b2>
<johnsel> thinking a little further down the line I can imagine a few derivative types coming into play which may become something like a DynamicVector or whatever (bad example but you get the point)
fridtjof[m] has joined #scopehal
<azonenberg>
yeah internally it's a Waveform with types of "analog" (implied analog waveform, since until yesterday waveform was the only kind of data) or "scalar" in the current un-pushed draft code
<d1b2>
<johnsel> is that type part of a Number class?
<d1b2>
<johnsel> or something therealong?
<miek>
i can't think of anything better immediately, i guess it's not such a big deal internally but i agree it would be nice to have something clearer if it ends up user-facing
mikolajw has joined #scopehal
<azonenberg>
There is a Unit class
<azonenberg>
there's no single class right now for a quantity-plus-unit
<azonenberg>
an OscilloscopeChannel has an X axis unit, a Stream of the channel has a Y axis unit, and then the Stream may or may not have a Waveform containing data
<azonenberg>
We do need to overhaul our unit handling longer term
<azonenberg>
we have a handful of hard coded rules for things like voltage * current = power
<azonenberg>
but when you start to get to things like integrating the area under a waveform, it quickly breaks down because it cant handle arbitrary algebraic combinations of units
<lain>
I wonder if anyone has written a ucum implementation in C++ with a permissive license
<azonenberg>
Something along those lines has been on my list of things to look at
<lain>
pretty easy to parse the xml spec and do your own impl tho, I did it in C# a while back
<azonenberg>
Yeah i think there has been an open github ticket for a while on that
<azonenberg>
The challenge is handling all of the higher order derived units cleanly
<d1b2>
<johnsel> lain: that anywhere public? I know someone who can probably use that very much
<azonenberg>
For example, say you take the derivative of a TDR trace with respect to time
<azonenberg>
now you have ohms per second
<azonenberg>
also there are often multiple possible derived units, e.g. kV/s == V/ms
<azonenberg>
so we may at some point want to allow the user to apply SI scaling factors to numerator and/or denominator to be more intuitive for a particular measurement
<azonenberg>
Open ticket but nobody is actively working on it right now
<azonenberg>
Somewhat related is propagating metadata, ideally even through filters, for uncertainties
<azonenberg>
Ideally i'd like to be able to have each waveform/measurement report expanded uncertainties (if known) for some specified sigma etc
<azonenberg>
or at minimum have a default uncertainty based on the instrument datasheet spec
<azonenberg>
e.g. this voltage is +/- (0.5% + 1 mV)
<azonenberg>
Again, there is an open ticket and nobody is actively working on it
<azonenberg>
But thats a ways out from being anywhere near a critical path lol
<lain>
johnsel: not currently public, I'll see about pushing it to github at some point
<bvernoux>
Good news I shall receive very soon DeePace KC761 "Radiation Dosimeters and Gamma-Spectrometers"
<bvernoux>
It is an other project to check Radiation levels with top of the art Hardware
Ekho has quit [*.net *.split]
ericonr_ has quit [*.net *.split]
Ekho has joined #scopehal
ericonr_ has joined #scopehal
<azonenberg>
bvernoux: gonna write a scopehal driver for it? :p
<azonenberg>
we might have to define some new waveform types for gamma spectra lol. i dont think we have an eV unit for axes (yet)
<bvernoux>
Hehe yes ;)
<bvernoux>
The KC761 have also Ethernet port for easy access but so far it is in beta test
<azonenberg>
Nice
<bvernoux>
I think it is the first spectrometer like that to have Ethernet, USB ... and which does not cost >500USD
<bvernoux>
It use top of the art detectors too which allow realtime measurements better than geiger old school stuff
<bvernoux>
I have some details of how it works
<bvernoux>
For those interested details in direct from DeePace: Accuracy 20% ≤1mSv/h, final parameters may change.
<bvernoux>
The KC761 uses a CsI scintillator as a detector, which is capable of measuring the magnitude and energy of radiation. Compared to dose meters using GM tubes, the KC761 is more capable of obtaining more accurate radiation dose rates. The KC761 is also more sensitive and faster. KC761 has a multi-channel analysis function to identify radioisotopes.
<azonenberg>
Nice. well i have no objection to adding drivers for other kinds of metrology gear, it doesnt have to be purely electrical in nature although that's of course the main focus
<azonenberg>
optical spectrometers, pH meters, etc are all at least somewhat in scope - although we might want to add them as a separate plugin module or something
<azonenberg>
Just to avoid cluttering the core scopehal codebase with other kinds of instrumentation most people won't use
<azonenberg>
But that's a problem we can address if and when we have enough instruments for it to be an issue
<bvernoux>
Yes so far it is clearly not a priority to add it to ngscopeclient
<bvernoux>
and anyway it is still beta firmware (with final HW)