<d1b2>
<azonenberg> You probably want the "trend" filter
<d1b2>
<azonenberg> Trend plots a scalar over wall clock time
<d1b2>
<azonenberg> X/Y is to plot a scalar vs another scalar if you're e.g. sweeping a power supply and want to plot some parameter vs voltage
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
<d1b2>
<rapzak_> how to control the sample time from the multimeter?
<d1b2>
<azonenberg> I don't think we've defined an API for that yet
<d1b2>
<azonenberg> The multimeter API is pretty basic at the moment (and not all of the supported meters have this capability)
<d1b2>
<azonenberg> If you want to add one, I'm all for it. But we'll need to figure out how to make it sufficiently generic that it will work for as many meters as possible
<d1b2>
<azonenberg> So it'll take some research and thought. File a ticket on the scopehal repo so we at least have the request to track, then if you want to start throwing some ideas and notes about the various commands different types of meter have for integration time that would be helpful
<d1b2>
<rapzak_> Let me see how it goes... still learning a lot, and the UI part is still quite new for me... but maybe some of the timebase can be used... i am thinking timebase of ~100ms to 10s or 100sec... like charge discharge of a battery etc
<d1b2>
<azonenberg> no it would not be related to the timebase
<d1b2>
<azonenberg> this is a separate setting scopes don't have
<d1b2>
<azonenberg> it's not the number of points to acquire, it's how long to record at each point
<d1b2>
<azonenberg> many seconds doesn't sound like something you'd do for a single sample so i'm confused?
<d1b2>
<azonenberg> unrelated: @hansemro do you have a rigol MSO5000?
<d1b2>
<rapzak_> I may also confuse you.. i think the sample time may be an option (how long it reads the signal / average it) - but i meant original the delta time between 2 measurement points from the multimeter
<d1b2>
<azonenberg> oh. the default for the trend filter is to just plot every point as it comes in
<d1b2>
<azonenberg> however fast that is
<d1b2>
<rapzak_> sure, but how to control the output of the multimeter
<d1b2>
<azonenberg> using the actual clientside wall clock time as the sample timestamp
<d1b2>
<azonenberg> You don't. you just read its value in a loop
<d1b2>
<azonenberg> at least that's been the case so far
<d1b2>
<azonenberg> Oh, if you are going to be doing very long term trending
<d1b2>
<rapzak_> like battery charge
<d1b2>
<rapzak_> discharge
<d1b2>
<azonenberg> one thing you might run into is that there is currently a technical limit of +/- 2^63 femtoseconds for timestamps
<d1b2>
<azonenberg> which is i wanna say about four hours
<d1b2>
<azonenberg> there's an open wishlist item for adding scaling factors for when you can tolerate lower precision but need to cover a longer period of time
<d1b2>
<azonenberg> but nobody's had time to work on it and it's not trivial
<d1b2>
<azonenberg> (We're going to need this for other things too, the whole units system needs an overhaul, but it's not going to happen in time for v0.1)
<d1b2>
<rapzak_> that is fine - i know there is a lot to do
<d1b2>
<rapzak_> as long there is a way into it, it is cool
<d1b2>
<azonenberg> There is a planned path forward for that, yes. but nobody is actively working on it, it's going to be probably addressing a bunch of other fundamental limitations with how we represent values
<d1b2>
<azonenberg> e.g. we want to be able to represent higher order units like "volts per second"
<d1b2>
<azonenberg> or even weirder combinations in the case of like a VCO where "Hz per volt" is a very reasonable metric
<d1b2>
<rapzak_> thats cool
<d1b2>
<rapzak_> i think i will look into some efficiency measurement
<d1b2>
<azonenberg> i would love a full set of filters and analysis blocks for SMPS characterization etc
<d1b2>
<rapzak_> like smps... in/out with several outputs etc
<d1b2>
<azonenberg> something like what lecroy has for their power option
<d1b2>
<azonenberg> it's not something personally i need
<d1b2>
<azonenberg> but other people could use it so we should have it :p
<d1b2>
<rapzak_> the hardware may come in a litle short on the sample speed... 10ksps...
<d1b2>
<rapzak_> but for many things i think it is ok, as caps average out a lot
<d1b2>
<rapzak_> but also for mcu power consumptions measurements
<d1b2>
<rapzak_> I think the/your code is really cool and good constructed... much smarter than my programmin experience... so good work...
<d1b2>
<hansemro> I don't
<d1b2>
<azonenberg> hmm who did then
<d1b2>
<azonenberg> i know one of the regulars did
<d1b2>
<vegard_e> not sure I count as a regular, but I've got one
<d1b2>
<azonenberg> @vegard_e do you use it with ngscopeclient semi often? can you try to reproduce the bug in that ticket?
<d1b2>
<azonenberg> i think it's fixed
<d1b2>
<vegard_e> hmm, I've never tried it over USB, and I'm on macos
<d1b2>
<azonenberg> ok so you can't easily test then
<d1b2>
<azonenberg> anybody else? i know we had some other rigol mso users
<d1b2>
<azonenberg> maybe @j4cbo ?
<d1b2>
<j4cbo> nope, I have an R&S RTB2004
<d1b2>
<azonenberg> lol who was it then
<d1b2>
<azonenberg> i suppose i can keep the ticket open and move to v0.2 if we can't find anyone to verify in the near term
<d1b2>
<azonenberg> i'm 99% sure it's fixed but i don't stale-close issues
<d1b2>
<azonenberg> so i want to make a reasonable effort to reproduce before declaring it fixed
<d1b2>
<vipqualitypost> i thought joshua recently bought one of those
<d1b2>
<azonenberg> ah i might be mixing up the J names