EEVblog 121GW Multimeter Issues

[joeqsmith]

Hi Joe,

Thanks, my meter behaves as in your video. 5V/autorange shows <1V, 50V range shows some garbage, other ranges work. Would be nice to show at least "I can't auto-range on that"...

Do you know, is this a hardware or a firmware problem? I really like the meter otherwise, but this makes it useless for tube radio stuff. My meter is 1807 Datecode and fortunately still within EU warranty.

The fact you are able to manually range the meter to overcome this problem is a big hint to where the problem lies.   If you just treat it as a manual range meter, you should be fine (assuming none of the other shortcomings are a problem for you). 

They have had a few years to get it right and as you have seen yourself, even the basic autorange still has major problems.   Without Dave pushing the designers for improvements, I don't think you will find problems being addressed very quickly.   

It certainly has caused me to view the certifications as having less value.   Scary to think it can't reliably display voltage.       
https://youtu.be/7AhypTCJOTE?t=1303

[bateau020]

5V/autorange shows <1V, 50V range shows some garbage, other ranges work. Would be nice to show at least "I can't auto-range on that"...

Had the same problem once, on capacitance (1nF), on v2.04. Since then, have been unable to reproduce this.
So yes, there is something strange going on, but it's not a biggy for me.

[movax]

Indeed, there are still issues with logging reliability:

I did find single block of zeros in 26MB file:

Code: [Select]

012f27d0  2c 0d 0a 32 35 36 31 33  36 2c 32 30 32 30 2f 30  |,..256136,2020/0|
012f27e0  34 2f 31 37 2c 30 38 3a  35 36 3a 35 35 2c 44 43  |4/17,08:56:55,DC|
012f27f0  6d 56 41 2c 30 30 31 37  2e 32 33 2c 6d 56 41 2c  |mVA,0017.23,mVA,|
012f2800  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2840  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2850  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2860  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2870  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2880  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f28f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2900  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2910  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2920  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2940  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
012f2950  00 00 00 00 00 00 00 00  00 32 35 36 31 34 31 2c  |.........256141,|
012f2960  32 30 32 30 2f 30 34 2f  31 37 2c 30 38 3a 35 37  |2020/04/17,08:57|
012f2970  3a 30 30 2c 44 43 6d 56  41 2c 30 30 31 37 2e 32  |:00,DCmVA,0017.2|
012f2980  33 2c 6d 56 41 2c 44 43  56 2c 30 31 2e 33 33 31  |3,mVA,DCV,01.331|
012f2990  33 2c 56 2c 44 43 6d 41  2c 30 31 32 2e 39 34 34  |3,V,DCmA,012.944|


Also, data logging stopped after 340560 data points:

Code: [Select]

340559,2020/04/18,08:30:16,DCmVA,0016.51,mVA,DCV,01.3035,V,DCmA,012.672,mA,,
340560,2020/04/18,08:30:17,DCmVA,0016.51,mVA,DCV,01.3035,V,DCmA,012.672,mA,,
MAX,1,DCmVA,0024.78,mVA,
MIN,340084,DCmVA,0016.51,mVA,

without me interrupting it.

Display was showing SdE (SD card error?, but the min/max trailer did end being written correctly; I think in fact it means SD End, and the end was probably triggered by low battery alarm indicator, which is now showing on the LCD), and also showing 20.04mVA, which is impossible, as the last measurement was 16.51 mVA, and it is battery into constant resistance mode, so the power should be strictly decreasing.

Also I feel like there should be one extra digit of significance in the mVA mode when logging,  i.e. 0016.514mVA, not 0016.51mVA. This is because right now it is only 4 significant digits, but both voltage and current do have 5 significant digits, so the product should also be 5 significant digits.

Example:





The spike correspond to the block of zeros probably / malformed data.

[jchw4]

I did another 600000 logging. Did not get zero blocks, so it seems to be pretty rare.

Unfortunately it does beep when logging ends automatically (would not be so bad if it had better voice).

This time it was sin(0.1Hz) 20Vpp. Did not get anything interesting. Just the old 3-20 seconds gaps in logging.

I was going to run another test with 1/exponent, but the power supply in my FeelTech stopped working (does not start under load), so now I need to fix it first.

[jchw4]

Another test with positive exponent, 0.005Hz this time. Maybe it dost not like exponent, but I got another block of zeroes:

Code: [Select]

