[please keep me in to: or cc: even on messages going to the list]
Thanks for your comments. I'll have to think about them a bit and
maybe whip up some suggestions in patch form when I have the time.
One other problem is that while obviously a new device class
("LCR-meter") should established in sigrok, this is my very first
LCR meter. So, I really don't know how the other meters out there
do these things and thus it is hard for me to guarantee that if I
base the model on my meter alone, will it be generic enough to fit
any other LCR meter out there. All I can do is hope that they have
similar functionality and interfaces.
> > The measured quantity can also be either selected by the meter
> > based on the dominating factor or forced by the user. In a way
> > this information is similar to the "autoranging", but in this
> > case it's just not about the "range". Should this be exported
> > and if so, how?
>
> Measurements come with their own MQ/unit per packet (struct
> sr_datafeed_analog). If you see the meter switch MQ, you'll
> just have to make sure you put it in a new packet.
Yeah, that's not a problem, but what I meant was that you have
a flag (SR_MQFLAG_AUTORANGE) for indicating that the device is
in autoranging mode. Should there be some flag to indicate that
my LCR meter is in "autoquantity" / "autoLCR" mode?
The display on the device itself just shows "LCR" on the display
in this mode and a different part of the screen then shows which
quantity is actually shown on the primary display. If I select
the measured quantity myself, the screen just shows the final
quantity and not the "LCR" symbol.
Knowing this doesn't affect the interpretation result of the
measurement in any way and thus is not that essential, but on
the other hand neither does the "autoranging" on a DMM.
> > The meter supports using different (user selectable)
> > frequencies when making a measurement. This is not
> > strictly a "measured" quantity (more like configuration),
> > but the information is still present in the protocol.
> > Should it be exported somehow?
>
> Is this the internal sampling frequency of the hardware?
No, an LCR meter works roughly by sending AC through the device
under test, measuring voltage and current and calculating various
quantities from there. This is the frequency of that AC and
affects some quantities, like e.g. ESR, a lot. My meter supports
100Hz, 120Hz, 1kHz, 10kHz and 100kHz + 0Hz (for DC resistance
mode). I do know that other LCR meters have something similar,
but the actual supported frequencies may vary from model to model.
I think this setting is fundamental for evaluating the results of
the measurements and should be exported somehow, but how exactly?
> > The meter can use either serial or parallel circuit model when
> > making the measurement. The model can be either automatically
> > selected by the meter or forced by the user. The protocol tells
> > if autoselection is on and which model was ultimately used to
> > get the result. Should this information also be exported
> > somehow?
>
> What does this mean?
I'm sure I'll explain this very badly, but if you think about
any real (i.e. non-ideal) capacitor or inductor, it will also
have some resistance to it in addition to its reactance. So,
you can kind of think that the real component consists of an
ideal resistor and an ideal capacitor / inductor. You can
further think that these ideal components are either in series
or in parallel.
Now the LCR meter reports the values of the ideal components
the real component "consists of". Depending on whether you
think the ideal components to be in series or in parallel
affects the values these ideal components need to have in
order to together match the real component under test (mostly
with very high or low values) i.e. the way the meter calculates
the values.
The setting is shown on the display of my device as a suffix
to the measured quantity like e.g. capacitance measured with
parallel model is shown with 'Cp' symbol, inductance with
serial model with 'Ls' etc.
The setting is then about the user telling the meter which
model to use in the calculations. It can also be a fundamental
parameter of the measurement and I think it should be exported.
It will only require a single flag since there are only two
alternatives, "serial" or "parallel".
The other thing is then that at least my meter can either
select the used model automatically based on which it thinks
will give "better" results or the user can force it. In
a way this is also similar information to the "autoranging"
flag, but in this case its "autoserialparallelmodel". Should
this information whether the meter is in automatic or forced
mode also be exported?
> > (like e.g. the battery status that I haven't yet seen
> > anywhere in the protocol).
>
> My favorite trick for finding that one is running a meter
> off an adjustable power supply on the battery clips, and
> reducing voltage until it whines about it :-)
Yeah, that's the trick. Unfortunately I don't have a suitable
power supply available right now for doing that.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
