EEVblog 121GW Multimeter Issues

[qft1967]

A thermocouple doesn't measure the absolute temperature, but only the temperature difference. (Keyword: Cold junction compensation) So in your case you would measure the temperature difference to its internal temperature of 19°C. If everything is in equilibrium that you should see 0mV!

This is not how thermocouples, or cold junction compensation works.

I suggest you read this as a primer.

Could you elaborate why you think that this is not true? I could suggest reading this paragraph: https://en.wikipedia.org/wiki/Thermocouple#Physical_principle:_Seebeck_effect
I just tried to put it in simple terms: With temperature difference I meant the integration of the temperature gradient from Tsense to Tref.

[beanflying]

Not that this is the place for a large discussion on K type thermocouples but the simple facts are they are not that accurate +-2C is about where they are at. Add to this the meter being used accuracy of another 0.5-1% and you have a 3C swing at 100C without anything being wrong. That is before you even get to cold junction compensation.

These are generalizations but K types are used with Meters because they are CHEAP and have a large temperature range and are fairly robust. 

If you want more accuracy then a quality 2 wire RTD 'might' be better but that is another can of worms for a dedicated thread.

[Brumby]

Indeed.  When I measure a temperature (for a heatsink, say) - whether it's 40ºC or 43ºC isn't a real concern.  I just need to know it's not in the vicinity of 60ºC or 80ºC.

If I was working in calorimetry, then things would be a bit different.

[bicycleguy]

...

I'm going away in a few days, so not sure when I'm going to have time to test this myself.
So might be best if I just attach it here and get feedback.
So consider this an internal not released try at your own risk if you dare firmware.
It fixes the resistance drift problem, i.e. 1M reading which slowly drifts down to the correct value over time, but only on the 2nd probing, it works fine after power-on and first measurement.

Also, time/date stamping has been added to the logging file.

The date/time stamp on the data is nice.  Too bad the resolution is only to the second.  At least you don't have to worry about the accumulated time error when using the O interval.  Here is a snippet of a sample at 0 (apparently .2 to .25 a second)

START   2020/01/04   17   42   9                         ID   170800121                                  INTERVAL   0   sec                                        MAIN         SUB-1         SUB-2         Remark No.    Date         Time       Func.    Value   Unit   Func.    Value   Unit   Func.    Value   Unit    1   2020/01/04   17   42   10   DCV   -0.0005   V                2   2020/01/04   17   42   10   DCV   0   V                3   2020/01/04   17   42   10   DCV   0.0003   V                4   2020/01/04   17   42   10   DCV   -0.0001   V                5   2020/01/04   17   42   10   DCV   -0.0005   V                6   2020/01/04   17   42   11   DCV   -0.0022   V                7   2020/01/04   17   42   11   DCV   0.0127   V                8   2020/01/04   17   42   11   DCV   0.002   V                9   2020/01/04   17   42   11   DCV   0   V                10   2020/01/04   17   42   11   DCV   0.0001   V                11   2020/01/04   17   42   12   DCV   0.0002   V                12   2020/01/04   17   42   12   DCV   -0.0001   V                13   2020/01/04   17   42   12   DCV   -0.0006   V                14   2020/01/04   17   42   12   DCV   0   V                15   2020/01/04   17   42   12   DCV   0.0004   V                16   2020/01/04   17   42   13   DCV   0.0001   V                17   2020/01/04   17   42   13   DCV   -0.0001   V                18   2020/01/04   17   42   13   DCV   -0.0012   V                19   2020/01/04   17   42   13   DCV   0   V                20   2020/01/04   17   42   13   DCV   -0.0008   V                21   2020/01/04   17   42   14   DCV   -0.0002   V                22   2020/01/04   17   42   14   DCV   0.001   V                23   2020/01/04   17   42   14   DCV   0.0078   V                24   2020/01/04   17   42   14   DCV   0.0033   V                25   2020/01/04   17   42   14   DCV   0.0006   V

[AVGresponding]

A thermocouple doesn't measure the absolute temperature, but only the temperature difference. (Keyword: Cold junction compensation) So in your case you would measure the temperature difference to its internal temperature of 19°C. If everything is in equilibrium that you should see 0mV!

This is not how thermocouples, or cold junction compensation works.

I suggest you read this as a primer.

