LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible recommendations for removing outliers from meter data

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.

0 Kudos
Message 1 of 8
(424 Views)

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...

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 2 of 8
(393 Views)

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.)

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 3 of 8
(370 Views)

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

Message 4 of 8
(355 Views)

@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.

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
0 Kudos
Message 5 of 8
(328 Views)

The software does wait (a configurable time) after switching to allow for bouncing, but longer times (> 100 ms) don't correct the issue.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 6 of 8
(325 Views)

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.

0 Kudos
Message 7 of 8
(273 Views)

Hi feniss,

 

what's the point in creating a new user account for the very same problem of naofomi?

Why don't you follow the recommendations you already received?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 8 of 8
(264 Views)