07-14-2022 06:20 AM
I'm developing an application to read conductance data from an LCR meter. The application collects 2 samples every half second and averages them together. The meter will occasionally output an overload that is shown as 9.9e37S when data is queried using SCPI commands. As it is now, I'm just using a max limit of 1S to determine whether or not the sample can be thrown out and remeasured but I don't exactly have confidence in case I catch the condition as it's on the rise or fall.
Does anyone have a better/recommended method of removing outliers? My data could range from nS - uS. The meter reads from 7 different UUTs that are switched using relays.
07-14-2022 09:30 AM - edited 07-14-2022 09:33 AM
I think you should investigate why sometimes your meter is sending you bogus data. Only after you know that it is safe to ignore that data should you actually go about ignoring it.
Edit: Dang, that number seems familiar. I've seen it somewhere before.
Edit2: Yes, this is a SCPI standard number for "NaN". Something is definitely going on here...
07-14-2022 12:27 PM
Now we just need to know why a Keysight E4980AL wants to report NaN... (I know the person that originally posted that question on reddit.)
07-14-2022 03:35 PM
The LCR meter uses a small AC signal at a set frequency. Depending on the measured device there can be conditions where the meter becomes "unbalanced" and won't return a measurement. Its basically a range where you can't/shouldn't measure using the given conditions and you need to adjust the frequency, AC bias, DC bias or measurement range to get the measurement conditions into a good operating point for the meter.
If you are programming the meter and run into 9.9E+37 values being returned then you are in a state where your meter is "unbalanced". Don't just hide those points! They are telling you your previous measurement points are on the edge of what the meter can measure and probably have higher error than you want. Instead adjust the frequency, AC bias, DC bias or expected measurement range to get the meter into a good condition.
Now if you are doing a frequency or bias sweep over a wide range it might be that you can't avoid things being unbalanced. In that case you could convert to NaN and have them show up on your plots as missing data. (Knowing that missing data is just that - a point that can't be measured.)
One other hint is to use the measurement corrections to account for OPEN, SHORT and LOAD, which do help prevent unbalanced conditions to some degree.
Hope that helps.
Craig
07-15-2022 08:54 AM
@naofomi wrote:
The meter reads from 7 different UUTs that are switched using relays.
Another possibility is that you might be trying to read too quickly after switching the relay... If you are using mechanical relays then there will be switch bounce to account for.
07-15-2022 09:03 AM
The software does wait (a configurable time) after switching to allow for bouncing, but longer times (> 100 ms) don't correct the issue.
07-18-2022 07:21 AM
I'm developing an application to read conductance data from an LCR meter. The application collects 2 samples every half second and averages them together. The meter will occasionally output an overload that is shown as 9.9e37S when data is queried using SCPI commands. As it is now, I'm just using a max limit of 1S to determine whether or not the sample can be thrown out and remeasured but I don't exactly have confidence in case I catch the condition as it's on the rise or fall.
Does anyone have a better/recommended method of removing outliers? My data could range from nS - uS. The meter reads from 7 different UUTs that are switched using relays.
07-18-2022 07:25 AM - edited 07-18-2022 07:27 AM