Could you elaborate why you think that this is not true? I could suggest reading this paragraph: https://en.wikipedia.org/wiki/Thermocouple#Physical_principle:_Seebeck_effect
I just tried to put it in simple terms: With temperature difference I meant the integration of the temperature gradient from Tsense to Tref.

In the simplest terms, you imply that the measurement is between the point inside the meter and the point the thermocouple is attached to.

In fact, the measurement is derived from the difference in conductivity (simplified beyond belief) between the two metals in the thermocouple junction itself.

The cold junction compensation is a reference measurement, at as controlled a temperature as possible, and is in effect used as a kind of real time calibration constant for the external thermocouple itself. Allowing it to be at ambient temperature is the laziest way to use it, and provides for the least accurate implementation of the system (likely at least a partial cause of the inconsistency in the 121GW temperature readings).

[CDaniel]

The real issue is  that it can't be recalibrated ... for now . Internal temperature and external .
The thermocouple measurement is done measuring the cold junction ,  121GW can do it with the internal thermistor .

[afedorov]

Is it possible to disable APO beeping? The way it is implemented is very annoying.

[movax]

...

I'm going away in a few days, so not sure when I'm going to have time to test this myself.
So might be best if I just attach it here and get feedback.
So consider this an internal not released try at your own risk if you dare firmware.
It fixes the resistance drift problem, i.e. 1M reading which slowly drifts down to the correct value over time, but only on the 2nd probing, it works fine after power-on and first measurement.

Also, time/date stamping has been added to the logging file.

The date/time stamp on the data is nice.  Too bad the resolution is only to the second.  At least you don't have to worry about the accumulated time error when using the O interval.  Here is a snippet of a sample at 0 (apparently .2 to .25 a second)

START   2020/01/04   17   42   9                         ID   170800121                                  INTERVAL   0   sec                                        MAIN         SUB-1         SUB-2         Remark No.    Date         Time       Func.    Value   Unit   Func.    Value   Unit   Func.    Value   Unit    1   2020/01/04   17   42   10   DCV   -0.0005   V                2   2020/01/04   17   42   10   DCV   0   V                3   2020/01/04   17   42   10   DCV   0.0003   V                4   2020/01/04   17   42   10   DCV   -0.0001   V                5   2020/01/04   17   42   10   DCV   -0.0005   V                6   2020/01/04   17   42   11   DCV   -0.0022   V                7   2020/01/04   17   42   11   DCV   0.0127   V                8   2020/01/04   17   42   11   DCV   0.002   V                9   2020/01/04   17   42   11   DCV   0   V                10   2020/01/04   17   42   11   DCV   0.0001   V                11   2020/01/04   17   42   12   DCV   0.0002   V                12   2020/01/04   17   42   12   DCV   -0.0001   V                13   2020/01/04   17   42   12   DCV   -0.0006   V                14   2020/01/04   17   42   12   DCV   0   V                15   2020/01/04   17   42   12   DCV   0.0004   V                16   2020/01/04   17   42   13   DCV   0.0001   V                17   2020/01/04   17   42   13   DCV   -0.0001   V                18   2020/01/04   17   42   13   DCV   -0.0012   V                19   2020/01/04   17   42   13   DCV   0   V                20   2020/01/04   17   42   13   DCV   -0.0008   V                21   2020/01/04   17   42   14   DCV   -0.0002   V                22   2020/01/04   17   42   14   DCV   0.001   V                23   2020/01/04   17   42   14   DCV   0.0078   V                24   2020/01/04   17   42   14   DCV   0.0033   V                25   2020/01/04   17   42   14   DCV   0.0006   V

This timestamp format is horrible.

Interval says: 0 SEC. What does this even mean?

Date is in weird and BAD format. It should be in ISO-8601. Especially people in US will have issues with the current format, because it will interpret it as US format, and switch month and date. But even people in other places will have issues, because software will often assume that format with / in them, is US format, and do weird things.

Plus the H:M:S is for no good reason in 3 separate columns. Put it all in ISO-8601 format, or even better just seconds (to 0.01 sec accuracy) from the start of measurement. (no minutes, hours or anything like that).

It will be way easier for everybody: for the MCU, simpler to code, easier for the SD card (less data), easier for the people using excel / libreoffice, for the people using python, awk, gnuplot, whatever.

The lack of sub-second resolution is just a topping on the cake.

