Author Topic: EEVblog 121GW Multimeter Issues  (Read 670085 times)

0 Members and 2 Guests are viewing this topic.

Offline mpallewa

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog 121GW Multimeter Issues
« Reply #1150 on: February 10, 2020, 09:28:42 am »
Diagram attached. The power source is a Li-ion battery with a voltage of approx 3.945 volts.
 

Offline e0ne199

  • Regular Contributor
  • *
  • Posts: 131
  • Country: id
Re: EEVblog 121GW Multimeter Issues
« Reply #1151 on: February 10, 2020, 02:21:53 pm »
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.

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

how about bargraph bug in VA mode? is it also solved too?
anyway UEi should take a look at VA mode measurement bugs too because there are lots of people talking about that here
« Last Edit: February 10, 2020, 02:25:38 pm by e0ne199 »
 

Offline dcac

  • Frequent Contributor
  • **
  • Posts: 336
Re: EEVblog 121GW Multimeter Issues
« Reply #1152 on: February 10, 2020, 05:07:47 pm »
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.

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


Thanks Dave! I was suspecting the problem was something like that, i.e. based on twp_rules comment about buffering samples in the EEprom:
Quote
The only functionality storing samples in EEPROM (as opposed to RAM) has given the firmware is (seemingly) the ability to play back the last 60 samples of the most recent logging session even after the meter has been restarted. Other than that, it's damaging to the ROM and probably pretty power-hungry. Why did they do it this way?

IMHO twp_rules did an amazing job disassembling the 1.02 FW and I've been using this as an template to disassemble the more recent FW's.

I did try an hack that used RAM buffer instead, it's a good thing the STM32 has allot of unused RAM. But even though this hack seemed to solve the repeating samples issue there was still some stalling every 60 samples when the the buffer gets translated to plain text and stored on the SD card. This stalling could be up to 10-14 sec during longer logging sessions and during this time incoming samples are simply lost. This issue could perhaps be dependent on the type of SD card used, I used the original that came with the meter. I will be interesting to test if V2.04 also have an affect on this.

 
 

Offline jchw4

  • Regular Contributor
  • *
  • Posts: 188
  • Country: 00
Re: EEVblog 121GW Multimeter Issues
« Reply #1153 on: February 23, 2020, 06:22:17 am »
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 on 2.04.

In short: it is MUCH better now.
I was surprised to find the meter shut off the next day. It seems that it now silently stops logging after reaching 600 000 entries. And them shuts down on Automatic Power-Off feature. Which is better than beeping, but does not help logging data.

There was still one block of zeroes though:
Code: [Select]
$ grep -a -B 1 -A 1 '^133619,2020' 20021500.CSV | xxd
00000000: 3133 3336 3138 2c32 3032 302f 3032 2f31  133618,2020/02/1
00000010: 362c 3034 3a35 303a 3533 2c44 4356 2c30  6,04:50:53,DCV,0
00000020: 3039 2e30 3835 2c56 2c2c 2c2c 2c2c 2c2c  09.085,V,,,,,,,,
00000030: 0d0a 3133 3336 3139 2c32 3032 3000 0000  ..133619,2020...
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 3133 3336 3231 2c32 3032  ......133621,202
000000a0: 302f 3032 2f31 362c 3034 3a35 303a 3534  0/02/16,04:50:54
000000b0: 2c44 4356 2c30 3039 2e30 3936 2c56 2c2c  ,DCV,009.096,V,,
000000c0: 2c2c 2c2c 2c2c 0d0a 3133 3336 3232 2c32  ,,,,,,..133622,2
000000d0: 3032 302f 3032 2f31 362c 3034 3a35 303a  020/02/16,04:50:
000000e0: 3534 2c44 4356 2c30 3039 2e31 3036 2c56  54,DCV,009.106,V
000000f0: 2c2c 2c2c 2c2c 2c2c 0d0a                 ,,,,,,,,..


As it has got much better, let's look at smaller issues that were not that important before (but already reported by users above).

