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.
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: 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"? 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. 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? 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? 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? 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(?). 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. 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). ------------------------------------------------------------------------------ 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