I didn't check reliability of the data logging yet with a new firmware. It was 100% of the time unreliable last time I checked. It will get stuck or get random corruptions EVERY single time I will do data logging.

I am testing 2.03 beta firmware now. I started data logging. I should know if it is somehow reliable in a day or two.

EDIT: Actually the format is SLIGHTLY better than what bicycle guy show. Here it is:

Code: [Select]

START,2020/02/02,01:20:24,
ID,170800000,
INTERVAL,001,sec,
,,,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Date      ,Time    ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,2020/02/02,01:20:25,DCVA,00012.4,mVA,DCV,01.1188,V,DCA,0011.10,mA,,
2,2020/02/02,01:20:26,DCVA,00012.4,mVA,DCV,01.1188,V,DCA,0011.10,mA,,
3,2020/02/02,01:20:27,DCVA,00012.4,mVA,DCV,01.1216,V,DCA,0011.10,mA,,
4,2020/02/02,01:20:28,DCVA,00012.4,mVA,DCV,01.1216,V,DCA,0011.13,mA,,
5,2020/02/02,01:20:29,DCVA,00012.4,mVA,DCV,01.1216,V,DCA,0011.13,mA,,
6,2020/02/02,01:20:30,DCVA,00012.4,mVA,DCV,01.1227,V,DCA,0011.13,mA,,
7,2020/02/02,01:20:31,DCVA,00012.4,mVA,DCV,01.1227,V,DCA,0011.13,mA,,
...

Still not perfect. It should use ISO-8601 format: 2020-02-02T01:20:31.3 (space for separator instead of T, both are fine).

And as before the Func column is fully redundant, and should not be present in data at all. Instead, it should be put in the column header once to show DCVA, DCV, DCA, and then be not be repeated in every row. This is silly.

[movax]

I just found another issue.

I had almost discharged battery that is at 4.711mV. Stable.

If I go to VDC range, it shows as 0.0047V. It sometimes shows 0.0048V. That is correct.

However, if I am in VDC range, and then switch to mVDC, it shows 4.400-4.550mV on the first reading, and on the second reading it snaps to the correct reading (4.711mV in this case).

It is repeatable. The first reading always reads about 5-8% lower than actual value. That is not great. The meter should never show the bad (out of spec) value.

I did test 5 other meters (all different models) and non is showing this erratic behavior.

[movax]

I'm going away in a few days, so not sure when I'm going to have time to test this myself.
So might be best if I just attach it here and get feedback.
So consider this an internal not released try at your own risk if you dare firmware.
It fixes the resistance drift problem, i.e. 1M reading which slowly drifts down to the correct value over time, but only on the 2nd probing, it works fine after power-on and first measurement.

Also, time/date stamping has been added to the logging file.

Did one day testing of a new firmware (2.03 beta), and data logging is still broken.

After 3900 data points logged (mVA mode, with 1 second interval; not 0 second), it stopped saving correct data.

Remaining 48000 data points, are just periodic repetition of about 11 point, and only differ at the last digit.



The same happens to voltage and current. After 3900 data points they become constants.

[e0ne199]

I'm going away in a few days, so not sure when I'm going to have time to test this myself.
So might be best if I just attach it here and get feedback.
So consider this an internal not released try at your own risk if you dare firmware.
It fixes the resistance drift problem, i.e. 1M reading which slowly drifts down to the correct value over time, but only on the 2nd probing, it works fine after power-on and first measurement.

Also, time/date stamping has been added to the logging file.

Did one day testing of a new firmware (2.03 beta), and data logging is still broken.

After 3900 data points logged (mVA mode, with 1 second interval; not 0 second), it stopped saving correct data.

Remaining 48000 data points, are just periodic repetition of about 11 point, and only differ at the last digit.

(Attachment Link)

The same happens to voltage and current. After 3900 data points they become constants.

everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs 

[EEVblog]

everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs 

It is being worked on. v2.03 did not address that bug at all

[Brumby]

everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs 

Software development follows the same fundamentals as most everything else....
 * Fast
 * Cheap
 * Quality
..... pick two.

This, at least, should ease fears for most:

It is being worked on. v2.03 did not address that bug at all

... but there will be some impatient souls who won't be happy.

[dcac]

everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs 

Software development follows the same fundamentals as most everything else....
 * Fast
 * Cheap
 * Quality
..... pick two.