Meter still gets stuck for a few seconds. Let's see how often this happened:
Code: [Select]
      1 -59
     13 2
    365 3
      1 4
     41 5
     14 7
      1 9
      2 10
      3 11
      1 13
      4 15
      3 16
      8 17
     20 18
      3 19
      1 21
      1 60


The second column is difference between two adjacent entries in the file (-59 seconds, 2 seconds, 3 seconds, ..., 60 seconds), the first column is number of occurrences of this interval.
Here are the largest ones:
Code: [Select]
26271,2020/02/15,22:46:57,DCV,009.319,V,,,,,,,,
26272,2020/02/15,22:46:58,DCV,009.319,V,,,,,,,,
26273,2020/02/15,22:46:58,DCV,009.319,V,,,,,,,,
26274,2020/02/15,22:46:58,DCV,009.318,V,,,,,,,,
26275,2020/02/15,22:46:58,DCV,009.319,V,,,,,,,,
26276,2020/02/15,22:46:58,DCV,009.318,V,,,,,,,,
26277,2020/02/15,22:46:59,DCV,009.318,V,,,,,,,,
26278,2020/02/15,22:46:59,DCV,009.318,V,,,,,,,,
26279,2020/02/15,22:46:59,DCV,003.392,V,,,,,,,,
26280,2020/02/15,22:46:59,DCV,003.514,V,,,,,,,,
26281,2020/02/15,22:46:00,DCV,003.704,V,,,,,,,,
26282,2020/02/15,22:47:00,DCV,003.818,V,,,,,,,,
26283,2020/02/15,22:47:00,DCV,003.860,V,,,,,,,,
26284,2020/02/15,22:47:00,DCV,003.972,V,,,,,,,,
26285,2020/02/15,22:47:00,DCV,004.013,V,,,,,,,,
26286,2020/02/15,22:47:00,DCV,004.122,V,,,,,,,,
26287,2020/02/15,22:47:01,DCV,004.332,V,,,,,,,,
26288,2020/02/15,22:47:01,DCV,004.383,V,,,,,,,,
26289,2020/02/15,22:47:01,DCV,004.484,V,,,,,,,,
26290,2020/02/15,22:47:01,DCV,004.532,V,,,,,,,,
26291,2020/02/15,22:47:01,DCV,004.630,V,,,,,,,,
26292,2020/02/15,22:47:02,DCV,004.808,V,,,,,,,,
--
74691,2020/02/16,01:30:29,DCV,007.065,V,,,,,,,,
74692,2020/02/16,01:30:30,DCV,007.140,V,,,,,,,,
74693,2020/02/16,01:30:30,DCV,007.185,V,,,,,,,,
74694,2020/02/16,01:30:30,DCV,007.200,V,,,,,,,,
74695,2020/02/16,01:30:30,DCV,007.243,V,,,,,,,,
74696,2020/02/16,01:30:30,DCV,007.259,V,,,,,,,,
74697,2020/02/16,01:30:31,DCV,007.344,V,,,,,,,,
74698,2020/02/16,01:30:31,DCV,007.384,V,,,,,,,,
74699,2020/02/16,01:30:31,DCV,007.398,V,,,,,,,,
74700,2020/02/16,01:30:31,DCV,007.437,V,,,,,,,,
74701,2020/02/16,01:30:50,DCV,009.029,V,,,,,,,,
74702,2020/02/16,01:30:50,DCV,009.031,V,,,,,,,,
74703,2020/02/16,01:30:50,DCV,009.036,V,,,,,,,,
74704,2020/02/16,01:30:50,DCV,009.041,V,,,,,,,,
74705,2020/02/16,01:30:50,DCV,009.047,V,,,,,,,,
74706,2020/02/16,01:30:50,DCV,009.048,V,,,,,,,,
74707,2020/02/16,01:30:51,DCV,009.054,V,,,,,,,,
74708,2020/02/16,01:30:51,DCV,009.059,V,,,,,,,,
74709,2020/02/16,01:30:51,DCV,009.062,V,,,,,,,,
74710,2020/02/16,01:30:51,DCV,009.068,V,,,,,,,,
74711,2020/02/16,01:30:51,DCV,009.072,V,,,,,,,,
--
94311,2020/02/16,02:37:30,DCV,009.019,V,,,,,,,,
94312,2020/02/16,02:37:30,DCV,009.023,V,,,,,,,,
94313,2020/02/16,02:37:30,DCV,009.029,V,,,,,,,,
94314,2020/02/16,02:37:30,DCV,009.034,V,,,,,,,,
94315,2020/02/16,02:37:30,DCV,009.038,V,,,,,,,,
94316,2020/02/16,02:37:31,DCV,009.049,V,,,,,,,,
94317,2020/02/16,02:37:31,DCV,009.052,V,,,,,,,,
94318,2020/02/16,02:37:31,DCV,009.057,V,,,,,,,,
94319,2020/02/16,02:37:31,DCV,009.063,V,,,,,,,,
94320,2020/02/16,02:37:31,DCV,009.065,V,,,,,,,,
94321,2020/02/16,02:37:50,DCV,009.282,V,,,,,,,,
94322,2020/02/16,02:37:50,DCV,009.282,V,,,,,,,,
94323,2020/02/16,02:37:50,DCV,009.283,V,,,,,,,,
94324,2020/02/16,02:37:50,DCV,009.284,V,,,,,,,,
94325,2020/02/16,02:37:50,DCV,009.285,V,,,,,,,,
94326,2020/02/16,02:37:51,DCV,009.286,V,,,,,,,,
94327,2020/02/16,02:37:51,DCV,009.287,V,,,,,,,,
94328,2020/02/16,02:37:51,DCV,009.287,V,,,,,,,,
94329,2020/02/16,02:37:51,DCV,009.287,V,,,,,,,,
94330,2020/02/16,02:37:51,DCV,009.288,V,,,,,,,,
94331,2020/02/16,02:37:52,DCV,009.288,V,,,,,,,,
--
205971,2020/02/16,08:59:08,DCV,008.884,V,,,,,,,,
205972,2020/02/16,08:59:08,DCV,008.889,V,,,,,,,,
205973,2020/02/16,08:59:08,DCV,008.898,V,,,,,,,,
205974,2020/02/16,08:59:08,DCV,008.902,V,,,,,,,,
205975,2020/02/16,08:59:08,DCV,008.912,V,,,,,,,,
205976,2020/02/16,08:59:09,DCV,008.922,V,,,,,,,,
205977,2020/02/16,08:59:09,DCV,008.931,V,,,,,,,,
205978,2020/02/16,08:59:09,DCV,008.939,V,,,,,,,,
205979,2020/02/16,08:59:09,DCV,008.942,V,,,,,,,,
205980,2020/02/16,08:59:09,DCV,008.950,V,,,,,,,,
205981,2020/02/16,08:59:28,DCV,009.262,V,,,,,,,,
205982,2020/02/16,08:59:28,DCV,009.262,V,,,,,,,,
205983,2020/02/16,08:59:28,DCV,009.263,V,,,,,,,,
205984,2020/02/16,08:59:28,DCV,009.264,V,,,,,,,,
205985,2020/02/16,08:59:28,DCV,009.265,V,,,,,,,,
205986,2020/02/16,08:59:29,DCV,009.267,V,,,,,,,,
205987,2020/02/16,08:59:29,DCV,009.268,V,,,,,,,,
205988,2020/02/16,08:59:29,DCV,009.268,V,,,,,,,,
205989,2020/02/16,08:59:29,DCV,009.269,V,,,,,,,,
205990,2020/02/16,08:59:29,DCV,009.271,V,,,,,,,,
205991,2020/02/16,08:59:30,DCV,009.271,V,,,,,,,,
--
350031,2020/02/16,17:06:05,DCV,009.226,V,,,,,,,,
350032,2020/02/16,17:06:06,DCV,009.230,V,,,,,,,,
350033,2020/02/16,17:06:06,DCV,009.231,V,,,,,,,,
350034,2020/02/16,17:06:06,DCV,009.233,V,,,,,,,,
350035,2020/02/16,17:06:06,DCV,009.234,V,,,,,,,,
350036,2020/02/16,17:06:06,DCV,009.235,V,,,,,,,,
350037,2020/02/16,17:06:07,DCV,009.239,V,,,,,,,,
350038,2020/02/16,17:06:07,DCV,009.240,V,,,,,,,,
350039,2020/02/16,17:06:07,DCV,009.240,V,,,,,,,,
350040,2020/02/16,17:06:07,DCV,009.241,V,,,,,,,,
350041,2020/02/16,17:06:28,DCV,009.328,V,,,,,,,,
350042,2020/02/16,17:06:28,DCV,009.309,V,,,,,,,,
350043,2020/02/16,17:06:28,DCV,009.309,V,,,,,,,,
350044,2020/02/16,17:06:28,DCV,009.309,V,,,,,,,,
350045,2020/02/16,17:06:28,DCV,009.309,V,,,,,,,,
350046,2020/02/16,17:06:28,DCV,009.310,V,,,,,,,,
350047,2020/02/16,17:06:29,DCV,009.310,V,,,,,,,,
350048,2020/02/16,17:06:29,DCV,009.310,V,,,,,,,,
350049,2020/02/16,17:06:29,DCV,009.311,V,,,,,,,,
350050,2020/02/16,17:06:29,DCV,009.310,V,,,,,,,,
350051,2020/02/16,17:06:29,DCV,009.310,V,,,,,,,,


