On 09/30/2014 11:24 AM, Janne Huttunen wrote: > Hi! > > I own an LCR meter with a USB connection and I am contemplating > about implementing support for it in sigrok. However I need some > hints how to model the various functionality and information > provided by the on-wire protocol. I found one LCR meter mentioned > in the wiki, but I cannot find it in the code (is it there > somewhere or just on a "wishlist"?) so I cannot take any hints > from there.
That's good news. Indeed we don't have any supported LCR meters yet, but we'd love to have you write a driver for one. The one in the wiki just needs somebody with a Voltcraft 4080 to sit down and write a driver for it, the docs are all there. > First, note that I haven't found any official documentation of > the protocol and while I tried contacting the manufacturer > a couple of weeks ago, they have not answered anything. So, all > I think I know about the protocol is based on me reverse- > engineering it. I think I've got about 90-95% of it figured out. > > While the PC adapter is USB only, it is (again) in reality > an RS-232 device. The adapter contains an FT232R chip that reads > an IR communication from the meter and presents it to the host > as a USB UART data. Based on all available information, the link > seems to be unidirectional i.e. the meter sends periodical updates > to the host but cannot be controlled via the link. That would in > a way suggest modeling the meter as a serial DMM, but there are > a few catches: That sounds great! Before you get started on a driver, could you please create a page on the wiki for your device, with as many pictures as you can stand to take? The protocol should be documented there as well. Mail me privately for a wiki account, or join us on IRC (freenode #sigrok). That is also a good place to get help on libsigrok in general. > 1. Dual display > > The meter in most modes shows two measurements at the same time > and also exports both of those in the protocol. It looks like > the serial DMM currently does not support this. It probably > would not be too much work to add support for it, but is it > "wanted"? I would recommend against using serial-dmm for this. That driver is basically a way to support cheap DMMs that are based around one of the DMM-on-a-chip ICs out there, see http://sigrok.org/wiki/Multimeter_ICs An LCR meter is not a cookie cutter DMM, and yours sounds like it has plenty of special functionality. A separate driver gives you much more freedom to implement whatever your hardware supports. > 2. Measured quantities > > The meter (obviously) measures inductance, capacitance and > AC and DC resistance, but it can additionally calculate quality > factor, dissipation factor, ESR and phase angle. Furthermore > in relative mode the meter calculates the difference between > the reference and current measurements (in %) and supports > alternating between the current measurement and the reference > with a touch of a button. All this information is also present > in the protocol. Exporting it would require at least some new > quantities and units to be added to the public API. That's no problem, we add new MQs and units all the time, as needed. Try to define them as generically as possible, so they can be reused by similar equipment. Also add a pretty-printer for it in src/output/analog.c -- this will help you test as well. > 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. But this is unlikely to be a problem -- meters like this are basically slow, and send one measurement at a time, which get sent to the frontend in a packet of their own anyway. > 3. Test signal frequency > > 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? That's not too relevant by itself, but does it affect the precision of the returned measurement? Not that we have a way to express that precision yet -- but we will, so it's worth documenting if that is the case. > 4. Measurement model > > 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? > 5. Sorting > > The meter has part sorting mode where a reference value and > tolerance limits are entered to the meter and then every > subsequent measurement returns PASS/FAIL status based on > whether the value is between the tolerance limits. The set > tolerances and the status are part of the serial protocol. > Should this functionality be exported somehow? > > On the other hand this is just an utility function that could > be also implemented purely on the PC side (with even more > flexibility) by using the normal measurement mode, so maybe > this is not all that important to support(?). I think you're right, this would be nicer to implement on a client. Supporting it would require communicating the reference value and thresholds as well, followed by essentially a bunch of booleans. It sounds needlessly messy. > 6. Calibration mode > > There is also an internal calibration mode in the meter and > the related statuses are shown in the serial protocol, but I > don't think this is a relevant thing to export in sigrok. > During the procedure the user needs to interact with the meter > anyways and the wire protocol just shows the same statuses > (what to do next and PASS/FAIL) as the display on the meter > itself, so there doesn't seem to be any too interesting > additional information present in there. Agreed. > The protocol also contains a few bits here and there that I don't > know about, so some other minor information might also be > obtained if I knew what those were. There are also a couple of > bytes both in the beginning and in the end of the packet that > never seem to change. I am currently assuming that those are > just "framing", but in theory at least some of them might contain > something (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 :-) -- Bert Vermeulen [email protected] email/xmpp ------------------------------------------------------------------------------ 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