This, at least, should ease fears for most:

It is being worked on. v2.03 did not address that bug at all

... but there will be some impatient souls who won't be happy.

I think all we can really ask for, is a message like that from Dave, that the problem has be recognized and a solution is being worked on. I know it's good enough for me anyway.

[Brumby]

Fair point.

I agree.

[jchw4]

I did try to use the new firmware twice. So there will be two posts.

I just installed new 2.03 beta firmware and attached it to the charging battery. Logging interval was 5 seconds (I actually needed data, it was not just a firmware test).
After two days I switched meter off by rotating the switch (I did not stop logging before switching it off).
Unfortunately I did not take the photo of the meter before switching off, but I think that the counter started with 4, which I believe means that the leading digit in number of records should be 4.

The SD card happened to contain corrupted file system. After Windows checked and fixed it, I found this (I skipped older files):

Code: [Select]

31.01.2020  21:57    <DIR>          FOUND.000
01.01.1601  03:00                 0 08240001.CSV
31.01.2020  10:30         1 190 258 20013001.CSV


FOUND.000 directory:

Code: [Select]

31.01.2020  21:57    <DIR>          .
31.01.2020  21:57    <DIR>          ..
31.01.2020  21:57            32 768 FILE0000.CHK
31.01.2020  21:57            32 768 FILE0001.CHK
31.01.2020  21:57            32 768 FILE0002.CHK
31.01.2020  21:57            32 768 FILE0003.CHK
31.01.2020  21:57            32 768 FILE0004.CHK
31.01.2020  21:57            32 768 FILE0005.CHK
31.01.2020  21:57            32 768 FILE0006.CHK
31.01.2020  21:57            32 768 FILE0007.CHK

All .CHK files contained only zeroes.

20013001.CSV looks OK, but contains only 24513 entries:

Code: [Select]

START,2020/01/30,00:22:27,
...
24513,2020/01/30,22:15:27,DCV,006.692,V,,,,,,,,


(5 seconds * 24513 entries) = 34 hours 2 minutes and 45 seconds.

22:15:27 - 00:22:27 = 21:53:00

That's strange. Where did the difference come from?

Probably from this:

Code: [Select]

$ perl -lne 'm#^\d+,(\d{4}/\d{2}/\d{2},\d{2}:\d{2}):\d{2},DCV,[\d\.+-]+,V,,,,,,,,# and print "$1"' 20013001.CSV  | sort | uniq -c | sort -n | awk '$1 != 12'
      4 2020/01/30,15:02
      7 2020/01/30,00:22
      8 2020/01/30,14:57
     11 2020/01/30,04:32
     11 2020/01/30,07:27
     11 2020/01/30,13:37
     11 2020/01/30,16:32
    453 2020/01/30,22:12
   1323 2020/01/30,22:17
   1764 2020/01/30,22:16
   1770 2020/01/30,22:15
   1776 2020/01/30,22:13
   1776 2020/01/30,22:14
$


The code above prints "minute" part from the line, calculates number of entries per minute (sort | uniq -c), sorts by the number of entries (sort -n) and filters out all minutes with 12 entries.

This way we have [2020/01/30,15:02] with 4 records, [2020/01/30,00:22] with 7 records and on up to [2020/01/30,22:13] and [2020/01/30,22:14] with 1776 records.

Here are some of the records:

Code: [Select]

