EEVblog 121GW Multimeter Issues

[Dr. Frank]

Ground, Earth, Static Field... whatever.

I propose simply to calculate the equivalent voltage on the last digit in 50mOhm range, that is about 0.4 mA times 1mOhm = 400nV.

That's simply extremely sensitive, so shielding is also difficult in a handheld DMM.

The reference current should have been 5mA, to get a stable reading as in 500 Ohm range.

Instead both ranges are derived from the same 1k reference resistor, but the 50 Ohm range uses an amplified AD range, which is the culprit
Frank

[firewalker]

Don't know if this is an Android software error or the meters sends wrong data, but when the scale overflows the bar graph stays near zero. Momenteraly it will gow to max but returns and stays close to zero.

The photo is out of focus cause it was taken with a 10+ years old phone.

 

Alexander.

[evava]

Ground, Earth, Static Field... whatever.

I propose simply to calculate the equivalent voltage on the last digit in 50mOhm range, that is about 0.4 mA times 1mOhm = 400nV.

That's simply extremely sensitive, so shielding is also difficult in a handheld DMM.

The reference current should have been 5mA, to get a stable reading as in 500 Ohm range.

Exactly, e.g. Fluke 289 on 50.000 ohms range uses current about 6mA.
(but, Fluke 289 has other problem on this range, namely extreme slowness)

[JS]

0.5 ohms.  You are the one who brought it up, so what ever values you were trying to measure will be fine.  Just do a before and after comparison and report the results.  If the noise you were seeing is reduced, I think we have our answer.

Maybe I'll give it a try after work tonight.

However, the problems I was seeing seemed to be related to static fields, caused by proximity of my hands to the meter or test leads.

The only way I think firmware can fix that is by having lots of software filtering. So it might be a choice between "slow and steady" or "fast and erratic".

  There are more clever ways to do noise filtering than just a LPF, the plots I'm seeing with V1.26 are glitchy, not just noisy, if I had the data I'd run an fft or find the spectral density to have a more meaningful data about the required filter for the job, or what filtering they are using, if it is a linear one it should show up quite nicely in the spectral density plot. If you just want a slow filter you could run the averaging on the meter to get a stable value, to find if you can repeat the measurement you could run a few and see if you will trust the first the next time.
  What I'm saying is with some smart filtering, non linear, with some hysteresis, averaging till a step bigger than X or a faster average goes further than X, etc. you could ignore those glitches but get a faster reading if the value is actually changing. Nice thing about having the fast data logged is that you can make your own filter afterwards, that could be nice to keep but show a filtered data on the display so it's easier to read than having 2 digits jumping around in a 3 digit reading (0.5Ω)

  I do have the meter, it came with V1.18 which doesn't seem to apear anywhere, let me say auto hold was really really bad, I upgraded it to V1.26 after a very short play around, as I found many many things wrong with that version. It came from US, I could look the SN but I haven't seen anybody with that FW version. Now I could get some data by myself but stabilizing temp to get a decent resistance measurement won't happen tonight while the cold cold wind is getting under the doors. I should set up a parallel of 1% MF resistors to get a low value, close to the 500mΩ you are using. While I'm at it I could set up something to short the leads as I run the measurement and look at the step response of the filter, opening could also do in manual range, as in auto range will start to jump around like crazy. I don't know what should I use as a switch to make it low resistance, fast and not bouncy, a mosfet maybe.

  Having an open source of the firmware would be so so great, ideally the original one but Dave already said that wasn't going to happen apparently as UEI wouldn't want to release some of their proprietary code. Playing around with filters, some functionality and possibly introducing new measurement math functions, not only statistics but also some automation in the measurement if you want to measure a parameter that means something else in a non linear way would be sooo great. Maybe someone could come around with an open source firmware at some point, I would totally get involved in the process.

  If I had to report, one thing I think it's missing is the ability to look at other logs than the last one, which is the only that shows, also the possibility to tag logs, a few characters makes a great difference in that respect. There might be some easter eggs in the firmware to be found, as we are in V1.26 and the user manual is only V1.07

JS

[ELzekio]

The issue about the movement on low ohms measurements should be pretty easy to replicate for anyone.

