> > An LCR meter is seldom if ever used to measure quantities that > > vary over time. Obviously since the meter is transmitting the > > results to the host continuously, the host will also see any > > "intermediate" results that will vary over time while the meter > > settles, but that is mostly just a side effect caused by the > > imperfect reality of things. Ideally there would be one result > > per measured component / circuit. > > Yes, that is something I would like to see as well. > I thought it would be nice to implement in sigrok some kind > of software touch-hold feature, so that it reports an analog > packet only when the reading settled to a steady value. > That way, you would get only one packet per mesured comonent.
I was actually looking at implementing something like that for my driver, but it is not quite working like I would like it to (at least not yet). Obviously it would be good to possibly have some generic helper(s) for doing something like this, but ultimately I think it should be up to each driver to decide how to it. At least in theory some hardware could be able to do this even without any help from the software. > > The problem is that I don't know if that is currently possible. > > It is easy to put data from multiple channels into one packet, > > but the problem is that in this case the different channels > > have different MQs and units. Is there currently some way that > > would allow sending a packet that contains multiple measurements > > with independent MQs and units each? > > No, unfortunatly it is not currently possible. > I agree with you about this problem, and IMHO, it would be nice > if we could output simultaneously several MQs on a single channel. > This would also benefit PPS which can report both V and A for each > channel. > If you have a concrete proposition to go in this direction, I > would like to here the opinion of other developpers. No, I don't have anything to propose, at least not yet. But unless someone else has some idea, I guess I'll have to look into it. > Ideally, the channel name should match what is printed on the > case of the device. This applies well to multi channel devices, > such as a power supply which will have labels on the front panel > such as CH1 and CH2. Ok, makes sense. How about channel indexes? What should they represent? > > There probably should be some sensible method of determining > > which drivers support certain device type. > > There is already one. > Grab the DEVICE_OPTIONS with sr_config_list() and check that > the list contains SR_CONF_LCRMETER. Yes, but that currently doesn't always work if I don't have the device yet (sdi == NULL). At least these drivers return an error if DEVICE_OPTIONS are tried to be listed without a device: atten-pps3203 demo hameg-hmo manson-hcs-3xxx motech-lps-301 scpi-pps yokogawa-dlm Of course if you think that is a bug, they can be fixed. Some of those may in reality not even care about the device at all, but just happen to check that one is given and return an error if there isn't one. I somehow have a feeling (but I might be totally wrong here) that the whole config key thing is currently a bit too much a wild wild west i.e. it is very flexible and can be used for just about anything, but at the same time it is not all that well documented what keys are supposed to be returned by various device types under various conditions. And at the same time the keys are not some "auxiliary" information, but contain essential information for the client program. Having consistent abstractions also in the keys and their expected values is a very good thing indeed. > > 4. Floating point representation > > This is definitely an important issue with sigrok for now. > > > [...] > > Have anybody have any thoughts on this before? > > Many thoughts yes, since a long time, but no implementation: > http://sigrok.org/wiki/High_precision_analog Aaah, good stuff. That pretty much covers every thought I had about the thing. One alternative that I don't see covered in there is using explicitly the _Decimal32 and/or _Decimal64 types as specified in ISO/IEC WDTR 24732 (some of the proposals in the Wiki are quite similar in principle, though). They would avoid the representation issues and I think they could also represent the amount of significant digits by using non-normalized significands. The main advantage I see is that some day they may be part of the C standard and supported out-of-the-box by the compilers. Unfortunately I have no idea when that "some day" will happen since it seems that the support has been under development for the better part of a decade and it still (AFAIK) hasn't been included in the standard. And when/if it finally appears in the standard, based on previous experience, it may take quite some time before they are ubiquitously implemented by the various toolchains. However e.g. gcc seems to have at least some sort of support for them right now i.e. it seems I can declare such variables, do some math with them and the compiler seems to accept that just fine. I haven't really used them for anything before, so I don't really know how complete the implementation is or what the possible limitations might be, though. I also have no idea what the support in other compilers currently is (or if that is even relevant for sigrok?) and using them might also have some interoperability issues or other requirements with other common libraries (like e.g. the standard C-library, GLib, etc.). All in all, it is a tough nut to crack. ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