$ egrep -B 1 -A 1 '^[0-9].*,(2020/01/30,15:02|2020/01/30,00:22|2020/01/30,14:57|2020/01/30,04:32|2020/01/30,07:27|2020/01/30,13:37|2020/01/30,16:32|2020/01/30,22:12|2020/01/30,22:17|2020/01/30,22:16|2020/01/30,22:15|2020/01/30,22:13|2020/01/30,22:14):' 20013001.CSV
No. ,Date      ,Time    ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,2020/01/30,00:22:28,DCV,006.579,V,,,,,,,,
2,2020/01/30,00:22:33,DCV,006.579,V,,,,,,,,
3,2020/01/30,00:22:38,DCV,006.580,V,,,,,,,,
4,2020/01/30,00:22:43,DCV,006.580,V,,,,,,,,
5,2020/01/30,00:22:48,DCV,006.578,V,,,,,,,,
6,2020/01/30,00:22:53,DCV,006.579,V,,,,,,,,
7,2020/01/30,00:22:58,DCV,006.580,V,,,,,,,,
8,2020/01/30,00:23:03,DCV,006.581,V,,,,,,,,
--
2995,2020/01/30,04:31:59,DCV,006.555,V,,,,,,,,
2996,2020/01/30,04:32:04,DCV,006.555,V,,,,,,,,
2997,2020/01/30,04:32:09,DCV,006.557,V,,,,,,,,
2998,2020/01/30,04:32:14,DCV,006.555,V,,,,,,,,
2999,2020/01/30,04:32:19,DCV,006.557,V,,,,,,,,
3000,2020/01/30,04:32:24,DCV,006.555,V,,,,,,,,
3001,2020/01/30,04:32:30,DCV,006.556,V,,,,,,,,
3002,2020/01/30,04:32:35,DCV,006.555,V,,,,,,,,
3003,2020/01/30,04:32:40,DCV,006.557,V,,,,,,,,
3004,2020/01/30,04:32:45,DCV,006.555,V,,,,,,,,
3005,2020/01/30,04:32:50,DCV,006.559,V,,,,,,,,
3006,2020/01/30,04:32:55,DCV,006.562,V,,,,,,,,
3007,2020/01/30,04:33:00,DCV,006.559,V,,,,,,,,
--
5094,2020/01/30,07:26:59,DCV,006.664,V,,,,,,,,
5095,2020/01/30,07:27:04,DCV,006.664,V,,,,,,,,
5096,2020/01/30,07:27:09,DCV,006.660,V,,,,,,,,
5097,2020/01/30,07:27:14,DCV,006.665,V,,,,,,,,
5098,2020/01/30,07:27:19,DCV,006.660,V,,,,,,,,
5099,2020/01/30,07:27:24,DCV,006.671,V,,,,,,,,
5100,2020/01/30,07:27:29,DCV,006.659,V,,,,,,,,
5101,2020/01/30,07:27:35,DCV,006.660,V,,,,,,,,
5102,2020/01/30,07:27:40,DCV,006.668,V,,,,,,,,
5103,2020/01/30,07:27:45,DCV,006.666,V,,,,,,,,
5104,2020/01/30,07:27:50,DCV,006.661,V,,,,,,,,
5105,2020/01/30,07:27:55,DCV,006.665,V,,,,,,,,
5106,2020/01/30,07:28:00,DCV,006.667,V,,,,,,,,
--
9533,2020/01/30,13:36:59,DCV,006.813,V,,,,,,,,
9534,2020/01/30,13:37:04,DCV,006.808,V,,,,,,,,
9535,2020/01/30,13:37:09,DCV,006.806,V,,,,,,,,
9536,2020/01/30,13:37:14,DCV,006.810,V,,,,,,,,
9537,2020/01/30,13:37:19,DCV,006.811,V,,,,,,,,
9538,2020/01/30,13:37:24,DCV,006.796,V,,,,,,,,
9539,2020/01/30,13:37:29,DCV,006.806,V,,,,,,,,
9540,2020/01/30,13:37:34,DCV,006.816,V,,,,,,,,
9541,2020/01/30,13:37:40,DCV,006.802,V,,,,,,,,
9542,2020/01/30,13:37:45,DCV,006.810,V,,,,,,,,
9543,2020/01/30,13:37:50,DCV,006.816,V,,,,,,,,
9544,2020/01/30,13:37:55,DCV,006.806,V,,,,,,,,
9545,2020/01/30,13:38:00,DCV,006.809,V,,,,,,,,
--
10492,2020/01/30,14:56:55,DCV,006.827,V,,,,,,,,
10493,2020/01/30,14:57:00,DCV,006.820,V,,,,,,,,
10494,2020/01/30,14:57:05,DCV,006.809,V,,,,,,,,
10495,2020/01/30,14:57:10,DCV,006.808,V,,,,,,,,
10496,2020/01/30,14:57:15,DCV,006.819,V,,,,,,,,
10497,2020/01/30,14:57:20,DCV,006.818,V,,,,,,,,
10498,2020/01/30,14:57:25,DCV,006.815,V,,,,,,,,
10499,2020/01/30,14:57:30,DCV,006.818,V,,,,,,,,
10500,2020/01/30,14:57:35,DCV,006.808,V,,,,,,,,
10501,2020/01/30,15:02:43,DCV,006.824,V,,,,,,,,
10502,2020/01/30,15:02:48,DCV,006.828,V,,,,,,,,
10503,2020/01/30,15:02:53,DCV,006.825,V,,,,,,,,
10504,2020/01/30,15:02:58,DCV,006.819,V,,,,,,,,
...
18397,2020/01/30,22:15:47,DCV,006.692,V,,,,,,,,
18398,2020/01/30,22:15:52,DCV,006.693,V,,,,,,,,
18399,2020/01/30,22:15:57,DCV,006.692,V,,,,,,,,
18400,2020/01/30,22:16:02,DCV,006.692,V,,,,,,,,
18401,2020/01/30,22:16:07,DCV,006.692,V,,,,,,,,
18402,2020/01/30,22:16:12,DCV,006.693,V,,,,,,,,
18403,2020/01/30,22:16:17,DCV,006.693,V,,,,,,,,
18404,2020/01/30,22:16:22,DCV,006.693,V,,,,,,,,
18405,2020/01/30,22:16:27,DCV,006.692,V,,,,,,,,
18406,2020/01/30,22:16:32,DCV,006.694,V,,,,,,,,
18407,2020/01/30,22:16:37,DCV,006.692,V,,,,,,,,
18408,2020/01/30,22:16:42,DCV,006.693,V,,,,,,,,
18409,2020/01/30,22:16:47,DCV,006.693,V,,,,,,,,
18410,2020/01/30,22:16:52,DCV,006.692,V,,,,,,,,
18411,2020/01/30,22:16:57,DCV,006.692,V,,,,,,,,
18412,2020/01/30,22:17:02,DCV,006.693,V,,,,,,,,
18413,2020/01/30,22:17:07,DCV,006.693,V,,,,,,,,
18414,2020/01/30,22:17:12,DCV,006.695,V,,,,,,,,
18415,2020/01/30,22:17:17,DCV,006.694,V,,,,,,,,
18416,2020/01/30,22:17:22,DCV,006.693,V,,,,,,,,
18417,2020/01/30,22:17:27,DCV,006.693,V,,,,,,,,
18418,2020/01/30,22:17:32,DCV,006.689,V,,,,,,,,
18419,2020/01/30,22:17:37,DCV,006.690,V,,,,,,,,
18420,2020/01/30,22:17:42,DCV,006.691,V,,,,,,,,
18421,2020/01/30,22:12:47,DCV,006.692,V,,,,,,,,
18422,2020/01/30,22:12:52,DCV,006.692,V,,,,,,,,
18423,2020/01/30,22:12:57,DCV,006.691,V,,,,,,,,
18424,2020/01/30,22:13:02,DCV,006.691,V,,,,,,,,
18425,2020/01/30,22:13:07,DCV,006.690,V,,,,,,,,
18426,2020/01/30,22:13:12,DCV,006.690,V,,,,,,,,
18427,2020/01/30,22:13:17,DCV,006.688,V,,,,,,,,
18428,2020/01/30,22:13:22,DCV,006.686,V,,,,,,,,
18429,2020/01/30,22:13:27,DCV,006.688,V,,,,,,,,
18430,2020/01/30,22:13:32,DCV,006.689,V,,,,,,,,
18431,2020/01/30,22:13:37,DCV,006.691,V,,,,,,,,
18432,2020/01/30,22:13:42,DCV,006.689,V,,,,,,,,
18433,2020/01/30,22:13:47,DCV,006.689,V,,,,,,,,
18434,2020/01/30,22:13:52,DCV,006.687,V,,,,,,,,
18435,2020/01/30,22:13:57,DCV,006.688,V,,,,,,,,
18436,2020/01/30,22:14:02,DCV,006.688,V,,,,,,,,
18437,2020/01/30,22:14:07,DCV,006.686,V,,,,,,,,
18438,2020/01/30,22:14:12,DCV,006.688,V,,,,,,,,
18439,2020/01/30,22:14:17,DCV,006.689,V,,,,,,,,
18440,2020/01/30,22:14:22,DCV,006.688,V,,,,,,,,
18441,2020/01/30,22:14:27,DCV,006.689,V,,,,,,,,
18442,2020/01/30,22:14:32,DCV,006.689,V,,,,,,,,
18443,2020/01/30,22:14:37,DCV,006.690,V,,,,,,,,
18444,2020/01/30,22:14:42,DCV,006.691,V,,,,,,,,
18445,2020/01/30,22:14:47,DCV,006.691,V,,,,,,,,
18446,2020/01/30,22:14:52,DCV,006.691,V,,,,,,,,
18447,2020/01/30,22:14:57,DCV,006.693,V,,,,,,,,
18448,2020/01/30,22:15:02,DCV,006.693,V,,,,,,,,
18449,2020/01/30,22:15:07,DCV,006.691,V,,,,,,,,
18450,2020/01/30,22:15:12,DCV,006.693,V,,,,,,,,
18451,2020/01/30,22:15:17,DCV,006.693,V,,,,,,,,
18452,2020/01/30,22:15:22,DCV,006.693,V,,,,,,,,
18453,2020/01/30,22:15:27,DCV,006.692,V,,,,,,,,
18454,2020/01/30,22:15:32,DCV,006.691,V,,,,,,,,
18455,2020/01/30,22:15:37,DCV,006.690,V,,,,,,,,
18456,2020/01/30,22:15:42,DCV,006.692,V,,,,,,,,
18457,2020/01/30,22:15:47,DCV,006.692,V,,,,,,,,
18458,2020/01/30,22:15:52,DCV,006.693,V,,,,,,,,
18459,2020/01/30,22:15:57,DCV,006.692,V,,,,,,,,
18460,2020/01/30,22:16:02,DCV,006.692,V,,,,,,,,
...