...
214797,2020/04/22,12:20:22,DCV,05.0887,V,,,,,,,,
214798,2020/04/22,12:20:22,DCV,05.0889,V,,,,,,,,
214799,2020/04/22,12:20:22,DCV,05.0888,V,,,,,,,,
214800,2020/04/22,12:20:22,DCV,05.0890,V,,,,,\0\0\0\0\0214801,2020/04/22,12:20:23,DCV,05.0887,V,,,,,,,,
214802,2020/04/22,12:20:23,DCV,05.0891,V,,,,,,,,
214803,2020/04/22,12:20:23,DCV,05.0892,V,,,,,,,,
214804,2020/04/22,12:20:23,DCV,05.0894,V,,,,,,,,
214805,2020/04/22,12:20:23,DCV,05.0897,V,,,,,,,,
...

It's one case in a file of 600 000 records. But you can see that it's again aligned on the record boundary (3 trailing "," are missing + "\r\n" missing).

[e0ne199]

anyone here knows how to calculate AC+DC voltage manually?
is it really just Vrms+Vdc or something else?
i want to test my 121GW for AC+DC voltage measurement anyway

[HKJ]

anyone here knows how to calculate AC+DC voltage manually?
is it really just Vrms+Vdc or something else?
i want to test my 121GW for AC+DC voltage measurement anyway

square root of Vrms*Vrms + Vdc*Vdc

[CDaniel]

Google is your best fried when you don't know something . Anyway the AC+DC is calculated by the microcontroller just like a pocket calculator , so the error is excluded if AC and DC are measured correctly

[movax]

I did another 600000 logging. Did not get zero blocks, so it seems to be pretty rare.

Unfortunately it does beep when logging ends automatically (would not be so bad if it had better voice).

This time it was sin(0.1Hz) 20Vpp. Did not get anything interesting. Just the old 3-20 seconds gaps in logging.

I was going to run another test with 1/exponent, but the power supply in my FeelTech stopped working (does not start under load), so now I need to fix it first.

It doesn't appear that rare to me. I did another two runs, one with 600000 points, another with 460000 points. The first one was corrupted and had block of zeros between sample 354716 and 354721. It was in the middle of the record, and looks to be somehow aligned with 32-byte, or so:

Code: [Select]

01a47bd0  2e 32 39 31 31 2c 56 2c  44 43 6d 41 2c 30 31 32  |.2911,V,DCmA,012|
01a47be0  2e 36 34 30 2c 6d 41 2c  2c 0d 0a 33 35 34 37 31  |.640,mA,,..35471|
01a47bf0  36 2c 32 30 32 30 2f 30  34 2f 32 32 2c 32 31 3a  |6,2020/04/22,21:|
01a47c00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c50  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c80  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47c90  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47cb0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47cc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47cd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47ce0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47cf0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d50  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01a47d70  00 33 35 34 37 32 31 2c  32 30 32 30 2f 30 34 2f  |.354721,2020/04/|
01a47d80  32 32 2c 32 31 3a 31 39  3a 31 34 2c 44 43 6d 56  |22,21:19:14,DCmV|

Second run did look uncorrupted, but I didn't run full 600k samples on it.

Processing this data with corrupted content is extremely tedious and tricky (multitude of grep, and sed tricks to do it automatically, which is even harded because grep refuses to parse the file by default as it is binary).

The fact that date and time are in separate column makes processing even harder (especially of multi-day data). I am using gnuplot for 21 years, and had a real trouble parsing the separate columns with this format. It is essentially impossible, and you need to have yet another sed to bring it to sanity (single column). I wasted like 2-3 hours trying to make it work, despite me knowing every piece of gnuplot for long time.

Code: [Select]

set grid
set ylabel "Power [mVA]"

set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"  # Input format.

set xlabel "Time"
set format x "%Y-%m-%d\n%H:%M"  # Tic label for x axis.

# 1  2          3        4     5       6   7   8       9 10   11      12 13
# 14,2020/04/14,09:13:43,DCmVA,0024.77,mVA,DCV,01.5981,V,DCmA,015.504,mA,,
# Filter only rows with data.
# Filter rows that are corrupted.
# Convert 14,2020/04/14,09:13:43,DCmVA to 14,2020/04/14 09:13:43,,DCmVA, maintaining column numbering.
set datafile separator comma
plot "<egrep --text '^[0-9]' 20041800.CSV | egrep --text -v '354716|354721' | sed -E -e 's/^([0-9]+),([^,]+),([^,]+),/\\1,\\2 \\3,,/'" u 2:5 w l t "power"

Of course this regexp would need to be adjusted every time to do something out of it. Or write another tool to try to detect this zeros somehow.