The first one looks like a bug in time printing code (human-readable is hard and slow, could we get UNIX time instead?).
Other issues are definitely lost data.

File is attached. It has less than 600 000 entries because I turned it off manually. I had prior (failed) attempt to do logging test that showed me that 600 000 is still the limit.

 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog 121GW Multimeter Issues
« Reply #1154 on: February 23, 2020, 11:19:48 am »
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 on 2.04.
In short: it is MUCH better now.
I was surprised to find the meter shut off the next day. It seems that it now silently stops logging after reaching 600 000 entries.

I do recall there being a hard limit on the logging length for some reason. 600,000 rings a bell.
 

Offline wizard69

  • Super Contributor
  • ***
  • Posts: 1175
  • Country: us
Re: EEVblog 121GW Multimeter Issues
« Reply #1155 on: February 24, 2020, 12:50:00 pm »
...

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.

While the time stamp could use some work having just the seconds from the start of sampling is NOT acceptable.    As for the ISO formats, like a lot of stuff from the ISO it is either not well thought out or very European centric.    Personally I'd rather see the CSV expressed in a way that easily allows the transfer of data to the widest array of software possible with the least amount of effort.   Maybe ISO-8601 is the right path I just haven't put a lot of thought into it and how it impacts various bits of software that one might want to use.   I guess it depend upon how you want ot process the data, but having time as a separate field can certainly simplify that.  This might be why you suggested time elapsed since the start of the sample.