(... - means I  manually removed lines from the output)


So basically the longer the logging was on, the more garbage is in the output. See how 22:15 was followed by 22:16, 22:17, and then again 22:12, 22:13, 22:14, 22:15, 22:16 ...

File is attached.

[jchw4]

Unfortunately I did not do the full analysis of the data immediately after the first attempt.
I thought that the meter logged less than a day of data and all the other data was lost in file system corruption.
I actually looked at the data only when writing the previous post.

So I thought that the meter probably corrupts file system after a day of logging, and decided to repeat my previous test from the https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856.

As this time I was looking into the "stuck data" issue, I set logging interval to 0 and stopped after 7 hours.
I draw graph of data and did not see that issue.

I did not pay attention to the data then. But now after my previous post, I see the same issue:

Code: [Select]

START,2020/02/01,02:15:47,
ID,170800000,
INTERVAL,000,sec,
,,,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Date      ,Time    ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,2020/02/01,02:15:48,DCV,007.793,V,,,,,,,,
...
130518,2020/02/01,04:12:27,DCV,007.661,V,,,,,,,,
MAX,33241,DCV,009.202,V,
MIN,3362,DCV,003.239,V,

While (130518 / (5 recors per second)) = 7.251 hours, which matched file modification timestamp:

Code: [Select]

