LCR Lab Grade Parameter Plotting "Fixture"

[mawyatt]

Lab Grade Bench LCR Meters with built-in plotting routines & displays are so expensive that we created our own routines to plot results using a laptop. We created a thread about ceramic capacitor behavior that got us thinking again.

https://www.eevblog.com/forum/projects/ceramic-capacitor-behavior/

An idea we've been bouncing around is to use a Dedicated RPi with small display to act as a plotting "fixture" for our 2 lab grade LCR meters (TH2830 & IM35356) and keep things connected up by RS232/USB/LAN all the time to alleviate having to configure things every time we want LCR plots.

We've already developed DC Bias Fixtures, SMD fixtures and such for LCR meter use, and have various software configurations that work under Windows with Python, also on RPi, however aren't that good at software developments so help here would be quite welcome.

Comments from folks that actually have and use Lab Grade LCR meters appreciated.

Best,

[aliarifat794]

You have to use the pyserial library. https://github.com/pyserial/pyserial

[mawyatt]

Here's a pair of Python routines for the Tonghui TH2830 LCR Meter that work with a PC (W10). The LCR Meter uses its RS232 with a null modem and RS232-USB adapter to the PC, however USB could be used with the proper LCR address. Addresses and comm type parameters must be set on the meter.

One routine preforms a frequency sweep and can plot various DUT parameters such as CS, CP, LS, LP, Z and RX with various secondary parameters (RS, RP, Q, D) with Linear or Decade Sweep plots.

The other Python routine utilizes a SDP3303X Power Supply to Sweep the DC Bias across the DUT when using a DC Bias Isolation adapter/fixture. Reading the DUT bias voltage is an optional HP34401A DMM using its RS232 interface with another Null modem and RS232-USB adapter. Communication with the PS is by USB as the SDP3303X has no RS232 port.

These are simple Python routines with little error checking and control/plot parameters must be entered as indicated (usually), and could benefit with some "quality" honing as our SW skills are quite limited.

Anyway, hope this helps some folks that want nice LCR type plots of various DUTs, but don't have the usual expensive LCR meters with direct plotting capability built-in.

Will add other routines later.

Best, 

[mawyatt]

Here's a Python routine to plot DUT parameters vs temperature utilizing a crude large ceramic resistor as the "heater" with a type K thermocouple to read temperature. The "system" is open loop and the voltage to drive the resistor (V^2/R heating) are based upon quadratic temperature estimates.

The setup utilizes a TH2830, SPD3303X Power Supply to drive the 10 ohm ceramic resistor and SDM3065X DMM to read the K type thermocouple. Note the paper clip as a holder to the resistor "heater" for the DUT capacitor.

Best,
 

[Nominal Animal]

You have to use the pyserial library. https://github.com/pyserial/pyserial

No.  Absolutely not.  All Python serial library abstractions are utter garbage because of the Windows-isms they are based on.

What you want to use with Python and Linux/Android/BSD/anything-non-Windows is python termios and POSIX-style termios controls.

For what it is worth, Teensy 4.x can sustain a 200+ Mbit/s (20 Mbytes/s – 30 Mbytes/s, depending on host machine) data stream to a Linux host over Teensyduino built-in USB Serial support.  I have posted the test benchmark here, with a Linux C host-side termios receive client.  To ensure it is at least somewhat realistic, it uses the Xorshift64+ pseudo-random number generator, using the 32 high bits of each 64 bit number generated –– this passes the diehard tests and the entire BigCrush test suite in the TestU01 framework; even Mersenne Twister fails some in the TestU01 framework –– with the Linux host-side client providing a new random seed, and generating the same sequence to verify the data stream from the Teensy for correctness.  I do claim to know what I'm talking about here, in other words.


Also, instead of Raspberry Pis, I would warmly recommend you look at much better Linux SBCs like Odroid M1 (or M1S) with a M.2 NVMe SSD; Radxa Rock 5B with a M.2 NVMe SSD; or other similar high-power SBCs.  Unlike Raspberry Pi, whose Foundation will not directly (using their long-term employees) interface to open source projects like Armbian or the Linux Kernel, Rockchip does employ developers who help develop support for these SoCs in upstream projects.

The M.2 NVMe media for both OS and data (only the u-boot loader will be in SPI Flash) is not only much faster than SD cards and most eMMCs, but will also be more reliable.  It makes a huge difference to the usability of the entire system.

For low-bandwidth stuff, one can do with much cheaper SBCs like NanoPi R2S Plus.  You'll want to limit the number of SBC types/Variants you need to support in the wild, but testing various SBCs to see how they fit your needs is A Good Idea.

At the USB-Serial interface point, you can use TI ISO6742/ISO7742 (RX,TX,RTS,CTS) or ISO6721/ISO7721 (RX,TX only) digital isolators for both isolation and voltage level translation to 1.8V/2.25-5.5V logic levels.  Downstream does need to supply a few milliAmps at its preferred I/O voltage level, and you'll want to add 100nF/0.1µF X7R/C0G/NP0 supply bypass capacitors on both side supplies, but that's it.  I've had excellent success with these.  As in, they've saved me from my own blunders time and time again.  I also suspect, but cannot confirm, that I have had better success with these in various projects because they also stop ground-related noise spikes/glitches/whatchamacallits, so even the data transfers tend to have less parity errors at higher baud rates.

If you use the more powerful Linux SBCs for both data collection and display (aforementioned support high-resolution HDMI displays with accelerated OpenGL ES graphics in Linux), I can warmly recommend using Python 3 + Qt 5 (easily with unified runtime support for both PySide2 and PyQt5, similar to QtPy), with the USB Serial termios stuff running in a separate thread, and using a Queue to transfer data.  If you need to preprocess the data, then I suggest writing a C termios preprocessor module as a dynamic library, loaded to the Python process; it can use pthreads for parallelization.

If you have people who can do systems programming in Linux, you can even split the UI and the data acquisition into separate processes, so that you can use the same acquisition/low-level C code on both headless appliances and interactive workstations, and just plonk the Python UI on top.

For headless appliance type –– local GbE Ethernet accessible data collection and control via public key-based SSH connections ––, I recommend starting by spending a couple of weeks to get familiar with LinuxFromScratch, then build your own appliance distro based on minimized Debian (ARM port) or Devuan.  Looking at LFS helps you understand the tiny but important details on how operating systems based on the Linux kernel actually work –– i.e., how to do systems integration right –– but starting from Debian/Devuan means you don't have to do everything alone, and can instead leverage the work done by the rest of the community.  Of course, I would warmly recommend that if you decide to go this way, you make your efforts public, to further share the workload; but, it is not a requirement: any organization can freely create their own variants without distributing them outside the organization, as distribution within ones own organization is not considered distribution or copying in the copyright law sense, the organization is the actual "end user".

If you go with RPi stuff, good luck.  Quite a lot of upstream developers have been burned by the RPi Foundation and RPi users – basically they're black holes that take everything but almost never contribute anything useful; and usually rename/repackage the projects so that the dependence of well-known FOSS projects is at least hidden if not obfuscated – and many will not engage with such any longer.  Myself somewhat included, although I make exceptions for people I like.