As for the Func you are certainly right there but I'd take it a bit farther and wonder why we have a Units column.   If we have a column defined as DC amps for example, and that number is a floating point number do we really need units?    Is the range the meter is set upon that important to the data?   I suppose if you want a fixed width for the value it is important but I'm not sure that even makes sense.

I'd also reconsider the record number.   It does have uses but in most instance I doubt it would ever be used.

In any event in either case I'm thinking about how you process the data and frankly don't really care about the human reading the raw data.   It should be easy to pull the data into a spread sheet, a charting/graphing program or a Python script.     Basically in any way that a user would want to massage the data, be it a FORTRAN program or an Excel Graph or whatever.

The other thing here is that we appear to be wasting lots of memory if this data is being stored as CSV in the meter itself.  We could be talking close to 50% waste.   
 

Offline dcac

  • Frequent Contributor
  • **
  • Posts: 336
Re: EEVblog 121GW Multimeter Issues
« Reply #1156 on: February 24, 2020, 07:35:22 pm »
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 on 2.04.
In short: it is MUCH better now.
I was surprised to find the meter shut off the next day. It seems that it now silently stops logging after reaching 600 000 entries.

I do recall there being a hard limit on the logging length for some reason. 600,000 rings a bell.

Yes logging is limited to 600k samples and this limit been there at least since fw 1.02.

