On Sat, Oct 25, 2014 at 10:43:11PM +0300, Janne Huttunen wrote: > > Hi! > > Now that the driver for my LCR meter is more or less feature > complete, I tried to write a small program to interface with > it to see if the exported API made sense and if it contained > all the relevant information. It was quite soon evident that > there are still some problems left with the driver and/or > libsigrok in general. Below are some of my observations. > > > 1. Packet format > > 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. > Now, this measurement in case of my LCR meter consists of two > independent "axes" that have their own MQ and unit, but still > are parts of the same measurement. The device sends one such > measurement as a single data packet, but the current driver > exports the two parts as separate "channels" in two separate > packets. This separates the parts from each other, which is > not a good thing. It would be much better to export a complete > measurement to the client program as a single packet. > > 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. > 2. Channels index and name > > I noticed that my driver currently uses index zero for both > of the channels, which feels weird. As far as I can see, it is > also not the only driver that does so. So, if after the point > #1 is solved, there still are multiple channels in the driver, > what exactly are the indexes supposed to mean? Also, what > names are the channels supposed to have? 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. Now, for devices which only have one channel (DMM, LCR meters...) there is almost never a channel label on the front panel, so you have to make up one. AFAIK, the convention generally used in sigrok is to name those Pn with n starting at 1 (and IIRC P means probe). So your driver should probably use P1 and P2 for now. > 3. Driver filtering > > There probably should be some sensible method of determining > which drivers support certain device type. If I wish to attach > to an LCR meter, I don't wish to see DMMs, oscilloscopes, > thermometers etc. So, at minimum, there should be some way to > ask the driver which device profiles it supports and that > method should work even before any devices have been probed. > As far as I can tell, there currently isn't one(?). There is already one. Grab the DEVICE_OPTIONS with sr_config_list() and check that the list contains SR_CONF_LCRMETER. > 4. Floating point representation > > This is very much a wishlist item, but one I think should be > solved somehow. It currently looks quite silly when the power > of two floating point representation of values causes weird > looking representation errors to like e.g. 44.82 is transmitted > correctly, but 44.83 will become 44.830002 and 44.829 will > change into 44.828999. I know it doesn't matter much when e.g. > drawing a graph but looks bad when showing the numeric value > on the screen. 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 Aurel ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