I tried also to use 'using (sprintf("%s %s", $2, $3)):5', but it didn't work.

If data was in a sane format, it would be simply be two lines:

Code: [Select]

set xdata time
plot "20041800.CSV" u 2:4 w l t "power"

Eh.

Also the lack of longer data logging than 600k, is also problematic, as you need to stitch data and remember to restart logging, which can make gaps:




I am attaching a simple Python 3 script to remove corrupted data and merge multiple files, and convert the date / time into single column. Inside you will find example how to use it with gnuplot:

Code: [Select]

set yrange [0:]

set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"  # Input format.

set xlabel "Time"
set format x "%Y-%m-%d\n%H:%M"  # Tic label for x axis.

set ylabel "Power [mVA]"
set grid

set datafile separator comma

plot "<python3 121gwfix.py 20041800.CSV 20042500.CSV" using 2:5 with dots title "Power"


[movax]

A new issues discovered. To prevent DMM from stopping logging on low battery (which would happen after about 1 million samples on crappy batteries, and about 2 million samples on good batteries), I switched to power it from my benchtop PSU (Agilent E3642A), with 6.00V, 250mA limit.

After powering it on, the PSU shows correctly 6.01V. Verified by secondary multi meter.

Well, in 121GW settings, it is reading 5.7V, which is lower than what it is. That is not too good, because it indicates that it will stop working earlier, and waste battery. If it was 5.9V that would be fine, to be on conservative side, but 0.3V different is not good. Is there some naive reverse polarity protection and diode voltage drop? That looks like bad design to me in low power device operated on batteries. Active reverse polarity protection would be better. Maybe it is some other issue? Maybe voltage divider to measure battery voltage has low accuracy resistors?

My ambient is about 32 deg C at the moment.

[AlanS]

@Movax - Clearly you are not outside. 

[J-R]

A new issues discovered. To prevent DMM from stopping logging on low battery (which would happen after about 1 million samples on crappy batteries, and about 2 million samples on good batteries), I switched to power it from my benchtop PSU (Agilent E3642A), with 6.00V, 250mA limit.

After powering it on, the PSU shows correctly 6.01V. Verified by secondary multi meter.

Well, in 121GW settings, it is reading 5.7V, which is lower than what it is. That is not too good, because it indicates that it will stop working earlier, and waste battery. If it was 5.9V that would be fine, to be on conservative side, but 0.3V different is not good. Is there some naive reverse polarity protection and diode voltage drop? That looks like bad design to me in low power device operated on batteries. Active reverse polarity protection would be better. Maybe it is some other issue? Maybe voltage divider to measure battery voltage has low accuracy resistors?

My ambient is about 32 deg C at the moment.

At 6.0V mine indicates 6.0V.  At lower voltages it does stray one or two tenths low.

You're already there, just test the point at which the low battery indicator comes on?

For me it comes on just below 4.3V supply voltage, so the batteries would be pretty well used up.

[AVGresponding]

Also bear in mind a set of brand spanking new cells will have an open circuit V of around 1.65 each, so 6.6V for the battery, and given the low current drain from the DMM it'll likely not drop hugely on load initially.

[dcac]

Well, in 121GW settings, it is reading 5.7V, which is lower than what it is. That is not too good, because it indicates that it will stop working earlier, and waste battery. If it was 5.9V that would be fine, to be on conservative side, but 0.3V different is not good. Is there some naive reverse polarity protection and diode voltage drop? That looks like bad design to me in low power device operated on batteries. Active reverse polarity protection would be better. Maybe it is some other issue? Maybe voltage divider to measure battery voltage has low accuracy resistors?

They are probably standard 1% smd resistors - so the error can't be explained by that.

My 121gw also show about 0.3-0.4V too low for the battery, I think the problem could be the chosen resistor values for the voltage divider:


This equates to about 250K signal source impedance for the ADC - which seems far above the recommended maximum of 50K.

This gives quite noisy sampling but they mitigated it to some degree with a look up table to compensate for the nonlinearity and some heavy average filtering in the firmware, but perhaps still not so good to be outside the recommended impedance values by that much.

[CDaniel]

Impedance shouldn't be much of the problem here ... they couldn't do a simple ADC measurement right in firmware ( what a surprise  ) . In firmware you can adjust the divider ratio to be accurate .

[dcac]

Of course they are adjusting for the divider ratio in firmware, they are also adjusting for the lack of linearity, but still they get a value that's way of.