01.02.2020  09:39         6 415 024 20020100.CSV

and not 04:12:27 as reported by the meter.

This time I also turned off logging before switching off meter, and I got no file system corruption.

So I decided to leave the meter on for more than a day to check the corruption.

To my surprise, as some point the meter started screaming with "SDfull" message.    Luckily I was next to it at that moment! 

I turned it off expecting another corrupted file system. (How else could it fill up 8Gb card?)

To my surprise, file system was OK. And there were plenty of space left.
But the file:

Code: [Select]

02.02.2020  19:39        29 889 125 20020102.CSV

ended with 60 000 entries:

Code: [Select]

START,2020/02/01,09:49:15,
ID,170800000,
INTERVAL,000,sec,
,,,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Date      ,Time    ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,2020/02/01,09:49:15,DCV,008.407,V,,,,,,,,
...
600000,2020/02/01,16:09:28,DCV,008.952,V,,,,,,,,
MAX,73741,DCV,009.224,V,
MIN,17209,DCV,003.251,V,

So it seems that the meter is (now?) limited to 60000 consequent records. I was expecting it to create new files as needed...


Probably no need to attach these files.

[jchw4]

I should probably mention what I think about new logging format.

Now about 50% of the file is occupied by timestamps. This not only wastes space, but also takes more time to generate and store data.

I would personally prefer time_t https://en.wikibooks.org/wiki/C_Programming/time.h/time_t as floating point number.
It is way more compact, much simpler to generate and parse (unless you are using speadsheets, but all the popular variants have conversion routines).