When I test a less than .5 ohm resistor and just lightly touch the hold button, I can easily make the reading jump around excessively. As soon as you pull the finger away, it will settle back down to the proper value.

[ggchab]

Same on mine. But also with range, mode, min/max and rel buttons.

[IanB]

Same on mine. But also with range, mode, min/max and rel buttons.

Well, apparently you have to use the meter in a sterile environment, inside a Faraday cage, with no mains wiring nearby, on a static-dissipative mat, wearing an anti-static wrist band; otherwise you are not following proper procedures... 

[JS]

  Here is my shot at the low resistance noise... I also have the noise when I touch any button but that's not what I'm addressing here.

  I grabbed a 2.2Ω 1% metal film resistor, BT connection, run some measurements of it and a short circuit using standard leads, to connect the resistor to the leads I screwed with the banana inserts pressing the resistor leads, for the short I did the same thing over the resistors leads but at the same lead of the resistor. I took a really crappy picture of the setup so wouldn't be so useful for you but I hope you get the idea. The DMM internal temp was around 17ºC.

  After a short warmup where I saw no more shifting of the readings and noise got noticeable lower I run a few logs via BT in different settings (short, short with delta, 2.2Ω with the delta of the short, 2.2Ω and 2.2Ω delta) From this last one I will show the data I obtained and some processing I'm proposing.

  From 380 samples via bluetooth, at about 0,5s each, I see 5 glitches of a few samples, if I were to guess this is product of some kind of calibration messing the readings. What I did was running a crude fft (I didn't correct for the mirroring or put freq reference) and plot (same thing, no freq or time ref, but with 380 samples at 0.5s you can see divide the x axis by roughly 100 to get a rough freq idea and divide by 2 to get the time. Of course the FFT data after half the plot is just a reflection of the first half. I added a moving average to the FFT plot to make things easier to read, if not it was just a mess of dots.

  Then I made some filtering, to impact on those 5 glitches, to do so I used the average of the measurement, and if the difference of the sample is more than 8 counts away from the average I ignore it, and the next two samples, to put something to fill the signal I used the last 3 samples before the glitch. I know this is not a usable filter for real time measurements as it's not a causal system, but I think that's not to hard to come by just taking the last few samples, detecting an actual change would be a tad slower as is usual with filters but 3 samples should be enough, bigger changes than the amplitude of the glitches could ignore the filter all together so it only acts in variations smaller than the glitches. In my measurements all the points fall within 5 counts to the average and the glitches go over 15 counts to about 30 counts, that difference should be enough to detect them within a few samples and not affect speed of measurement in any other case than fast variations between 10 counts and 40 counts, even just detecting inter sample variations of that amplitude and ignore that and the next two samples would do, just freeze the screen for that time.



  The LF noise isn't reduced too much up to 0.2Hz by the filter but the HF noise up to 2Hz is reduced roughly 10dB, the messy display would go over completely with jumping digits other than the last one which in this measurements is expected to be. As there is a LPF key and display segment already in the meter it could be cool to be able to slow down the measurement even further to make the reading more stable, wouldn't be 1kHz but rather 0.1Hz or something but would be nice to have for almost every range so you can get a stable reading without needing to run an average each time, reset it and all that, even more as pressing the average button messes the readings.

  I hope something is implemented in order to correct this, as it was good in V1.0 of the FW doesn't make sense to have it wrong 27 versions later. For an extra FW feature I would add such LPF as moving average or something like that which would give only ±2 or 3 counts in this scenario changing slow rather than ±5 counts changing fast. For the issue with the buttons delaying the function could be a walk around, so if you press delta it does to the next few readings (or the ones before) rather than the actual one, same thing for hold, min max should start checking a few samples after the button press. Also, I'd like the delta function to take the avg value while the avg is active instead of the instantaneous reading.

  Just to clarify, here we are talking of reading noise rather than precession but is useful to detect those small changes in the short term and be able to read from the screen rather than needing go post process the data to get an actual reading.

JS

[IanB]

You forgot firmware 1.0 as well.  Had you given me a detailed procedure, I would have tried to follow it. So I documented what I did for you.  I'm not sure why that bothers you.  A more productive approach maybe to ask if I can repeat the test some other way.  You would just need to describe it.

You really don't have to be very detailed or precise. If you merely move your finger near any of the buttons, especially the hold button, the display reading jumps around as attested to by ELzekio, ggchab and others previously.

The fact that you didn't reproduce it suggests your pre-production sample differs in some significant way from later production meters. The effect is not subtle. It jumps right out at you. If you were going to see it, you would have seen it by now without needing to look for it.

[IanB]

So I documented what I did for you.  I'm not sure why that bothers you.

It doesn't bother me at all. I am happy that you tried to reproduce it. It is curious that you didn't observe any effect, which suggests there is something different about that particular hardware compared to later revisions.

The reason for my comment was your suggestion that rugged and portable meters, that are inherently designed for field use, should have to be used under carefully controlled laboratory conditions to avoid malfunctions in their behavior. That doesn't seem quite realistic.

[JS]

Joe, about the buttons, I see that too, just trying to press a button (delta, min/max, hold and maybe mem are the more problematic as you want the meter to capture the readings and it does so right after) makes the reading jump like 100 counts or something. I see it even worse when taking the fingers out of the button after a slight touch. I haven't tried V1.0 so I don't know if that is still present there.

First, thanks for taking the time to help look into this.   I assume the data is normalized and that's why the "signal" is shown near zero rather than 2.2ohms.    At least you are seeing what appears to be the same spikes. It sounds like you may have tried rolling the firmware back to 1.0 as well.   

I'm with Dr. Frank on this one.

  I didn't went back to V1.0, I should tonight and try something similar, will be back soon with the results.

  I used the rel function once the 2.2Ω resistor was in place, that's why the readings are close to zero (centered at 2.2mΩ as the average of the signal suggests rather than 2.2Ω, which suggest the rel function works really nice, just 0.1% from long average) but for the FFT I did substracted those 2.2mΩ to avoid the spike at zero which would mess the scale of the plot, cheating with that instead of fixing the axes range as I used different samples with the same program, just posted that one which was pretty representative of the test, being longer and having quite a few spikes. During the test I didn't came even close to the meter, I sit in the couch looking at the phone and controlled the whole experiment from there (except of course swapping the resistors, but not at all while datalogging)

  Now for homework I will take it back to V1.0 and check what happens, I will try making a causal filter for the spikes and lastly use a switch to short the leads during the logging (maybe over a higher resistor) to check what filtering is shown on the signal. For now I should test a mechanical switch and if I see some problems come up with a remote solution so I don't affect the measurement with that either.

JS

PS, I'm running some logs right now, the display didn't jumped as much as I saw it do yesterday, I don't know what changed, all my setup is more relaxed than yesterday... probes wires all around the PC and noise doesn't look that bad, I will need to check for those few glitches if they are there.

[Brumby]

So I documented what I did for you.  I'm not sure why that bothers you.

It doesn't bother me at all. I am happy that you tried to reproduce it. It is curious that you didn't observe any effect, which suggests there is something different about that particular hardware compared to later revisions.

The reason for my comment was your suggestion that rugged and portable meters, that are inherently designed for field use, should have to be used under carefully controlled laboratory conditions to avoid malfunctions in their behavior. That doesn't seem quite realistic.

While documenting the details of a test gives you and other members an opportunity to try and replicate the results, the real purpose is to provides the designers with enough detail that they can replicate it.  If they can replicate a problem, there is a good chance they will be able to solve it.

I want to emphasise this point ... very strongly.

The testing regime is just that ... TESTING.  If some are finding an anomaly that others are not, then there is likely to be some rather subtle difference in the testing process that accentuates it or hides it.  In fact, this is not "likely" - it is almost a certainty.

It is only by fully describing the TESTING environment and setup can any subtle influences be properly investigated - and with electronics, an extra couple of feet of wire can have a different effect when left dangling or is rolled up, when it's laying on a grounded chassis or next to a powered transformer.

Full and proper testing protocols are a hassle, especially if you're not used to them.  They require a discipline that some may consider over the top - but such attention to detail is absolutely essential.

Nobody is saying you have to use the equipment this way!!

[IanB]

We know how 1.0 implements the filter is a fair bit different.  The fact I keep going back to it as a baseline should tell you how unstable the code base is.    You have no desire to try and run it to see if it has any effect on what you are seeing and I have no problem with you ignoring that.   I just find it odd that you take the time to suggest there is something different but fail to look at the most obvious change.   

My test case doesn't suggest how it behaves under different conditions.  As I have said, this is how I normally work on electronics.  If you would like to see how the prototype works in a different environment that you would consider less controlled, you only need ask and to define what that environment should be.

It does not seem to me that changing the firmware would affect something that looks like a hardware behavior. However, just to make sure I put the firmware back to v1.00 and the effect is indeed observed just the same.

If you would like to try to reproduce what I am seeing, I am doing the following:
1. Put the meter on a sensitive range where it is measuring DC mV (e.g. measuring a low resistance like 0.5 ohms, or measuring temperature, or actually measuring a few mV)
2. No special precautions taken (meter on a normal bench, no wrist strap, 60 Hz mains in the environment)
3. Place finger on the Hold button. On approach the display may dip. On taking the finger away the display may jump. A stronger effect is observed if the finger is rested on the Hold button for three seconds or so before pulling it away. Try slow and fast movements with different intervals between actions.

For everyone who has reported this problem it is very obvious. You don't have to look very hard to see it. It is not subtle!

[Brumby]

Well, the first thing I would suggest is that we get the serial numbers of those meters that are out there -  and whether they exhibit the problem or not.  I would further suggest only meters with a specified firmware version be included.  If there is a change between "problem seen" and "no problem seen" at a point in the serial number range, then the question could be asked if UEI changed something in the hardware at that point.


However, if the problem seems to NOT follow such a pattern, then it will be something else.  But what?  Could it be related to temperature? Humidity? Barometric pressure? Urban/Rural location? The list goes on and on .... and on ... and this list is only to identify some commonality so that we can zero in on the real, underlying problem.

Saying something is obvious and just pointing at may be quite valid from your perspective, but it isn't helping find a solution.

[IanB]

One problem is that hundreds of meters have been shipped, but very few people are commenting in this thread or reporting their experiences with their meters. As Joe said, it is almost as if everyone has just put them on a shelf in their boxes for posterity.

So trying to find a pattern is very difficult with such a small sample size.

[Brumby]

That is true - and it does make things much more difficult.

My thought is that many of the ones sitting on the shelf are awaiting a stable release of the firmware that everyone is pretty happy with - and then they will get pressed into service.  I also think there will be a lot of meters just opened up and are being used in the belief they are "good enough" for the people who are aware of these discussions and those who blindly believe that it's a brand new product and therefore must be A-OK.  Unfortunately, this takes a lot of meters out of the testing pool.

I hope we can at least characterise the circumstances for the behaviour (as was done with a certain meter from the Keysight stable not so long ago).  Fixing it would be great.

[Bratster]

I have one of the kickstarter meters and would be happy to check some things out on it. But only be able to get to it on a weekend.



Sent from my Fi Moto x4 using Tapatalk

[Brumby]

That would be great.  I don't think a few days' delay will be a problem at all.  Any additional information you can contribute will be welcome, I'm sure.

[JS]

Quote from: joeqsmith on Today at 12:58:22 pm

JS, sounds good.  I didn't even consider the rel function.  Makes sense.   I can tell you that the prototype with the later firmware is not near as stable beyond just the noise.  I've posted a few times how it is sensitive to the proximity of my hand.  If you look at some of that early data I took I even mentioned that the spikes were from me walking by the meter.  1.0 does seem to help tame it on the proto.  Look forward to seeing your results.

I do see the jumping with V1.00 while touching the buttons as well, 100 counts or so and all over the place, not the single sided glitches of a few samples.

Well, I did my homework... The meter connected to a resistor (22Ω and 2.2Ω in different experiments) and parallel with the resistor a toggle switch. Everything up and running switch open, press the mem button to start recording (yes, this time no BT) wait for about 200 samples in the fastest speed (40s or so) toggle the switch to close it, wait for 100 samples, toggle the switch open again, wait for another 100 samples and stop recording. All that done with both resistors and both versions (1.00 and 1.26)

  Now, what did I saw, let's start by looking at the switching moments... 10 samples are plenty to observe the switching, so we are looking at a 2s interval. Here I normalized the resistances and placed the 22Ω and 2.2Ω together, the observer eye will detect which is which.
  FW V1.00 looks consistently slower, taking 4 samples to settle to within the noise floor, strangely only one signal looks 5 samples, so we call it 4.25 samples for version 1.00.
  FW V1.26 looks consistently faster, taking one or two samples to settle within the noise floor, so we call it 1.5 samples, which is about 3 times faster than V1.00.
  Is interesting to look at the shapes of the different pulses, going down all show slower, and for V1.00 a step in mid air lasting up to 4 samples in exactly the same value (stop for a coffe maybe). V1.26 settles in just one sample going up, while going down stops for a single sample in a place where it doesn't seems to be a single pole filter, but also doesn't seem to be just toggling the switch during the sampling time, too similar shape for both traces, I wouldn't call consistency 2 samples but something to look for if I was trying to replicate the filter.


  Enough with the step response, let's go to the noise observations, I took the first 200 samples of each measurement for this, from the start to a few samples before the switching, this time I did normalized the resistance to just look at the noise around zero. Looking at the 2.2Ω resistor plot, for V1.26 there are no glitches in those 40s, just within 5 counts of the mean, I guess I just got lucky, they were around 30s to 90s apart, while the V1.00, after a high start of 4 counts over, stays within 2 counts from the mean for the rest of the time. In the frequency plot shows a faster response from V1.26 as in the step plots, with higher noise all over the spectrum.


  Now the 22Ω plots, all other just as before. Hey! We have glitches   So noise went up to the roof for all the spectrum and now we cant even see clearly the V1.00 noise while glitches go like 30 counts away from the mean. The first one was just at the start, could be due to the button problem but I don't think so, I'm observing such behavior mainly with the hold, not the mem button. Also, the reading just shift around and doesn't stabilize just one or two samples after, slower process all together, but it could very well be. Second glitch I don't think I went even close to the meter, as it was way before toggling the switch. Due to those glitches the noise goes up all the way up to 5Hz to about 4 times than without the glitches, and 10 times higher than the V1.00 figures.


  To wind up, I don't think the glitches are external perturbations, as I said I was quite a few meters away in yesterday experiments and it was in the middle of the room with just one incandescent bulb on, main source of noise would be the BT or the cellphone on my hand. If I had to guess the thing is doing some kind of calibration, auto zero or something at a pseudorandom intervals and just showing up whatever value it reads instead of ignoring the samples affected by the cal procedure.
  The noise levels and frequency response of V1.00 are similar to what I was expecting, falling within 2 or 3 counts, I was getting that with a moving average of about 15 samples. The staircase response tells me it's not doing just that or other type of linear filter but some other processing about that, I kind of like that a bit more but if I could I wouldn't switch completely to that, I would still prefer for the data logging to have the faster response but ignoring the glitches. For me the best choice would be to have the choice at the time of the measurement (and not having to change firmwares to do so) and make use of the buttons that are not being used, could be the 1ms but the LPF symbol makes more sense, to add a LPF even if it's not 1kHz but 0.1Hz. Also, using a linear filter to deal with the spikes doesn't seem right to me, they are clearly not random noise and getting them into the averaging isn't the way to go, just masking the problem but introducing even more error than leaving it there, hard to catch with the eye and can be suppressed while processing the logged data.
  If I were to design a filter for an application like this, just for the display, I would make it varying with time, a very fast, almost non existent as it detects a fast change in the signal and slower as it just detects the noise of the system, let's say (in time constants) single sample for a change over 200 counts, 4 samples for a change over 20 counts and 20 samples for a change under 20 counts. For the data logging I would always prefer faster, noisier samples, the V1.00 clearly shows slugginess in the data, as has many consecutive samples in the same reading. Good for display, bad for logging (IMO) the problem with the BT logging is that you are logging the display value. A walk around of all this would be to write a BT app to do the trick, and look at whatever kind of reading I want from the phone, just leave my noise alone so I have something to work with...


  Hope all this helps, I'd be happy to run any test with this, just bare in mind I don't have a higher resolution meters if that's what's required, can't do long term stability, calibration checks, etc, but for this kind of feedback I'm available. I just got my meter two weeks ago, that's why I'm just jumping in here now...

Regards
JS

[EEVblog]

One problem is that hundreds of meters have been shipped, but very few people are commenting in this thread or reporting their experiences with their meters. As Joe said, it is almost as if everyone has just put them on a shelf in their boxes for posterity.

No, people are using them, I get a ton of feedback this is the case, and they are simply not running into any issues in their use.
Yes there are some outstanding issues, but in the scheme of a multimeter that has dozens of different functions and ranges, only a few of those are affected. Most people will not see any issues in daily use.

[EEVblog]

UEi have reported back on the Mohm range drift issue, and the problem is the 1N4007 diodes D7 and D8, they are going to be replaced by a single TVS in future builds.
I don't have any further details, but I presume there is some sort of temperature/voltage dependency related issue with those diodes that can manifest itself under certain circumstances.
They are sending me an updated meter with the new part fitted for testing.

[JS]

I'm loving the meter, haven't come across it too much to use it as I just got it but I'm totally happy with this, looking for the switch press on the low ohms I came across the noise issue with the low ohms and saw people working on it and wanted to help...

UEi have reported back on the Mohm range drift issue, and the problem is the 1N4007 diodes D7 and D8, they are going to be replaced by a single TVS in future builds.
I don't have any further details, but I presume there is some sort of temperature/voltage dependency related issue with those diodes that can manifest itself under certain circumstances.

I haven't tested that yet on my DMM, nice to know they found something about it.

I run a 15 minutes log using V1.26 and had a play around with the filtering, this time using causal systems. To address the glitches It just took me comparing 2 samples, the new and the last, and if they were more than 9 counts away ignore it and the next two samples filling it with the last samples of the filtering I was making using 0.95 and 0.05 as coefficients. Samples taken are in black, after ignoring glitches in red, filtered in blue.

I don't know about the drift, likely warmup, I placed the thing inside a cabinet but looks like not long enough, reads starts to settle at the end.

One problem I'm having is not being able to log the second function, is there a way to do so? Not with BT nor to the SD.

JS

[Zucca]

UEi have reported back on the Mohm range drift issue, and the problem is the 1N4007 diodes D7 and D8, they are going to be replaced by a single TVS in future builds.
I don't have any further details, but I presume there is some sort of temperature/voltage dependency related issue with those diodes that can manifest itself under certain circumstances.
They are sending me an updated meter with the new part fitted for testing.

Please make a video on that, I am interested on details.

[firewalker]

UEi have reported back on the Mohm range drift issue, and the problem is the 1N4007 diodes D7 and D8, they are going to be replaced by a single TVS in future builds.
I don't have any further details, but I presume there is some sort of temperature/voltage dependency related issue with those diodes that can manifest itself under certain circumstances.
They are sending me an updated meter with the new part fitted for testing.

Will this improve be user addressable?

Alexander.

[Dr. Frank]

UEi have reported back on the Mohm range drift issue, and the problem is the 1N4007 diodes D7 and D8, they are going to be replaced by a single TVS in future builds.
I don't have any further details, but I presume there is some sort of temperature/voltage dependency related issue with those diodes that can manifest itself under certain circumstances.
They are sending me an updated meter with the new part fitted for testing.

I assumed a temperature dependent leakage current in Ohm mode, due to protection diodes:
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1728887/#msg1728887

but only now I know where these are located!

It's clear, that 1N4007 has high leakage currents on reverse voltages, not suitable for such a circuit. These create non-linearity over voltage, and the strong temperature dependence of this leakage current creates that huge 0.64%/K gain change in 50MOhm range.

Edit: I'd replace these 1N4007 by reversed npn transistors, as these usually have very low leakage current, as already being used similarly  in the 121GW, i.e. Q1, Q2 (n.a.), Q3, Q5. n-JFETs. Used as diodes, these have low leakage, but also high breakdown voltage (which the E-B diode of npns don't have), as 15V may be present there.

Frank