I wonder why that number was chosen, it doesn’t seem to relate to any file size or anything like that I can find.
 

Offline dcac

  • Frequent Contributor
  • **
  • Posts: 336
Re: EEVblog 121GW Multimeter Issues
« Reply #1157 on: February 24, 2020, 10:19:14 pm »
Each sample uses 24 bytes in the meters log buffer in a “packed format", so yeah it could be argued to just save those bytes to a 'bin’ file and skip the whole plain text translation to csv. That csv information is not used or really accessible by the meter anyway.

So even in when logging just one value i.e. DCmV that takes about 50 bytes in csv form per sample you’d already saved move than 100% of data needed to be stored on the SD card. Drawback is of course an external translation program have to be used to generate the csv.

Messing with the disassembled FW I must say I’ve never seen so many inefficient routines in code made for a MCU. But still not that inefficient that it really can explain the (random?) stalling when logging at max. But cutting down the data needed to be saved to SD would likely help allot.

Further enhancement could be to implement BT transfer of the bin files, so no need to pull out the SD card. This probably is feasible at least for smaller files at the relatively low speeds BLE allows for. I seriously doubt though UEi would even consider spending time on this and the bug tracing that follows.

 

Offline mart1n

  • Contributor
  • Posts: 22
  • Country: us
Re: EEVblog 121GW Multimeter Issues
« Reply #1158 on: February 24, 2020, 11:50:16 pm »

I'm strongly considering purchasing one of these and have a couple questions for you fine folks...

1. What are the current outstanding issues (firmware v2.04)?
1.1 Is there an issue tracker anywhere? I searched and couldn't find one.

2. Is the official firmware open source? I found a repo on github for unofficial firmware and official bluetooth apps, etc...but couldn't find anything for the official firmware.

Thanks!
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: EEVblog 121GW Multimeter Issues
« Reply #1159 on: February 25, 2020, 04:56:57 am »
This one I can answer....
2. Is the official firmware open source? I found a repo on github for unofficial firmware and official bluetooth apps, etc...but couldn't find anything for the official firmware.
No.  The official firmware is proprietary.

The reason given is that there are some "secret sauce" routines that UEI consider commercially valuable.  These would have been developed for their own use and would have been a significant investment - and they are not prepared to make those known to the world.
 
The following users thanked this post: movax

Offline Fenton Bresler

  • Supporter
  • ****
  • Posts: 6
  • Country: be