In my opinion it is much better even if they always assume the meter to be in UTC time zone, because it probably does not matter too much.

[jolshefsky]

For what it's worth, I'm an idiot.

I suddenly started noticing out-of-specification DC voltage readings—a 9V battery would read 10.5 volts or so then drift all around.

As it turns out, the batteries were at 3.6V. I didn't realize the icon in the display is actually supposed to be a battery. I thought it was indicating some kind of positive/negative mode because I read it as "+-".

So in case someone else is also an idiot, perhaps they'll find this post.

[dlow]

UPDATE:
The issue with the cracked input jacks is as several suspected, a molding issue.

input jacks which were injected from the uncompletely-cleared mould probably resulting in for ABS mixed with any foreign materials so the injected jacks could be more easily broken.

Units potentially affected are with serial numbers S/N 18087001 to 181008000
The sockets for these were manually inspected for this issue but it seems that some slipped passed the inspection and have resulted in cracking.

They also mention the Brymen leads are not ideal:

2. Our input jacks were designed to be ideally matched with our test lead probe with 4.2 - 4.3 phi.  However, Brymen's probe has 4.5 - 5.0 phi, which can give more mechanical stresses to our input jacks.

"Phi" means diameter of the banana plug.
I'm not sure about their measurements because I measured the Brymen at 4.3mm or a smidge over. The UEi ones are spot on 4mm and not the lantern type ones the Brymen use.
They aren't saying don't use the Brymen leads, just that could be a contributing factor in this case. Welectron have been supplying Brymen leads.
My new stock of meters will all come with UEi leads.

They will be sending me a bunch of replacement jacks so I can send to people who want that option.
If you have been affected by this and prefer to replace it yourself, please email me your address so I can send you one. Use the email Title "121GW Connector"
Alternatively you send your meter back to UEi at this address. I'm not sure if they will rework or replace the meter or board.

Attn: (Mr.) Heegoo Kang
Tel: 82-32-837-5777
309, A-dong, Smart Valley,
Songdomirae-ro 30, Yeonsu-gu, Incheon,
21990, Korea

Email sent. Thanks Dave!

Unfortunately, despite numerous emails, I've never heard back from Dave's representative on this matter. My meter is completely unusable and has been since November. If anyone knows of a way to repair the meter or better, replace the jacks, please let me know. Otherwise, I guess I'll be paying out the nose in shipping and brushing up on my Korean if I ever hope to get it functional again.

[EEVblog]

UPDATE:
The SD card logging issue has been resolved, although I have not tested it myself yet, it just came through.
v2.04 is attached.

ST Micom recommended our team to use their library in order to send every 60 data packet stored in the EEPROM built-in the ST micom to the SD card.  We found this issue is caused by our using this library. We solved this issue by sending every 60 data packet stored in the RAM, instead of the EEPROM, built-in the ST micom to the SD card.

So it seems it was an issue with the ST micro SD card library.
IIRC they used to use their own driver, but then switched to the ST driver a suggested, so maybe this issue wasn't present on some much older version perhaps.

[beanflying]

That is interesting and I hadn't seen any glitches in the logs I collected during testing and playing with it initially or with some of the later firmware (generally I don't use the 121GW for that much due to other gear available). Most recent version I have loaded is 1.58 so the logging would have that or earlier so maybe time I upgraded as one of my pet hates the time base has been fixed too and have another play

[mpallewa]

F/W ver 2.02. The current shown in the VA mode is incorrect. See attached image for details.

With the same source and the load the 121GW on the left which is in the VA mode is showing 4.8208mA and the one on the right which is in the A mode is showing 10.415mA (correct value verified with a Fluke 287).

Please investigate this. Mux-ed ADC issue ?.

[EEVblog]

F/W ver 2.02. The current shown in the VA mode is incorrect. See attached image for details.
With the same source and the load the 121GW on the left which is in the VA mode is showing 4.8208mA and the one on the right which is in the A mode is showing 10.415mA (correct value verified with a Fluke 287).
Please investigate this. Mux-ed ADC issue ?.

Can you please provide a diagram of how the entire system is wired up, it is not clear from the photo.

[EEVblog]

That is interesting and I hadn't seen any glitches in the logs I collected during testing and playing with it initially or with some of the later firmware (generally I don't use the 121GW for that much due to other gear available).

It was an intermittent problem, didn't always show up.