I think the design criteria perhaps was - this only need to be good enough to show if batteries are good or bad.
 
But still, reading the battery voltage with a 12bit ADC could certainly provided for a much more accurate measurement, and perhaps down to 10mV resolution. And it could’ve been interesting to follow more exactly how the batteries was consumed.

[van0014]

It would be awesome if that low battery divider could be changed and re calibrated without changing firmware. I guess one way of finding if there's a calibration value for low batt would be uploading blank or random calibration data. Might be risky even with a backup, depending on what other data might be read from the calibration file

[CDaniel]

For what do you want that ? Correct calibration can be attempted by replacing one of the resistors with a trimpot to change the divider ratio , no ideea if it will be linear afterwards , depends on how the firmware was made ... Anyway , I doubt that the the low voltage bat value  is stored in calibration data , most probably is in firmware .

[billrule]

I haven't noticed if this has been covered already, but a quick search didn't turn anything up....
By now, I imagine lots of us will have exhausted the original batteries in the meter, and as casual as I am, I disregarded the notification that this had happened. What concerned me however, was that while the meter still gave a reading, checking the mains voltage reported basically 0 volts! Luckily, I didn't lick the terminals before using a second meter to confirm, but it could have been a severe lesson for disregarding the "battery low" symbol.

[Kilrah]

After powering it on, the PSU shows correctly 6.01V. Verified by secondary multi meter.

Well, in 121GW settings, it is reading 5.7V, which is lower than what it is. That is not too good, because it indicates that it will stop working earlier, and waste battery. If it was 5.9V that would be fine, to be on conservative side, but 0.3V different is not good.

Looks like someone's been looking to find a use for those batterizers... 

[dcac]

It would be awesome if that low battery divider could be changed and re calibrated without changing firmware. I guess one way of finding if there's a calibration value for low batt would be uploading blank or random calibration data. Might be risky even with a backup, depending on what other data might be read from the calibration file

I wouldn't mess with the divider network, though their choice of values are strange. The only reason I can think of using such high resistance would be to limit possible over current into the ADC pin coming from the battery terminals - perhaps from a static discharge.

But it obviously caused them some problems getting a stable ADC reading, it's quite an elaborate filter they implemented in FW and it costs some processing power. But then they really seem to be over correcting for possible linearity faults, I actually think much of the error is coming from this, but then again I only have one 121gw to compare to, but mine hardly need any correction at all, 4V to 6.5V it is within 50mV if I bypass the correction in FW all together.

[CDaniel]

High resistance is for low consumption ... that divider is allways connected .
Measuring a voltage with  microcontroller's ADC is very basic , you are talking about "elaborate filter in FW" like is some magic  , sorry . How sloppy the firmware is , with so many bugs ,  I personally doubt there is any coding sophistication , just the minimum possible to work 

[ve2mrx]

Hi movax,

After powering it on, the PSU shows correctly 6.01V. Verified by secondary multi meter.

Well, in 121GW settings, it is reading 5.7V, which is lower than what it is. That is not too good, because it indicates that it will stop working earlier, and waste battery. If it was 5.9V that would be fine, to be on conservative side, but 0.3V different is not good.

Did you calculate the error percentage? 0.3V/6V=0.05, so 5%. I'd think your batteries will have more variance than this. I could be wrong, but it looks like a very minor issue.

If you think it's wrong, just ask @EEVblog?

73's,
Martin

[Scottjd]

I only have one 121gw to compare to, but mine hardly need any correction at all, 4V to 6.5V it is within 50mV if I bypass the correction in FW all together.

Two more meters to throw in the mix.
Both meters display the battery low icon at 4 volts. The accuracy seems to be further out the lower the batteries get, still I would consider the batteries dead at this point.

On meter 1
@ 6V displayed on the meter, I measured it at 6.080V
@ 4.0V displayed on the meter, I measured them at 4.331V

On meter 2
@ 6V displayed on the meter, I measured it at 6.027V
@ 4.0V on the meter, I measured them at 4.270V

[dcac]

I did some test with an hacked routine for the battery display. First optimizing the code considerably, so it's about 40 times faster now which allowed me to increase the oversampling and resolution - which now also is displayed. Pictures show the meter being powered from bench PSU, the Iso-Tech meter showing voltage at battery terminals, or close by as I was powering 121gw through the STlink - this is also why I didn't want to test above 5.5V. It is without any linearity correction at all, just a fix constant to calibrate for the divider error.

I mostly did this hack as I thought it would be cool to monitor the battery voltage more precisely.

@3.50V