Re: EEVblog 121GW Multimeter Issues
« Reply #1160 on: February 25, 2020, 12:34:39 pm »
Boll*cks, looks like I got a dodgy unit with naff connectors. One of them has split after barely any use. :(

Ordered from Welectron.

Waiting to hear back from them.
 

Offline jchw4

  • Regular Contributor
  • *
  • Posts: 188
  • Country: 00
Re: EEVblog 121GW Multimeter Issues
« Reply #1161 on: February 26, 2020, 07:28:02 am »
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 on 2.04.
In short: it is MUCH better now.
I was surprised to find the meter shut off the next day. It seems that it now silently stops logging after reaching 600 000 entries.

I do recall there being a hard limit on the logging length for some reason. 600,000 rings a bell.

It would be nice if this was included in the manual.
 

Offline dcac

  • Frequent Contributor
  • **
  • Posts: 336
Re: EEVblog 121GW Multimeter Issues
« Reply #1162 on: March 06, 2020, 03:48:13 pm »
Perhaps the manual also should be updated with the capacitance calibration procedure that I posted in Joe's thread:


I can't recalibrate ... for some reason using a 10nF like in instructions result in 0.000nF readings in this range for any cap , so the only option is to reload the saved calibration . Maybe it's a bug , I tried many times even with different values , I don't think I did something wrong  :-//

Also pay attention if you try to re-calibrate the capacitance ranges.
There is no entry for zero value calibration in the small table inside the chapter ZERO OFFSET CALIBRATION.
In the big colored table, though, there is a scrambled entry, 'R1 : ', which might indicate that the first calibration point with open leads sets the offset, and the 2nd one with the nominal reference capacitor sets the gain.
That might explain CDaniels problem, that 0.000 is displayed for a 10nF capacitor, after calibration.

Frank

I'm not sure if the capacitance calibration procedure ever been properly documented, I can't find it anyway, but here is what worked for me:

First make sure you saved current calibration to the SD card.

Then you need a 1nF, 10nF and a 100nF reference cap.

Enter calibration mode, select lowest cap range and connect a 1nF cap, meter will display a value probably somewhat less than 1nF, press Setup to perform offset cal, after count down meter will still display an offset value. Now change the 1nF to a 10nF cap, press Mem to perform gain cal, after count down meter will store both offset and gain calibration and should now display 10nF.

Select next cap range and repeat the procedure but using 10nF to start with and then change it to 100nF.     

The rest of the cap ranges only seem to have gain calibration and if needed use the values from the table in the manual.

Also this procedure is probably only valid for FW 1.57 and up.


And just to further explain, 121gw uses this procedure because especially D13 (TVS diode) can cause a 'negative' capacitance offset, so 1nF/10nF is simply needed to lift the value above zero when offset is calibrated. Keep in mind though the capacitance from D13 can/will drift with temperature - so it might take a few tries to get a good calibration.

 
The following users thanked this post: hammy, Marco1971

Offline cpposteve

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
Re: EEVblog 121GW Multimeter Issues
« Reply #1163 on: March 07, 2020, 12:51:52 am »
hi.

can anyone help?

trying to load 2.04 onto meter but just does nothing and stays on the "down" screen for ever and doesn't actually do anything.

i have downloaded the bin file, extracted it and sent it to the sd card. followed the firmware upgrade instructions but nothing, just hangs there. ive upgraded the firmware many times and never had an issue.


cheers

edit: i have logged some random stuff onto the card to make sure its logging and seeing the card fine and yep it writes to the card just fine, and can also read from it too, just will not download new firmware, i am reading instructions from 2018,

steve
« Last Edit: March 07, 2020, 01:38:32 am by cpposteve »
 

Offline J-R

  • Frequent Contributor
  • **
  • Posts: 952
  • Country: us
Re: EEVblog 121GW Multimeter Issues
« Reply #1164 on: March 07, 2020, 01:59:38 am »
Just to double check, did you rename the "EEVBlog2_04.bin" file to "EEVBlog.bin"?
 
The following users thanked this post: cpposteve, Marco1971

Offline cpposteve

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
Re: EEVblog 121GW Multimeter Issues
« Reply #1165 on: March 07, 2020, 02:05:25 am »
nope, forgot all about it as it does not mention it anywhere in the manual.  :-// :palm:
 

Offline beanflying

  • Super Contributor
  • ***
  • Posts: 7358
  • Country: au
  • Toys so very many Toys.
Re: EEVblog 121GW Multimeter Issues
« Reply #1166 on: March 07, 2020, 02:12:00 am »
Not explicitly but it does use 'EEVblog.bin' maybe a bracketed note on renaming in the user manual would be a good idea for the next revision?

Coffee, Food, R/C and electronics nerd in no particular order. Also CNC wannabe, 3D printer and Laser Cutter Junkie and just don't mention my TEA addiction....
 

Offline cpposteve

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
Re: EEVblog 121GW Multimeter Issues
« Reply #1167 on: March 07, 2020, 02:22:01 am »
yup agreed. something in the notes about firmware upgrade should say about the bin files.
 

Offline movax

  • Contributor
  • Posts: 21
  • Country: aq
Re: EEVblog 121GW Multimeter Issues
« Reply #1168 on: April 11, 2020, 01:39:46 am »
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.

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

Thanks Dave. Started testing on two multimeters. Will get results in 2-3 days, just to confirm long time stability.

I hope ST team is notified about these issues, if this is the issue in the library indeed. Is this related to SD driver, or FAT driver, do you know?

I don't want to blame anybody, as this is counter productive (I personally doubt it is the issue with ST driver, but it could be), I just wish the product is working correctly, and engineers responsible for firmware are debugging and working on a solution.

« Last Edit: April 11, 2020, 01:42:12 am by movax »
 

Offline movax

  • Contributor
  • Posts: 21
  • Country: aq
Re: EEVblog 121GW Multimeter Issues
« Reply #1169 on: April 14, 2020, 07:54:39 am »
I can happily report that firmware 2.04 fixed issues with SD logging. I did log 280k data points. No corruptions, no weird blocks, no stopped logging. All data is continues and looks good.

Example:



I am going to do another run, with even longer logging, of about 600k data points. But I think it should work fine.

I am still hopping that the date / time format is changed, to ISO 8601, or a timestamp (in seconds and deci second as a single number) from start of logging.
« Last Edit: April 14, 2020, 07:56:39 am by movax »
 

Offline movax

  • Contributor
  • Posts: 21
  • Country: aq
Re: EEVblog 121GW Multimeter Issues
« Reply #1170 on: April 14, 2020, 08:17:27 am »
There was still one block of zeroes though:
Code: [Select]
$ grep -a -B 1 -A 1 '^133619,2020' 20021500.CSV | xxd
00000000: 3133 3336 3138 2c32 3032 302f 3032 2f31  133618,2020/02/1
00000010: 362c 3034 3a35 303a 3533 2c44 4356 2c30  6,04:50:53,DCV,0
00000020: 3039 2e30 3835 2c56 2c2c 2c2c 2c2c 2c2c  09.085,V,,,,,,,,
00000030: 0d0a 3133 3336 3139 2c32 3032 3000 0000  ..133619,2020...
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 3133 3336 3231 2c32 3032  ......133621,202
000000a0: 302f 3032 2f31 362c 3034 3a35 303a 3534  0/02/16,04:50:54
000000b0: 2c44 4356 2c30 3039 2e30 3936 2c56 2c2c  ,DCV,009.096,V,,
000000c0: 2c2c 2c2c 2c2c 0d0a 3133 3336 3232 2c32  ,,,,,,..133622,2
000000d0: 3032 302f 3032 2f31 362c 3034 3a35 303a  020/02/16,04:50:
000000e0: 3534 2c44 4356 2c30 3039 2e31 3036 2c56  54,DCV,009.106,V
000000f0: 2c2c 2c2c 2c2c 2c2c 0d0a                 ,,,,,,,,..

I did not expirience blocks of zeros yet on a new 2.04 firmware, but I will keep looking into it. Could you try doing a `dd` of entire card, or `badblocks` on it?

Code: [Select]
26280,2020/02/15,22:46:59,DCV,003.514,V,,,,,,,,
26281,2020/02/15,22:46:00,DCV,003.704,V,,,,,,,,
26282,2020/02/15,22:47:00,DCV,003.818,V,,,,,,,,
--
74700,2020/02/16,01:30:31,DCV,007.437,V,,,,,,,,
74701,2020/02/16,01:30:50,DCV,009.029,V,,,,,,,,
--
94320,2020/02/16,02:37:31,DCV,009.065,V,,,,,,,,
94321,2020/02/16,02:37:50,DCV,009.282,V,,,,,,,,
--
205980,2020/02/16,08:59:09,DCV,008.950,V,,,,,,,,
205981,2020/02/16,08:59:28,DCV,009.262,V,,,,,,,,
--
350040,2020/02/16,17:06:07,DCV,009.241,V,,,,,,,,
350041,2020/02/16,17:06:28,DCV,009.328,V,,,,,,,,

The first one looks like a bug in time printing code (human-readable is hard and slow, could we get UNIX time instead?).
Other issues are definitely lost data.

I agree. The first looks like a printing bug.

The other ones are worrying tho, as it looks like the meter is locked for some time. It could be due to faulty card tho, where the firmware on card tries to reallocate / move faulty blocks around, which can take some time.

I will analyze my data and see if similar things is present.

It looks like you are using data logging with interval 0 (as fast as possible). Could you try switching to interval 1 (1 second), and see if the problem also occurs then?
 

Offline martinwag

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog 121GW Multimeter Issues
« Reply #1171 on: April 14, 2020, 10:20:34 am »
Hi,

don't know if I'm right in this thread. If not, please move.

I'm having a problem measuring DC voltage overlayed with AC voltage with the 121GW.



This is a 250V DC voltage with 90V RMS AC modulated on top. Measuring DC works fine, however AC doesn't.

969408-1

969396-2

The same measurement with Fluke 175 (and a few cheap meters) works as expected.

969400-3

This is inside the motor control for a SABA tube radio, however I get the same behavior when measuring AC ripple on the main filter capacitor.



Firmware version is U-2.02.

Any idea what's wrong here?

Thanks!
« Last Edit: April 14, 2020, 10:24:43 am by martinwag »
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: EEVblog 121GW Multimeter Issues
« Reply #1172 on: April 14, 2020, 11:07:53 am »
Hi,

don't know if I'm right in this thread. If not, please move.

I'm having a problem measuring DC voltage overlayed with AC voltage with the 121GW.
...
This is a 250V DC voltage with 90V RMS AC modulated on top. Measuring DC works fine, however AC doesn't.
...
The same measurement with Fluke 175 (and a few cheap meters) works as expected.
...
Firmware version is U-2.02.

Any idea what's wrong here?

Thanks!

Welcome to the forum.  I am not at all surprised with your findings and suspect if you manually select the range the meter will work.  Try that and report back.

I looked at some older version of the production meters a few months ago and saw similar problems. 
https://youtu.be/dvV6pf1yaUs?t=567
 
The following users thanked this post: Marco1971

Offline martinwag

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog 121GW Multimeter Issues
« Reply #1173 on: April 14, 2020, 12:06:33 pm »
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.
 

Offline jchw4

  • Regular Contributor
  • *
  • Posts: 188
  • Country: 00
Re: EEVblog 121GW Multimeter Issues
« Reply #1174 on: April 14, 2020, 02:48:05 pm »
There was still one block of zeroes though:
Code: [Select]
$ grep -a -B 1 -A 1 '^133619,2020' 20021500.CSV | xxd
00000000: 3133 3336 3138 2c32 3032 302f 3032 2f31  133618,2020/02/1
00000010: 362c 3034 3a35 303a 3533 2c44 4356 2c30  6,04:50:53,DCV,0
00000020: 3039 2e30 3835 2c56 2c2c 2c2c 2c2c 2c2c  09.085,V,,,,,,,,
00000030: 0d0a 3133 3336 3139 2c32 3032 3000 0000  ..133619,2020...
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 3133 3336 3231 2c32 3032  ......133621,202
000000a0: 302f 3032 2f31 362c 3034 3a35 303a 3534  0/02/16,04:50:54
000000b0: 2c44 4356 2c30 3039 2e30 3936 2c56 2c2c  ,DCV,009.096,V,,
000000c0: 2c2c 2c2c 2c2c 0d0a 3133 3336 3232 2c32  ,,,,,,..133622,2
000000d0: 3032 302f 3032 2f31 362c 3034 3a35 303a  020/02/16,04:50:
000000e0: 3534 2c44 4356 2c30 3039 2e31 3036 2c56  54,DCV,009.106,V
000000f0: 2c2c 2c2c 2c2c 2c2c 0d0a                 ,,,,,,,,..

I did not expirience blocks of zeros yet on a new 2.04 firmware, but I will keep looking into it. Could you try doing a `dd` of entire card, or `badblocks` on it?

I will, but you can see that this block is aligned with record size. To me it looks like exactly two missing lines. I doubt that it's a card problem. I also never deleted anything from this card, so I am using every block only once ;)

Quote
I will analyze my data and see if similar things is present.

It looks like you are using data logging with interval 0 (as fast as possible). Could you try switching to interval 1 (1 second), and see if the problem also occurs then?

Then we should expect issues to come at least 5 times slower ;) I think we should check the maximum possible rate, because this is when all the issues arise.

I can replace the card and do some tests again. Will need to set up the environment.



 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf