1. If I change the year (it defaults to 2016), the day, month, hour or minutes the setting does not stick/save. Changing (and having them save) other set up menu items works fine. I have tried cycling the power on the meter after making a change but that has no effect.Just got my meter today, and I am very impressed. Calibration is pretty much spot on.
1. If I change the year (it defaults to 2016), the day, month, hour or minutes the setting does not stick/save. Changing (and having them save) other set up menu items works fine. I have tried cycling the power on the meter after making a change but that has no effect.
2. Is it possible to disable the beep please, at least for button presses and any time the rotary switch is changed? The beep is loud which is great for continuity etc but after trying to figure out how to change the date/time it is starting to annoy.
After changing a time/date field, are you pressing the setup button for about two seconds until the beep to save the change?
Are you saying that if you change the year to 2018 and hold the setup button down till the beep, then if you check the year again, it is back to 2072?1. If I change the year (it defaults to 2016), the day, month, hour or minutes the setting does not stick/save. Changing (and having them save) other set up menu items works fine. I have tried cycling the power on the meter after making a change but that has no effect.
Confirmed. I have 2072-06-12 as the default date and changing it does not save.
Time does not save correctly either.
Yes, I cycled through all the date/times and set them. Then cycling back to the year again it was unchanged. There must be a difference between pressing the Setup button to cycle to the next setup option and holding it for longer to save the current value. The manual was not clear on this.Are you saying that if you change the year to 2018 and hold the setup button down till the beep, then if you check the year again, it is back to 2072?1. If I change the year (it defaults to 2016), the day, month, hour or minutes the setting does not stick/save. Changing (and having them save) other set up menu items works fine. I have tried cycling the power on the meter after making a change but that has no effect.
Confirmed. I have 2072-06-12 as the default date and changing it does not save.
Time does not save correctly either.
To change the date items:
1. Navigate to the menu item.
2. Hold SETUP
3. Press UP and DOWN to configure the date/time item.
4. Press SETUP again to save
Yes, I cycled through all the date/times and set them. Then cycling back to the year again it was unchanged. There must be a difference between pressing the Setup button to cycle to the next setup option and holding it for longer to save the current value. The manual was not clear on this.You have to hold the setup button for 2 seconds until the beep to change the date/time settings. Otherwise it is not changed. I don't think it does clearly say that in the manual.QuoteTo change the date items:
1. Navigate to the menu item.
2. Hold SETUP
3. Press UP and DOWN to configure the date/time item.
4. Press SETUP again to save
The source code for the Bluetooth 121GW App is available. The code for the Multimeter will likely never be open source according to Dave.But I suspect someone will disassemble it at some point...
The source code for the Bluetooth 121GW App is available. The code for the Multimeter will likely never be open source according to Dave.But I suspect someone will disassemble it at some point...
IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Do the IEC test equipment standards actually cover software funcitionality ( e.g. not under-reading)?The source code for the Bluetooth 121GW App is available. The code for the Multimeter will likely never be open source according to Dave.But I suspect someone will disassemble it at some point...
IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Yes, I cycled through all the date/times and set them. Then cycling back to the year again it was unchanged. There must be a difference between pressing the Setup button to cycle to the next setup option and holding it for longer to save the current value. The manual was not clear on this.You have to hold the setup button for 2 seconds until the beep to change the date/time settings. Otherwise it is not changed. I don't think it does clearly say that in the manual.QuoteTo change the date items:
1. Navigate to the menu item.
2. Hold SETUP
3. Press UP and DOWN to configure the date/time item.
4. Press SETUP again to save
I do believe that it's not his to do this, it's up to UEi, as they hold the IP. Dave gave up a lot of his rights regarding the meter as a part of the deal between them, from what I understood.IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Dave maybe can sell a version with open source firmware as DMM development kit? As a dev kit, you can basically bypass any certification requirements.
From a video in another thread, it seems it takes 7 seconds to autorange from open to zero ohms - how can Dave have considered this remotely acceptable ?
UEi's source code, but they don't own all the rights to the code (i.e. they don't have the right to re-distribute the source code in its entirety).
Anyone else have a lot of play (loosy-goosy) in their rotary switch?
Also my meter flashes the backlight when first turning on (firmware issue?) and beeps every time you switch settings (ie rotate the rotary switch) which is very annoying.
I do believe that it's not his to do this, it's up to UEi, as they hold the IP. Dave gave up a lot of his rights regarding the meter as a part of the deal between them, from what I understood.
Just to be clear, I have ZERO legal rights to this meter apart from exclusive distributorship.
I did not pay a single cent for its development.
IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Dave maybe can sell a version with open source firmware as DMM development kit? As a dev kit, you can basically bypass any certification requirements.
mVA Problem:
I seem to have a definite measurement problem on the mVA range in DC. Can anyone confirm this on their meters?
If I have a test setup with a power supply and a precision 100ohm resistor and I am putting 5V across the resistor, then as long as the current flowing into the mAuA socket is positive, I get 5.0000V across the resistor, 50.000mA current and 250.00 mVA. All good. Just using absolute numbers here - not worrying about the +/- polarities.
If I swap the power supply polarity - nothing else changes, I get 5.000V, 0.0368mA and 55.215 mVA. The current is wrong and the mVA product makes no sense.
The configuration I used was the mAuA socket to the power supply, the multimeter common to one side the resistor load, the V/Ohms input to the other side of the load that also connects to the other power supply output. I am using this configuration so that the multimeter is measuring the actual voltage across the load. The problem happens whether or not the v/Ohms input is connected or not, so my meter just cannot measure negative currents over exactly 10mA in the mVA/VA mode.
The problem occurs exactly when the current reaches 10.000mA. It works perfectly at 9.999mA with both power supply polarities. At 10.000mA, it fails. This makes it look like a software bug.
The mAuA input works fine in A/mA switch setting. This is only a problem in the mVA/VA mode.
The same problem does not occur using the A input for current instead of the mAuA input - at least at up to 100mA. The problem might be there using the A input at higher currents, but I cannot test that right now.
Are the formats of the calibration data, and the firmware update file public yet ?IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Dave maybe can sell a version with open source firmware as DMM development kit? As a dev kit, you can basically bypass any certification requirements.
There is absolutely nothing stopping anyone writing their own firmware and making it open source.
mm@ovid:~/121gw$ ls -l
total 232
-rwxr-xr-x 1 mm mm 39189 Feb 9 2006 18011100.CSV
-rwxr-xr-x 1 mm mm 117848 Dez 29 07:17 EEVBlog.bin
drwxr-xr-x 2 mm mm 4096 Dez 4 08:31 System Volume Information
time (s), Power DC (VA)
0.66214, 10.04
2.319854, 10.04
3.587273, 7.41
5.342622, 135.58
7.682192, 10.04
8.947719, 135.58
10.70679, 7.41
12.94711, 6.66
14.21456, 6.47
15.48118, 102.93
18.74924, 131.67
20.99118, 7.3
21.77326, 9.65
25.52709, 138.36
27.76692, 7.41
28.54338, 10.04
30.30227, 7.41
31.5711, 7.41
32.78831, 135.57
33.56652, 10.04
34.25069, 7.41
37.56762, 7.41
38.34549, 7.4
40.53939, 9.89
40.83278, 6.72
41.61178, 6.46
42.87929, 103.97
44.63388, 7.03
They look "goldish" the pcb also looks like ENIG finish. All looks good, so I have no idea why it happens.
Hi joeqsmith,
yes, I can handle line voltages and do so regularly.
Do you think it's related to spikes on the mains? I usually use a 0-300V 6A insulating transformer for tests like this, but if you think it makes sense I can test directly on mains but have only 230V available then. So your request would be >50VA for >6h logging to SD-card? Resistive load would be fine (they are more quiet)?
I will run it over night and hope it doesn't burn down the house. :-)
Just tell me if with or without the transformer.
I was checking the power using an arb, amplifier and transformer coupled. It seems like it was limited to 50V when I started to turn it up. You don't need a lot of current. Obviously the meter has no problems reading just voltage. It was tied to the power measurement.
They look "goldish" the pcb also looks like ENIG finish. All looks good, so I have no idea why it happens.
May be they don't reach well the pcb?
In lowZ mode the meter only starts to display a value >0 when the voltage rises to around 11.5V. When the voltage is lowered from 12V it works down to around 3V. If this is expected behaviour, it should be documented in the manual.I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
In lowZ mode the meter only starts to display a value >0 when the voltage rises to around 11.5V. When the voltage is lowered from 12V it works down to around 3V. If this is expected behaviour, it should be documented in the manual.I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
To limit dissipation to, say, 5W, then you are limited to around 110V maximum. At 240V, the dissipation would be 21W which is a lot of heat to be contained inside the meter. You could do a quick measurement, but a long term measurement would be really cooking the insides of the meter.
I think I will be replacing the 2.7K resistors with something much larger. 27K or higher. This seems like a dangerous feature as it is right now. Like the VA mode, very underveloped as you can see from the lack of documentation and specifications in the manual.
But how does it work? Is it a PTC thermistor and not a 2k7 resistor? I was just looking at the Fluke 114 manual and its LowZ goes to 600V and has about a 3K impedance. It better be a PTC thermistor, because 120W of heat inside a multimeter is a massive problem.In lowZ mode the meter only starts to display a value >0 when the voltage rises to around 11.5V. When the voltage is lowered from 12V it works down to around 3V. If this is expected behaviour, it should be documented in the manual.I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
To limit dissipation to, say, 5W, then you are limited to around 110V maximum. At 240V, the dissipation would be 21W which is a lot of heat to be contained inside the meter. You could do a quick measurement, but a long term measurement would be really cooking the insides of the meter.
I think I will be replacing the 2.7K resistors with something much larger. 27K or higher. This seems like a dangerous feature as it is right now. Like the VA mode, very underveloped as you can see from the lack of documentation and specifications in the manual.
My Aglient U1232A has an impedance of 3.6kOhm on its LowZ mode. I think 2.7kOhm on the 121GW is fine.
In lowZ mode the meter only starts to display a value >0 when the voltage rises to around 11.5V. When the voltage is lowered from 12V it works down to around 3V. If this is expected behaviour, it should be documented in the manual.I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
I think I will be replacing the 2.7K resistors with something much larger. 27K or higher. This seems like a dangerous feature as it is right now. Like the VA mode, very underveloped as you can see from the lack of documentation and specifications in the manual.
Thanks. Even Fluke didn't bother to explain that in their manual. I guess it is one of those things that you are just meant to know.In lowZ mode the meter only starts to display a value >0 when the voltage rises to around 11.5V. When the voltage is lowered from 12V it works down to around 3V. If this is expected behaviour, it should be documented in the manual.I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
No! That's not how this meter or any other Low-Z meter works.
The "resistor" is actually a PTC themristor, it's resistance increases when it heats up.
NOTE: Can we please limit this thread to reporting and confirmation of bugs and issues, any discussions should be on the discussion thread.I think we have been doing that. If I crossed a line by not understanding the undocumented low Z mode, I apologize.
Thanks.
I haven't had a meter with a Low Z mode so I am not familiar with how it is meant to work. It seems to be trying to autodetect whether the input is AC or DC and it needs at least 12V to do this. It has no ranges so I assume the 550V range is fixed. The Low Z input resistance looks to be about 2.7K ohms which would dissipate 112W at 550V!
To limit dissipation to, say, 5W, then you are limited to around 110V maximum. At 240V, the dissipation would be 21W which is a lot of heat to be contained inside the meter. You could do a quick measurement, but a long term measurement would be really cooking the insides of the meter.
I think I will be replacing the 2.7K resistors with something much larger. 27K or higher. This seems like a dangerous feature as it is right now. Like the VA mode, very underveloped as you can see from the lack of documentation and specifications in the manual.
Probably some thermistor or similar.
Instruction Sheet for Fluke SV225 says:
Specifications
Voltages up to 1000 volts continuous can be safely applied to
the Adapter without damage.
Operation Temperature
-20 °C to +55 °C (-40 °F to 131 °F)
Altitude
2,000 Meters Operating
Humidity
90 % at 0 to 35 °C (32 °F to 95 °F), 70 % at 35 to 55 °C
(95 °F to 131 °F)
Nominal Resistance
3,000 ? @ 25 °C (77 °F)
I would think it uses a PTC thermistor, so it draws a semi constant power over the voltage range. You find a similar one in the cheap voltstick devices.
I think part of the problem as well is that it's not always cut and dry if the perceived problems were not that way by design. To me, the slow auto range was by design. It's known and not really a bug. For the most part, the feedback appears to be going in one of two places.NOTE: Can we please limit this thread to reporting and confirmation of bugs and issues, any discussions should be on the discussion thread.I think we have been doing that. If I crossed a line by not understanding the undocumented low Z mode, I apologize.
Thanks.
Keep us posted on the data logging.
mm@ovid:~/121gw$ head -10 18011200.CSV ; echo "[...]" ; tail -10 18011200.CSV
START,2018/01/12,01:48:47,
ID,170800000,
INTERVAL,000,sec,
,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,DCVA,00000.0,mVA,DCV,00.0001,V,DCA,-0001.41,mA,,
2,DCVA,00000.0,mVA,DCV,00.0001,V,DCA,-0001.41,mA,,
3,DCVA,00000.0,mVA,DCV,00.0001,V,DCA,-0001.41,mA,,
4,DCVA,00000.0,mVA,DCV,00.0001,V,DCA,-0001.41,mA,,
5,DCVA,00000.0,mVA,DCV,00.0001,V,DCA,-0001.41,mA,,
[...]
130656,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.83,mA,,
130657,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.83,mA,,
130658,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.81,mA,,
130659,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.81,mA,,
130660,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.81,mA,,
130661,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.81,mA,,
130662,DCVA,01292.9,mVA,DCV,03.2999,V,DCA,0391.81,mA,,
MAX,49,DCVA,01294.1,mVA,
MIN,1,DCVA,00000.0,mVA,
When I was reviewing the 121GW meter, almost every time I turn the knob from OFF to Low-Z, the back-light flickers.
The back-light going on for about 0.1 sec seems to consume battery consumtion every time start using the meter.
I did run VA logging for about 9h over night.
It produced a logfile with 130662 entries, which is about 4 lines per second.
So this seems fine.
Should I try something else?
What's the open circuit HV diode test putting out now?
That's interesting. I think the prototype was under 17. I was a bit concerned with the mux they were using had an absolute max rating. It looked like they stayed with the same part in Dave's close up video showing the board. Maybe they came up with a better way to protect it. From what I saw, the mux was the weak point as far as the transient tests I run. That mux is an HEFxxxx located near the edge of the PCB if you wanted to pull the datasheets to have a look. I think its an absolute max of 18 on that one. You can drive it a little above the rail. Easy enough to trace the path to the input pin to see how it is being protected. Again, hard to say if you would call it a bug or issue anyway. Maybe just something to be aware of.What's the open circuit HV diode test putting out now?17.332V
Good question, it was claimed to be 15V, so if it has the room maybe a good TVS diode could go in and even with the voltage drop it would still be above 15V. But I don’t know if a TVS diode would even stop your transients Joe. But it would be better then nothing.That's interesting. I think the prototype was under 17. I was a bit concerned with the mux they were using had an absolute max rating. It looked like they stayed with the same part in Dave's close up video showing the board. Maybe they came up with a better way to protect it. From what I saw, the mux was the weak point as far as the transient tests I run. That mux is an HEFxxxx located near the edge of the PCB if you wanted to pull the datasheets to have a look. I think its an absolute max of 18 on that one. You can drive it a little above the rail. Easy enough to trace the path to the input pin to see how it is being protected. Again, hard to say if you would call it a bug or issue anyway. Maybe just something to be aware of.What's the open circuit HV diode test putting out now?17.332V
What's the open circuit HV diode test putting out now?
17.332V
Is it significantly dependent on battery voltage ?What's the open circuit HV diode test putting out now?
17.332V
000063 = 16.3V
000061 = 17.8V
Is it significantly dependent on battery voltage ?What's the open circuit HV diode test putting out now?
17.332V
000063 = 16.3V
000061 = 17.8V
Here 15.45V (and 3.23V for the 3V mode), FW 1.02What's the open circuit HV diode test putting out now?
17.332V
- The range switch is unreliable, you sometimes need to poke it a bit until the meter behaves properly.
- The inability to disable the excessive beeping or at least lowering the volume get's annoying fast.
- Autoranging speed in Ohms is way too slow.
Good question, it was claimed to be 15V, so if it has the room maybe a good TVS diode could go in and even with the voltage drop it would still be above 15V. But I don’t know if a TVS diode would even stop your transients Joe. But it would be better then nothing.That's interesting. I think the prototype was under 17. I was a bit concerned with the mux they were using had an absolute max rating. It looked like they stayed with the same part in Dave's close up video showing the board. Maybe they came up with a better way to protect it. From what I saw, the mux was the weak point as far as the transient tests I run. That mux is an HEFxxxx located near the edge of the PCB if you wanted to pull the datasheets to have a look. I think its an absolute max of 18 on that one. You can drive it a little above the rail. Easy enough to trace the path to the input pin to see how it is being protected. Again, hard to say if you would call it a bug or issue anyway. Maybe just something to be aware of.What's the open circuit HV diode test putting out now?17.332V
Has anyone checked to see if they still limit the frequency counter to 1MHz? Again, not really a bug perhaps but more a slight oversight.Or maybe there are issues like jitter or miscounts that make higher frequencies subject to errors?
Has anyone checked to see if they still limit the frequency counter to 1MHz? Again, not really a bug perhaps but more a slight oversight.It's still limited.
NOTE: Can we please limit this thread to reporting and confirmation of bugs and issues, any discussions should be on the discussion thread.
Thanks.
I didn’t know we were keeping score.NOTE: Can we please limit this thread to reporting and confirmation of bugs and issues, any discussions should be on the discussion thread.
Thanks.
#!/usr/bin/python
from bluepy import btle
from bluepy.btle import UUID, Peripheral,DefaultDelegate
import binascii
import array
from struct import *
def parse_data(x):
xlen = len(x)
for offset in range(0,xlen):
if (ord(x[offset:offset+1]) == 0xF2):
# Process accumulated data
print ("Accumulated data(%d): %s" % (len(parse_data.accumulated_data), str(parse_data.accumulated_data)))
parse_data.accumulated_data = array.array('c')
else:
parse_data.accumulated_data.append(x[offset:offset+1])
class MyDelegate(btle.DefaultDelegate):
def __init__(self):
btle.DefaultDelegate.__init__(self)
def handleNotification(self, cHandle, data):
parse_data(data)
parse_data.accumulated_data = array.array('c')
# Put your multimeter mac here
p = btle.Peripheral("88:6B:XX:XX:XX:XX", btle.ADDR_TYPE_PUBLIC)
p.setDelegate( MyDelegate() )
print('Ready!')
p.writeCharacteristic(0x9, "\x03\x00")
while True:
if p.waitForNotifications(1.0):
continue
print("Waiting...")
with this script it is easy to reproduce data corruption over BLE, length is changing and bits are flipping.31373038303030303030313031343041451b34303130304537303130383038343030303030300a
3137303830303030303031300c343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453607303834303030303030303030303030303030300a
31373038303030303030313031343041450d74373031303830383430303030303030303030300a
3137303830303030303031303134304145360a
31370638303030303030313031343041453634303130304537303130383038343030303030300a <-- here is a "06" at pos 5,6 where I expected "30"
31373038303030303030313031343041453634303130304537303106383038343030303030300a
31373038303030303030313031343041453634303130534537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
3137303830303030303031303134304145360c304537303130383038343030303030303030300a
3137303830303030303031303134304145360630303030303030303030303032440d0a
313730383030303030303130313430414536343031300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634300330304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453681303030303030303030303030303030303030300a
313730383030303030303130313430414536303032440d0a
3137303830303030303031303134304145363430313030453730313038303834300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038341830303030300a
The data is corrupted as bellow in the middle of the data.
59625,DCV,049.997,V,,,,,,,,
59626,DCV,049.997,V,,,,,,,,
59627,DCV,049.996,V,,,,,,,,
59628,DCV,049.997,V,,,,,,,,
59629,DCV, 59641,DCV,050.001,V,,,,,,,,
59642,DCV,049.996,V,,,,,,,,
59643,DCV,049.996,V,,,,,,,,
59644,DCV,049.998,V,,,,,,,,
59645,DCV,049.996,V,,,,,,,,
The garbled line only happened in one line out of four files of data logging.
The data is corrupted as bellow in the middle of the data.
59625,DCV,049.997,V,,,,,,,,
59626,DCV,049.997,V,,,,,,,,
59627,DCV,049.996,V,,,,,,,,
59628,DCV,049.997,V,,,,,,,,
59629,DCV, 59641,DCV,050.001,V,,,,,,,,
59642,DCV,049.996,V,,,,,,,,
59643,DCV,049.996,V,,,,,,,,
59644,DCV,049.998,V,,,,,,,,
59645,DCV,049.996,V,,,,,,,,
The garbled line only happened in one line out of four files of data logging.
It looks to me as if samples 59629 through 59640 are missing from the file? So it's not just a garbled line, it's some dropped data.
Seems like YOU are the one polluting it. Have anything technical to add?
Seems like YOU are the one polluting it. Have anything technical to add?
I'll be very clear again.
This thread is for REPORTS of bugs and issues and CONFIRMATIONS of those bugs and issues.
DO NOT discuss them here, PLEASE!
...CONFIRMATIONS of those bugs and issues.
Firmware Version 1.01 has an extra setup field "00000" not mentioned in the manual. It is between the hour-minute setting and logging interval setting.
The data is corrupted as bellow in the middle of the data.
59625,DCV,049.997,V,,,,,,,,
59626,DCV,049.997,V,,,,,,,,
59627,DCV,049.996,V,,,,,,,,
59628,DCV,049.997,V,,,,,,,,
59629,DCV, 59641,DCV,050.001,V,,,,,,,,
59642,DCV,049.996,V,,,,,,,,
59643,DCV,049.996,V,,,,,,,,
59644,DCV,049.998,V,,,,,,,,
59645,DCV,049.996,V,,,,,,,,
The garbled line only happened in one line out of four files of data logging.
It looks to me as if samples 59629 through 59640 are missing from the file? So it's not just a garbled line, it's some dropped data.
Good comment, I should have attached the raw data of the log file from the beginning why I thought it was a garbled line.
I just opened the file with binary editor.
awk -F, '/^[0-9]+,/{if ( c != $1 ) { printf("%6d %6d %s\n", l, c, $0); c = $1 } c++; l++; }BEGIN{l=1;c=1}' < 18011500.CSV 61501 61501 61502,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
139554 139555 139562,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
243949 243957 243962,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
267167 267180 267182,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
344797 344812 344822,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
356188 356213 356222,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
412106 412140 412142,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
431304 431340 431342,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
478699 478737 478742,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
523695 523738 523742,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
61499,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
61500,DCVA,01959.5,mVA,DC^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@61501,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
61502,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
139553,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
139554,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,044^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@139561,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
139562,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
243956,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
24395^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@243961,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
243962,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
267178,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
267179,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@267181,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
267182,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
344810,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
344811,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@344821,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
344822,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
356212,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
35621^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@356221,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
356222,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
412138,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
412139,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@412141,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
412142,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
431338,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
431339,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@431341,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
431342,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
478735,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
478736,DCVA,01959.5,mVA,DCV,0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@478741,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
478742,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
523736,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
523737,DCVA,01959.5,mVA,DCV,04.4482,V^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@523741,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
523742,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.52,mA,,
600000,DCVA,01959.5,mVA,DCV,04.4482,V,DCA,0440.53,mA,,
Bug/mechanical issue in the Diode test mode. When selected if you jiggle the plugs at the meter you get the short double beep and sometimes a continuous beep which requires further lead or switch jiggles to stop. So the switch seems to be very sensitive mechanically to trigger the continuous beep. Also via some PCB flexing (i guess), due to the test lead plugs will also trigger the beep.I do not get the jiggling issue, but for some reason, when the diode mode senses any change (like a 10K resistor or anything else), it double beeps and then a second later double beeps again. Not sure why that is wanted. If the probes are shorted, it beeps continuously just like the continuity test mode.
firmware 1.01
By jiggling I mean moving the lead plugs intentionally forward and back "a bit" in their sockets causes the continuous beep to engage with out shorting the probes together. And further to this once the continuous beep has started I can remove the probes from the meter and it carries on beeping until I "wiggle" the selector switch a little bit then it will stop followed with the 2 short beeps.Sounds like you have an intermittent supply of 3V and 15V to the sockets. Could be a poor contact on the switch or a broken trace on the board. Can you connect a voltmeter to the probes and see if the voltage drops when you wiggle?
Unfortunately I cannot do a video which would make it very clear whats going on.
Okay checking the output with a voltmeter still gives 3 or 15V when continuous beep is going, also when this condition has started the display also goes to all '0' from OFL so no short at the input terminals it would seem.So it looks like the intermittent connection is somewhere between the measurement IC and the point at which the 3/15v is connected. I still think a switch connection is the most likely cause. You probably should contact Dave directly, unless you want to just Take-It-Apart yourself and have a look.
How much burden voltage do you guys have on the 10A range? Mine is 0.035V/A measured externally while the manual says 0.02V/A. The 112GW itself reports 28.7mV/A.
I created a Youtube acc. and uploaded a very short video clip of the Diode test mode continuous beep after giving the probe plugs a wiggle in the meter sockets.
I then removed the probes from the meter to show no external short circuits being the cause and then how a light press on the range switch will stop the tone.
(I will open the meter to investigate this after a weeks holiday)
I created a Youtube acc. and uploaded a very short video clip of the Diode test mode continuous beep after giving the probe plugs a wiggle in the meter sockets.
I then removed the probes from the meter to show no external short circuits being the cause and then how a light press on the range switch will stop the tone.
(I will open the meter to investigate this after a weeks holiday)
I can confirm this. I also experienced the switch to be unreliable some times.
I fixed it by mounting two small sheets of 0.25mm telson below the snap ring of the switch.
I'll attach a photo.
I can confirm this. I also experienced the switch to be unreliable some times.
I fixed it by mounting two small sheets of 0.25mm telson below the snap ring of the switch.
I'll attach a photo.
Hello mr Jones..!!
Just curious as to when people will get their answers to these on going faults?
I can confirm this. I also experienced the switch to be unreliable some times.
I fixed it by mounting two small sheets of 0.25mm telson below the snap ring of the switch.
I'll attach a photo.
I do not understand this.
That fix is on the case of the meter, not on the carrier that holds the switch contacts which is a different assembly mounted and clipped to the PCB that has it's own tension with the plastic insert clip.
Basically what I am saying is if the knob moulding was tweaked a bit, the switch could possible be more reliable and feel much more solid. It is just out here and there by fractions of a millimetre and that is all it takes.
IIRC the point of not open-sourcing it is that messing with the firmware could affect the safety of the meter so there's no way they can officially sanction that or help people to do it.
Dave maybe can sell a version with open source firmware as DMM development kit? As a dev kit, you can basically bypass any certification requirements.
There is absolutely nothing stopping anyone writing their own firmware and making it open source.
There is absolutely nothing stopping anyone writing their own firmware and making it open source.Does that include YOU Dave ?
3. measuring any resistance (short or higher value) in diode mode gives a constant and loud beep
5. Strange to me is that when in diode mode a small green LED has a Vf of 1.79 in the 3V mode and a Vf of 1.98 in the 15V mode. And also is a bit brighter then.
The manual specifications is a bit vague on diode test currents. It mentions 1.4mA and 7mA short circuit but they don't really line up with the 3V range and 15V ranges.
It seems the actual currents are different on my meter (v1.01):
3V 0.7mA short circuit
15V 4.6mA
The manual specifications is a bit vague on diode test currents. It mentions 1.4mA and 7mA short circuit but they don't really line up with the 3V range and 15V ranges.
It seems the actual currents are different on my meter (v1.01):
3V 0.7mA short circuit
15V 4.6mA
Short circuit current is a maximum. It will be less when there's no short circuit.
No one is suggesting constant current. I have done a report on short circuit currents of my meter because they are different from the spec. It would be useful if you can confirm my numbers, or if your 121GW meter matches the spec. O miss0.7mA on 3V range
0.71 mA on 3V rangeNo one is suggesting constant current. I have done a report on short circuit currents of my meter because they are different from the spec. It would be useful if you can confirm my numbers, or if your 121GW meter matches the spec. O miss0.7mA on 3V range
4.25mA on 15V range
On my meter pins PE13 (SPI1_SCK/FSMC_D10) and PE14 (SPI_MISO/FSMC_D11) of the STM32L1 are shorted together (continuity tested). The attached file has the best focused image I could get of this. Should I do anything about it?
The switch on my meter (#000499) is also wobbly and has the problem described here.
I took it apart, and contacts and pcb looked ok. After I put it back together it worked allright for a while, but now it's back and I have to fiddle with the switch again to get it to display correct readings. :-BROKE
Dave, once UEi figures out a fix, will you send out a replacement part?
Minor Issue:
I just opened my 2nd set of leads, note the positive lead, recessed threaded portion, and it's broken internally. Slightly flexing the break in the 2nd photo to accentuate the area.
It's electrically connected however. (Replacements not necessary, I got a zillion of them)
inside spins
I wonder if someone could check the meter in the LowZ mode. In the early unit, if I applied a 1VRMS 60Hz signal, the meter would read zero as expected. However, when I would increase the frequency to 389KHz, the meter was displaying 181.3 volts even though there was still only a volt being supplied. There was something strange going on with it that I never looked into. I reported the problem when I discovered it but with as many problems that the meter still has, I wonder if this was addressed in the released version.
Edit: the calibration tables are also only specified up to 10KHz. Perhaps the 10KHz correction factor becomes invalid at such a high frequency? Can anyone dump their calibration data (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1406163/#msg1406163) (requires firmware 1.02) for me?
If the switch is wobbly, but the measurements are not affected by moving it, is this still a defect?
I'd argue the wobbly switch has a questionable longevity.
@ChrisG What tpw_rules was suggesting I believe was to input the 1Vrms 100+kHz input into the VAC mode (instead of LowZ), and then manually select 1000V range. And thus see if the same wrong readings were displayed as in LowZ.
...
I tried several things including increasing my output to 5Vpp and I couldn't get those strange readings again. The fact it happened once does point to tpw_rules theory about the whacky adjustment for frequency being potentially correct. Or I could have been hit with the rotary switch wobble issue that one time. Or maybe there is a specific sequence needed to reproduce... |O
you patched the firmware or which patch did you apply? If you're still in version 1.02 of the firmware what would be different then?
With 2.8Vpp (~1Vrms) sine at 300kHz:
LowZ AV 1000V range read 161V - consistent
VAC auto range (5V) read 1.63V 299.9kHz - once only, see below - otherwise ~1V 299.9kHz
VAC 5V range read 1.63V 299.9kHz - once only, see below - otherwise ~1V 299.9kHz
VAC 50V range read 12.6V 299.8kHz - once only, see below - otherwise 0V 0Hz
VAC 500V range read 149.2V 299.8kHz - once only, see below - otherwise 0V 0Hz
VAC 1000V range read 149.3V 299.8kHz - once only, see below - otherwise 0V 0Hz
1. Temperature
2. Battery Voltage
3. Auto Power Off (APo)
4. LCD Contrast
5. Year
6. Month-Day
7. Hour-Minute
8. Multimeter ID
9. Logging Interval (ln 1)
10. Additional settings dependent upon the function selected.
So 95 % of the time the random numbers come up instead of blanking the display while changing ranges. It only occurs on the top M Ohm range and will blank as soon as the auto ranging starts.
Do others see this effect on theirs with firmware version 1.07. ?.
I already posted in the discussion thread about a problem I have with Vac readings. Now I will switch to the correct place for this.
In 5Vac mode I get wrong readings.
Today I checked the ZERO OFFSET CALIBRATION and had to find out, that only in 5Vac range mode with shorted inputs I get a reading of 0,499xVac. With open input I get nearly the same value of about 0,5Vac.
In all other Vac (and Vdc) ranges I get 0,0xxV. So I tried to calibrate only the zero offset in Vac 5V range mode. During the count down it displays the 0,499xV and after the calibration I still have this offset with shorted inputs on the 5Vac range. At the end of the calibration countdown I see "OFF-E" for about half a second what is not mentioned in the manual.
I have two references from voltagestandard.com. The 121GW is spot on for all voltage measurements I can do (Vdc 0,350V up to 10.000V and Vac 5V).
So there must be something wrong with the 5Vac range mode of my 121GW.
Another thing happened today while testing for the first time. When I switched from left side off to V mode the meter did not turn on. I taped on the mode switch still in this mode and it turned on. So there must be another problem with my 121GW.
You can read my postings and realted answers if you want to get the complete story:
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1446232/#msg1446232 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1446232/#msg1446232)
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1447697/#msg1447697 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1447697/#msg1447697)
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1447957/#msg1447957 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1447957/#msg1447957)
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1465469/#msg1465469 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1465469/#msg1465469)
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1469130/#msg1469130 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1469130/#msg1469130)
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1469890/#msg1469890 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg1469890/#msg1469890)
Source code not available.
To me this was the biggest bug of them all and enough reason to not buy this meter.
Maybe I'll revise my opinion when a "community" alternative version of the software for this meter becomes available.
Ok the new firmware is out. I flashed v1.15 and tried again. But it is still the same. In 5Vac range I have an offset of about 0,5V (shorted or opened port is nearly the same). I tried to calibrate the zero offset for the 5Vac range but it did not help. So there must be a problem with the 5Vac range of my 121GW.I already posted in the discussion thread about a problem I have with Vac readings. Now I will switch to the correct place for this.
In 5Vac mode I get wrong readings.
Today I checked the ZERO OFFSET CALIBRATION and had to find out, that only in 5Vac range mode with shorted inputs I get a reading of 0,499xVac. With open input I get nearly the same value of about 0,5Vac.
In all other Vac (and Vdc) ranges I get 0,0xxV[...]
Thankyou for your message we are aware of your issue, the issue with the on-off is almost certainly due to the shim fix (this will be shipped to you at some point soon, it will resolve the issue if that is an issue). It does sound like your 5V AC range has an issue, there is a new firmware update coming out. It might improve the situation for you and if you did want to recalibrate it would be better to do it after the next update.
Firmware 1.15 has a regression vs. 1.10.
When connecting via bluetooth and disconnecting again by closing the app (or the bluetooth connection) no connection is possible until bluetooth is switched on and off on the meter.
Firmware 1.15 has a regression vs. 1.10.
When connecting via bluetooth and disconnecting again by closing the app (or the bluetooth connection) no connection is possible until bluetooth is switched on and off on the meter.
That is unlikely as the Bluetooth is basically a UART-BLE bridge module and it hasn't been updated. It is more likely an update to windows or android that caused the issue, otherwise i'm not really sure how this could have happened.
One important thing to know is that if you simply minimize the app it is still using the bluetooth device until it is properly closed this means if you opened another instance it will not connect as the bluetooth device is already in use.
Firmware 1.15 has a regression vs. 1.10.
When connecting via bluetooth and disconnecting again by closing the app (or the bluetooth connection) no connection is possible until bluetooth is switched on and off on the meter.
That is unlikely as the Bluetooth is basically a UART-BLE bridge module and it hasn't been updated. It is more likely an update to windows or android that caused the issue, otherwise i'm not really sure how this could have happened.
Didn't I already read about this? I am not sure so I post it here in the issues thread.
When I turn off the beeper and afterwards go to diode test I get a nonstop beep with firmware 1.15.
PS: On 19th april I got a message telling me that the repair parts for the 121GW have been sent to me. They still not arrived ;-(
@ CandidNo, I did not receive anything up to now. And no update to the issue except that it is getting worser. Very often from off to any position the meter stays off or resets/starts from time to time and still having the +0,5V with shorted leads on ac 5V-range.
Did you receive your shims and whatnot, any update with the issue you were having?
Video of the issue is still being processed but the link is down belowIt thinks your probes are closed. When you crossed continuity it sounded off.
my serial number is #420 (heh)
EDIT: i should add that AC and DC volt reading in the standard (non-lowZ) mode read fine (not sure about accuracy but it looks good enough compared to my UT61E)
My meter arrived a couple of days ago followed by an email from Kick-starter telling me it was my last chance to update my shipping details :)
Mine arrived with an immediate problem. The screen contrast and viewing angles were weird and touching the screen even very lightly caused various segments to come on. The packaging was largely OK, some bumps and bruises.
Anyway I gave the meter a bump on my bench (just on the top edge of the rubber surround) front and back. Problem solved. Not sure if the screen suffered a squish in transit or if it was pushed to hard front or back during assembly but I am thinking it was one or the other. If you have this problem you can try giving the thing a bump. Worked for me but, as they say, YMMV.
From preliminary testing I find the resistance mode to have some issues.
If I move my hand to the Rel button to null out the reading the display seems sensitive to the proximity of my hand.
Thought I should report that the knob on mine felt way too tight, with a squeaking grind. Opened it after about a day of use and found the shim installed at Kane (from delayed batch) had been installed upside-down.
Thought I should report that the knob on mine felt way too tight, with a squeaking grind. Opened it after about a day of use and found the shim installed at Kane (from delayed batch) had been installed upside-down.UODATED;
(https://i.imgur.com/PMQt9YR.png?1)
i took it fully apart except for the LCD and found really nothing out of place, some bodges that look fine and some flux here and there but no solder blobs or lifted components, i attached some high res photos of both sides, see if you can see anything
i also checked out under the switch and found nothing out of place
my next course of action is tracing down both signal paths and see if anything is a miss
EDIT: no attachment, too big, i placed both images here https://imgur.com/a/vHISAb5
EDIT2: I traced down what i could, PA9, PLD and PB0, none of these show a short or anything below what looks normal as referenced to agnd
i also looked at u16 and that also appears to be functional
I can confirm this also. Since I don’t believe the meter is capable of reading mili Ohms (like most meters can’t) it probably why other meter remove the least significant digit in this range.From preliminary testing I find the resistance mode to have some issues.Yes I'm having this as well, meter go way out of spec when touching or nearly touching buttons.
If I move my hand to the Rel button to null out the reading the display seems sensitive to the proximity of my hand.
Finger just above REL button (almost touching) or lightly touching any of range-hold-rel buttons causes resistance value to change, 0.5ohm+ on mine. Same with light taps.
Also similar in the mVDC ranges. Touching / lightly depressing the range/hold (or both) buttons causes mater to go way out of spec, 0.5mv+
v1.15
Has anyone reported or noticed when you zero out the meter on voltage or resistance (I think all settings) and use the auto hold at the same time, the auto hold results ignore the zeroed out value when it displays the auto hold results.
Then if you turn off the Auto hold the relative triangle symbol is still displayed on the meter, but it’s not the truly zeroed out value being displayed. It’s the normal value ignoring the relative value it should be doing math with like you didn’t zero it at all. But the triangle is still displayed on the LCD. So I pushed the relative button again, instead of the triangle turning off it blinks on and off real fast and sets a new zero value.
Or, once you get the Auto hold reading without the relative value calculated into the Auto hold reading displayed, then turn off the relative set value by pressing the button again the triangle on the LCD does turn off and the Auto Hold is still displayed on the LCD. But it’s not doing any auto holding despite the LCD showing Auto hold being displayed, the meter will display the live readings with no holding at all or beep indicating it’s captured a hold.
And then also Auto hold might capture a value and beep, but if you don’t immediately remove the probe from the point being measured really fast it will display a lower value as you disconnect the probes from the source.
And it doesn’t detect small changes like mV or uV changes even when it’s set to the highest resolution using auto range or selecting a manual range. I think it’s looking for pre-set amount of change in the value it’s measuring before it will display a new hold value. I’m not sure how much difference it needs to see before it captures and display the new hold value? I think it’s between 35mV and 40mV?
Latest firmware 1.15, just recveied it today.
Scott
Has anyone reported or noticed when you zero out the meter on voltage or resistance (I think all settings) and use the auto hold at the same time, the auto hold results ignore the zeroed out value when it displays the auto hold results.
Then if you turn off the Auto hold the relative triangle symbol is still displayed on the meter, but it’s not the truly zeroed out value being displayed. It’s the normal value ignoring the relative value it should be doing math with like you didn’t zero it at all. But the triangle is still displayed on the LCD. So I pushed the relative button again, instead of the triangle turning off it blinks on and off real fast and sets a new zero value.
Or, once you get the Auto hold reading without the relative value calculated into the Auto hold reading displayed, then turn off the relative set value by pressing the button again the triangle on the LCD does turn off and the Auto Hold is still displayed on the LCD. But it’s not doing any auto holding despite the LCD showing Auto hold being displayed, the meter will display the live readings with no holding at all or beep indicating it’s captured a hold
And then also Auto hold might capture a value and beep, but if you don’t immediately remove the probe from the point being measured really fast it will display a lower value as you disconnect the probes from the source.
And it doesn’t detect small changes like mV or uV changes even when it’s set to the highest resolution using auto range or selecting a manual range. I think it’s looking for pre-set amount of change in the value it’s measuring before it will display a new hold value. I’m not sure how much difference it needs to see before it captures and display the new hold value? I think it’s between 35mV and 40mV?
1. set max/min active, -> range button does not function
2. set max/min active, set hold, unset hold -> readings change as if max/min off, but shows max/min as on
3. set a-hold, press max/min button (note min/max mode change is not displayed), turn off a-hold, -> max/min mode change suddenly displayed but not in min/max mode
4. set hold, press max/min button (note max/min mode change is displayed), set a-hold -> a-hold works as if max/min is off, even though max/min is displayed as active
5. In mvDC press range and immediately press REL -> REL sets before ranging completes, leaving error in offset. REL should delay until range completes
6. Short v-com, set VAC mode, set manual range other than 1000v, turn on 1ms peak, select 1000v range -> meter flashes high voltage warning symbol
7. Set a VAC mode, set a manual range, turn on 1ms peak, turn off 1 ms peak, -> meter forgets manual range set and reverts to auto range
8. Short v-com, set mVAC mode, set manual 50mv range (shows ~0mv), turn on 1ms peak, set range to 500mv-> suddenly large offset appears. Similar in Vac mode
9. Short v-com, set VAC mode, set range to 1000V, activate 1ms peak, set range to 5v -> takes over 10 seconds to switch into 5v.
10. Open v-com, set mVAC mode, set 1ms peak, switch to VAC -> mater never ranges - infinite blank
11. VAC or maVAC, set a manual range, turn on 1ms peak, turn off 1 ms peak -> meter goes to auto-range, forgetting it was in manual
My meter arrived a couple of days ago followed by an email from Kick-starter telling me it was my last chance to update my shipping details :)Mine has a weird viewing angle also, straight on is dim compared to looking up at it. But looking at a down angle it get worse, almost unreadable.
Mine arrived with an immediate problem. The screen contrast and viewing angles were weird and touching the screen even very lightly caused various segments to come on. The packaging was largely OK, some bumps and bruises.
Anyway I gave the meter a bump on my bench (just on the top edge of the rubber surround) front and back. Problem solved. Not sure if the screen suffered a squish in transit or if it was pushed to hard front or back during assembly but I am thinking it was one or the other. If you have this problem you can try giving the thing a bump. Worked for me but, as they say, YMMV.
Mine has a weird viewing angle also...
Thanks for the testing. Haven't received mine yet.Yes, contrast doesn’t change viewing angles. It just adjusts the dark and light between the displayed numbers and the background.Mine has a weird viewing angle also...
Have you tried the LCD Contrast adjustment?
Did you check these on 1.15 or 1.17 for the things you want to me check?I checked on both 1.15 and 1.17
In Amp if you measure current, hold the reading and pull the probes out the reading stays displayed.Same behavior on mine on 1.17
In the mA/uA jack if you do the same thing when you pull the probe out, the screen goes blank. And if you had it set to a manual range it changes over to Auto range when you pull the probe with the reading on hold.
Mine has a weird viewing angle also, straight on is dim compared to looking up at it. But looking at a down angle it get worse, almost unreadable.The view angle bias seems ok on mine - viewable flat on a table or looking straight on at meter (contrast does fade a little bit straight on but it's not bad). The default contrast setting on mine (4) was way too low though, I have mine set at max (7) and do wish it would go a little higher.
Bummer, but you triedOh okay, thanks for the heads up ill keep that in mind
For sent messages to appear in outbox, you have to make sure "Save a copy in my outbox" is checked before sending. If you go to preferences there's a "Save a copy of each personal message in my sent items by default" option too.
I noticed a potential quality issue with the rubber boot. On the right side, the lip is a bit deformed and doesn't adhere to the contour of the meter. Based on videos I've seen of the production meter, my problem doesn't seem to be a one-off (didn't notice it with Joe's pre-production meter though).
Any thoughts?
Mine is probably permanent, it was like this out of the box. I'm guessing it's either an issue with the way they're pulled out of the mold or with how the meters were handled when they were opened up to install the shim.I noticed a potential quality issue with the rubber boot. On the right side, the lip is a bit deformed and doesn't adhere to the contour of the meter. Based on videos I've seen of the production meter, my problem doesn't seem to be a one-off (didn't notice it with Joe's pre-production meter though).
Any thoughts?
mine does the same thing, but does slowly pull it self back together after an hour after pulling it out of its sheath
Mine has a weird viewing angle also, straight on is dim compared to looking up at it. But looking at a down angle it get worse, almost unreadable.
Does anyone know the material that the outside boot is made of? Ifs it TPU, or some combined mix of stuff?Mine is probably permanent, it was like this out of the box. I'm guessing it's either an issue with the way they're pulled out of the mold or with how the meters were handled when they were opened up to install the shim.I noticed a potential quality issue with the rubber boot. On the right side, the lip is a bit deformed and doesn't adhere to the contour of the meter. Based on videos I've seen of the production meter, my problem doesn't seem to be a one-off (didn't notice it with Joe's pre-production meter though).
Any thoughts?
mine does the same thing, but does slowly pull it self back together after an hour after pulling it out of its sheath
Not sure if this is worth a warranty inquiry though. Maybe if many other customers have the same problem.
Does anyone know the material that the outside boot is made of? Ifs it TPU, or some combined mix of stuff?That's a piece of information that if it's not already in the manual, I think it should be added there, also for ecological disposal purposes.
Nope, it’s not in the manual. Unless I missed it both times I gone over the manual.Does anyone know the material that the outside boot is made of? Ifs it TPU, or some combined mix of stuff?That's a piece of information that if it's not already in the manual, I think it should be added there, also for ecological disposal purposes.
I noticed a potential quality issue with the rubber boot. On the right side, the lip is a bit deformed and doesn't adhere to the contour of the meter. Based on videos I've seen of the production meter, my problem doesn't seem to be a one-off (didn't notice it with Joe's pre-production meter though).
Any thoughts?
Hi Dave, you did this video a while back with voltage. I’ve been :palm: trying to figure this out, and I think I finally figured out why my resistance testing is gettting such large differences in readings.
I haven’t had time to check the voltage and temperature change but it also didn’t jump out at me during basic testing so I’m assuming it’s probably ok.
What I have noticed is the resistor mensrment range being severely affected by the internal meter temperature. I’m going off what the internal temperature is showing on the meter.
Can you run this again in the resistance mode? Specifically the 50M resistance mode maybe with a 10M resistors? Although I’ve noticed the temperature affecting all resistance modes, the 50M ohm range seems to be the worse and most sensitive. The ambient temperature in the lab did not change more then 1C but the internal temp on the meter with backlight on went from 21.1C to 26.1C.
My Caddock 10M resistor at 0.1% tolerance is a 15ppm temp coefficient but as I mentioned the lab room temperature hardly changed at all. At internal meter reading temp it showed 10.005. By the time the meter internal temp reached 26.1C the resistor was reading 10.158. And the day my air con was off the lab was at 24.4C and the internal temp on the meter reached 28.9C and the reading was much higher at 10.356.
Despite the 10M resistor being 15ppm I also testing with Vishay that are 2ppm at 0.025% tolerances and those are affected also with all ranges I own 1, 10, 1K, 10k, 100k ohm resistors.
I will also note the 50M range seems to be the most sensitive jumping around a lot just going to push a button on the meter or waiving your hand around it.
I just want to know if this is mine only, or if you can repeate the test with the resistance mode and see if this is a common thing? And maybe the sensitivity can be adjusted in the firmware, it reminds me of your 2016 mV range video showing it being so sensitive that I believe was corrected with firmware or maybe a hardware change? If it not just mine maybe theirs a specific component this resistance mode uses that can be changed to something that has better temperature coefficiency?
The sweet spot for internal meter internal temperature seemed to be about 21.1C for all ranges.
https://youtu.be/Wwz_fdU17aQ
did this thread get unpinned by accident? - it no longer appear at the top of the thread list.
Hello scott!Nope, no difference. I didn’t log the results, I just watched it change.
Just did some long term logging of 10MR. Don't see the same error you discuss, is there any specific things I missed with my tests?
Test 1: Simply connected 10M resistor to the multimeter and logged for an hour.
Test 2: Placed multimeter in a thermal chamber starting at 26.6 degrees and raised it to 35.6. The 121GW measured a 10M resistor that was outside the thermal chamber (so it was unaffected by rising temperature or humidity), logging for an hour.
NOTE: There are some glitches in my logging, thats just when I bumped the leads with my computer mouse, try not to move wires when measuring such high impedances.
The next test starts at 26.6 and raises to 35.6. These were logged using the windows app over bluetooth. At about 2000 I left the room for lunch and the erroneous readings stopped entirely, again high impedance readings are very sensitive.
Are you able to show something similar? I recommend using the Windows App for this is as it will make saving and posting the data a little easier.
Hello scott!Nope, no difference. I didn’t log the results, I just watched it change.
Just did some long term logging of 10MR. Don't see the same error you discuss, is there any specific things I missed with my tests?
Test 1: Simply connected 10M resistor to the multimeter and logged for an hour.
Test 2: Placed multimeter in a thermal chamber starting at 26.6 degrees and raised it to 35.6. The 121GW measured a 10M resistor that was outside the thermal chamber (so it was unaffected by rising temperature or humidity), logging for an hour.
NOTE: There are some glitches in my logging, thats just when I bumped the leads with my computer mouse, try not to move wires when measuring such high impedances.
The next test starts at 26.6 and raises to 35.6. These were logged using the windows app over bluetooth. At about 2000 I left the room for lunch and the erroneous readings stopped entirely, again high impedance readings are very sensitive.
Are you able to show something similar? I recommend using the Windows App for this is as it will make saving and posting the data a little easier.
I’ll have to find my wondws laptop and install the software.
Speaking of apps, do you know what happened to the iOS app for Apple devices? I had it downloaded and it controls thing like ranges, hold, but doesn’t display any numbers. Then I realized it was removed from the iOS App Store, do you know when we can expect this to be returned?
I also took into the consideration based off Dave’s video showing a grounded ESD mat affecting mV readings and moved it to another room that is latterly empty. Still the same results.
I’ll try to log it if I find the computer, It might just be my meter?
Thanks for checking and running the tests,
Scott
Hi all, Dave, Seppy, I've received my shim and selector switch and installed it. The internal selector with the wipes is still causing abrasion to the PCB by the looks of it. Initially the selector knob could not be operated with one hand and I had to fix the 121GW with my left-hand. I've loosened the internal 2 screws and this helps (a bit). What remains now is that when the selector is in the ohms range and I wiggle or pull the V+/Ohm cable the 121GW goes into black/reset mode. I loved the 121GW from the on-start due to the crowd funding, the discussions, the feature set and specifications. But I need to come to the conclusion that this is not workable for me and need to revert back to my trusted BM869s. I can inspect the socket on the PCB but suspect it's the wipes and internal selector which causing the issue since it only happens when in the Ohms range. A genuine pitty it is.
..Up, down, into selector assembly? A picture of the proper installation by the seller would be worth 1000 posts.
Please ensure that shim's routed cutout faces downwards into the plastic rotary selector assembly. The cutout is NOT for the circlip, a lot of people have had that issue with upside down shims.
...
..Up, down, into selector assembly? A picture of the proper installation by the seller would be worth 1000 posts.
Please ensure that shim's routed cutout faces downwards into the plastic rotary selector assembly. The cutout is NOT for the circlip, a lot of people have had that issue with upside down shims.
...
Hi all, Dave, Seppy, I've received my shim and selector switch and installed it. The internal selector with the wipes is still causing abrasion to the PCB by the looks of it. Initially the selector knob could not be operated with one hand and I had to fix the 121GW with my left-hand. I've loosened the internal 2 screws and this helps (a bit). What remains now is that when the selector is in the ohms range and I wiggle or pull the V+/Ohm cable the 121GW goes into black/reset mode. I loved the 121GW from the on-start due to the crowd funding, the discussions, the feature set and specifications. But I need to come to the conclusion that this is not workable for me and need to revert back to my trusted BM869s. I can inspect the socket on the PCB but suspect it's the wipes and internal selector which causing the issue since it only happens when in the Ohms range. A genuine pitty it is.
Please ensure that shim's routed cutout faces downwards into the plastic rotary selector assembly. The cutout is NOT for the circlip, a lot of people have had that issue with upside down shims.
There is also chance that some burs on the plastic are causing the shim to raise up too far, you might want to remove the injection molding burs if possible. It is a shame that the shim was needed.
It might also be worth opening up the device and removing the selector switch, carefully (this can be pretty tricky), making sure the PCB underneath it is fine.
It could be that the brushes aren't perfectly housed, or that one of the brushes has two spring contacts stacked on-top of each other (happened once in pre-production, but thought this was sorted out).
Hi all, Dave, Seppy, I've received my shim and selector switch and installed it. The internal selector with the wipes is still causing abrasion to the PCB by the looks of it. Initially the selector knob could not be operated with one hand and I had to fix the 121GW with my left-hand. I've loosened the internal 2 screws and this helps (a bit). What remains now is that when the selector is in the ohms range and I wiggle or pull the V+/Ohm cable the 121GW goes into black/reset mode. I loved the 121GW from the on-start due to the crowd funding, the discussions, the feature set and specifications. But I need to come to the conclusion that this is not workable for me and need to revert back to my trusted BM869s. I can inspect the socket on the PCB but suspect it's the wipes and internal selector which causing the issue since it only happens when in the Ohms range. A genuine pitty it is.
Please ensure that shim's routed cutout faces downwards into the plastic rotary selector assembly. The cutout is NOT for the circlip, a lot of people have had that issue with upside down shims.
There is also chance that some burs on the plastic are causing the shim to raise up too far, you might want to remove the injection molding burs if possible. It is a shame that the shim was needed.
It might also be worth opening up the device and removing the selector switch, carefully (this can be pretty tricky), making sure the PCB underneath it is fine.
It could be that the brushes aren't perfectly housed, or that one of the brushes has two spring contacts stacked on-top of each other (happened once in pre-production, but thought this was sorted out).
The shim is installed as it should be no worries there (but will triple check). The selector switch on the PCB is very difficult to take out as the three (3) plastic prongs are super difficult to squeeze and thereby remove the switch. I did this once and it already damaged the plastic prongs from the outside. I guess that if I start to remove this once more, or you have a smart tip, I will start to ruin more and more of the selector PCB switch. As a last request to you I would like to request a new one if possible and then will take the old one out. Is this an idea?
Just an update, new meter arrived and it works flawlessly, slight blip on the shroud but nothing to write home about, switch is fantastic, tested well in cal, firmware updated perfectly
I noticed the meter will auto-power off while in BT communication mode. I noticed this while logging some data and I wondered why the screen and graph froze. I suspect that auto-power off should be suspended while BT communication is enabled?
This is an option, at least manually, you can disable APo in the settings menu.
Long time reader first time poster. Received My 121gw (Thanks), and was playing around and found the burden voltage with firm ware V1.17 to be less than spot on, and totally not working with the new V1.21 firmware, only tested dc amps, (all ranges) so far.
Quote from: Bugsyson on Today at 01:44:28 pm (https://www.eevblog.com/forum/index.php?topic=101807.msg1614049#msg1614049)Long time reader first time poster. Received My 121gw (Thanks), and was playing around and found the burden voltage with firm ware V1.17 to be less than spot on, and totally not working with the new V1.21 firmware, only tested dc amps, (all ranges) so far.
I have never been able to make the burden voltage appear. How did you achieve that?
With "bd.OFF" in upper display, hold setup till display blinks , select "be.ON" with REL or 1ms PEAK , hold setup button again till display blinks (beeps if you have that on) then press setup one more time to display "b 0.0 mV"There is a bug (I think) in 1.17 and 1.21 where if you go from bd.off, switch mode to bd.on, and then press setup to apply without holding for some length (1/2-1 second), then i goes in to a weird state where it says bd.on but never actually displays burden voltage. Must hold setup button for some period.
With "bd.OFF" in upper display, hold setup till display blinks , select "be.ON" with REL or 1ms PEAK , hold setup button again till display blinks (beeps if you have that on) then press setup one more time to display "b 0.0 mV"
There seems to be a problem with auto-ranging up from the 5 mA range to the 50 mA range. The meter seems to get confused and cannot lock into the reading. See video linked, where I have slowly ramped the current up from around 3 mA to around 30 mA. This is with firmware 1.21. Does anyone else see this?Yes, but only when burden volt mode is on; meter tries to switch out of the 5ma range to the 50ma range but gets stuck edit FW V1.21
Had the same auto ranging issue, also seem to have locked my meter up, reading 50mv all the time now (in A/mA rang), removed batteries no help, only thing that will make it go away is to put a banana plug into the mAuA jack. Fuses good, never went above 100mA while playing around with the burden voltage. Went back to 1.17 also no help...If software, there must be someway to do a factory reset? Settings seem to persist after pulling main and rtc batts and across firmware updates.
Is there a change log for the new firmware 1.21?not yet afaik
There seems to be a problem with auto-ranging up from the 5 mA range to the 50 mA range. The meter seems to get confused and cannot lock into the reading. See video linked, where I have slowly ramped the current up from around 3 mA to around 30 mA. This is with firmware 1.21. Does anyone else see this?
https://youtu.be/AOJ8776Qg5Y
Could you attempt the same test without the burden voltage measurement?I am seeing it too, but only when burden volt mode is on
This is because when burden voltage measurement is switched on the multimeter alternates between voltage and current, this might be reseting the auto-ranging.
Had the same auto ranging issue, also seem to have locked my meter up, reading 50mv all the time now (in A/mA rang), removed batteries no help, only thing that will make it go away is to put a banana plug into the mAuA jack. Fuses good, never went above 100mA while playing around with the burden voltage. Went back to 1.17 also no help...
Had the same auto ranging issue, also seem to have locked my meter up, reading 50mv all the time now (in A/mA rang), removed batteries no help, only thing that will make it go away is to put a banana plug into the mAuA jack. Fuses good, never went above 100mA while playing around with the burden voltage. Went back to 1.17 also no help...
What happens if you manually range to a different range?
Had the same auto ranging issue, also seem to have locked my meter up, reading 50mv all the time now (in A/mA rang), removed batteries no help, only thing that will make it go away is to put a banana plug into the mAuA jack. Fuses good, never went above 100mA while playing around with the burden voltage. Went back to 1.17 also no help...
What happens if you manually range to a different range?
See video, having a read through the cal procedure, do you think it may be possible it was cal's with a lead in the mA/uA jack?
https://www.youtube.com/watch?v=NqbcHCiH5Ew (https://www.youtube.com/watch?v=NqbcHCiH5Ew)
Yes can manual range in both cases, every time you cycle a plug into the jack it goes into auto range.
Yes can manual range in both cases, every time you cycle a plug into the jack it goes into auto range.I can confirm this, it does reset to Auto when you cycle the plug. It’s also the reason that Auto Hold messed up with one of my tests. But I don’t know if the auto hold issues was worked on in the new firmware 1.21 since I came across a different error specifically to my meter in the 50M \$\Omega\$ range. I sort of gave up on testing for now since this one is a hardware issue. That’s why I was wondering if a change log was published for 1.21 firmware.
Yes can manual range in both cases, every time you cycle a plug into the jack it goes into auto range.I can confirm this, it does reset to Auto when you cycle the plug. It’s also the reason that Auto Hold messed up with one of my tests. But I don’t know if the auto hold issues was worked on in the new firmware 1.21 since I came across a different error specifically to my meter in the 50M \$\Omega\$ range. I sort of gave up on testing for now since this one is a hardware issue. That’s why I was wondering if a change log was published for 1.21 firmware.
Scott
Yes can manual range in both cases, every time you cycle a plug into the jack it goes into auto range.
It still displays 50 mA in both cases?
I suspect at some point your full scale range calibration for that range was calibrated while open circuit. Is this possible?
Yes can manual range in both cases, every time you cycle a plug into the jack it goes into auto range.
It still displays 50 mA in both cases?
I suspect at some point your full scale range calibration for that range was calibrated while open circuit. Is this possible?
Have definitely not been in the cal mode, and it really thinks there is 50 extra mA, but only when plugged into the Amp Jack, readings are all good when using the mA/uA jack.
So what range is the bad one? The 50mA or 500mA, or should I just try and cal both, best I have is an 20 year old fluke 87 ( been calibrated every year) and a 87v never cal'd. Should be alright eh...
There seems to be a problem with auto-ranging up from the 5 mA range to the 50 mA range. The meter seems to get confused and cannot lock into the reading.
Could you attempt the same test without the burden voltage measurement?
This is because when burden voltage measurement is switched on the multimeter alternates between voltage and current, this might be reseting the auto-ranging.
So what range is the bad one? The 50mA or 500mA, or should I just try and cal both, best I have is an 20 year old fluke 87 ( been calibrated every year) and a 87v never cal'd. Should be alright eh...
500mA? Thats the one with the error right (getting worried)?
Only calibrate Offset.
It looks like there is a solder bridge on AD8436.It's probably fine as the schematic shows the two pins shorted; bridging ok in another spot https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1408213/#msg1408213 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1408213/#msg1408213)
Also, U3 pin 6 shorted to pin 7....?Does look kinda iffy
The attached picture shows the problem I found. It looks like something is wrong with SMT process.Nothing is missing from what I can tell; unpopulated locations seems to be same as mine
Please let me know if the components are not lost, I only need to welding them.
Not sure if anyone encountered this or I just unlucky.
I found my meter reading for voltage rather unstable for some time until today I find it is actually the probe problem.
The black probe jumps around 40-500kohm and after playing for a while it is completely open circuit now.
(https://uploads.tapatalk-cdn.com/20180623/9212a7874d01c204550346d65bfe1ae9.jpg)
The probes came with the meter is really nice and I can’t find a replacement source for it. Any tips how can I get this fixed?
So 95 % of the time the random numbers come up instead of blanking the display while changing ranges. It only occurs on the top M Ohm range and will blank as soon as the auto ranging starts.
Do others see this effect on theirs with firmware version 1.07. ?.
Yes, I see the same thing with 1.07. When the probes are applied to a resistor the screen blanks for a moment, then shows a random bad value and pauses for a second or two with no sign that it is still working to find the correct value, then it blanks again briefly before showing the correct value with relatively rapid updates to the lest significant digits.
Mine does this with v 1.22 (and did it with 1.17 and 1.21). When set to Ohms almost every time I short the probes it will display a random reading in the MOhm range for about a second then it will start autoranging and giving me accurate readings.
It's just cosmetic but I really don't like it, because for a moment it sure looks like it thinks it's giving me an accurate reading.
Do they all do this?
Mine does this with v 1.22 (and did it with 1.17 and 1.21). When set to Ohms almost every time I short the probes it will display a random reading in the MOhm range for about a second then it will start autoranging and giving me accurate readings.
It's just cosmetic but I really don't like it, because for a moment it sure looks like it thinks it's giving me an accurate reading.
Do they all do this?
Yes, mine does this. I have been debating whether to log this as a formal issue. I think I may do so.
Mine does this with v 1.22 (and did it with 1.17 and 1.21). When set to Ohms almost every time I short the probes it will display a random reading in the MOhm range for about a second then it will start autoranging and giving me accurate readings.
It's just cosmetic but I really don't like it, because for a moment it sure looks like it thinks it's giving me an accurate reading.
Do they all do this?
Yes, mine does this. I have been debating whether to log this as a formal issue. I think I may do so.
Mine with v1.22 only does this sometimes, mostly it's straight to ohms range.
I think if I tap the probes slower or with less force then it happens more, but I'd have to do controlled tests to really see that.
Are you touching the probes with your fingers?
Mine with v1.22 only does this sometimes, mostly it's straight to ohms range.
I think if I tap the probes slower or with less force then it happens more, but I'd have to do controlled tests to really see that.
Are you touching the probes with your fingers?
has anyone tried Low Z measurements? Can somebody check for me if it works for voltages below, say, 5V?
Same experience with emails.
BTW, has anyone tried Low Z measurements? Can somebody check for me if it works for voltages below, say, 5V? It doesn't work for me even on latest firmware (but I think I destroyed calibration data, so can be my bad if it's fixed). It would be great to have a list of bugs somewhere to see what's fixed and what is not.
Low Z is not designed for low voltages. It is designed to eliminate ghost voltages (usually on higher voltage AC lines).
It is not expected that this range work below around 12V.
I have still not received the shim.Please leave us a PM, we will take care of it.
I emailed dave, david and susan multiple times about this, yet never got a reply back.
I'm pretty disappointed how this is being handled by dave..
Another point I found was when I was doing the overnight SD card data logging.
one of the file had garbled data in the file, when I was testing for the thread in the forum.
https://www.eevblog.com/forum/testgear/new-eevblog-branded-multimeter-coming/msg1398530/#msg1398530 (https://www.eevblog.com/forum/testgear/new-eevblog-branded-multimeter-coming/msg1398530/#msg1398530)
The data is corrupted as bellow in the middle of the data.
59625,DCV,049.997,V,,,,,,,,
59626,DCV,049.997,V,,,,,,,,
59627,DCV,049.996,V,,,,,,,,
59628,DCV,049.997,V,,,,,,,,
59629,DCV, 59641,DCV,050.001,V,,,,,,,,
59642,DCV,049.996,V,,,,,,,,
59643,DCV,049.996,V,,,,,,,,
59644,DCV,049.998,V,,,,,,,,
59645,DCV,049.996,V,,,,,,,,
The garbled line only happened in one line out of four files of data logging.
The other three files had no issue.
The firmware is 0.01 and the SD card is the SunDisk which is included in the meter as a factory default.
I attached the original file with zip compression to work around the file size limitation on the forum.
Hope these report help improving the meter.
That black plastic molding for the switch is either cracked or malformed. I would ask for a replacement part for it, but I'm guessing they will replace the meter with one that works.Are you talking about the rotary switch? It is perfectly fine, it may look worse because of the lighting.
I really thought the quality of this UEI manufactured meter would be better than this! Having said that, my meter works fine and I'm loving it.
Dave or David - It would be good to have a version or date for the manual on the 121gw page. Today I got the Kickstarter reminder on firmware (I already had 1.22) and manual updates. I tried to download the manual to see if it is newer than the 24 May version I have. The download was very slow (5+ minutes) so I just canceled.
Maybe the Kickstarter reminder caused a server overload? (Mostly joking about that).
In any case, if the manual version was listed I might not have needed to attempt the download.
Got my meter today. Worked great first time I turned it on. Then I went to monkey with it later and found that the date and time wouldn't save no matter what I did. Anyways I kept messing with the settings and next thing I know nothing works. The light started turning on and off and it switched from AC/DC reading. I think it must be the mode button. This makes sense because when I turn it on it starts the cal process and displays "Cal.1" . I took it apart to try to take a look but nothing obvious is wrong. Tried updating the firmware, no luck.
Anybody else having these issues?
Where do I go to actually report this so I can get a replacement?
Edit: After looking at some pictures I took, it seems the pull-up resistor R3 is not populated. (I'm guess the X in the diagram means do not populate so thats fine) That means they're doing the pull-up on the STM32. Any chance this may be the cause of my issues? Issue is frustratingly intermittent. Firmware U-1.22
The solder mask, center left is damaged, this is a manufacturing defect, this unit needs to be replaced.I don't see any solder resist damage :-//. However C23 is soldered on footprint of larger size and looks like tombstoned. Although it might be just lighting.
Please PM me your backer details, email address for correspondence and address (if it changed).
The solder mask, center left is damaged, this is a manufacturing defect, this unit needs to be replaced.I don't see any solder resist damage :-//. However C23 is soldered on footprint of larger size and looks like tombstoned. Although it might be just lighting.
Please PM me your backer details, email address for correspondence and address (if it changed).
That's light reflection, not damaged solder resist.The solder mask, center left is damaged, this is a manufacturing defect, this unit needs to be replaced.I don't see any solder resist damage :-//. However C23 is soldered on footprint of larger size and looks like tombstoned. Although it might be just lighting.
Please PM me your backer details, email address for correspondence and address (if it changed).
Circled areas: https://imgur.com/a/dAZVSSC
Hello. I'm backer #1063. I got my 121GW meter today and was super excited. That is until I tried to turn it on, and nothing happened... I've checked the factory installed batteries and they're fine. Can any one help me either get this one fixed or tell me if there's a reset button I could try?
Thanks
Hello. I'm backer #1063. I got my 121GW meter today and was super excited. That is until I tried to turn it on, and nothing happened... I've checked the factory installed batteries and they're fine. Can any one help me either get this one fixed or tell me if there's a reset button I could try?
Thanks
That's light reflection, not damaged solder resist.The solder mask, center left is damaged, this is a manufacturing defect, this unit needs to be replaced.I don't see any solder resist damage :-//. However C23 is soldered on footprint of larger size and looks like tombstoned. Although it might be just lighting.
Please PM me your backer details, email address for correspondence and address (if it changed).
Circled areas: https://imgur.com/a/dAZVSSC
I think we should reserve that judgment to comeau, he will have a definitive answer to that.
I don't see any solder resist damage :-//. However C23 is soldered on footprint of larger size and looks like tombstoned. Although it might be just lighting.
FYI the July 9 Manual link provides a Manual with 25 June on the front page.Dave or David - It would be good to have a version or date for the manual on the 121gw page. Today I got the Kickstarter reminder on firmware (I already had 1.22) and manual updates. I tried to download the manual to see if it is newer than the 24 May version I have. The download was very slow (5+ minutes) so I just canceled.Good idea, I'll add it now.
Maybe the Kickstarter reminder caused a server overload? (Mostly joking about that).
In any case, if the manual version was listed I might not have needed to attempt the download.
Edit : Added, your manual is out of date.
Fixed, thanksFYI the July 9 Manual link provides a Manual with 25 June on the front page.Dave or David - It would be good to have a version or date for the manual on the 121gw page. Today I got the Kickstarter reminder on firmware (I already had 1.22) and manual updates. I tried to download the manual to see if it is newer than the 24 May version I have. The download was very slow (5+ minutes) so I just canceled.Good idea, I'll add it now.
Maybe the Kickstarter reminder caused a server overload? (Mostly joking about that).
In any case, if the manual version was listed I might not have needed to attempt the download.
Edit : Added, your manual is out of date.
That video link comes up unavailable.
Haven't seen quite this issue posted. Appears the auto range doesn't work when the meter's batterys are at ~5.2V and try to measure something around 6V. It is supposed to work with the batteries as low as 4.2After further testing it appears this auto ranging issue only happens in DC+AC mode and is completely unrelated to meter battery voltage. I tested in AUTO DC with meter battery voltage down to 4.0V and auto ranging and indicated voltage was the same as with 6.2V meter batteries. The low battery indicator came on at exactly 4.2V as the manual says.
https://youtu.be/CXcKBs3Twv8 (https://youtu.be/CXcKBs3Twv8)
Worked ok with the measured batteries in the meter. Will try some more experiments with different voltages.
I see some people commented on this earlier, but mine showed up and I'm a little concerned about the viewing angles on the screen. I had to adjust the contrast up to the max value but it didn't help with the angle. Looking straight on, or sitting on the desk propped up on the tilting bale the display looks pretty hazy. This is accentuated if you're looking down at it. You really have to be looking at it from a very shallow angle, more or less looking up at the screen, to make it look crisp. In person it's much more pronounced than the pictures, but they were the best I could get and should get the point across. These pictures are with the backlight on, but there is no difference when it's off.
WRT the ohms autoranging situation, the thing that kind of annoys me, and you can see it in Dave's video; https://www.youtube.com/watch?v=uUCQuIp_hzU&t=72s (https://www.youtube.com/watch?v=uUCQuIp_hzU&t=72s) is that it seems to always display a spurious value in the 5-50 Mohm range first, even though the resistance is much smaller, before blanking the display as it autoranges. My Fluke 179 doesn't display a false reading like that while autoranging (haven't yet had a change to try out my various bench meters).Others have noted this above and yeah its something that should be fixed for a more 'polished' feel to the meter.
Nice meter otherwise though!
Inaccurate on DC mA measures in the Auto and 5 mA ranges when reading 1.00 mA DC.
Got my meter this week, updated to U 1.22. Batteries at 6.0 V. Burden voltage off.
I wanted to confirm the meter was at least close to spec using my DMMCheck Plus.
Everything ok, except having significant issues with the 1.00 mA DC standard. On Auto DC mA, i get readings ranging from 0.46mA, to nearly there at 0.953 (every time I change back to Auto, i get a completely different reading ). If i change range to 5mA range, I get the similar varying and inaccurate readings. When I change down to the 50 mA range (the one showing 3 places after decimal), it's fine at 0.998, and consistent every time.
It is consistently fine on the 1mA AC standard. Voltage and resistance readings all fine. It's just the mA readings on Auto or 5 mA DC range. I'm baffled.
Do I have a lemon :scared:?
--adam
Here are several pictures:. . . .
Everything ok, except having significant issues with the 1.00 mA DC standard. On Auto DC mA, i get readings ranging from 0.46mA, to nearly there at 0.953 (every time I change back to Auto, i get a completely different reading ). If i change range to 5mA range, I get the similar varying and inaccurate readings. When I change down to the 50 mA range (the one showing 3 places after decimal), it's fine at 0.998, and consistent every time.
It is consistently fine on the 1mA AC standard. Voltage and resistance readings all fine. It's just the mA readings on Auto or 5 mA DC range. I'm baffled.
Do I have a lemon :scared:?
--adam
Perhaps a lemon lets see.
1. Can you take a photo/s of your setup, with enough angles to fully describe the test setup?
2. Can you place a second meter in series with the measurement to confirm the current is what it claims at the moment it is tested?
The default contrast setting on mine (4) was way too low though, I have mine set at max (7) and do wish it would go a little higher.Same with mine. The default 4 was far too low if viewed straight on. The max 7 is about 90% of the way there but 1 more notch would have made it perfect. There seems to be significant variation in the LCDs if some are okay with 4.
The default contrast setting on mine (4) was way too low though, I have mine set at max (7) and do wish it would go a little higher.Same with mine. The default 4 was far too low if viewed straight on. The max 7 is about 90% of the way there but 1 more notch would have made it perfect. There seems to be significant variation in the LCDs if some are okay with 4.
The default contrast setting on mine (4) was way too low though, I have mine set at max (7) and do wish it would go a little higher.Same with mine. The default 4 was far too low if viewed straight on. The max 7 is about 90% of the way there but 1 more notch would have made it perfect. There seems to be significant variation in the LCDs if some are okay with 4.
Auto-Hold issues (FW 1.22), I notice there already are some reports on this, but anyway.
I can't get Auto-Hold to work properly in Resistance mode. Measuring resistance in it self works fine but using Auto-Hold I get totally wrong values. It seems to be related to Auto-range because selecting a manual range Auto-Hold seems to work (within that range), but in Auto-Range my 121GW will beep as if it captured the reading but the value it displays is totally wrong.
Auto-Hold issues (FW 1.22), I notice there already are some reports on this, but anyway.
I can't get Auto-Hold to work properly in Resistance mode. Measuring resistance in it self works fine but using Auto-Hold I get totally wrong values. It seems to be related to Auto-range because selecting a manual range Auto-Hold seems to work (within that range), but in Auto-Range my 121GW will beep as if it captured the reading but the value it displays is totally wrong.
This I also observe. My impression is that it was working better until people complained it was too slow. In the attempts to speed it up it seems to have got broken. I would prefer if it went back to being slow and reliable.
Voltage measurement DC + AC Auto-range loops forever
David DLC
Voltage measurement DC + AC Auto-range loops forever
David DLC
Regarding this issue and the resistance/capacitance issue do you have some specific values that you have found produce the auto ranging loop. I have experienced that loop before but cannot get it to happen under controlled conditions.
You can try these. Looks like others are seeing it now as well.
https://youtu.be/RgzBC40gCoY?list=PLZSS2ajxhiQDBDdtQNjVnGxShaVQ3nUMY
You can try these. Looks like others are seeing it now as well.
https://youtu.be/RgzBC40gCoY?list=PLZSS2ajxhiQDBDdtQNjVnGxShaVQ3nUMY
I haven't been following this meters progress nor read all of the associated threads and I don't know if this has been mentioned previously so please forgive me if it has. I am aware that the meter Joe Smith was testing in the video linked above was a pre-production model and that the current version may perform in an entirely different manner.
Anyway, at 2:59 in the video with approximately 20 volts applied and whilst manually cycling through the ranges the meter displayed 20.62 volts then 206.2 volts, the applied voltage was exactly the same but the decimal is in the wrong location, can somebody else please confirm what I saw and if it has been mentioned already then I will delete this post.
I imagine they know it's a pre-production meter.
I am not aware of a way to display the firmware version. I have never attempted to update this one as there is no mention of a way to back it up. It would be prior to 1.00 as there appears to be no support for exporting the calibration data. It does however give them one more data point if they suspect the firmware.
For the auto hold when measuring resistance, I had tried various values from 10ohms to 10M and it seems to work as I would expect.
A few times now, I've touched the screen with the meter off and a few random segments turned on briefly. Static electricity?
Hi Seppy,Frank, thanks for the detailed look, everybody complains about poorly written manuals but nobody helps to fix. :-//
I have finally summarized the errors / gaps of the latest manual, 9th July, see doc file.
...
Frank
Hi Seppy,
I have finally summarized the errors / gaps of the latest manual, 9th July, see doc file.
During these investigations, I found a malfunction of the DC burden voltage item.
When I initially toggled to bd.on in any DC A range, the burden voltage display wouldn't appear, even not on the mobile via BT.
Only after I once engaged bd.on in AC A mode, it directly functioned there, and afterwards, also in DC A mode, permanently.
Seems to be a missing initialization flag in the 1-22 firmware.
Frank
PS: I'm still investigating on the spurious instability of the 5M and 50M ranges..
A few times now, I've touched the screen with the meter off and a few random segments turned on briefly. Static electricity?I noticed that when I took off the protector. I put it back on and reduced it again to confirm and yes, the LCD does show to ‘illuminate’ certain elements with a discharge like that.
- For frequency: I don't think offset is calibrated, only gain.
- For frequency: I don't think offset is calibrated, only gain.
Of course you're right.. I was completely confused, that Frequency even showed up in this list, and by the term 'Factory Calibrated'
Anyhow, as LowZ does not require any calibration at all, i.e. also no offset calibration, you simply might take both modes out this list.
And it's not clear from the table on page 69, whether capacitance needs any Offset alignment.
Thanks for all your effort,
Frank
Kellee Crisafulli – July 21, 2018
2018-07-20, I was pleased to received my 121GW a couple days ago, first reaction is very cool 🙂
I plugged it into a Tektronix 515A meter calibrator to run a fast out of the box accuracy check.
Tested AC volts at 400hz, 1KHz, 50KHz, 1V to 100V, appeared to be within stated accuracy.
Tested DC volts 25uV to 100.0V and appeared to be within stated accuracy.
Test Ohms from 0 to 1MEG appeared to work OK.
10 Meg Ohms looks a bit “wonky” reading ~9.7 Mega Ohms +- 200K depending how I hold the cable, position of my hands, and if I blink or not (kidding). Other handhelds and my bench meter indicate very close to 10.00 Meg no matter which way I hold the cable.
As Dave might say “That’s a fine how do you do”, seriously something on the 10M scale appears to have a noise issue, not a show stopper but interesting…
That’s all the testing I have done so far.
AC+DC Mode while measuring 230VAC Mains do not shows anything to me: autorange goes in loop?
:-//
Interesting,
Can you repeat the experiment with the R DUT in a closed box and by using coax BNC cables to the 121GW, surely you have some of those adapters:
I don't remember the pre-production meter being all that unstable.
Could you please remind me how 50/60Hz filtering works? I thought there are only three ways of get rid of ripple: 1) synchronize measurements to mains frequency 2) set integration time (or whatever) equal to one period of sine. 3) low-pass filter, but it may make DMM unresponsive and slow to settle.
1) Impossible on a battery device with no main input.
Any chance of detecting lower than 12V on Low Z mode in the future firmware upgrade?
Hello,
I finally analysed the Ohm function.
The 500k and 5M ranges are especially unstable, sometimes giving an unreadable display.
But sometimes, also the 50 Ohm range is unstable on the last two digits, but may stabilize after some 'warmup'.
The 50M range sampling rate is a bit slower, and therefore delivers more stable readings, which makes sense for these high values.
Anyhow, it seems that in this range, there also exist some disturbance, which cause a virtually static shift of the reading (gain error).
I have digitized the probing current of the 121GW by means of my 34465A.
All currents from 470µA down to 20nA, were absolutely stable apart from some amplifier noise.
When I digitized the voltage across the D.U.T. resistor, I encountered a huge 50Hz signal, 100mVpp @ 700mV DC, which might be picked up by the mains environment (Germany = 50Hz). The 121GW seemed to be extremely sensitive to that 50Hz pickup, although its A/D should suppress the mains frequencies of either 50Hz, or 60Hz.
I have the suspicion, that the sampling rate especially in Ohms mode is not selected correctly, for 60Hz only, so that this would be stable in U.S. or other countries with 60Hz mains frequency, but unstable here in Europe.
Do other owners here in EU see that same effect?
How can I check inside the guts of the 121GW, which mains frequencies are suppressed?
Frank
Hello,
I finally analysed the Ohm function.
The 500k and 5M ranges are especially unstable, sometimes giving an unreadable display.
But sometimes, also the 50 Ohm range is unstable on the last two digits, but may stabilize after some 'warmup'.
The 50M range sampling rate is a bit slower, and therefore delivers more stable readings, which makes sense for these high values.
Anyhow, it seems that in this range, there also exist some disturbance, which cause a virtually static shift of the reading (gain error).
I have digitized the probing current of the 121GW by means of my 34465A.
All currents from 470µA down to 20nA, were absolutely stable apart from some amplifier noise.
When I digitized the voltage across the D.U.T. resistor, I encountered a huge 50Hz signal, 100mVpp @ 700mV DC, which might be picked up by the mains environment (Germany = 50Hz). The 121GW seemed to be extremely sensitive to that 50Hz pickup, although its A/D should suppress the mains frequencies of either 50Hz, or 60Hz.
I have the suspicion, that the sampling rate especially in Ohms mode is not selected correctly, for 60Hz only, so that this would be stable in U.S. or other countries with 60Hz mains frequency, but unstable here in Europe.
Do other owners here in EU see that same effect?
How can I check inside the guts of the 121GW, which mains frequencies are suppressed?
Frank
I don't recall seeing that here (we use 50Hz too).
We'll have to do more testing to see if it can be replicated.
Assuming you feel the meter is sensitive to something going on with the mains...
Firmware 1.22
I logged my mains voltage for 1 hour plus a few minutes. (MEM button) Logging interval 1 second.
I stopped the logging when the display said 4049 data points.
Issue 1: When reviewing the data on the instrument, it only steps from 1 to 60 and then back to 1 (maybe it should be like that, I don't remember), and the decimal point is in the wrong place. It says 2350.4V for example, not 235.04V.
Issue 2: When loading the data off of the SD-card, the data is only 3990 lines. Not 4049. They're all consecutive. And the decimal point is in the right place.
Issue 3: This is really weird. Look at the attached diagrams. I find the regularity in the right half highly unlikely. Exactly 60 second periods. I must log for longer to see what that looks like.
The preproduction meter is also sensitive to the proximity of my hand, similar to that Gossen I looked at but not to that extent.
As an example, here's one log of 1000 samples, 5M range, 1.9000 MOhm from the 5450A, short cables, 'noise' is 0.4%RMS or 1.3% PP.
That's not usable at all.
Frank
PS: I've verified, that the correct XTAL of 4.9152MHz is assembled, and also re-soldered these bad junctions J1 / J2 (wrecking my soldering tip by the lead-free stuff) - no change at all.
UEI manufacturing also burnt the edge of one coil a bit.. :palm:
Don't know if it is mentioned already, but I got mine today and I noticed some segments on the screen turning on as I peeled off the protective film.
I attempted to repeat your test the best I could. I am using a few Caddock TK series resistors to make up roughly 1.9M. The two plots shown are my HP34401A (white) compared with the pre-production 121GW (red). I have also included the CSV file off the meter (renamed to .txt to allow uploading). The recording interval is 1 second for both meters.
Looking at the schematic, nothing pops out other than you should have a better reference. A bit odd you don't see the problem in every range.
Added your data set for completeness.
I attempted to repeat your test the best I could. I am using a few Caddock TK series resistors to make up roughly 1.9M. The two plots shown are my HP34401A (white) compared with the pre-production 121GW (red). I have also included the CSV file off the meter (renamed to .txt to allow uploading). The recording interval is 1 second for both meters.
Looking at the schematic, nothing pops out other than you should have a better reference. A bit odd you don't see the problem in every range.
Added your data set for completeness.
Hello Joe,
thanks for your tests.. the measurement of the 1.9M inside the 5450A by a 34465A, or a 3458A at NPLC 10 is as stable to the last digit, as yours with the 34401A, but w/o drift.
I could replicate that instability with other very stable 1M resistors and short, drilled cables also, but sometimes, I also get stable readings.. very strange.
So I wonder, what you mean by 'you should have a better reference', do you mean the 121GW internal reference resistors?
I doubt that these are the root cause for this instability problem.. because the Ohm mode is usually realized by a ratio measurement, so I suppose, that it's caused by the AD1.
And yes, this instability is visible part time in other ranges also, surprisingly in the 50 range, although that's driven by a high 470µA current.
Maybe you still have an old firmware running. In the latest 1-22, the counter register for the sampling frequency might be set improperly. Otherwise, 50 and 60Hz should be suppressed by 120dB @ 5Sa/sec, but 75dB only, when using a faster sampling rate... that could also be the case, as the sampling seems much too fast.
Maybe something inside the Ohm circuit is oscillating, or super sensitive, depending on the hardware version..
I did not fully understand the schematics, either, and also the HY3131 datasheet is really crap., still searching for an Application Note.
Anyhow, I really think, that this problem could be solved by software.
Frank
.. I updated the pre-production meter to 1.02 then saved the calibration data. I then proceeded up upgrade the meter to 1.22.
I remember reading something early on about the firmware may have required the meters to be realigned. This appears to be the case but it should be good enough to see if running the latest firmware will cause the noise problem.
...
*********** Update *************
...
One last note, it does appear that at least with a 0.5 ohm resistor, with the 1.22 firmware installed, the readings are VERY unstable. The meter will display 0.5 and noise for the other two places. After downgrading, the meter again changes a couple of counts at most. So it does appear that the noise people are seeing could very well be due to the firmware. The other thing I noticed is the display update rate for the low values is much faster with the 1.22 firmware.
Both date and time is on the first row in the file, then it says what interval is used. So it is not impossible, just somehwat cumbersome. Add another column, copy the time from the top row, then next row is the one above+(interval in seconds)*(1/86400). If using excel or the like. Otherwise I suppose a script could be used...
But it would be very easy codewise to implement the timestamp into the log file, so we don't have to mess around like that.
One detail paid my attention: I barely can read red labels. Too dark tone compared to the background.
The default setting is to sample and save points as fast as the ADC allows, hence the interval is not fixed but depends on the mode, range, etc. It is therefore impossible to calculate the time for each point using the default setting.
However it is true that if you change the settings and limit yourself to a slower sampling speed, i.e. not using the full potential of the meter, it does seem like the timing is consistent so that can assume a fixed number of seconds between each point. I tried it over 4 minutes using a stopwatch and I could not detect any drift or dropped points by eye at least. Hence I guess this is the recommended method for now.
In order to allow for faster sampling I guess you need the actual time in a column (seconds since start is probably easiest), as it would make analysis much easier without having to process the time manually every time. Also as a separate improvement I would remove the "mode" from being printed on every row, either print it once in the header or only print it when it changes (if you intend to include mode switching during logging in the future). This would save approx 10-30 % in space depending on the mode used.
I also noticed that the meter does not autorange during logging (it goes into manual ranging when starting the logging process). This is definitely a feature that I would like to see in future updates.
Edit:
More issues I noticed today:
- The claimed "update rate" is 5 samples/s nominal, however my display only updates 1-2 times/s, hence the meter feels slow and unresponsive, is this an error in the manual or is the meter supposed to be faster?
- When manually selecting the 10 A current range, the display tells you that you are in the 1000 A range. Perhaps there is no 10 indicator in the LCD and this is intended, if that is the case please update the manual.
- There is a 1000 V range, however the manual specifies maximum 600 V for the input protection. Perhaps this is the same issue as above? Please update the manual.
- There are no range indicators in the display for Frequency, Period, Capacitance. Perhaps indicators is lacking in the LCD? In that case I suggest to always show leading zeros in these modes when in a manual range. For example the 100 nF range, write 07.6 nF, instead of just 7.6 nF in order to indicate the amount of headroom available.
Arrived this morning. Flabbergasted. Cant use it, NO PROBES and no zippy-up case thing...
Can someone clarify the DC+AC mode? Should the meter show on the secondary display the AC or DC component? Are the segments in red circle for that purpose?\
What other DMM use the HY3131?
What other DMM use the HY3131?
Keysight U1282A
AC+DC mode means the meter measured the AC and the DC part of the voltage and then sums them together before showing them.That's not true. To avoid having Dave remove this post as a non-issue, the manual should be updated to show it as a feature and the proper equation should be added as well.
What the AC DC sgments next to the secondary display are for? Many manuals explain all the segments of the screen. It would be nice touch.
But I have measured the logging interval at ln 0 to be 4 Sa/sec, or 250ms, but not 5 Sa/sec, as implied in the manual.
That's important to know, if one makes timed logging of data.
But I have measured the logging interval at ln 0 to be 4 Sa/sec, or 250ms, but not 5 Sa/sec, as implied in the manual.
That's important to know, if one makes timed logging of data.
That is interesting, did you check if it was exactly 4 Sa/s in all ranges/modes or does it vary? I believe I read somewhere that it is "as fast as the ADC can sample" and that the speed depends on several factors.
When I look at the display I can see that the sampling numbers do not increment smoothly, perhaps this is only an issue with the update rate of the LCD?
Did you by chance try any of the older ones to see if your meter was stable? I suspect the pre-production meter will require realignment before I can use it again. If not, I will try 1.02 (assuming it uses the same tables) and report back.
It's possible that when the meter is in the calibration mode that they use different routines to sample the data. Maybe the notch is correct in this mode. Otherwise, I wonder what their process was to align them. Maybe they update the firmware again after alignment and that's why they did not catch this.
So I dug into the firmware and it's interesting. For the 5MΩ range, v1.02 configures an oversampling ratio of 4096 but v1.22 has it configured as 1024. That's the only difference in the chipset configuration. Presumably, they did this to help with autorange speed. You are also correct about C30; 50MΩ (which BTW has an oversampling ratio of 8192 on v1.02 and 16384 on v1.22) has it switched in, but 5MΩ does not. Try changing the byte at 0x1F732 in the v1.22 firmware from 0 to 8 to kick it in on 5MΩ too and see how much that improves things. The byte at 0x17F2A controls oversampling at 5MΩ, changing it from 0x10-0x17 changes the ratio from 256 to 32768 (i.e. 2^(n-8)).
So I dug into the firmware and it's interesting. For the 5MΩ range, v1.02 configures an oversampling ratio of 4096 but v1.22 has it configured as 1024. That's the only difference in the chipset configuration. Presumably, they did this to help with autorange speed. You are also correct about C30; 50MΩ (which BTW has an oversampling ratio of 8192 on v1.02 and 16384 on v1.22) has it switched in, but 5MΩ does not. Try changing the byte at 0x1F732 in the v1.22 firmware from 0 to 8 to kick it in on 5MΩ too and see how much that improves things. The byte at 0x17F2A controls oversampling at 5MΩ, changing it from 0x10-0x17 changes the ratio from 256 to 32768 (i.e. 2^(n-8)).
Is it possible to tweak the bin file with a HEX editor, and w/o any checksum alignment?
THX Frank
Could you also please check version 1.0 as well while I dig out a Hex editor...I'm sorry but I don't have that binary so I can't look. Please PM me a link or attach it.
I had attempted to patch the 1.02 as you suggested with the 4 bytes. I ran it but sadly when I went to retrieve the data, the file was not created. Anytime this has happened, the MEM is displayed and the counter is being updated. I press MEM, stop the logging and turn off the meter to pull the card, but there is no file. Maybe it's doing some house keeping on the card and I am not giving it enough time before turning off the meter.
Anyway, I have restarted this test. Once this is done, I will try the 1.0 version you patched as well. After I have all of the data, I will post a new set of plots.
Again, thank you for taking the time to help dig into this. Seems early when I saw you post, you did not yet have a meter. Is this still the case?
I spent some time running a few sweeps. The patch you provided acts very strange. It appears to log and actually creates the files. I am testing in the 5Meg range with the same 1.9Meg resistor I have been. While logging the meter displays 1.9Meg. I have attached the two files. At least it appears to be repeatable.
I encountered a bug with the logging: After logging temperatures for a long time (21 hrs) I got a file where a number of data points keeps repeating itself.
- Firmware 1.22
- Temperature logging
- Logging interval 145 seconds
- Total logpoints: 520, pretty much 21 hours of logging with that interval
- The logging was started and stopped normally through the mem-button
The first 180 points are normal. The next 60 points, however, keep repeating themselves. So logpoint 181 has got the same value as logpoint 241, 301, etcetera. See the attached file for a graph. The logged csv is available at: https://www.dropbox.com/s/1zq2uf1xgz10y9w/18073002.CSV?dl=0 (https://www.dropbox.com/s/1zq2uf1xgz10y9w/18073002.CSV?dl=0)
Firmware 1.22
I logged my mains voltage for 1 hour plus a few minutes. (MEM button) Logging interval 1 second.
I stopped the logging when the display said 4049 data points.
Issue 1: When reviewing the data on the instrument, it only steps from 1 to 60 and then back to 1 (maybe it should be like that, I don't remember), and the decimal point is in the wrong place. It says 2350.4V for example, not 235.04V.
Issue 2: When loading the data off of the SD-card, the data is only 3990 lines. Not 4049. They're all consecutive. And the decimal point is in the right place.
Issue 3: This is really weird. Look at the attached diagrams. I find the regularity in the right half highly unlikely. Exactly 60 second periods. I must log for longer to see what that looks like.
So the logging engine logs points to EEPROM. Every 60 points, it reads all the points from EEPROM and flushes them to SD card. If you power off the meter completely and restart logging, are the points still stuck there? You may have gotten a bad EEPROM for some reason. I can't think of anything else except a bad EEPROM or cosmic rays which would cause this. Maybe it got write protected somehow, but the built in write protection circuitry should have crashed the processor.
So the logging engine logs points to EEPROM. Every 60 points, it reads all the points from EEPROM and flushes them to SD card. If you power off the meter completely and restart logging, are the points still stuck there? You may have gotten a bad EEPROM for some reason. I can't think of anything else except a bad EEPROM or cosmic rays which would cause this. Maybe it got write protected somehow, but the built in write protection circuitry should have crashed the processor.
I just started a new log, I'll have a look tomorrow morning how it looks. Where did you see that the meter logs 60 points to EEPROM before flushing? I couldn't find any reference to that. I'm still cautiously optimistic that this is a software bug rather then a hardware error. Maybe this problem occurs universally with the above parameters and is being caused by the long interval, or the date ticking over to the next day during the measurement, or a combination or maybe something completely else. :-//
I'll also do some logging with a short interval, see where that leaves me.
Hi everyone,
I received my 121GW 2 weeks ago and am really happy with it, great job Dave!
It wasn't until this week that I had time to play with it. I decided to test the meter's ultra-low current measuring capabilities, something for which I've relied on my trusty EEVBlog uCurrent gold until now.
Good news: The 121GW can measure mA and uA very well, no need for my uCurrent anymore :)
But that's not what this post is about.
While comparing measurements of my uCurrent I hooked the uCurrent up to the 121GW, and set the 121GW to the mV measuring setting, and noticed something strange.
While the V setting seems to do fine, the mV setting is giving weird measurements. I couldn't identify another means of generating a reliable sub-10mV source right away, so I only tested with the uCurrent.
I made a video of the whole process since I'm not ruling out at all that I botched something which resulted in this behavior :):
https://www.youtube.com/watch?v=6OoFH99jLOU (https://www.youtube.com/watch?v=6OoFH99jLOU)
I had my bench PSU set to 10V and applied this across a 1.8k resistor. This should give ~5.5mA current, which I also did measure when I had to the 121GW set to V, but when I set it to mV, the results were way off, it was showing ~0.260 mV while I was expecting ~5.550. To my surprise, when dropping the voltage on my bench PSU to 5V (expecting to measure ~2.7mA or ~2.7mV on the uCurrent), the voltage on the 121GW went UP to ~2.000 mV ?!?
Something else which I forgot to record on the video, but perhaps someone else can try:
using the uCurrent, I was measuring an ESP module running at 70mA, with the 121GW set to V the measurement from the uCurrent was 0.0070V, which is correct.
But when I switched the 121GW to mV, the measurement was reading ~7.000mV, so there seems to be a decimal point issue here.
TPW, did you happen to archive the original firmware from the prototype meter?
The attached video is showing how the patched 1.02 compares with the original firmware's auto-ranging speed. If you have an older version, if may be worth understanding why there is such a dramatic difference.
This behavior to me is completely crazy. I don't quite understand the code behind the rules or what purpose they serve, but they are clearly there. I have no idea why they designed it like this.
I am not suggesting that the original firmware was bug free by any means. It makes me wonder if they (UEI) can't produce firmware for the meter, what's the future plans. It's painfully obvious they are unable to test the code they release. If you are going to charge a premium for it, it should at least perform as well as other meters in that price class and I don't see that happening today.
The card is a pain for logging. I have left the meter apart since starting this little side project. I don't have long enough finger nails to reach the card and my fingers are too large. So needle nose pliers.A small piece of tape on the card as a pull tab makes it so much easier to extract the card.
It makes me wonder if they (UEI) can't produce firmware for the meter, what's the future plans. It's painfully obvious they are unable to test the code they release.I wondering if it is because it is a STM32 inside and they're having issues with development + testing. The 121GW development video mentions that it originally a PIC with a choice of a MSP430 as well but UEI changed it for a STM32 later on.
The other great loss of an open source firmware is that UEI has presumably acres of expensive testing, characterization, and calibration equipment they can use to make the meter the best it can be (whether they use it is another matter). An open source firmware would have to rely on the generous effort of people like joeqsmith and others in this thread who have access to similar equipment in order to make the guarantees that make the equipment worth its price. Will this be practical? I guess we will soon see.
The other great loss of an open source firmware is that UEI has presumably acres of expensive testing, characterization, and calibration equipment they can use to make the meter the best it can be (whether they use it is another matter). An open source firmware would have to rely on the generous effort of people like joeqsmith and others in this thread who have access to similar equipment in order to make the guarantees that make the equipment worth its price. Will this be practical? I guess we will soon see.
UEI are seriously missing a trick here - Open Sourcing their code would make this meter into a unique platform, and the extra eyeballs would quickly solve these niggling firmware issues. They're likely worried about clones, but I doubt keeping the source secret will slow the cloners down much - they need to have more confidence in the value of their offering.
My opinion is that it's probably less about clones and more that UEI probably have quite a lot of routines and generic blocks of code in the meter that they use or want to use in forthcoming products and don't want to give those ideas away...…...I couldn't blame them for that. I think the fully open source idea would only have happened if it had been designed that way from the start......but then price point and timing would have been affected.
I wondering if it is because it is a STM32 inside and they're having issues with development + testing. The 121GW development video mentions that it originally a PIC with a choice of a MSP430 as well but UEI changed it for a STM32 later on.
I doubt that it should be that. Software engineering is a generic skill, just like hardware engineering. Apparently many weaknesses in the code relate to structure and organization, which would point to poor design skills.
Here's the behavior in v1.22. It's the same code as v1.02, except the "mode/range change delay" in ohms is now 0, i.e. the meter will perform an autorange on the next sample. This figure was 1 or 2 in v1.02, depending on range. To replace that, there is now an "autorange lock" function called right before the autorange change happens. Rule A: If not in ohms mode, the change is allowed. Rule B: If in ohms mode and changing to a lower range, deny changes for 1 second, then allow all changes. Rule C: If in ohms mode and changing to a higher range, deny the change, then allow one to happen in 1 sample. This leads to some bizarre behavior. If changing from a lower to a higher range, the meter will switch ranges quickly as expected. However, if changing from a higher to a lower range, Rule B above will force the meter to range down as quickly as possible, until either it's at the lowest range or a new ADC measurement arrives. Then it will use each sample to decide to range up, and eventually end up at the desired range. This behavior can easily be demonstrated by starting with open leads and connecting the meter to something like a 100k resistor.
I've done a complete reverse engineering (https://github.com/tpwrules/121gw-re) of the v1.02 firmware, which is how I know basically all the information I've posted in this thread.
how.
I pored over my disassembly for anything that could explain this bug but I don't see anything. The fact that it's writing bogus data but at a consistent interval is really weird. As you can see, someone else reported something similar. It's 100% a fixable software issue, except for maybe cosmic rays or damage to the EEPROM. Could you reprogram your meter with the v1.02 firmware and see if the issue is still there? I understand it a little more than v1.22. If you can't reproduce the issue, then I can look at what's changed between the versions for clues. Is there any chance whatsoever you own an ARM SWD CMSIS-DAP programmer?
There is a way to test if the EEPROM became write protected. Set up your experiment, start logging, wait however long, then hold the MEM button to turn off logging. Without turning off the meter, turn the dial to your favorite selection and note what mode is shown on the screen. Now, press the MODE key to change modes, and note what mode is now shown. Wait a few seconds, turn the dial to another selection, and then back to your favorite. If the mode shown is the one before you pressed the MODE key, the EEPROM is going into write protection somehow.
Hot off the presses is the v1.25 release, which claims to fix this behavior, and in fact does.I am not too surprised to hear this.
Also, auto-ranging seems to work fine now, no false intermediate readings any more, and auto ranging speed seems to be the same as before.
DavidDLC and joeqsmith,In my case, I am always referring to the data collected on the SD card. I have no desire to watch the LCD for 40 minutes and try to manually pick out any sort of trend.
concerning the noise, are you referring to data logged to SD card?
The reading on the display is now stable, compared to 1-22, and as far I could determine.
Frank
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine.
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine.
I bought the meter out of curiosity, and because it might have some useful features.
I have not had time to give it a comprehensive evaluation, but I have decided for now that I don't trust any of the resistance ranges.
So I for one don't think the meter is "fine". So far, it passes as a curiosity, but not as a working tool. For a working tool I trust my Brymen meters.
In my case, I am always referring to the data collected on the SD card. I have no desire to watch the LCD for 40 minutes and try to manually pick out any sort of trend.
Again, keep in mind this is not the same hardware you are testing. I have damaged the meter three times and have changed some of the hardware in an attempt to make it more robust. I have also completely realigned the meter. Maybe there is some other difference.
I would expect with your setup you should easily replicate anything I show. If you are seeing something different there must be something we have not accounted for.
I did make a short video for you. I start out with the modified 1.02 firmware. I just let it run for a few minutes. You can see the drift as the meter warms up. Again, I assume this is caused by the Hycon chip they chose. I always found it strange they used that part after Dave's review of the Keysight meter. Anyway, I then reprogrammed the latest firmware and let the meter run for 15 minutes or so to stabilize. I then captured some video while it continued to run for several more minutes.
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine. Perhaps they really have no need for a higher class meter and bought it for other reasons. Another possibility is they are not seeing the problem. If it's the later, then why.
I wondering if it is because it is a STM32 inside and they're having issues with development + testing. The 121GW development video mentions that it originally a PIC with a choice of a MSP430 as well but UEI changed it for a STM32 later on.
I noticed I have cracked the SD card connector. I am surprised none of the pins nave broke yet as many times as I have cycled the card in and out. I always saw this as a mechanically weak point and thought they would do something to try and make it more robust in the final design but it appears to still be the same.
I assume you checked your test setup before concluding the 121GW was defecting and returning it.
What's the output of your test signal look like? How did you check it?
. . . . I can make 121gw go +/- 30 counts depending on where I touch the cables. The U1252A only flicker on 1 count.it seems that the 121GW is excessively sensitive to either stray capacitance, or EM pickup, pushing it out of spec.
5 mA DC range FAILS again - can anybody replicate?
So i got a replacement 121GW after the problem i had with my first unit (see my posts
https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1692650/#msg1692650 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1692650/#msg1692650)
and
https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1693298/#msg1693298) (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1693298/#msg1693298))
I repeated the same tests with a 1 mA DC source, and got essentially the same results, here are photos showing the poor measurement on the 5 mA DC range, but the perfect measurement on the 50 mA range, on my Amprobe AM270 meter, and also using the uCurrent Gold.
Summary: On the 5mA DC current range, the 121GW reads off, and is quite significantly affected by touching the leads. None of these effects are seen on the 50mA range, on the Amprobe meter, nor when using the uCurrent.
Can anybody replicate these findings? Figure out a way to mitigate this problem? Should I consider the 5mA DC current range to be an "extreme" measurement and i'm just expecting too much? I wouldn't think so in a meter in this price range, considering the Amprobe is a significantly lower price class instrument. I kind of think Dave would be giving a Thumbs Down :-- on this performance if he was reviewing it.
Thanks.
--adam
This is the only change?
v1.26 is now on the website for download. We have not tried it yet, but UEi have said that it now logs the displayed data instead of the bargraph data. There should now be no noise on the logged data as per previous versions. Please try it and report.Dave sorry to report that the new V1.26 will not load!
v1.26 is now on the website for download. We have not tried it yet, but UEi have said that it now logs the displayed data instead of the bargraph data. There should now be no noise on the logged data as per previous versions. Please try it and report.Dave sorry to report that the new V1.26 will not load!
Tried numerous times and then copied V1.25 back onto the SD card and it loaded fine.
Maybe something wrong with the file image you have placed on your site to download?
5 mA DC range FAILS again - can anybody replicate?I just tried with firmware 1.25 and the 121GW of course and a Brymen 235, Fluke 27II and 2 other DMMs in series. As source I used my DMMCheck Plus vom voltagestandard.com as you did and I think I used the same green 4mm banana cable and the clips from Franky ;-). I could not reproduce the problem you have. So it may have something to do with your configuration I think. How about the 9V battery of your DMMCheck Plus, maybe it's somewhat flat even if the Amprobe shows the correct value?
5 mA DC range FAILS again - can anybody replicate?
So i got a replacement 121GW after the problem i had with my first unit (see my posts
I repeated the same tests with a 1 mA DC source, and got essentially the same results, here are photos showing the poor measurement on the 5 mA DC range, but the perfect measurement on the 50 mA range, on my Amprobe AM270 meter, and also using the uCurrent Gold.
Summary: On the 5mA DC current range, the 121GW reads off, and is quite significantly affected by touching the leads. None of these effects are seen on the 50mA range, on the Amprobe meter, nor when using the uCurrent.
Can anybody replicate these findings? Figure out a way to mitigate this problem? Should I consider the 5mA DC current range to be an "extreme" measurement and i'm just expecting too much? I wouldn't think so in a meter in this price range, considering the Amprobe is a significantly lower price class instrument. I kind of think Dave would be giving a Thumbs Down :-- on this performance if he was reviewing it.
Thanks.
--adam
I have this weird problem that started after I used the multimeter to log my socket voltage (230V AC, 50Hz) for a full day.
Now in VAC mode, the autoranging continuously hunts. If I manually select the range, it shows weird and very low values. It seems to get the frequency right though. It also shows the correct value in 1ms peak mode.
Is my meter farked?
EDIT: Tried installing latest (1.26) firmware. Nothing changed.
I have this weird problem that started after I used the multimeter to log my socket voltage (230V AC, 50Hz) for a full day.
Now in VAC mode, the autoranging continuously hunts. If I manually select the range, it shows weird and very low values. It seems to get the frequency right though. It also shows the correct value in 1ms peak mode.
Is my meter farked?
EDIT: Tried installing latest (1.26) firmware. Nothing changed.
Did you use the LoZ mode for this test, as you explicitly stated, to be 'NOW in VAC mode' ??
Frank
Do I want to even ask why you were trying to log the AC line.. Nah. Many people believe the meters don't need to survive a transient, just keep the operator safe. Sounds like you are still fine.
In Fubar.gr's case I wonder if they damaged their meter. The 121GW has a pretty weak front end compared with some of the other meters I have looked at. Maybe they will chime in again with more details about the other modes.
What about all of the other modes? No mention of them.
Do I want to even ask why you were trying to log the AC line.. Nah. Many people believe the meters don't need to survive a transient, just keep the operator safe. Sounds like you are still fine.
I had tried it as well towards the end of that last video. I asked them about trying it with a battery/resistor to at least eliminate their current source. No word if they did anything more with it. You don't by chance have one of those meter calibrator things do you?
Looking at their pictures, I thought I could pick up the same source but they are out of stock.
http://shop.voltagestandard.com/product.sc;jsessionid=DAEB70EDBC48F53DD528284FB53FCF35.p3plqscsfapp003?productId=5&categoryId=1 (http://shop.voltagestandard.com/product.sc;jsessionid=DAEB70EDBC48F53DD528284FB53FCF35.p3plqscsfapp003?productId=5&categoryId=1)
If you have a 121, it may be worth it. They claim 500mV compliance but that would be with a good battery. Looks like it has a microcontroller for some reason. Maybe try it with the source running off your bench supply and dial it down. Maybe it goes unstable before it drops out.
When in mA range without any probes connected the meter shows about 80 uA. When Inserting the probes goes to 800 nA and with the probes shorted it goes to 1.5 uA.
Something similar happens when in uA range. It is present only in DC mode. In AC everything is 0.000
Is it normal? Is it an effect of the opamp used for the low burden voltage?
Alexander.
Originally they were testing w/ 1.22 but I have no idea after that what was loaded. I installed 1.22 in the prototype and it seems just as stable. So I setup the Brymen BM869s next to the 121GW prototype and had some fun with the tape eraser.
It would seem that there are a few things that the OP could have going on.
*****
Combined it all into one video and added another test
If you have a 121, it may be worth it. They claim 500mV compliance but that would be with a good battery. Looks like it has a microcontroller for some reason. Maybe try it with the source running off your bench supply and dial it down. Maybe it goes unstable before it drops out.I have a dmm check plus and a 121gw.
Looking at the manual for the AM270, looks like in the 5000uA range its spec'ed at 150uV per uA. Maybe just stick a 150 ohm resistor in series with the 121 to simulate it.
Thanks you for the reply. I could understand it for 50 uA range and I mentioned it in my original post. But in 500 mA range also? And why only DC mode?
This offset current is always there. Regadless If I connect probes or not. I tested with many probes. With golden ones, even with a thick wire soldered directly in banana plugs.
And the most important is that the meter measures high in relation the the other meters I own. How much higher? 100 uA. Exactly the offset I see. If I rel the offset, it measures exactly like the others.
What the rest of you see if you sort COM and 500 mA input?
I am just trying to figure it out. To understand it.
Alexander.
Did you play with the calibration function of the 121GW?
Well, probably yes.
I already re- calibrated 3 of the Ohm ranges, because it was done improperly (not optimal) @ UEI...
It might depend on the environmental temperature, if this offset can be persistently be calibrated, may be it vanishes, when summer temperatures go back to normal.
I'm not sure, if a zero calibration only is possible, because both cal constants for a particular range are stored after gain adjustment only.
Therefore you might need a calibrated constant current source.
Frank
Well, probably yes.
I already re- calibrated 3 of the Ohm ranges, because it was done improperly (not optimal) @ UEI...
It might depend on the environmental temperature, if this offset can be persistently be calibrated, may be it vanishes, when summer temperatures go back to normal.
I'm not sure, if a zero calibration only is possible, because both cal constants for a particular range are stored after gain adjustment only.
Therefore you might need a calibrated constant current source.
Frank
If I read the manual correctly it is possible to make only a zero calibration.
(https://i.imgur.com/1aDL2nGs.png) (https://i.imgur.com/1aDL2nG.png)
Since I have backed up the calibration data, is it safe to play around with calibration?
Alexander.
Well, probably yes.
I already re- calibrated 3 of the Ohm ranges, because it was done improperly (not optimal) @ UEI...
It might depend on the environmental temperature, if this offset can be persistently be calibrated, may be it vanishes, when summer temperatures go back to normal.
I'm not sure, if a zero calibration only is possible, because both cal constants for a particular range are stored after gain adjustment only.
Therefore you might need a calibrated constant current source.
Frank
If I read the manual correctly it is possible to make only a zero calibration.
(https://i.imgur.com/1aDL2nGs.png) (https://i.imgur.com/1aDL2nG.png)
Since I have backed up the calibration data, is it safe to play around with calibration?
Alexander.
It is not safe to play around with calibration data.
hi Dr Frank, what did you use to calibrate the ohms ranges? e.g. Vishay 0.01% low ppm resistors?
I repeated the same tests with a 1 mA DC source, and got essentially the same results, here are photos showing the poor measurement on the 5 mA DC range, but the perfect measurement on the 50 mA range, on my Amprobe AM270 meter, and also using the uCurrent Gold.
Summary: On the 5mA DC current range, the 121GW reads off, and is quite significantly affected by touching the leads. None of these effects are seen on the 50mA range, on the Amprobe meter, nor when using the uCurrent.
Can anybody replicate these findings?
My guess would be that maybe you have a problem with your test setup or measurement procedure?
Hey IanB, please try downgrading to 1.0 and see if your low resistance range becomes stable.
I ran the same test using the UNI-T UT181A. This meter has a 10mohm res, so you loose a digit. Even with that handicap, the 181A still appears slightly tighter than the 121 prototype with the 1.26 firmware installed.
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.
If/when they release it and we start seeing positive reviews, I will be more than happy to put it through it's paces. Seeing its a bit of a novelty, I may give it some special treatment like the Gossen and take it on a road trip. That's big investment on my part so I want to make sure its stable first.
Hey IanB, please try downgrading to 1.0 and see if your low resistance range becomes stable.
Where did you find firmware version 1.7? What is the sample rate you are using? Are you collecting to the SD card or using BT?
I would like to try and repeat your 90 second test.
So the question now is if that 0.01 you are seeing is good enough. It sounds like you are expecting much better results. For some reason, I was thinking your meter had a lot more variance when you first posted about it. IMO, on a 2 wire handheld, I wouldn't have expected it to be much better than this. In the second attachment, I compare it with the data I collected at 1 second intervals with the other meters. The yellow is the UNI-T UT181A. 0.01ohm res and 4 counts, its a pretty big swing.
Can you do related test for me on your hardware?
While measuring the 0.5 ohm resistance, can you repeatedly reach out and lightly touch the Hold button with your finger and then pull it away again? Don't press the button, just touch it. Repeat the touch/withdraw cycle a few times. What happens to the reading when you do that? On my meter I can make the reading vary between about 0.2 ohms and 0.9 ohms.
Why do you (Ian, Joe and Dave) perform these tests on the low end of the range?
The resistor under test is connected to a grounded lead and I am also holding a grounded lead during the test, so both meter and I should be at equal potential.
I would have no idea what this "ground" is you describe. What I see are a bunch of antennas. Are you using 1.0? It's very possible for what you are showing in this video that it would make a difference as it appears the filter has a lower cutoff.
Personally, I would not have all this added wire, BT off, twisted the test leads, rev 1.0. Then again, you can see what I am doing to make this same measurement.
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.
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.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".
Same on mine. But also with range, mode, min/max and rel buttons.
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.
So I documented what I did for you. I'm not sure why that bothers you.
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 didn't went back to V1.0, I should tonight and try something similar, will be back soon with the results.
I'm with Dr. Frank on this one.
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.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.
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.
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.
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.
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 haven't tested that yet on my DMM, nice to know they found something about it.
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.
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.
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.
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 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.+1.
Sent from my Fi Moto x4 using Tapatalk
I'd replace these 1N4007 by reversednpn 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.
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.I take a little offense to that thought.
So trying to find a pattern is very difficult with such a small sample size.
...I think that slower samples in 121gw are single samples stored every once in a while but from the set of fast samples, not filtered to get better, more stable readings, so the spikes would still br there but you wouldn't have way to know that is a spike without the samples around it.
As for logging, if the spikes were real I would want to see them but they are not. I don't see a problem like this with even the cheapest logging meters I have when sampling at the same rates. I really can't think of a time where I have needed a handheld meter to record faster than a second. In most cases, even that is fast. If I am need to see faster changing signals, I am using something else to collect the data. For me, what ever I collect, I want the data to be accurate first and foremost. If the meter is not the right tool for the job because of it's speed, I will use another tool.
I saw 13 spikes in 15 minutes at 5Sa/s, with the spikes taking at least 3 samples, thats 1% of the samples corrupted.
Thanks! I should check the mV range then, it could help to narrow the cause, IE if it's present there we know for sure the problem is not on the resistor current source but on the ADC side...I saw 13 spikes in 15 minutes at 5Sa/s, with the spikes taking at least 3 samples, thats 1% of the samples corrupted.
I saw a spike when measuring DC mV directly (the green trace below just after 100 s). At the time I thought it might have been some external influence. It didn't occur to me that the meter itself might have introduced the artifact. That's interesting.
(https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=499727;image)
Hand proximity tests using various configurations with firmware 1.0.
https://youtu.be/s7QVwFXmxgQ
Thanks for this update. Good to hear they are working on it. What ever their reason for this change, it could have an added advantage if they pick the parts right. U9 is the first thing to get damaged in my testing. I am using a TVS rather than the 4007s to protect it and swapped the HEF4053 for a CD4053. It held up pretty good after that.
I also have to comment that if the software was truly open source (or hacked to be) as I thought when I purchased the meter I might be more inclined to get into the discussion.
The bugs like not defaulting to the default scale is more "serious" imho.
The bugs like not defaulting to the default scale is more "serious" imho.
What bug is that? :-//
Select a position. E.g. V DC. Press Mode to change it in AC. Turn off the meter and on. Select again V. It remembers the AC mode selected.
One scenario is that you try to measure a high DC or AC voltage and the meter is in the other mode. It will show 0...
We'll fix the manual.
Hi,I think a lower rail would be even better, as the voltage at 4V reg would change with batteries running low, and to avoid the up to 50ppm/V line regulation coef, typ is lower but gets worse when it's warm. Using a 3.3V rail would make sense but a quiet one would be needed, as a LDO running there will stay there even with the batteries at 0.9V or 0.8V each.
I think I found another design issue in the meter circuit.
I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 7 V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
I also have to comment that if the software was truly open source (or hacked to be) as I thought when I purchased the meter I might be more inclined to get into the discussion.
Sorry anyone thought the meter would be open source firmware, that was never promised.
The schematic is available, the PC software is fully open source, and the protocols are open.
We'll fix the manual.
Bug solved! :D :D :D
Alexander.
Hi,
I think I found another design issue in the meter circuit.
I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
Good question, which you could also add and a suitable supplier for 1 of TVS components.
Will instructions be provided for replacing the 4007 diodes with the TVS for current 121gw owners in the future?
There is also a resistor that Dr. Frank has identified that may need replacing to enable a higher current for stability reasons.
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
The 50 Mohm range uses 20nA reference current by its internal R9 = 10MOhm reference resistor, which causes a susceptibility to leakage currents (I will demonstrate that later). Maybe it's possible to increase the Vref (by firmware) from about 0.2V to 2V, to get 200nA test current, but probably that's not possible due to supply/reference voltage limitation, as in total >4V would be required. See HY3131 Confirguration document, page 31.
The 50 Ohm configuration also follows the HY3131 document, see page 33, so R26 = 1k is used also for 50 Ohm, giving 470µA test current only, and a sensitivity of 470nV on the last digit, causing the noise trouble. The analog multiplex bus of the HY3131 is completely occupied, so it's not possible to add another 100 Ohm reference resistor for 5mA test current.
Frank
The voltage reference is connected to AGND, not AVSS which is the battery negative. The full battery voltage is not across the reference, as AGND is a referenced voltage rail lifted above ground.
If you actually measure the voltage across the reference I think you'll find it's fine.
The 50 Ohm configuration also follows the HY3131 document, see page 33, so R26 = 1k is used also for 50 Ohm, giving 470µA test current only, and a sensitivity of 470nV on the last digit, causing the noise trouble. The analog multiplex bus of the HY3131 is completely occupied, so it's not possible to add another 100 Ohm reference resistor for 5mA test current.
The voltage reference is connected to AGND, not AVSS which is the battery negative. The full battery voltage is not across the reference, as AGND is a referenced voltage rail lifted above ground.
If you actually measure the voltage across the reference I think you'll find it's fine.
Doh... :palm:
i was sure I made some mistake.
I have mixed up AVSS with AGND, sorry.
I must subract 1.8V from B+ of course.
So it is clear that the 121GW can be used with lithium batteries.
In case that the lithium cells are brandnew the voltage at the reference chip is above the operation voltage for a short time, but never above the absolute maximum voltage.
Thanks for clarifying.
The replacement of the 1N4007s by a TVS (SM6T22CA) probably is much better for ESD / overvoltage protection, as these TVS react much faster than ordinary power diodes.
A TVS can't be used in that application, though, because they have leakage currents of up to 200nA @ 25C
The voltage reference is connected to AGND, not AVSS which is the battery negative. The full battery voltage is not across the reference, as AGND is a referenced voltage rail lifted above ground.
If you actually measure the voltage across the reference I think you'll find it's fine.
Doh... :palm:
i was sure I made some mistake.
I have mixed up AVSS with AGND, sorry.
I must subract 1.8V from B+ of course.
So it is clear that the 121GW can be used with lithium batteries.
In case that the lithium cells are brandnew the voltage at the reference chip is above the operation voltage for a short time, but never above the absolute maximum voltage.
Thanks for clarifying.
Beware that the AGND voltage seems to change depending on measurement mode. It's i.e. 1.09V in Ohms mode and 0.38V in Diode mode - and that seems to put more voltage over the ADR3412 than it perhaps was designed for - all depending on how fresh the batteries are.
Or am I also missing something? I measured the voltage between the batteries (-) which = VSS and the COM terminal which = AGND.
The replacement of the 1N4007s by a TVS (SM6T22CA) probably is much better for ESD / overvoltage protection, as these TVS react much faster than ordinary power diodes.
A TVS can't be used in that application, though, because they have leakage currents of up to 200nA @ 25C
That's not correct.
Not only is the 200nA a maximum figure (not typical), it's at the rated voltage.
It drops drastically with lower voltage.
Can Dave maybe weigh in on this? It would be nice to know if there is a legitimate cause for concern using lithium batteries in this or not.
The voltage reference is connected to AGND, not AVSS which is the battery negative. The full battery voltage is not across the reference, as AGND is a referenced voltage rail lifted above ground.
If you actually measure the voltage across the reference I think you'll find it's fine.
Doh... :palm:
i was sure I made some mistake.
I have mixed up AVSS with AGND, sorry.
I must subract 1.8V from B+ of course.
So it is clear that the 121GW can be used with lithium batteries.
In case that the lithium cells are brandnew the voltage at the reference chip is above the operation voltage for a short time, but never above the absolute maximum voltage.
Thanks for clarifying.
Beware that the AGND voltage seems to change depending on measurement mode. It's i.e. 1.09V in Ohms mode and 0.38V in Diode mode - and that seems to put more voltage over the ADR3412 than it perhaps was designed for - all depending on how fresh the batteries are.
Or am I also missing something? I measured the voltage between the batteries (-) which = VSS and the COM terminal which = AGND.
I was not aware that the virtual ground is changing with the measurement mode. With 0.38V in Diode mode my doubts would be true, event though I made a mistake with AGND. That needs further investigations. But I think like you, we maybe overlook something. i cannot believe that UEI has overlooked such a problem.
Update:
Meanwhile I made the same measurement, the voltage between com terminal and - battery. It is -1.8V as expected in all modes, except Diode test. In 15V Diode test mode there are indeed only 0.38V. I assume because of the high 15V level they had to shift the virtual gnd level in Diode mode, prevent the adc to overrange.
And now the problem is back again, with lithium batteries the voltage at the reference element is over 6 V in 15V Diode test mode.
Update 2:
Actually there is no problem.
With alkaline batteries the voltage at the reference chip will never exceed 6 V, even in the 15V Diode mode. According to the manual there are only alkaline batteries mentioned.
This meter cannot be used with lithium batteries. In the 15V Diode test mode is a high risk to damage it.
So: Do not use the meter with lithium batteries!
That is the point we have overlooked.
It should be a warning in the manual.
I put Lithium in mine the first day I got it - wanting to avoid any potential leakage problems with the usual chemistries.Same as me...
Now I am worried about the Lithiums...
I've seen it too, unable to repeat as I turned off and on again and was good.Hi,
I noticed that the meter is locked in a auto-ranging loop in the DC+AC mode in some conditions (Ver. 1.26).
For example: Genrate this signal with a function generator:
6.4Vss, sinus, 800Hz together with a DC offset of +6.6V.
I've seen this very same auto-ranging loop in AC+DC simply measuring the mains 50 Hz, 230 V.
Regards.
can one use Lithium or LSD NiMH batteries?
Actually 6.38V and above is the critical value.can one use Lithium or LSD NiMH batteries?
Looks like the problem is when the batteries voltage goes above 6V. Full Lithium batteries are at 1,7V and they stay above 1,5V until they are done:
http://data.energizer.com/pdfs/l92.pdf (http://data.energizer.com/pdfs/l92.pdf)
So it's 1,7x4=6,8V
LSD NiMH are more relaxed:
https://www.kronium.cz/uploads/BK-3MCCE.pdf (https://www.kronium.cz/uploads/BK-3MCCE.pdf)
they start at 1,5V and they drop to 1,2V.
So LSD NiMH are just fine, Lithium are dangerous, see posts above.
PS: In my future projects the MAX AA Battery Voltage MUST be 1,8V to be safe.
My 121GW showed 7.7V (!!) with brandnew lithium cells...
About leaking batteries, just replace them every a year or two, that's all it takes, even ig they are not fully depleated, and use them till they die in the mouse, tv remote or torch.
I don't know if you canmake a claim, they aren't supposed to leak so easily, after expiration day or really abused. Alkalines can take a fair share of abuse, not as sensitive as lipo where a short will most likely make them explode, or being too empty, or too full, or too warm, or too cold, or you get my point...About leaking batteries, just replace them every a year or two, that's all it takes, even ig they are not fully depleated, and use them till they die in the mouse, tv remote or torch.
That's not all it takes, unfortunately. I've had batteries well under a year old that weren't depleted pop on me. I think they aren't building them as heat resistant as they used to. I have become pathological about checking on my alkalines now because they seem to pop on me all the times these days and they never used to do that.
I don't know if you canmake a claim, they aren't supposed to leak so easily, after expiration day or really abused. Alkalines can take a fair share of abuse, not as sensitive as lipo where a short will most likely make them explode, or being too empty, or too full, or too warm, or too cold, or you get my point...About leaking batteries, just replace them every a year or two, that's all it takes, even ig they are not fully depleated, and use them till they die in the mouse, tv remote or torch.
That's not all it takes, unfortunately. I've had batteries well under a year old that weren't depleted pop on me. I think they aren't building them as heat resistant as they used to. I have become pathological about checking on my alkalines now because they seem to pop on me all the times these days and they never used to do that.
You should swap brands or something, I don't see blown batteries that often, a calculator I got from a friend, parched a few traces in the keyboard and got away with it and, a tv remote or two, where the things last for ever, and some really old stuff forgotten with the batteries on. I don't use cheap batteries either, I mostly gpt them from a friend's music shop who buys mostly for personal use, replace or fit in products, so I get them for cheap or free, but still you won't loose your salary over different brands.
JS
Have you contacted energizer? Use them all the time, one of the few brands I use, and never seen one leaking, what enviroment do you usually have? Where I live 40°C is not unussual, humidity well over 90% most nights.I don't know if you canmake a claim, they aren't supposed to leak so easily, after expiration day or really abused. Alkalines can take a fair share of abuse, not as sensitive as lipo where a short will most likely make them explode, or being too empty, or too full, or too warm, or too cold, or you get my point...About leaking batteries, just replace them every a year or two, that's all it takes, even ig they are not fully depleated, and use them till they die in the mouse, tv remote or torch.
That's not all it takes, unfortunately. I've had batteries well under a year old that weren't depleted pop on me. I think they aren't building them as heat resistant as they used to. I have become pathological about checking on my alkalines now because they seem to pop on me all the times these days and they never used to do that.
You should swap brands or something, I don't see blown batteries that often, a calculator I got from a friend, parched a few traces in the keyboard and got away with it and, a tv remote or two, where the things last for ever, and some really old stuff forgotten with the batteries on. I don't use cheap batteries either, I mostly gpt them from a friend's music shop who buys mostly for personal use, replace or fit in products, so I get them for cheap or free, but still you won't loose your salary over different brands.
JS
You think I haven't tried different brands? I've tried everything. It just doesn't matter unless I'm checking once a month or more a popped AAA or AA always sneaks up on me. AAAs are the worst. I recently had two Energizer AAA go in a laser pointer that were only 6 months old and they were still reading 1.2V and working fine. My understanding is there's a sealed plastic membrane of some kind inside them that pops. And it seems like that membrane is more delicate than it used to be. I wish I knew what causes it, but it's not age or being deep discharged.
Up until 2010 or so this NEVER happened to me with alkalines, now it happens all the time. Something has changed.
I wish I knew what causes it, but it's not age or being deep discharged.
Up until 2010 or so this NEVER happened to me with alkalines, now it happens all the time. Something has changed.
Have you contacted energizer? Use them all the time, one of the few brands I use, and never seen one leaking, what enviroment do you usually have? Where I live 40°C is not unussual, humidity well over 90% most nights.
I think what has changed is "High Power" or "Super Extra Power" or "Ultra Performance".
...
The best solution is to avoid all the expensive, high performance brands and buy the cheap dollar store brands instead. The cheaper cells use the older, less active formulations and don't have the same leaking tendency.
Looks like that's what I'll be doing in my 121GW. It would be nice to know officially if lithiums are a bad choice and to see that added to the manual.
Possible an issue with the range switch:
- disconnect any leads
- turn beep off in setup
- rotate range switch to resistance/continuity/...
- press "Mode" and switch it to continuity (the meter remembers the mode)
- rotate the range switch to "mVA/VA" while applying a small pressure to it (when you are very careful and do not apply any pressure, it does not do that)
- the meter will beep during the switching
- you can even find a position of the range switch where the meter reads 0 ohms and beeps continuously
My meter is a Kickstarter one - Johnny B. Goode, delivered by Welectron.
Video showing the problem:
I think this is because of the jack detection for current ranges and because you have it in continuity mode.It is probably not the jack detection thing. It seems that there is a position of the range switch between "ohm" and "mVA/VA", where the meter is still switched do "ohm", however it reads short. In principle, I do not mind that, other meters do similar things, however the 121GW switch does not have the best indent, it is very easy to accidentally leave it in an intermediate position. However, the fact that the meter beeps when switching ranges even when it should not is quite annoying. Even if I do not apply any pressure on the switch and I try to switch as fast as possible, it beeps in 10 % of cases.
This leads me to believe there is a problem with the bluetooth module on the meter.
No devices can see it.
First activate bluetooth on the phone, close everithing, activate bluetooth on the meter, once activated open the app, if it doesnt show press refresh. I uave build 9 on android and works fine.
JS
I've seen it too, unable to repeat as I turned off and on again and was good.Hi,
I noticed that the meter is locked in a auto-ranging loop in the DC+AC mode in some conditions (Ver. 1.26).
For example: Genrate this signal with a function generator:
6.4Vss, sinus, 800Hz together with a DC offset of +6.6V.
I've seen this very same auto-ranging loop in AC+DC simply measuring the mains 50 Hz, 230 V.
Regards.
JS
Lost my posting for some reason, site bombed me out!
Just picked up my meter. v1.17
Tried to update to 1.26 and nothing happened. Followed the instructions as per page 70 of the latest manual. The meter just sat there showing 'down'. File on SD card is there and changed to EEVBlog.bin.
Tried to download 1.17, same result.
Any suggestions?
Lost my posting for some reason, site bombed me out!
Just picked up my meter. v1.17
Tried to update to 1.26 and nothing happened. Followed the instructions as per page 70 of the latest manual. The meter just sat there showing 'down'. File on SD card is there and changed to EEVBlog.bin.
Tried to download 1.17, same result.
Any suggestions?
Thanks
Geoff
The 50 Mohm range uses 20nA reference current by its internal R9 = 10MOhm reference resistor, which causes a susceptibility to leakage currents (I will demonstrate that later). Maybe it's possible to increase the Vref (by firmware) from about 0.2V to 2V, to get 200nA test current, but probably that's not possible due to supply/reference voltage limitation, as in total >4V would be required. See HY3131 Configuration document, page 31.
The 50 Ohm configuration also follows the HY3131 document, see page 33, so R26 = 1k is used also for 50 Ohm, giving 470µA test current only, and a sensitivity of 470nV on the last digit, causing the noise trouble. The analog multiplex bus of the HY3131 is completely occupied, so it's not possible to add another 100 Ohm reference resistor for 5mA test current.
Frank
Can you remind me which Configuration Document you're referring to?
Can you remind me which Configuration Document you're referring to?
Somebody recently posted the HY3131 configuration document, you have to look for it.
Frank
Lost my posting for some reason, site bombed me out!
Just picked up my meter. v1.17
Tried to update to 1.26 and nothing happened. Followed the instructions as per page 70 of the latest manual. The meter just sat there showing 'down'. File on SD card is there and changed to EEVBlog.bin.
Tried to download 1.17, same result.
Any suggestions?
Thanks
Geoff
Does the meter write to the card if you start logging?
Alexander.
Tried again to update with 1.26 and same result as meter stays showing "douun", bar graph remains at zero. Waited 10 mins, no change.
Brumby, you will see from my first post that I have changed the file name as required.Have you tried with other versions other than 1.26?
This is how the file change instruction in the manual has it. I think we might have heard by now if others were having this trouble. Appears its just me :-\Yes, appears it's just you. If you want to fix it yourself the bootloader is in the reverse engineering docs so you can write it with a st-link. Before doing so try writing your cal data to the sd file and decode it with the phyton routing that's there as well, to checl it makes sense. Then take what's in the stm with the st-link, save it and then write the new bootloader to it, then try installing the new firmware with the SD again. Looks like it's that or shipping it back for a fix at Dave's HQ.
“EEVBlog.bin”
Tried another version, same thing. I can read/write to the SD card from the PC, and read from the meter but can't write to the meter.
Geoff
Brumby, you will see from my first post that I have changed the file name as required.
Thanks JS but I'll wait and see what Dave comes back with as I registered the issue on the web site's "Report an Issue".That's fine, I think he's aware of your case, he answered your first post on this IIRC... I'm just saying something that might solve your issue, and what reaources there are to do so, in case he gives you green light to poke with it.
Geoff
Thanks JS but I'll wait and see what Dave comes back with as I registered the issue on the web site's "Report an Issue".
Geoff
Brumby, you will see from my first post that I have changed the file name as required.
Oooof. Sorry. :palm:
So being a literal being, that's exactly what I did already knowing it was a bin file, I assumed the program looked at the "name" wanting to see a .bin. So I had in effect EEVBlog.bin.bin. The penny dropped when I saw Dave's email from EEVBlog with a included file to try. Now I have v1.26.
Sorry all for the distraction. I'll now email Dave and apologies :palm:
Geoff
Thanks JS but I'll wait and see what Dave comes back with as I registered the issue on the web site's "Report an Issue".
Geoff
OK...so my bad!! This is the text from the web site;
Note: When upgrading a multimeter the “.bin” file must be renamed “EEVBlog.bin”:
So being a literal being, that's exactly what I did already knowing it was a bin file, I assumed the program looked at the "name" wanting to see a .bin. So I had in effect EEVBlog.bin.bin. The penny dropped when I saw Dave's email from EEVBlog with a included file to try. Now I have v1.26.
Sorry all for the distraction. I'll now email Dave and apologies :palm:
Geoff
On this 600V meter, the latest version of the manual August 30, 2018, still confusingly specifies AC and DC VA as 500VA without mentioning its limited to 50V for whatever reason :(I don't understand that limitation, everything is in the meter to measure higher voltages and that's all that should be required. I guess I'm missing something but measuring VA directly on mains would be nice.
I've seen a few people change out the shunt in the Kill-a-Watt to use it for lower current devices. I assumed a meter like the 121GW would fit nicely as they have the scaling built-in already. I never understood the reason why they limited it to 50V. The prototype was limited as well.
Additionally, all log files are dated 2006.09.02 (yyyy.mm.dd format used) @ 21:30:00. Yes, a timestamp is in the actual file, but that doesn't help things if you go searching through the files for one at a specific time. Timestamps for the actual sample should be trivial to do since there is a hardware RTC in the DMM. A solution some other logging packages takes is to either log the absolute time or even using a relative time in thousandths of a second. I've well enough versed in Excel to add fractional second timestamps if I have at least 1 second resolution added in, but when you are using the fastest ADC output, and given that there is no "end" timestamp in the log file, it is not possible to determine the duration of a logged session.Both date and time is on the first row in the file, then it says what interval is used. So it is not impossible, just somehwat cumbersome. Add another column, copy the time from the top row, then next row is the one above+(interval in seconds)*(1/86400). If using excel or the like. Otherwise I suppose a script could be used...
But it would be very easy codewise to implement the timestamp into the log file, so we don't have to mess around like that.
The default setting is to sample and save points as fast as the ADC allows, hence the interval is not fixed but depends on the mode, range, etc. It is therefore impossible to calculate the time for each point using the default setting.
However it is true that if you change the settings and limit yourself to a slower sampling speed, i.e. not using the full potential of the meter, it does seem like the timing is consistent so that can assume a fixed number of seconds between each point. I tried it over 4 minutes using a stopwatch and I could not detect any drift or dropped points by eye at least. Hence I guess this is the recommended method for now.
In order to allow for faster sampling I guess you need the actual time in a column (seconds since start is probably easiest), as it would make analysis much easier without having to process the time manually every time. Also as a separate improvement I would remove the "mode" from being printed on every row, either print it once in the header or only print it when it changes (if you intend to include mode switching during logging in the future). This would save approx 10-30 % in space depending on the mode used.
I also noticed that the meter does not autorange during logging (it goes into manual ranging when starting the logging process). This is definitely a feature that I would like to see in future updates.
Edit:
More issues I noticed today:
- The claimed "update rate" is 5 samples/s nominal, however my display only updates 1-2 times/s, hence the meter feels slow and unresponsive, is this an error in the manual or is the meter supposed to be faster?
- When manually selecting the 10 A current range, the display tells you that you are in the 1000 A range. Perhaps there is no 10 indicator in the LCD and this is intended, if that is the case please update the manual.
- There is a 1000 V range, however the manual specifies maximum 600 V for the input protection. Perhaps this is the same issue as above? Please update the manual.
- There are no range indicators in the display for Frequency, Period, Capacitance. Perhaps indicators is lacking in the LCD? In that case I suggest to always show leading zeros in these modes when in a manual range. For example the 100 nF range, write 07.6 nF, instead of just 7.6 nF in order to indicate the amount of headroom available.
New bug, also logging related. Anyone with a freezer could verify this for me. Regardless of sample rate, negative Celsius temperature values are logged as 7.1-7.6 °C regardless of their value. Lost a couple days worth of logging as a result. This is on firmware 1.26Just tried and no problem with 1.26
Probably it is known by now , just in case , DC+AC is autoranging endlenssly if DC voltage is greater than 5V . I used just an adjustable power supply . Latest firmware .
In AC mode , last measured frequency on secondary display stay there for about 15sec , way too long , even with shorted leads ... Could be very misleading if you measure some small voltage around 0.15Vac , at the threshold of frequency sensitivity .
Additionally, all log files are dated 2006.09.02 (yyyy.mm.dd format used) @ 21:30:00. Yes, a timestamp is in the actual file, but that doesn't help things if you go searching through the files for one at a specific time. Timestamps for the actual sample should be trivial to do since there is a hardware RTC in the DMM. A solution some other logging packages takes is to either log the absolute time or even using a relative time in thousandths of a second. I've well enough versed in Excel to add fractional second timestamps if I have at least 1 second resolution added in, but when you are using the fastest ADC output, and given that there is no "end" timestamp in the log file, it is not possible to determine the duration of a logged session.Both date and time is on the first row in the file, then it says what interval is used. So it is not impossible, just somehwat cumbersome. Add another column, copy the time from the top row, then next row is the one above+(interval in seconds)*(1/86400). If using excel or the like. Otherwise I suppose a script could be used...
But it would be very easy codewise to implement the timestamp into the log file, so we don't have to mess around like that.
The default setting is to sample and save points as fast as the ADC allows, hence the interval is not fixed but depends on the mode, range, etc. It is therefore impossible to calculate the time for each point using the default setting.
However it is true that if you change the settings and limit yourself to a slower sampling speed, i.e. not using the full potential of the meter, it does seem like the timing is consistent so that can assume a fixed number of seconds between each point. I tried it over 4 minutes using a stopwatch and I could not detect any drift or dropped points by eye at least. Hence I guess this is the recommended method for now.
In order to allow for faster sampling I guess you need the actual time in a column (seconds since start is probably easiest), as it would make analysis much easier without having to process the time manually every time. Also as a separate improvement I would remove the "mode" from being printed on every row, either print it once in the header or only print it when it changes (if you intend to include mode switching during logging in the future). This would save approx 10-30 % in space depending on the mode used.
I also noticed that the meter does not autorange during logging (it goes into manual ranging when starting the logging process). This is definitely a feature that I would like to see in future updates.
Edit:
More issues I noticed today:
- The claimed "update rate" is 5 samples/s nominal, however my display only updates 1-2 times/s, hence the meter feels slow and unresponsive, is this an error in the manual or is the meter supposed to be faster?
- When manually selecting the 10 A current range, the display tells you that you are in the 1000 A range. Perhaps there is no 10 indicator in the LCD and this is intended, if that is the case please update the manual.
- There is a 1000 V range, however the manual specifies maximum 600 V for the input protection. Perhaps this is the same issue as above? Please update the manual.
- There are no range indicators in the display for Frequency, Period, Capacitance. Perhaps indicators is lacking in the LCD? In that case I suggest to always show leading zeros in these modes when in a manual range. For example the 100 nF range, write 07.6 nF, instead of just 7.6 nF in order to indicate the amount of headroom available.
After hitting the range button the range button will no longer cycle back to AUTO. You must hit the mode button to get back to AUTO xx, but it will be the next mode.
To get back to AUTO, shouldn't you press and hold the range button?
.........
I also noticed that the meter does not autorange during logging (it goes into manual ranging when starting the logging process). This is definitely a feature that I would like to see in future updates.
...
No. Func. Value Unit
1 DCV -0.0362 V
2 DCV -0.0362 V
3 DCV -0.0359 V
4 DCV 2.634 V
5 DCV 4.8042 V
6 DCV 7.4089 V
7 DCV 7.4623 V
8 DCV 9.9954 V
9 DCV 13.7631 V
10 DCV 13.7631 V
11 DCV 13.7631 V
12 DCV 13.7631 V
13 DCV 13.7631 V
14 DCV 13.7631 V
15 DCV 13.7631 V
16 DCV 13.7631 V
17 DCV 9.194 V
18 DCV 4.539 V
19 DCV 0.7786 V
20 DCV -0.0204 V
21 DCV -0.0356 V
22 DCV -0.0359 V
23 DCV -0.036 V
24 DCV -0.0374 V
25 DCV -0.036 V
26 DCV -0.0382 V
I removed C21 27nF , the input LPF capacitor , and for measuring resistance seems to be no change , exactly the same instability ... so it is not used by firmware in my opinion . Or if it is used the effect is very weak .
In this case DC ranges become unstable , picking up the noise , as should be expected without it . For measuring DC that filter is useful , no doubt .
I added a 47nF capacitor ( first value I found ) from PB0 to AGND ( ADC input is PB0 - PB3 connected to AGND with 10Kohm ) and now there is first some charging effect ( big capacitor and low measurement current) but then the resistance value is pretty stable and you can move the probes around , touch them and the tips . No worries ;D . More or less like other multimeters .
In the HY3131 configuration document for measuring resistance it is clearly shown that this capacitor must be used , the red one between FTP and FTN pins . I'm not sure what that selectable resistors 100K , 10K and 0 (short) do , are in series with this capacitor or not ... if they are in series than 100K + 27nF may not be such a good filter for cutting down strong AC 50Hz induced noise ... than 10K or the capacitor directly connected at input could be selected.
After installing version 1.51:
- The mA range shows 0.30 mA with no leads connected, went back to 1.26 and it shows 0, programmed 1.51 again and then press Rel when 0.3 mA was showing and now it shows 0 mA ?????
- The uA range shows 0.021 uA with no leads connected, went back to 1.26 and it shows 0, same as the mA range, after pressing Rel no it shows 0.
In both cases even when turning the unit off and on now shows 0
David DLC
Never mind, after turning it off for a while, it when back to show 0.3 and 0.021
David DLC
I have been looking at the packet protocol document but as it seems to be missing a fair bit of information (It may be me not be reading it correctly) I decided to start making my own but as I don't have a blue tooth adapter on the PC I have been probing the UART interface to the BLE112 inside the meter with my logic analyser and have noticed a couple of quirks.
1. The Year value of the packet never changes no matter what is set on the meter.
2. The Month value of the packet never changes no matter what is set on the meter.
3. While decoding the Main LCD Range packet (7) I noticed that on AC and DC micro Watts the 2500.0uVA range appears to be repeated - this shows on both the meter display and the UART packet.
I am using V1.51 on my meter.
Jem
I think that when the upload of an EEVBlog.bin file is complete, it should be deleted. This would free up that space for meter logging functions. I can't think of a reason why to keep it there once the upload is done. A user would not have to go back into the meter to delete the file, assuming they are OCD about that. Then - as I prior recommended, the battery door can be screwed down before an upload is started.Seriously? How much does the bin file weights? How much time for logging it is? And compare that with the 8GB the SD has... If you record that much data will need to be in many separate batches as the batteries won't last that long, then you have the problem with the naming and k owong which is which...
What ever is causing the communications to slow down appears to be the 121GW's main firmware.
...Your having so much fun with the new 121GW !! and so persistent :-+
...
As a side note, I had changed the meter to Eneloop NiMH and had never charged it. The battery indicator never came on. Even after all of this testing. Finally it gave up last night. ...
It appears by the time version 10.0 rolled out, they had converted to a 19 byte, binary format. It's very similar to what we have today. They were still running at 250ms. It looks like the firmware, even with only 30% of the amount of data that had been sent, it was already starting to lag.
Firmware Version - Format, #Bytes in packet, Packet Rate, Timing Stable or does it lag
1.00 - ASCII, 56 Bytes, 250ms, Stable
1.05 - ASCII, 56 Bytes, 250ms, Stable
1.07 - ASCII, 56 Bytes, 250ms, Stable
1.10 - Binary, 19 Bytes, 250ms, Lags
Corrected version numbers
It appears by the time version 10.0 rolled out, they had converted to a 19 byte, binary format. It's very similar to what we have today. They were still running at 250ms. It looks like the firmware, even with only 30% of the amount of data that had been sent, it was already starting to lag.
Firmware Version - Format, #Bytes in packet, Packet Rate, Timing Stable or does it lag
1.00 - ASCII, 56 Bytes, 250ms, Stable
1.05 - ASCII, 56 Bytes, 250ms, Stable
1.07 - ASCII, 56 Bytes, 250ms, Stable
1.10 - Binary, 19 Bytes, 250ms, Lags
Corrected version numbers
Do you have some details about the test you performed, I'm writing a bug report but not really sure specifically what you've done. By lag do you mean the time between logging and the actual signal or the the sample rate is slower than expected slightly?
Forget the RF link for now. Just monitor the serial lines from the meter's MCU. You will find that the rate that the packets are sent will vary depending on the input signal. Depending on the version of firmware you install, the time between packets will be 500ms or 250ms. I have shown where this time can be seconds. This does not appear to be a problem with the older firmware. It appears the problem showed up in version 1.10 when the packet sized was reduced and the binary format was introduced.
I suspect the packet rate was slowed down even further after 1.10 in an attempt to resolve the lag between packets. However, in 1.00, they were sending almost 3X more data at the 250ms rate and not lagging.
I would think they could write the newer binary formatted, smaller packet like 1.51 uses at the same rate they write to the SD card and not lag.
Yes, I confirm these values of 0.022µA and 0.32mA @ FW 1.51.
With FW 1.26, it's 0.046µA and 0.06mA, though.
Maybe there's a systematic bug inside these modes.
Change was 'Amp range sensitivity improved'.. probably that causes this offset.
Frank
[Adder]: It makes no difference, whether probes are inserted, or not.
I'll look into this for you, I think we will be able to work it out.
Just so I don't have to redo your test (will be faster), do you have examples of the sampled UART data that show this (a screen shot or photo of the logic analyzer)? Something that shows the jitter between samples.
If you don't see this before 4pm I'll do the test myself but I figured I'd ask.
There are several posted on this thread. If you look at this picture for example, there are two different programs shown. The one in the upper left is using a FTDI TTL to USB adapter to sniff the serial line from the MCU. In this case, I am counting the number of times the the time between packets is longer than 800ms. The main program is looking at the data across the RF link. The yellow trace is also the number of times the packet spacing has exceeded 800ms. Note how the two track. Als note that the blue trace, showing the CRC failure rate is not effected.
It you would rather see the actual time, TEST2E is showing just that using different modes and signals applied. Again, in the 5V range with nothing attached to the meter, so the readout is basically all zeros, the packet spacing is very repeatable.
You could use a LA but I was wanting to capture more metrics. Actually, you could add some checks to your Windows application and check it on the RF receiver side like I was originally doing. Should be easy enough to replicate.
****
On TEST2E, the vertical axis is time in ms.
Very nice. Thanks for taking the time to dig into it.
I am playing around with a UNI-T meter using BLE as well. There is still a lot of work to do on it but there are some things that UNI-T does that UEI could leverage. One major difference is how the display data is sent. The 121GW has the data, sign bit, scaling... The UNI-T sends the data as a float. IMO this is much easier on the PC side of things.
They also embed a checksum and like the 121GW, it seems to be required but the error rate is much lower for what ever reason. They can update at 10Hz rather than 2Hz and are sending 55 Bytes. If anything, I would expect the CRC error rate to be higher on the UNI-T.
https://www.eevblog.com/forum/projects/uni-t-ut-d07a-bluetooth/ (https://www.eevblog.com/forum/projects/uni-t-ut-d07a-bluetooth/)
I was a little confused about what I was seeing when I was attempting to write a Labview app for the 121. Looking deeper into the BLE interface, if you fire up Wireshark you will find that the 121 sends a single packet for the start byte. It's a bit odd as the entire data structure could fit into a single packet but the 121 will send two. I suspect this may have been a carry over from the earlier structure.
It's too bad that the BLE112's serial interface was not routed to the MCU so you could field upgrade it with the firmware. It looks like you are stuck with what you have unless there is a newer release of the meter at some point.
I am back to 1.26 with the BLE112 image that was uploaded.
Did you try to see if you could still replicate the lag with the beta firmware like I showed?
It's loaded and running now. I am using the mVDC mode. I am only looking at the data rate from the MCU to the BLE112.
I can already tell you that the problem appears to still be there but it may be improved. Try it on your setup and see if you have similar results.
Sorry, time to head out.
Consider the following when attempting to replicate my tests:
* The lag can be longer than one second.
* The lag is aligned on the packet boundary. Or in other words, you need to measure the time between packets and look for missing events.
* When using a separate program to measure the time between packets with the RF interface, it will track the times seen on the serial line going to the BLE112.
* If I run older versions of the firmware prior to 1.10, even though the data rate is doubled, it is stable.
If you scope can measure the time between packets, this is what you want. A simple thing you could do is just add the timing metric to your application software and trend the data as I have done.
Ok , the meter is able to swallow that overvoltage and survive , but don't expect to be very happy . It's a mistake to switch like that ... and should be a very rare occurrence not something normal as you seem to suggest . Frequency range is for low voltage ( signal ) too , the same as you would use a stand alone frequency meter ... For AC high voltages frequency you have the secondary display
It should happen in minutes, assuming the input signal is varying enough to cause the display to change. One other thing to consider is that the failure rate is low, less than 1%. It's not something you would want to watch for.
If you like, I can see if I can capture the events with scope. I assume your scope was decoding and storing the packets and there was nothing wrong with the data. If the MCU were corrupting the packet, I would have no way of knowing with my current setup but I certainly could detect a problem like this with the scope.
It should happen in minutes, assuming the input signal is varying enough to cause the display to change. One other thing to consider is that the failure rate is low, less than 1%. It's not something you would want to watch for.
If you like, I can see if I can capture the events with scope. I assume your scope was decoding and storing the packets and there was nothing wrong with the data. If the MCU were corrupting the packet, I would have no way of knowing with my current setup but I certainly could detect a problem like this with the scope.
Do you mean varying enough to cause an autorange, if yes I did not do that, I'll need to.
I believe I will have an answer for you shortly. Let me start by apologizing for sending you, UEI developer's and possibly others, on a wild goose chase on the communications lagging problem I am seeing. Let me explain where I am at with it.
I changed my test setup to use a scope to monitor the serial communications between the microcontroller and the BLE112. I set the scope to decode the packets and then changed my PC software that I use to monitoring the serial bus (using the FTDI controller) so when a lag fault was detected, it sends a trigger signal to the scope.
138 shows the trigger pulse in red. Note that the packets before it are not missing. At first I though maybe a framing error, clock mismatch, etc, but ...
140 shows the decoding of the first packet prior to the fault. Everything looks good. I tried this a few more times and everything seems fine.
So I started looking at my software and realized I had made a mistake in how I architected the packet parsing. I have not looked into why the pre 1.10 versions worked with my BLE software but suspect that it is linked to the short message. The parsing is done differently for the UT181A which is why that software does not have a problem.
Of course, I used this same parsing routine for both the 121GW BLE software as well as the serial sniffer. This is why the two programs tracked the lag as well.
I have corrected the parser and have been running the serial sniffer using firmware 1.26 and have not seen a single miss. The BLE software will need to be corrected and then I can repeat all of my testing but I am pretty confident that this is all on my end.
Again, I am very sorry for not digging into this before bringing it up. I will let you know in a day or so if I saw any problems.
|O |O |O |O
I wonder in your case if you have another device in range that is opening an connection to the meter. I don't own a cell phone so I can't test to see if there is a difference with their other applications. Is anyone else having problems connecting?
I am fortunate that the neighbors are far enough away that they don't cause a problem. It will be interesting to see when they return if it stops working again. My CEM meter uses 900MHz with a simple FSK modulation. I've been amazed at how far that meter will transmit.
Maybe IanB's problem is similar.
As usual, change log is lagging
QuoteAs usual, change log is lagging
Is the ChangeLog available somewhere other than the manual? Seems like it ought to be included in the firmware ZIP or at least as a link beside the download link for it.
Edit
Interesting , when measuring capacitors in manual range is showing overrange if the capacitor is not too big , so in 10nF range is showing overrange for 100nF but just freeze for 10uF ...
Confirmed
Nanofarad values of capacitance yield readings of zero with nanofarad manual ranging. Occasionally an incorrect low value for a capacitance is displayed which then very slowly increases over a ~30 minute period up to the correct value.
Also the Logging/Bluetooth value for the nonofarad capacitance is 10 times what it should be.
Using 121GW meter recently purchased from Welectron with V1.57 firmware.
iPhone bluetooth app version: build 1.78
Problem is reproduced by:
1.) Attach .014NF cap
2.) Turn on meter, select capacitance
3.) Set mode to capacitance the correct value usually displays.
4.) Cycle through mode selection and ranges once or twice.
5.) The capacitance shows zero in both nonfarad ranges or an incorrect slowly increasing value toward the correct value.
Slowcap1 shows the initial Log file.
Slowcap2 shows Log file after about 20 minutes.
Hello EEVBlog!
I feel honored to now be a part of this awesome community. What makes me very sad is that my first post has to be a negative one.
I purchased my 121GW meter on July 26th 2018, during a small batch at official EEVBlog store, after being informed about its availability by the newsletter. Soon I discovered how big mistake I have made.
After receiving the meter and unboxing it, few things immediately stood out. The meter was scratched in many places (especially the knob and in the area around lead sockets) - see attachment. Scratches on two flat sides of the knob clearly came from someone's else fingernails. Part of the knob you grab by your fingers was noticably shinier than other areas. Batteries have also already been put inside the meter - From what I've seen on unboxing videos, these should be included seperately in the pouch. Conclusion is simple - I recieved a used meter. I thought - "Ok, fine. This is not that bad. I can use this meter nevertheless." And I could - for a month. After that strange things started to happen.
Before making the purchase I did some research online (mainly this forum) and discovered that at some point a common problem with 121GW meters was the knob itself. Apparently there was a recall done at some point regarding the contact issues (knob replacement and addition of a shim). This took place months earlier. Common sense suggested that my meter should have already been free of this issue. This couldn't be farther from the truth.
After a month of very, very light use the meter is basically unusable. The knob wipers stopped making a good contact with the PCB (i think) and the meter reboots constantly while switching modes. Resistance mode cannot be turned on at all. The meter just turns off when I select it. The issue is present for every single knob position.
I made a short video where the issue is clearly visible:
https://www.youtube.com/watch?v=DIlfYcioE4w (https://www.youtube.com/watch?v=DIlfYcioE4w)
As you can see, this is clearly not a 121GW revision with a fixed knob. I must have received an older, flawed version. This is absolutely unforgivable for a meter this expensive (and every other for that matter). What I find the most frustrating is that the recall was done some time before I bought my meter from the EEVBlog store. At that point I should expect this issue to be already resolved but in the end I recieved a meter with this exact defect still present.
I've sent Dave an email describing these issues on 5th October. He replied a week later and promised to send me a new meter. I was really happy about that. So why am I even writing this post, you may ask? Well, because the new meter has never been shipped and Dave has not replied to any of my emails since then :palm:. I've been trying many times to contact him through at least 3 EEVBlog email adresses and sending him PMs on the forum, asking why the new meter hasn't been shipped. Three weeks have passed and I have not recieved any reply. I have no idea why.
I can only hope that this post will grab Dave's attention and that my meter will get replaced eventually. Do you know if there is any other way to contact Dave or to fix the meter? I just want to be able to use the product i paid for.
Thank you for your help in advance,
A VERY frustrated customer.
The resolution of the capacitance is 0.01 nF, unless I've misunderstood you might be using it for values out of the meters range.
I just installed firmware version 1.57, and it still shows a fixed current value of about 34 mA with nothing connected.
I had to go back to 1.26.
Does anybody know about this issue ?
David DLC
QuoteThe resolution of the capacitance is 0.01 nF, unless I've misunderstood you might be using it for values out of the meters range.
My apologies, my message and post had the wrong capacitance value. The capacitance used was 0.14 nano-farad. Please see the corrected EEVblog 121GW Multimeter Issues Reply #869
Seems like YOU are the one polluting it. Have anything technical to add?
I'll be very clear again.
This thread is for REPORTS of bugs and issues and CONFIRMATIONS of those bugs and issues.
DO NOT discuss them here, PLEASE!
I did not realize you were censoring posts in this area. I resubmitted the post you removed twice because I literally thought I had forgotten to press the send key, not because I was trying to be a dick about it.
After shorting the leads and pushing the rel button the meter zeros out the low ohm range and compensates the lead resistor as expected. But it also disables simultaneous the autorange function.
Why? That makes no sense, no other of my meters does this.
Re-enabling the auto mode deletes the resistor compensation :palm:.
Hi,
beside of the unacceptable slow autorange in ohms mode there is another issue in this mode.
After shorting the leads and pushing the rel button the meter zeros out the low ohm range and compensates the lead resistor as expected. But it also disables simultaneous the autorange function.
Why? That makes no sense, no other of my meters does this.
Re-enabling the auto mode deletes the resistor compensation :palm:.
That should be changed.
GeoffreyF , 121GW is very slow in comparison with cheap or expensive multimeters , so stop being a fanboy troll . This firmware program should be scrapped completely and start from scratch with speed efficiency in mind . With a PIC family microcontroller a long time ago many , many users could have done a better firmware .
GeoffreyF , 121GW is very slow in comparison with cheap or expensive multimeters , so stop being a fanboy troll . This firmware program should be scrapped completely and start from scratch with speed efficiency in mind . With a PIC family microcontroller a long time ago many , many users could have done a better firmware .
So you can't make any real point and you call me a fan boy troll? You discredited yourself completely. Did I say I was a "fan"? No. I own one. I own others. Troll? I am not one of these people who never gets tired of repeating the same point again and again, completely unproductively. As for "Scrapped completely" (as opposed to correcting bugs). It is equally obvious you never really worked on production code.
This is an Engineering blog - that means numbers, facts, comparisons - not rude school boy remarks.
GeoffreyF , 121GW is very slow in comparison with cheap or expensive multimeters , so stop being a fanboy troll . This firmware program should be scrapped completely and start from scratch with speed efficiency in mind . With a PIC family microcontroller a long time ago many , many users could have done a better firmware .
To add something , autorange hysteresis is 55000 counts up and 40000 counts down .Unreasonable huge . So , when you measure a 470ohm resistor from infinite resistance ( autoranging down ) , it will autorange in the 5K range and you will see 0,4700K .
But if you short the leads first and wait for 0 ohm reading , then measure fast ( now autorange is going up in ranges ) that 470ohm resistor , it will autorange correctly in 500ohm range as 470.00ohm .
Hi, my Fluke 89IV/189 and 287 (with firmware 1.16) all do it in the same way with automatically switching to MANUAL ranging.
Regards from Italy.
Marco1971
GeoffreyF , 121GW is very slow in comparison with cheap or expensive multimeters , so stop being a fanboy troll . This firmware program should be scrapped completely and start from scratch with speed efficiency in mind . With a PIC family microcontroller a long time ago many , many users could have done a better firmware .
So you can't make any real point and you call me a fan boy troll? You discredited yourself completely. Did I say I was a "fan"? No. I own one. I own others. Troll? I am not one of these people who never gets tired of repeating the same point again and again, completely unproductively. As for "Scrapped completely" (as opposed to correcting bugs). It is equally obvious you never really worked on production code.
This is an Engineering blog - that means numbers, facts, comparisons - not rude school boy remarks.
Yes , sure I'm discredited not you for implying that 121GW slowness has something to do with price ... Fanboys allways find excuses for any issues .
I don't think this firmware could be "corrected" that much . This is a core feature when designing a software to work efficiently . Not 3 lines of code that they couldn't change in 1 year or more ...
But I don't care how is done
This may have been reported before, but I came across this video that shows the meter's strange behavior in Auto Hold. My meter is a kickstarter unit and was shipped to me with the switch shim installed. It is running V1.57 firmware and I have tested it on the same precision voltage source, (ebay) as shown in the video it performs exactly the same.Actually I tried following the video, but this person (apart from the confusion between uV, hundreds of uV and mV) has, for my tastes, a terrible way of exposing his thoughts.
The meter seems overly sensitive and the readings jump around especially when removing the probe from the voltage source. Also has the problems shown with not always working when auto hold selected. Its just flaky behavior that keeps me guessing if I can rely on the readings and necessitates taking numerous readings to be sure it is as shown on the display. Anyone else found this behavior with their meter?
There is one other issue with my meter that occurs from time to time and that is with the Rel button operation. I have had the Rel button refuse to function when pressed and it requires turning the meter off and on to reset the function back into operation.
Anyone else experienced this when using Rel?
Note: All those above comments about the whining on this thread should be removed and re-posted to the Discussion thread!
This thread is for reporting on issues that are effecting the meter, so may appear as whining to the thin skinned crowd of proud owners. Reporting issues may seem negative, but without this feedback the meter will never reach its potential.
A one sentence summary would be that the 121GW meter was a good idea poorly implemented!
Hindsight is a wonderful thing, but maybe if Dave ponied up and backed his own idea and design instead of a freebie UEi deal, it may have actually been developed and tested before being released to backers to buy?
The potential for getting a useful meter, (I'm Johnny Be Goode backer) is still high, but the way it has been handled with bugs and switch problems has certainly knocked the gloss of acquiring this meter for me!
This thread is for reporting on issues that are effecting the meter, so may appear as whining to the thin skinned crowd of proud owners. Reporting issues may seem negative, but without this feedback the meter will never reach its potential.
I think if the 121GW ever gets to the point where everybody is happy (I'll set the bar at 95%), Dave could double the price.
Autorange slowness in all modes ( voltage , resistance , capacitance ... ) makes it pretty useless for any professional use ... This is not a small bug like others .
Could be enough for beginners ( first meter ) , occasional users , fanboys and people who bought it like a toy because they have too many meters . No offence .
Reporting issues is not whining because we can't afford or own something "expensive" like a Fluke |O
Just try to work on something when you have to wait about 1sec ( an eternity compared with other multimeters ) to switch the ranges up and down , maybe with some fast changing voltage . Annoying is not enough to describe the feeling ... when you have fast meters to compare . Could have 1000 extra features , if the simple ones are not implemented right.
Of course I hope they will resolve all the issues , it is for their own good , this meter can become a Fluke "killer" if they want .
What chipsets ? How do you know it is hardware ? HY3131 is faster in other multimeters , and if a 32MHz 32bit ARM micro is not fast enough for a multimeter than what "rocket" should be used ?
There is nothing wrong with pointing out the quirks of the 121GW, only fanboys have a problem with this.
Hi,
beside of the unacceptable slow autorange in ohms mode there is another issue in this mode.
......
That is the point! The 121GW has the most powerful processor in its class but is as slow as a 20 Euro multimeter with autoranging.
...
You are a very good examble how not to discuss technical issues....
Hi, I may have missed it but is there an instruction on how to use the Bluetooth “activate Bluetooth on the meter” as I can’t see the meter on my iPhone or in the app.
Many Thanks.
Barry
Hi, I may have missed it but is there an instruction on how to use the Bluetooth “activate Bluetooth on the meter” as I can’t see the meter on my iPhone or in the app.
Many Thanks.
Barry
With the iPhone it should be nearly instant, android and windows are much slower at detecting devices."You might" what Seppy? Seems to have been accidentally edited out mid sentance?
You don't need to pair the 121GW with the iPhone and it will not connect if it (the 121GW) is already paired to another device. Paired devices take precedence until they are unpaired.
BLE doesn't have much power, if your near other high power devices you might
Manual 2019-01-29 vs. 121GW 1.57 in VA mode?
The Manual (p.20) shows 3 µVA ranges and 6 mVA/VA ranges in AC or DC. But I can select 4 ranges at the µVA position of the rotary switch and 4 ranges at the mVA/VA position. I don't get it.
Rotary Switch in position µVA input. MODE = AC or DC.
I see this decimal point positions. (RANGE) pressed between each step:
1. AUTO
2. ##0.00
3. ###0.0
4. ###0.0 ?
5. ####0
back to step 2
(Hold RANGE to go back to AUTO range)
Rotary Switch in position mVA/VA input. MODE = AC or DC.
I see this decimal point positions. (RANGE) pressed between each step:
1. AUTO
2. #0.000
3. ##0.00
4. ##0.00 ?
5. ###0.0
back to step 2
(Hold RANGE to go back to AUTO range)
Manual 2019-01-29 vs. 121GW 1.57 in VA mode?
The Manual (p.20) shows 3 µVA ranges and 6 mVA/VA ranges in AC or DC. But I can select 4 ranges at the µVA position of the rotary switch and 4 ranges at the mVA/VA position. I don't get it.
Rotary Switch in position µVA input. MODE = AC or DC.
I see this decimal point positions. (RANGE) pressed between each step:
1. AUTO
2. ##0.00
3. ###0.0
4. ###0.0 ?
5. ####0
back to step 2
(Hold RANGE to go back to AUTO range)
Rotary Switch in position mVA/VA input. MODE = AC or DC.
I see this decimal point positions. (RANGE) pressed between each step:
1. AUTO
2. #0.000
3. ##0.00
4. ##0.00 ?
5. ###0.0
back to step 2
(Hold RANGE to go back to AUTO range)
OK, let's say it's a manual issue but I can't check the multimeter against hidden information. The manual could have been created more carefully. I like the very clear Gossen manuals most.
It works for me on Android. When the meter is first turned on, bluetooth is off. Did you turn it on, as discussed in the manual? It would be helpful if you wrote the steps you used to use bluetooth. Generally speaking - the bluetooth feature works.
It'll display dBm (a useless metric in 2019 for all but the most select circumstances, I would argue)I'd beg to differ. It does not make much difference if the the display is in dBm or dBV or any other dBxxx. A reference level is needed in any case.
I can always get out a calculator and 20*log(acv2/acv1), but the whole point of a fancy meter is to NOT have to do that!And, in fact, you don't need to do that. Just measure the dBm value at the input, and subtract it from the dBm at the ouput...though I agree that being able to use Rel would be nice (I stand by your words on this, I'm away from home at the moment).
It'll display dBm (a useless metric in 2019 for all but the most select circumstances, I would argue)I'd beg to differ. It does not make much difference if the the display is in dBm or dBV or any other dBxxx. A reference level is needed in any case.
If a meter has a sufficiently high impedance, it's "invisible" to any circuit under test, so an external termination of any given value could be connected. I live in an HP/Agilent dominated analog world where dBv is by far the most common comparison point. If I'm reporting amplifier gain or frequency response, it's always a dBv thing.The meter impedance remains around 10 M \$\Omega\$ when in dBm mode, it does not use a 600 \$\Omega\$ load: it is, in fact, measuring dBu not dBm.
I've been noticing that the mA/A current mode always shows a reading of 0,10...0,12 mA current even when there is no test leads connected to the multimeter. Is that normal or is it some bug in firmware etc?
+1 for proper bug tracking system, it's not easy to look for already reported bugs in1416 pages of thread.
+1 for proper bug tracking system, it's not easy to look for already reported bugs in1416 pages of thread.
I second that. It's kinda meta but I see this as a bug.
For potential buyers it would be very interesting which bugs exist, which are unfixable(e.g. hw bugs) or won't be fixed and which are fixed or UEI is working on.
Also there seems to be no change-log (just looked at fw 1_57) whatsoever.
Digging through 34 pages of a forum Thread is insanity.
I second that. It's kinda meta but I see this as a bug.
For potential buyers it would be very interesting which bugs exist, which are unfixable(e.g. hw bugs) or won't be fixed and which are fixed or UEI is working on.
Also there seems to be no change-log (just looked at fw 1_57) whatsoever.
Digging through 34 pages of a forum Thread is insanity.
Is there a product which fits with your vision of bug tracking? Did you look for it? The meter complies with it's specification. It does what it says on the tin. So why theorize about a benighted process for this particular product which I think would actually be pretty unique in the industry. Because of its relationship with this forum, there is a lot more information about this meter than others.
So sad that Mr. Jones does not care replying to messages regarding his multimeter's issues, the 121GW. The 121GW bluetooth is not working with the iPhone. I have the iPhone XS MAX, I cannot make 121GW bluetooth to work on this phone. I read the manual, I followed the outlined steps, no luck. I sent two messages to Mr. Jones, he cares less replying. I did not buy this meter from Amazon, otherwise, I would have sent it back long ago.
Somehow I still like the little thing, so sad that there is zero support from Mr. Jones.
Yes, I turned bluetooth ON, I followed page 53 instructions. I pressed the "1ms PEAK," and I see the "BT" on the screen, but the iPhone does not see the meter at all. So the application is blank.
So sad that Mr. Jones does not care replying to messages regarding his multimeter's issues, the 121GW. The 121GW bluetooth is not working with the iPhone. I have the iPhone XS MAX, I cannot make 121GW bluetooth to work on this phone. I read the manual, I followed the outlined steps, no luck. I sent two messages to Mr. Jones, he cares less replying. I did not buy this meter from Amazon, otherwise, I would have sent it back long ago.Direct any messages to Seppy (David #2) as IIRC he wrote the app.
Somehow I still like the little thing, so sad that there is zero support from Mr. Jones.
So sad that Mr. Jones does not care replying to messages regarding his multimeter's issues, the 121GW. The 121GW bluetooth is not working with the iPhone. I have the iPhone XS MAX, I cannot make 121GW bluetooth to work on this phone. I read the manual, I followed the outlined steps, no luck. I sent two messages to Mr. Jones, he cares less replying. I did not buy this meter from Amazon, otherwise, I would have sent it back long ago.
Somehow I still like the little thing, so sad that there is zero support from Mr. Jones.
Which application have you installed on the iPhone?
Just for clarity, are you looking for the meter on the iPhone, or inside the app? The iPhone does not need to connect to the meter, only the app does.
I installed the 121GW iOS. I think that's the only application available for this meter, am I right?
Well I tried both ways. I looked for the meter on the iPhone in Settings, Bluetooth. The iphone does not find the meter. Then I tried just the application, it never finds the iPhone as well. I delete the app, and reinstalled it, no help.
By the way I found a different serious bug regarding logging, where all measurements become corrupted/incorrect, will try to replicate it now... Will post it later if can figure out when and why it happens.I also encounter incorrect logging values (VA mode, with fw v1.53, v1.58beta), thou the display values are OK at the same time. On earlier fw versions (1.2-ish) same type of logging was OK.
So sad that Mr. Jones does not care replying to messages regarding his multimeter's issues, the 121GW. The 121GW bluetooth is not working with the iPhone. I have the iPhone XS MAX, I cannot make 121GW bluetooth to work on this phone. I read the manual, I followed the outlined steps, no luck. I sent two messages to Mr. Jones, he cares less replying. I did not buy this meter from Amazon, otherwise, I would have sent it back long ago.
Somehow I still like the little thing, so sad that there is zero support from Mr. Jones.
But please note that we do not have an iPhone XS MAX, nor do either of us use iPhone or any other apple hardware so we are not across any inctricacies of quirks of the iPhone and Apple stuff.:o
I would not expect Dave or David to be across all platforms with a high degree of expertise in them all.
What I might expect is a 121GW owner who does have such expertise in iOS and could write an App for the Apple ecosystem.
I would not expect Dave or David to be across all platforms with a high degree of expertise in them all.
What I might expect is a 121GW owner who does have such expertise in iOS and could write an App for the Apple ecosystem.
Quite normal behavior for any high input impedance meter and nuthing to get worried about.
(http://www.kellyphotos.org/ForumPics/eevblog/121gv%20ac%20voltage.jpg)
Seems odd to me. Am I making some noob mistake?
I get similar behavior from it if the probes aren't connected at all.
Thanks, I appreciate the feedback. I thought that might be the case, as the room I'm in has lots of active electronics. The difference in results from the fluke kind of surprised me though.Quite normal behavior for any high input impedance meter and nuthing to get worried about.
Seems odd to me. Am I making some noob mistake?
I get similar behavior from it if the probes aren't connected at all.
Sanity check; where is the decimal point ? 2mV is nothing but environmental EMI.
Has anyone else had the beeper fail on them intermittently?Around the beeper?
... ...
Anyone have suggestions where to concentrate my search for a bad solder-joint?
Has anyone else had the beeper fail on them intermittently?Around the beeper?
... ...
Anyone have suggestions where to concentrate my search for a bad solder-joint?
None of my other meters behave in this fashionThat's interesting, as all the autoranging DMMs I have/had did lock the range with relative measurements (e.g. Fluke 87V (https://dam-assets.fluke.com/s3fs-public/80v_____umeng0200.pdf?tKDGTic.KN0dP9_UJVtSyLsuYWEUp3SY), page 34, same for Fluke 289).
None of my other meters behave in this fashionThat's interesting, as all the autoranging DMMs I have/had did lock the range with relative measurements (e.g. Fluke 87V (https://dam-assets.fluke.com/s3fs-public/80v_____umeng0200.pdf?tKDGTic.KN0dP9_UJVtSyLsuYWEUp3SY), page 34, same for Fluke 289).
At the same time I've always wondered whether that was an easy to overcome limitation...
Care to share which brads/models don't do that?
pin4 <= tickms;
if(tickcounter3 == 8'd128) begin
tickms <= 1'b0;
end
if(tickcounter3 == 8'd255) begin
tickcounter3 <= 8'b0;
tickms <= 1'b1;
end
else begin
tickcounter3 <= tickcounter3+8'b1;
end
I noticed today when sampling a ~125KHz square waveGiven the Verilog, those look more as 250 kHz (64 MHz / 256), slightly above the specified frequency for Duty Cycle (200 kHz).
Given the Verilog, those look more as 250 kHz (64 MHz / 256), slightly above the specified frequency for Duty Cycle (200 kHz).
Also, the minimum pulse width is 5 µs, so the 200 kHz limit is a bit of a best case.
Moreover, the stated sensitivity is 2.5 V RMS: what's the FPGA output level?
.....a 5V digital circuit . Higher or lower than this level is slow to stabilize and increasingly inaccurate .
Anyway , bellow 5% is not accurate to be trusted at all , maybe at low frequency .$$Vrms=Vp\sqrt{D}$$
I think your math may be incorrect for the frequency. That code sets the output to 0 when the counter is at 128, then sets the output to 1 when the counter is 255. This would mean a full peak-to-peak cycle would be 512 clock ticks.
Am I missing something obvious?
TinyFPGA_BX_pll pll(.REFERENCECLK(clkGB),
.PLLOUTGLOBALA(clk128),
.PLLOUTGLOBALB(clk64),
.RESET(1'b1));
led ledmain (
.ledclk(clk64),
.led2clk(clk),
.led(led),
.usb_pu(usb_pu),
.pin1(pin1),
.pin4(pin4)
);
module led(
input ledclk,
input led2clk,
output reg led,
output usb_pu,
output reg pin1,
output reg pin4
);
reg [7:0] tickcounter3;
reg tickms;
always @ (posedge ledclk) begin
pin4 <= tickms;
if(tickcounter3 == 8'd128) begin
tickms <= 1'b0;
end
if(tickcounter3 == 8'd255) begin
tickcounter3 <= 8'b0;
tickms <= 1'b1;
end
else begin
tickcounter3 <= tickcounter3+8'b1;
end
end
#include <util/delay.h>
void setup()
{
pinMode(9, OUTPUT);
}
void loop()
{
noInterrupts();
while(1) {
PORTB |= _BV(PORTB1); // turn on
_delay_us(3.81);
PORTB &= ~_BV(PORTB1); // turn off
_delay_us(3.81);
}
}
I don't think is possible , my Fluke 867B is better because Hz ( duty cycle ) is a soft button , you are still in volts mode and you can choose manually a voltage range where works the best . This is how it should be done according to manual .
But 121GW use the rotary switch and has fixed sensitivity , whatever that might be when switched to Hz .
Another small issue - the bargraph in millivolt AC with 1KHz low pass filter activated is showing ~50mV less ::) . In the first picture is sitting at 3 and half , in the second at 3 .This also might be a regression on 1.51, in the revision history it mentions:
VAC + LPF bargraph issue resolved.
Another small issue - the bargraph in millivolt AC with 1KHz low pass filter activated is showing ~50mV less ::) . In the first picture is sitting at 3 and half , in the second at 3 .
(http://i64.tinypic.com/35me9hh.jpg)
(http://i63.tinypic.com/fn6c92.jpg)
has anyone noticed this?
try to turn burden voltage on, set the 121GW to 10A range and measure load current without using its voltage probe
mine on 10A range, the current reading drops about 2mA when the burden voltage is on, but when i turn the burden voltage off, the current reading on 10A range is back to normal again (without 2mA drop)...
no problems with burden voltage turned on or off when i set the meter to 5A or 500mA range
is this a bug or something? please respond, thx
The meter has firmware and calibration data ... if the calibration is corrupt the firmware update won't help , but you can try . Yes the firmware is backwards compatible .I have an update. I tried updating the firmware. I managed to downgrade it but it did not fix the problem.
I don't know the procedure , if you bought the meter from him you might have a phone number , if not , an email or you can send him a message using the forum .
I then tried removing all the leads and then turned on the meter to the A / mA selection. The display shows -100.19 mA when the 500mA scale is selected. All other ranges it shows zero. So I had an idea. I used the relative button to zero the display. I then plug in the leads and to my surprise it reads correctly. So there is obviously a problem with the offset for the 500mA scale. Is there a way to reset this?
You can try a zero offset callibration for that range as described in the manual . I did that myself for current offsets ( obvious not that bad that yours )Ok so I can do a offset calibration without affecting my range calibration?
Yes you can and it's simple .Ok. So its fixed but I didn't do anything besides steps 1 to 5 from page 65. Turning it on from the 3 o'clock position anti clockwise to the A / mA position. When I pressed the Rel button I noticed that the offset went back to zero. So I thought I wonder if this did anything. So I just turned it off and back on again and it was fine back to zero. Very strange.
Who knows what firmware or calibration bug you had , good that now it is okOne other thing that I noticed was that in mVA/VA mode the Range scale indicator does not change it just says '5' in the bottom right corner not matter what range you select. Is this normal?(https://uploads.tapatalk-cdn.com/20190707/5a5555838d6a8b00e45a1e9a4c6627dc.jpg)
That is a bug that now I see ... the range stay in the last used range on the other functions , so if it was 50 or 500 in current mode and you switch to VA it will show 50 or 500 and so on . The default is 5 if you turn it fast from OFF to VA and doesn't have time to settle anywhereSo how does the bug get reported and fixed in a future firmware update.
has anyone noticed this?
try to turn burden voltage on, set the 121GW to 10A range and measure load current without using its voltage probe
mine on 10A range, the current reading drops about 2mA when the burden voltage is on, but when i turn the burden voltage off, the current reading on 10A range is back to normal again (without 2mA drop)...
no problems with burden voltage turned on or off when i set the meter to 5A or 500mA range
is this a bug or something? please respond, thx
I don't see this particular issue clearly , but may be explicable ... with the voltage probe inserted and burden turn on is picking up the electrical field noise which somehow interfere with the current reading . So when I touched the voltage probe tip from 930mA the reading went to 990mA . Pretty insane .
Even that non zero current offset when you don't measure anything changes when you put the hands near the terminals ...
May be an issue but I don't see it ...
(https://i.ibb.co/5rszGtL/Burden-off.jpg) (https://ibb.co/R3QMYZc)(https://i.ibb.co/xMTWtBD/Burden-On.jpg) (https://ibb.co/4jrznX7)
So I’ve posted before about this but the Bluetooth radio in my meter isn’t working. My buddy’s meter will connect instantly but mine will not. Using a Bluetooth scanner does not detect the meter at all. This leads me to believe the radio is not functioning. Anyone else have this issue?
I've got two of these, updating the 1st went without an issue (just like all the other times I've done this), #2 locked up during the v2.0 update. After about 10 minutes of just letting it be I finally switched it off and back on:
:-//
Also note, the MEM and HOLD buttons no longer respond on power up.
The banana socket tips on my meter broke off with normal use, nothing was forced. I used Pomona banana cables inserted into meter. NBD for functionality, but it's a brand new meter and doesn't feel great..
That's a first. No other reports of that, and I've tried pulling the SD card during the update and other stuff to abuse it and the bootloader recovers fine.
Are the batteries ok?
That's a first. No other reports of that, and I've tried pulling the SD card during the update and other stuff to abuse it and the bootloader recovers fine.
Are the batteries ok?
Not sure what's different, played with it a few times today trying to get back to the bootloader, 5-6 times no luck. Then I pulled the batts again and just happen to attempt the bootloader while inserting the batteries (selector switch was not off) and it came up, flashed v2.0 without issue?
I guess issue resolved, thanks Dave.
That's a first. No other reports of that, and I've tried pulling the SD card during the update and other stuff to abuse it and the bootloader recovers fine.
Are the batteries ok?
Not sure what's different, played with it a few times today trying to get back to the bootloader, 5-6 times no luck. Then I pulled the batts again and just happen to attempt the bootloader while inserting the batteries (selector switch was not off) and it came up, flashed v2.0 without issue?
I guess issue resolved, thanks Dave.
Can I measure voltage peak to peak directly with this meter or do I need to calculate it?
Thanks Dave awesome meter by the way. Probably a silly question , but is it not possible to calculate it then and add it to the mode button.Can I measure voltage peak to peak directly with this meter or do I need to calculate it?
No, you can't do that with any meter. All meters are either average or RMS responding.
There is Peak mode, but that for capturing fast transients and not for peak-peak of a sine wave for example.
When will be a firmware update for all the bugs in V2.0 discussed here , and for some older ones still not resolved ?
Sorry I thought David had put v2.00 on the website, I've just added it now.
Had the weirdest thing happen with my 121GW after a 2 week vacation.
1. Turned on to 'V' with no leads plugged in and got beep beep beep ...
2. Turned to any A setting and beep would stop.
3. With knob set to 'V', plugged a lead into 500mA and beeping stopped |O
4. Let meter alone to check email and after about 15 seconds it starts beeping again. (like its supposed to in this state)
5. Took lead out and seemed to be working normally again.
Turned off meter for a few seconds and when turned on the whole cycle repeated.
Did this a few more times but the 15 seconds got shorter and shorter.
Next got video camera out to record process and of course the meters seems to be working correctly again.
Thought I would post anyway incase someone else has similar issue. I'm using NMH batteries and the voltage is only 5.1V. The auto shutoff is off and I left the meter on overnight and the problem still has not recurred. :-//
Can't understand why you do such experiments.I used the meter exactly as intended, beeped with leads in correct place or removed completely which should never beep. Only removed them to avoid chumps stating I had the leads in the wrong place.
Simply use the DMM as intended, i.e. with both leads plugged in at V / COM in DCV mode and in A or mA / COM in current mode.
DMM should beep when + lead is plugged in wrong jack.
Best use four ordinary 1.5V AA (manganine) cells, RTFM.Why don't you RTFM! As you note, 5.1V is above 4.2 and while alkaline are suggested, NiMH is not mentioned and by the way Dave has confirmed them acceptable. When your alkaline batteries start leaking in your meter you'll know why I use NiMH. Also the whole point of my post is to document a problem so others and the maker can learn from it. I doubt this will be the last time this happens on somebodies meter. I have a lot more details if someone else has had the issue.
5.1V is obviously ok, as low bat is something below 4.2V, RTFM.
Can't understand why you do such experiments.I used the meter exactly as intended, beeped with leads in correct place or removed completely which should never beep. Only removed them to avoid chumps stating I had the leads in the wrong place.
Simply use the DMM as intended, i.e. with both leads plugged in at V / COM in DCV mode and in A or mA / COM in current mode.
DMM should beep when + lead is plugged in wrong jack.Best use four ordinary 1.5V AA (manganine) cells, RTFM.Why don't you RTFM! As you note, 5.1V is above 4.2 and while alkaline are suggested, NiMH is not mentioned and by the way Dave has confirmed them acceptable. When your alkaline batteries start leaking in your meter you'll know why I use NiMH. Also the whole point of my post is to document a problem so others and the maker can learn from it. I doubt this will be the last time this happens on somebodies meter. I have a lot more details if someone else has had the issue.
5.1V is obviously ok, as low bat is something below 4.2V, RTFM.
START,2019/08/14,19:37:37,
ID,170800000,
INTERVAL,001,sec,
,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.512,mA,,
2,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.512,mA,,
3,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.511,mA,,
4,DCmVA,0018.74,mVA,DCV,01.3874,V,DCmA,013.511,mA,,
5,DCmVA,0018.74,mVA,DCV,01.3874,V,DCmA,013.511,mA,,
6,DCmVA,0018.74,mVA,DCV,01.3874,V,DCmA,013.510,mA,,
7,DCmVA,0018.74,mVA,DCV,01.3874,V,DCmA,013.510,mA,,
8,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.510,mA,,
9,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.510,mA,,
10,DCmVA,0018.74,mVA,DCV,01.3872,V,DCmA,013.510,mA,,
11,DCmVA,0018.73,mVA,DCV,01.3870,V,DCmA,013.510,mA,,
12,DCmVA,0018.73,mVA,DCV,01.3870,V,DCmA,013.510,mA,,
13,DCmVA,0018.73,mVA,DCV,01.3870,V,DCmA,013.509,mA,,
14,DCmVA,0018.73,mVA,DCV,01.3870,V,DCmA,013.509,mA,,
15,DCmVA,0018.73,mVA,DCV,01.3869,V,DCmA,013.509,mA,,
16,DCmVA,0018.73,mVA,DCV,01.3869,V,DCmA,013.509,mA,,
... // all good
14382,DCmVA,0017.26,mVA,DCV,01.3311,V,DCmA,012.967,mA,,
14383,DCmVA,0017.26,mVA,DCV,01.3311,V,DCmA,012.967,mA,,
14384,DCmVA,0017.26,mVA,DCV,01.3311,V,DCmA,012.967,mA,,
14385,DCmVA,0017.25,mVA,DCV,01.3311,V,DCmA,012.966,mA,,
14386,DCmVA,0017.25,mVA,DCV,01.3311,V,DCmA,012.966,mA,,
14387,DCmVA,0017.25,mVA,DCV,01.3311,V,DCmA,012.966,mA,,
14388,DCmVA,0017.25,mVA,DCV,01.3311,V,DCmA,012.966,mA,,
14389,DCmVA,0017.25,mVA,DCV,01.3311,V,DCmA,012.966,mA,,
... // still all good
21238,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21239,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21240,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21241,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21242,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21243,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21244,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.875,mA,,
21245,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21246,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21247,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21248,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21249,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21250,DCmVA,0017.02,mVA,DCV,01.3219,V,DCmA,012.876,mA,,
21251,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21252,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21253,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21254,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21255,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.875,mA,,
21256,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.875,mA,,
21257,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.875,mA,,
21258,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21259,DCmVA,0017.01,mVA,DCV,01.3219,V,DCmA,012.874,mA,,
21260,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.874,mA,,
21261,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.874,mA,,
21262,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21263,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21264,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21265,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21266,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21267,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21268,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21269,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21270,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21271,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21272,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.876,mA,,
21273,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21274,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21275,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21276,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
21277,DCmVA,0017.01,mVA,DCV,01.3218,V,DCmA,012.875,mA,,
... // stuck forever
113359,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.873,mA,,
113360,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113361,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113362,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113363,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113364,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113365,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113366,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113367,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113368,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113369,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113370,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113371,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113372,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113373,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113374,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113375,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.871,mA,,
113376,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.871,mA,,
113377,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.871,mA,,
113378,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113379,DCmVA,0017.01,mVA,DCV,01.3216,V,DCmA,012.872,mA,,
113380,DCmVA,0017.01,mVA,DCV,01.3215,V,DCmA,012.872,mA,,
113381,DCmVA,0017.01,mVA,DCV,01.3215,V,DCmA,012.872,mA,,
113382,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.870,mA,,
113383,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.870,mA,,
113384,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.870,mA,,
113385,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.871,mA,,
113386,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.871,mA,,
113387,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.871,mA,,
113388,DCmVA,0017.00,mVA,DCV,01.3215,V,DCmA,012.871,mA,,
113389,DCmVA,0017.01,mVA,DCV,01.3215,V,DCmA,012.873,mA,,
MAX,1,DCmVA,0018.74,mVA,
MIN,21477,DCmVA,0017.00,mVA,
Isn't it able to log over bluetooth, so that you can modify the data on the fly with a Pi Zero W, ESP32, smartphone or something like that?
...Hm, it is working, but with an issue, in the moment. This meter is rel fresh and need some community support, as it is defined to be. Your longtime logging is a little worst case scenario, even for meters like the Keithley DMM6500, imho. Maybe you need an other meter for that, or look inside the firmware by yourself (don't know it is open source - hackable too).
The SD data logging functionality is in the meter, is advertised, and is not working at the moment.
I do use two 121GW for few months, but recently started doing some extra data logging intensively (which is the reason I got this meter really), and unfortunately it is broken in many ways. I tested both, 1.57, and 2.00 fw.
- SERIOUS: After some time of data logging to SD card, it stops updating values in the file. LCD is showing proper values, and says that new records are added to the file. However the file only starts having 3 values cycling forever (flat line forever). This can start after 1000 records, or after 10000, or somewhere in between, hard to say. If I do a data logging for a 3 days, it is 100% certain my data file will be ruined, and experiment waste of time, and possibly money. The worst part is you only learn about it later, when you read files back on a computer. Example at the bottom.
0 3959
1 219
2 54
3 44
4 54
5 43
6 28
7 11
8 11
9 11
10 11
11 11
12 11
13 11
14 11
15 11
16 11
17 11
18 11
19 11
20 11
...
2032 11
2033 11
2034 11
2035 11
2036 11
2037 11
2038 11
2039 11
2040 11
2041 11
- CONSIDERABLE: It looks like a there is a limit of 600000 records, after which the logging automatically stops. Please rise it at least 100 times, as I don't see much reason to have it, and it is somehow limiting.
- SERIOUS: When having Interval of 0, the sampling rate is very non uniform, sometimes doing 1 per second, sometimes 10 per second, sometimes stopping for some time. And because records don't have timestamp, it makes data logging at interval 0, totally useless for anything, there is no way to reliably use them for anything. This comes back to the 4th point above.
There are some other minor things that do bother me about the 121GW, but really, the data logging issues are the biggest problem right now, making it not usable at the moment.
...Hm, it is working, but with an issue, in the moment. This meter is rel fresh and need some community support, as it is defined to be. Your longtime logging is a little worst case scenario, even for meters like the Keithley DMM6500, imho. Maybe you need an other meter for that, or look inside the firmware by yourself (don't know it is open source - hackable too).
The SD data logging functionality is in the meter, is advertised, and is not working at the moment.
Wish good luck. ;)
Quote
- SERIOUS: When having Interval of 0, the sampling rate is very non uniform, sometimes doing 1 per second, sometimes 10 per second, sometimes stopping for some time. And because records don't have timestamp, it makes data logging at interval 0, totally useless for anything, there is no way to reliably use them for anything. This comes back to the 4th point above.
It seems that the meter likely blocks while writing to SD card. By turning logging quickly on and off several times I managed to block DMM completely for a few (about 10) seconds.
I even started thinking that it died, but then it unblocked on its own, so I am pretty sure writes to SD card are synchronous.
...Hm, it is working, but with an issue, in the moment. This meter is rel fresh and need some community support, as it is defined to be. Your longtime logging is a little worst case scenario, even for meters like the Keithley DMM6500, imho. Maybe you need an other meter for that, or look inside the firmware by yourself (don't know it is open source - hackable too).
The SD data logging functionality is in the meter, is advertised, and is not working at the moment.
Wish good luck. ;)
I don't think firmware is open source. I tried to find it, and debug, add some features, but can't find it anywhere.
Darn, there are so many issues around data logging on this thing...Hm, what do you expect from "this price range" on the market?
Was also one of my main reasons to get it.
But it's crazy to get to Data, screw open instead of BT File access.
No timestamps, instable on long measurements...
What's a better logging meter at around that price range? Or, how far up to get something better?
Any recommendations?
after Dave multiple comments about his intent for this threadYes, i was unsure what this monster thread is meant for and what not.
But someone quite going into the details like Dave, i expected every feature to be reasonably usable. SD under screws is... well, not thought through at all. Seems like a marketing gimmick, unless it was thought to be used with BT file access, which was maybe cut out due to no time/money to finish it, is what i guess.Your criticism is based on ignorance. Many of us have been following the development of the 121GW for quite some time. The SD card addition came late in that development and a lot of the features which are now being exploited came along as "feature creep". This alone means (in my book) criticism needs to be tempered. I expect there will be some further firmware revisions that will address these issues, but they were not in the original design brief - so I would advise some patience. The key functionality as a DMM is what is most important and that is becoming mature.
Your criticism is based on ignorance. Many of us have been following the development of the 121GW for quite some time. (snip)...BTW - These things have been discussed before.
The fact is it doesn't have an easy way to see/download the data logging . This is a fair criticism . You should have pointed out clearly this deficiency at the "supporters area" early discusions ;D
A fully custom EEVblog Electronics Multimeter designed by Dave & UEI, with many exclusive features like SD card logging & Bluetooth!This gave me the impression Datalogging is not a feature creep thing, but one of the more notable features. And as such, well-thought-out and executed.
The fact is it doesn't have an easy way to see/download the data logging . This is a fair criticism . You should have pointed out clearly this deficiency at the "supporters area" early discusions ;D
Do you really go out of your way to be an ASSHAT?
Data being logged to an internal card at speed that is the same as on the display is not an 'issue' and you once again are being a TROLL !
I'm not entering the war here, just commenting on my experience with the bluetooth logging...Time for a signature change ?
I have tried to log my solar powered golf cart dozens of times and have not once had the logging last an entire day-light span. Sometimes it will log for a few hours, sometimes less than 5 minutes before updates just stop, Android tablet on plug power 5' from the 121.
Note: I have not tried with the 2.0 FW update, have since moved to a different meter.
The fact is it doesn't have an easy way to see/download the data logging . This is a fair criticism . You should have pointed out clearly this deficiency at the "supporters area" early discusions ;D
Do you really go out of your way to be an ASSHAT?
Data being logged to an internal card at speed that is the same as on the display is not an 'issue' and you once again are being a TROLL !
I"m a troll for fanboys like you , the logging has issues not just the physical acces , a pain in the butt because they couldn"t do it wirelessly or add a normal computer interface . Whatever ...
It’s too bad Fanboys and Trolls are such a major issue with the 121gw as their posting seems to drown the real hardware and firmware problems being reported.
It’s too bad Fanboys and Trolls are such a major issue with the 121gw as their posting seems to drown the real hardware and firmware problems being reported.
Well, bug tracking only works with a list that summarizes all recognized bugs, all fixes with an exact description and all open issues. That was often desired, but never done. It does not work in the current state (forum with a lot of "noise"). Several described bugs are simply ignored (like the very strange "low capacity bug", the 500V range loop etc.). I can't understand why this is not done more professionell.
The fact is it doesn't have an easy way to see/download the data logging . This is a fair criticism . You should have pointed out clearly this deficiency at the "supporters area" early discusions ;D
Do you really go out of your way to be an ASSHAT?
Data being logged to an internal card at speed that is the same as on the display is not an 'issue' and you once again are being a TROLL !
I"m a troll for fanboys like you , the logging has issues not just the physical acces , a pain in the butt because they couldn"t do it wirelessly or add a normal computer interface . Whatever ...
As you have spent maybe half of your posts TOTAL on this forum whining bitching and moaning about this meter, the manufacturer and the distributor you are an ASSHAT ! Stop being a serial SOOK
It turns out that I require to have Location Services on for the app to have it work. I could see the meter in the BT list and it was already paired, just needed the Location for some reason
When performing a firmware update, the LCD looks like it's displaying "Douun". I fully understand that the two U's together are supposed to resemble a W. However, would it be possible to make it display "LOAd" or "Run.." instead?
if this multimeter's firmware is truly open source, i believe it will sell like hot cakes...
if this multimeter's firmware is truly open source, i believe it will sell like hot cakes...It was never open source or intended to be. The Bluetooth is a different matter.
That was the original hope, but UEi have said they will not allow this as it contains proprietary code used on others products etc.if this multimeter's firmware is truly open source, i believe it will sell like hot cakes...It was never open source or intended to be. The Bluetooth is a different matter.
That was the original hope, but UEi have said they will not allow this as it contains proprietary code used on others products etc.if this multimeter's firmware is truly open source, i believe it will sell like hot cakes...It was never open source or intended to be. The Bluetooth is a different matter.
I wonder, would it be possible to have the internal hardware interfaces documented so that a completely independent firmware might be written?
Thinking that perhaps I was too rough or something on the V jack, I started looking at the others. I used the mA once to verify operation with the provided leads (I may have used the A jack once as well). Both mA and A shrouds are already cracked near the top around near the edge of the metal insert. The attached image shows that the mA shroud already cracked (just not completely broken through).
The common shroud appears to still be intact.
:-//
1) Purchased.
2) Plugged in leads that came with the meter.
3) Ran through basic measurements to make sure it worked.
4) Removed leads - everything OK.
5) Plugged in leads, coiled around meter, probes pressed into holster.
6) Put on shelf.
7) A few weeks later,decide to store leads by hanging them.
8 ) Remove leads, shroud sticking out of lead banana plug. >:(
I haven't even opened up the meter to update the firmware yet.
I've snapped a few close ups of the broken shroud. It is seriously stress cracked beyond what I would think the mere insertion and removal of test leads should cause.
So, how can I fix this? Superglue? :-\
So, how can I fix this? Superglue? :-\
Look at the plugs carefully that they were not the cause first! If you have some verniers do some measuring of them and inspection of the lantern and outer shroud.
I wouldn't think superglue would work for something like this, probably more of two part epoxy thing maybe?
I've contacted UEi to see what the deal is.
It seems to have happened in a couple of cases now, and given the numbers shipped and the use they've had it's unlikely to be a systemic issue.
I wouldn't think superglue would work for something like this, probably more of two part epoxy thing maybe?
I've contacted UEi to see what the deal is.
It seems to have happened in a couple of cases now, and given the numbers shipped and the use they've had it's unlikely to be a systemic issue.
Thanks Dave. I purchased this from your store, not because I needed yet another meter, but more to support the blog/channel. Now that I've seen the extent of the cracking, I've abandoned the gluing idea. I was just trying to avoid more round-the-world shipping.
It might be damage due to the metal insertion step over-forcing the plastic and causing fractures. If the metal is out of spec, it might be stressing the plastic.
I know that there had been some issues previously reported about defects with some of the Brymen leads, but it is interesting that future meters will be sold with uei leads. Dave, was this your call to simplify things or did uei recommend this change?
Kind of figured. I've got quite a few sets of those and so far they've been problem free. From what I remember reading, the issues reported thus far had mostly been quality control problems on the stabby end.
1) Purchased.
2) Plugged in leads that came with the meter.
1) Purchased.Just for the record, were the leads you received made by Brymen or UEI ?.
2) Plugged in leads that came with the meter.
At different times I believe both brands have been supplied with the 121GW and I'm pretty sure the UEI leads have a really long strain relief on the banana plug end. I received the Brymen leads with the BM-235 and have found them rather a tight fit in some other meters such as the Flukes.
I think I had a set of Brymen probes that one banana end was tight in most of my meters, and really tight in the 121GW KS they came with. You replaced them and all was good.Kind of figured. I've got quite a few sets of those and so far they've been problem free. From what I remember reading, the issues reported thus far had mostly been quality control problems on the stabby end.Yes, I don't recall a single issue with the banana plug end.
I think I had a set of Brymen probes that one banana end was tight in most of my meters, and really tight in the 121GW KS they came with. You replaced them and all was good.Kind of figured. I've got quite a few sets of those and so far they've been problem free. From what I remember reading, the issues reported thus far had mostly been quality control problems on the stabby end.Yes, I don't recall a single issue with the banana plug end.
If the meter had any plastic shrouding issues with the first batch that one probe you replaced would have cracked it for sure.
1) Purchased.
2) Plugged in leads that came with the meter.
Just for the record, were the leads you received made by Brymen or UEI ?.
At different times I believe both brands have been supplied with the 121GW and I'm pretty sure the UEI leads have a really long strain relief on the banana plug end. I received the Brymen leads with the BM-235 and have found them rather a tight fit in some other meters such as the Flukes.
Dave,
I'm not sure if this is an issue or not, so feel free to erase it.
Way back when you sent me the prototype meter, it included some really old firmware and you supplied me with what documents you had at the time. At that time the alignment procedure was not included in the user's manual. When I attempted to upgrade the firmware on this meter, the calibration was no longer valid. I think this was something you had posted about or covered in Amp hour. I made some transfer standards using my bench meter and realigned it. I took some notes about what I had done and called it good enough.
There is a member attempting to realign their meter and they ran into a problem.
https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/msg2790680/#msg2790680 (https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/msg2790680/#msg2790680)
Looking at the various manuals that were made available that include the alignment procedure, it appears that they changed it. I suspect based on what this person has found and having gone through it myself, this is the reason the meter is no longer able to read down into the 100pF ish values.
Dave,
I'm not sure if this is an issue or not, so feel free to erase it.
Way back when you sent me the prototype meter, it included some really old firmware and you supplied me with what documents you had at the time. At that time the alignment procedure was not included in the user's manual. When I attempted to upgrade the firmware on this meter, the calibration was no longer valid. I think this was something you had posted about or covered in Amp hour. I made some transfer standards using my bench meter and realigned it. I took some notes about what I had done and called it good enough.
Anything related to the prototype meter I sent you should have no relevance to any production meter, this is why I specifically told you at the time not to test it or review it, it was just for shit'n'giggles to watch the magic smoke escape.QuoteThere is a member attempting to realign their meter and they ran into a problem.
https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/msg2790680/#msg2790680 (https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/msg2790680/#msg2790680)
Looking at the various manuals that were made available that include the alignment procedure, it appears that they changed it. I suspect based on what this person has found and having gone through it myself, this is the reason the meter is no longer able to read down into the 100pF ish values.
I don't recall changes to the calibration procedure.
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.
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.
Thanks for the quick update Dave. I'll be sending an email to get a replacement jack assembly from you as I'm pretty sure that my SN is within the affected range, though it's a shame that you've got to go through this. :(
UPDATE:
The issue with the cracked input jacks is as several suspected, a molding issue.Quoteinput 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:Quote2. 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
UPDATE:
UEi have indicated they have fixed (or greatly improved) the resistance drift problem.
They are just working on another issue that could take another week or two before a new firmware release.
UPDATE:
UEi have indicated they have fixed (or greatly improved) the resistance drift problem.
They are just working on another issue that could take another week or two before a new firmware release.
YesUPDATE:
UEi have indicated they have fixed (or greatly improved) the resistance drift problem.
They are just working on another issue that could take another week or two before a new firmware release.
People have been talking about problems when long term logging to the SD-card.
Is that problem being addressed as well?
UPDATE:
UEi have indicated they have fixed (or greatly improved) the resistance drift problem.
They are just working on another issue that could take another week or two before a new firmware release.
Is this the drift I asked about during your 10ohm speed test video or is there another problem with the resistance drift?
Is the other issue they are planning to go after the one where the auto range seems to not work with a biased HV AC source?
Is this the drift I asked about during your 10ohm speed test video or is there another problem with the resistance drift?
No, it's the 1Mohm range settling thing.
Hmm I posted this in the wrong forum - so I repost it here:
Since v2.0 the SD card logging stops working properly after a while. I haven't tried that in 2.02. The last time I recorded voltage for 19.5-20 hours with interval 2 seconds, fixed range. I monitored the display - the battery dropped gradually with cut off at about 10.8V. At about 19.5 hours the voltage was 11. At 19.0 hours - 11.8V. However since about 2h 40min (about 4800 recods) the value in csv is 12.529V +/- 3 LSD. The last digit keeps moving around like it's recording real data, but it has nothing to do with what's on the display.
I've reported this before, but I don't see it in firmware change log. Is this fixed? Does anyone else have similar problems?
Edit: Also since v2.0 the multimeter will occasionally freeze when I start logging - switching ranges, pressing buttons have no effect, until I turn it off.
P.S. Yes, I know that bluetooth exists. I don't want to rely on wireless for long term logging.
P.S. 2: I am currently starting a new 20+ hours log with v2.02 - we'll see if it happens again.
Same results with 2.02 firmware. 39003 points collected, at some point the voltage just stops dropping. The last value is 11.65V, but I've seen that at the end it was about 11.1V (cutoff is at 10.5 and then the battery voltage recoveded a bit).
Btw I tested the cut off with a bench power supply - the cut off at 10.50V works fine.
The drop near 5000th record is the end is because I physically bumped the probes off the battery. You can see after 26000-27000 records the graph flattens and stays at about 11.65V, and I know that can't be true because I can see different value on the display of the DMM
Same results with 2.02 firmware. 39003 points collected, at some point the voltage just stops dropping. The last value is 11.65V, but I've seen that at the end it was about 11.1V (cutoff is at 10.5 and then the battery voltage recoveded a bit).
Btw I tested the cut off with a bench power supply - the cut off at 10.50V works fine.
The drop near 5000th record is the end is because I physically bumped the probes off the battery. You can see after 26000-27000 records the graph flattens and stays at about 11.65V, and I know that can't be true because I can see different value on the display of the DMM
Did you measure the voltage of DMM by using the same DMM?
In my case, I used a constant resistive load so I know there is nothing going on that could fool me. I also changed out the battery for the last 5 hours of data to make sure the meter is still recording new data. It still has a ways to go but at least looking at the display, everything appears to be fine.I meant to set mine up last night, but forgot as I fell asleep waiting for my meters and voltage ref to warm up. I needed to check the calibration since I moved and the equipment was not in use for I months. The good news, bench meter is still looking good. But I already created the profile for this log test yesterday, so I figured I would still run it.
Did you measure the voltage of DMM by using the same DMM?
Wow so first the A/mA jacks cracked at top, now entire Volt jack sleeve came off from next to no use of meter :--Bad batch, see here:
See attached..
The battery is 9Ah lead acid (rated at 0.45A for 20h). The load is an embedded pc with DC-DC buck converter. it started at 0.33A at 12.8V . First time it took 20 hours, second time less - I guess battery wasn't fully charged. Sample time is once a 2 secodns
Wow so first the A/mA jacks cracked at top, now entire Volt jack sleeve came off from next to no use of meter :--
UPDATE:Did you measure the voltage of DMM by using the same DMM?I did try second DMM - braymen BM869 to confirm voltage
npelov, has your failed since you updated to firmware 2.02?Yes, I did one 10+ hours test and the cuttoff voltage is at 10.5V, but I don't see anything below 11.6V. I did not witness the cut off this time, but when I stopped the logging the battery has recovered to 11.1-11.2V (noticed on the DMM display) and I don't see that voltage in the table. Nothing below 11.6.
Maybe it was a firmware issue that was fixed in the past.
npelov, has your failed since you updated to firmware 2.02?Yes, I did one 10+ hours test and the cuttoff voltage is at 10.5V, but I don't see anything below 11.6V. I did not witness the cut off this time, but when I stopped the logging the battery has recovered to 11.1-11.2V (noticed on the DMM display) and I don't see that voltage in the table. Nothing below 11.6.
I will make more tests, but right now I'm getting ready for a surgery, so I might do that after a week or two ... if I survive.
The weird thing is trying to make it repeatable. I did capture another 44K logs and it didn’t show up this time. So I ran a faster more aggressive fall curve with only 1000 points and 5 seconds between each point change from 20VDC to 5VDC over a few hours capturing a little over 2000 logs. And again I didn’t see it.
I doubt it's go anything to do with the input signal, I suspect that's a red herring.I tend to agree.
The weird thing is trying to make it repeatable. I did capture another 44K logs and it didn’t show up this time. So I ran a faster more aggressive fall curve with only 1000 points and 5 seconds between each point change from 20VDC to 5VDC over a few hours capturing a little over 2000 logs. And again I didn’t see it.
I could run another 19 hour test with 50K logs captured, but this is such a long test to do and not fun to watch :popcorn: It must be a very specific chain of events that happens to cause this loop.
I think having three different meters see the issue is enough for me. My power supply is needed for some other projects.
I doubt it's go anything to do with the input signal, I suspect that's a red herring.
For those interested, we (Kane & EEVblog) are now setting up a shared git (not public) for firmware version control with the intention that we (EEVblog) now have full visibility on all firmware changes, and in time will be able to make our own changes and compile ourselves etc.
At present we have almost no real visibility into their internal firmware environment.
Hi,
Worried about this log issue I started to make my own measurements. The first one was logging the current thru a 2k2 resistor feed by a Li/SOCl2 cell during 24 h at 1 sps, BT off, FW2.00. Nothing to report, all went OK.
The next was a 24 h (in fact ~26 h) log of the mains (230 V/50 Hz here) voltage at 1 sps, BT off, FW2.02. This time the issue surfaced in less than 2 hours:
....
I'll try to continue testing other magnitudes.
Hope this helps. Regards.
Are both you and Scott erasing the SD card between tests?I’m not, after all a 12hr to 16hr test only produces a 1mg , to 1.5mg file on an 8GB card.
$ awk '{print length}' 19120701.CSV | uniq -c
1 27
1 14
1 18
1 32
1 60
9 24
90 25
900 26
9000 27
11476 28
1 173
78518 28
18848 29
1 419
17752 29
1 239
2927 29
1 389
44207 29
1 389
20757 29
1 89
87220 29
1 25
1 21
$
$ awk 'length > 30 { print }' 19120701.CSV
,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
21476,DCV,009.121481,DCV,009.185,V,,,,,,,,
118118861,DCV,009.120,V,,,,,,,,
136614,DCV,009.136621,DCV,009.120,V,,,,,,,,
139561,DCV,009.120,V,,,,,,,,
183769,DCV,009.160,V,183781,DCV,009.120,V,,,,,,,,
204539,DCV,009.166,V,,,,,204541,DCV,009.120,V,,,,,,,,
$
$ awk 'length > 30 { print }' 19120701.CSV | xxd
00000050: 2c56 616c 7565 2c55 6e69 742c 0d0a 3231 ,Value,Unit,..21
00000060: 3437 362c 4443 562c 3030 392e 3100 0000 476,DCV,009.1...
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0032 ...............2
000000f0: 3134 3831 2c44 4356 2c30 3039 2e31 3835 1481,DCV,009.185
00000100: 2c56 2c2c 2c2c 2c2c 2c2c 0d0a 3131 3800 ,V,,,,,,,,..118.
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000200: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000210: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000220: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000230: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000240: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000250: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000260: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000270: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000280: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000290: 0000 3131 3838 3631 2c44 4356 2c30 3039 ..118861,DCV,009
000002a0: 2e31 3230 2c56 2c2c 2c2c 2c2c 2c2c 0d0a .120,V,,,,,,,,..
000002b0: 3133 3636 3134 2c44 4356 2c30 3039 2e00 136614,DCV,009..
000002c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000300: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000310: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000320: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000330: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000340: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000350: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000360: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000370: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000380: 0000 3133 3636 3231 2c44 4356 2c30 3039 ..136621,DCV,009
00000390: 2e31 3230 2c56 2c2c 2c2c 2c2c 2c2c 0d0a .120,V,,,,,,,,..
000003a0: 3133 3935 3439 2c44 4356 2c30 3039 2e31 139549,DCV,009.1
000003b0: 3630 2c56 2c2c 2c2c 2c2c 2c2c 0d00 0000 60,V,,,,,,,,....
000003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000430: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000440: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000450: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000460: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000470: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000480: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000490: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000500: 0000 0000 0000 0000 3133 3935 3631 2c44 ........139561,D
00000510: 4356 2c30 3039 2e31 3230 2c56 2c2c 2c2c CV,009.120,V,,,,
00000520: 2c2c 2c2c 0d0a 3138 3337 3639 2c44 4356 ,,,,..183769,DCV
00000530: 2c30 3039 2e31 3630 2c56 2c00 0000 0000 ,009.160,V,.....
00000540: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000550: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000560: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000570: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000580: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000590: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000005f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000600: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000610: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000620: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000630: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000640: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000650: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000660: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000670: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000680: 0000 0000 0000 0000 0000 0000 0000 3138 ..............18
00000690: 3337 3831 2c44 4356 2c30 3039 2e31 3230 3781,DCV,009.120
000006a0: 2c56 2c2c 2c2c 2c2c 2c2c 0d0a 3230 3435 ,V,,,,,,,,..2045
000006b0: 3339 2c44 4356 2c30 3039 2e31 3636 2c56 39,DCV,009.166,V
000006c0: 2c2c 2c2c 2c00 0000 0000 0000 0000 0000 ,,,,,...........
000006d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000006e0: 0000 0000 0000 0000 3230 3435 3431 2c44 ........204541,D
000006f0: 4356 2c30 3039 2e31 3230 2c56 2c2c 2c2c CV,009.120,V,,,,
00000700: 2c2c 2c2c 0d0a ,,,,..
$
but once is enough of course.
Thanks for the tip floobydust. I have just performed this test...121GW reads 0 even holding the instrument next to the VFD.
To see if it's an interference problem, put the DMM on ACV manual range say 1000V, short the two input leads together and it should read around 0V. With the drive running, place both probes on ONE motor terminal (DMM should still read 0V). I have seen DMM's freak out, reboot or crash, or give silly readings during this test.
any news about firmware update?
any news about firmware update?
I have a new version but I haven't tried it yet due to the holidays.
any news about firmware update?
I have a new version but I haven't tried it yet due to the holidays.
Hey everyone,Good to have you back. I did mention your findings in my last video. If you need to get some sleep to help with your recovery, I suggest you watch it.
I'm back from the surgery - alive and kicking. I can see you've repeated the strange SD card logging problem - thanks joeqsmith. I noticed that the sample repeat frequency is about 60 samples. I would have guessed 64, but looking at this image (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=885056;image) it's more like exactly 60 (I didn't look at the csv data - just eyeballing it in two screnshots). So that's nice round number - maybe the developers can relate this number to the code.
Happy holidays!
any news about firmware update?
I have a new version but I haven't tried it yet due to the holidays.
Dave, does this mean you dont take your 121GW meter away with you on holidays ?
Shame on you :-DMM :-DMM :-DMM
Enjoy the holiday break :-+
Thank you, Dave.
The 1 MOhm range now works as intended, i.e. gives instantaneously a stable display on 2nd measurement.
The 600Vdc range, down ranging problem is not yet solved, i.e. it still down ranges at <= 49.9 V only.
Frank
how about logging? did you test that too?If your referring to the offing loop error in this thread, he didn’t mention that this firmware fixes it. This version just adds date and time stamp to the logs.
I'm in the same boat. There's also no mention of them correcting the auto range problems that prevent the meter from indicating a presence of high voltages. I can't see spending any time retesting it and plan to pull the Duracells and box them up. Maybe in another couple of years we can revisit what ever hardware they come up with. I doubt we have seen the last of changes to the front end or that switch design. Maybe they will get some proper lettering on the meter by then as well. ANENG could help them out with that one.how about logging? did you test that too?If your referring to the offing loop error in this thread, he didn’t mention that this firmware fixes it. This version just adds date and time stamp to the logs.
Joe, npelov, Dave and I spent a lot of time replicating this log error. I know I had a few days running logs for it.
As for me, I’m not looking to run that test again until Dave specifically states that issue was addressed in the firmware.
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!
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 (https://en.wikipedia.org/wiki/Thermocouple#Type_K) as a primer.
...
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.
| 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 |
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 (https://en.wikipedia.org/wiki/Thermocouple#Type_K) 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 (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.
This timestamp format is horrible....
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
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,,
...
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.
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 ;D
everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs ;DSoftware development follows the same fundamentals as most everything else....
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.
everyone here has the same problem as yours sir so good luck convincing Dave to repair 131gw's data logging bugs ;DSoftware 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.
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
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
START,2020/01/30,00:22:27,
...
24513,2020/01/30,22:15:27,DCV,006.692,V,,,,,,,,
$ 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
$
$ 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,,,,,,,,
...
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,
01.02.2020 09:39 6 415 024 20020100.CSV
02.02.2020 19:39 29 889 125 20020102.CSV
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,
UPDATE:
The issue with the cracked input jacks is as several suspected, a molding issue.Quoteinput 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:Quote2. 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!
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.
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 ?.
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).
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.QuoteST 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.
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.QuoteST 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.
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?
$ 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 ,,,,,,,,..
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
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,,,,,,,,
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 (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.
This timestamp format is horrible....
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
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.
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 (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.
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.
I run the same test as in https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2819856/#msg2819856 (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.
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.
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.QuoteST 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.
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 ,,,,,,,,..
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.
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!
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 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?
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.
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"...
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|
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,
...
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,,,,,,,,
...
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
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.
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|
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"
set xdata time
plot "20041800.CSV" u 2:4 w l t "power"
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"
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.
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?
After powering it on, the PSU shows correctly 6.01V. Verified by secondary multi meter.Looks like someone's been looking to find a use for those batterizers... :-DD
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.
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
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.
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.
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.
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:
(Attachment Link)
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.
Yes a capacitor would help against the noise, but I feel they could also just used a resistor divider with much lower values i.e. 180k+59k and still the battery consumption (about 25uA) wouldn’t really be much of a problem, but perhaps though after a very long time in auto power off mode.
With regard to the accuracy of the battery indicator - they rely on the a fixed correction value in firmware together with the values in a look up table - so there’s no calibration done as such. The hack I did on my meter (shown above) shows it could be made much more accurate without changing the hardware and even have higher resolution. But that was only on my meter, or on my stm32 mcu, there's no guarantee it would work on all 121gw’s - now with the divider being so far above the recommended max impedance, but I think it could be made significantly more accurate and really should also have a user calibration implemented for it in FW
That datasheet input ADC impedance is not an absolute value ... in some applications can be larger . The battery voltage is very clean , that's why they could skip the input capacitor ( low pass filter ) although this "economy" is questionable .
After reading a bit more and checking schematics, the 50kΩ maximum input resistance, is only allowed for very longest sampling time (i.e. long sampling time, or low adc clock frequency). I.e. for 24 μs. This is because of internal sample capacitors (total being 8pF, which together with internal and external resistance forms the RC circuit, so the time for sampling need to be sufficiently high to reach actual correct value). Using high ADC clock frequency, or short sampling time, requires significantly lower maximum input resistance, in many case 1Ω-2kΩ. I don't know what settings (sampling time, resolution, adc clock frequency, multiplexing, oversampling / averaging) are used for reading the battery voltage from the divider but it is possible incorrectly configured in software. But even if it is configured most conservatively possible, the input resistance would still be too high for very accurate measurements.
The schematics is also somehow incomplete. It shows external voltage reference (ZD2), of unknown voltage and model, and R49 is marked as 0Ω, which doesn't make sense.
Additionally, VREF+ and VDDA capacitors doesn't follow application notes. They should be 1μF // 10nF. But on schematics I see single C99 for VREF+ with unknown value, and 1μF // 100nF for VDDA, deviating from the recommended values. It is somehow closish to what the Figure 11 (in 6.1.6 Power supply scheme) in the STM32L151xD STM32L152xD datasheet shows, but not exactly.
And we don't know if the external VREF+ is calibrated at startup against the internal VREFINT in the chip, which is actually pretty accurate, and close in performance to external reference (like LM236).
Hi . Could you help me to fix the problem that get from 121GW multimeter and then It's can't use as well.
when I turn on a DC and AC voltage mode. you can see the problem in the video:
https://drive.google.com/file/d/1Rxx9sBTdvFitgmP3Ob37sN5uFWsPeg3n/view?usp=sharing (https://drive.google.com/file/d/1Rxx9sBTdvFitgmP3Ob37sN5uFWsPeg3n/view?usp=sharing)
please respond back if you can help me.
Thank a lot.
Modify message
Is it work joeqsmith??
It have a warranty for multimeter. I boungh it 7 month ago. I send an email to dave but he not respone me. right now It's still drift up all the time when it switch mode to measure DC AC voltage and also still not do with another funtion.
No. The official firmware is proprietary.They could release the part of the source that is not secret (blanking out the valuable parts, and leaving some markers in the code, so people would know what the missing code should be doing).
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.
No. The official firmware is proprietary.They could release the part of the source that is not secret (blanking out the valuable parts, and leaving some markers in the code, so people would know what the missing code should be doing).
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.
Some companies do this, and the community makes great use of it (one example I know is Descent 2 game).
For example I would be interested in writing a better software for the meter if I knew I wouldn't screw the calibration data.
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
This may be because you have a DC offset on the signal.
Thanks, you are right. I've putted a 4.7µF capacitor between
and the display stays at 17.588kHz without any blinking or something.
Is this a behaviour which should to be expected?
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
This may be because you have a DC offset on the signal.
Thanks, you are right. I've put a 4.7µF capacitor between
and the display stays at 17.588kHz without any blinking or something.
Is this a behaviour which should to be expected?
Hello,
I'm not sure if this is a known issue to the 121GW. I discovered this issue recently.
I've looked in the 121GW issues thread in the forum but I didn't find anything related. Perhaps I've overlooked something.
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
Firmware on the 121GW: 2.04
The 121GW is one from the kickstarter campaign (not early bird).
This is my setup:
(https://i.imgur.com/u2Cbbse.jpg)
This is the schematics:
https://www.mikrocontroller.net/attachment/133498/nixie-wandler.pdf (https://www.mikrocontroller.net/attachment/133498/nixie-wandler.pdf)
Here is a video which I did to show the issue (ca. 2.5MByte, just remove .zip after downloading):
https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=1052136 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=1052136)
What do you think? Did I do something stupid?
Thanks for your comments etc.
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
This may be because you have a DC offset on the signal.
Thanks, you are right. I've put a 4.7µF capacitor between
and the display stays at 17.588kHz without any blinking or something.
Is this a behaviour which should to be expected?
Yes.
That seems to be the very same overload problem (AC +DC) we're discussing in the other thread (new eevBlog DMM).
Op1 inside the HY3131 goes in saturation with DC offset, therefore the comparator which produces the count signal, stays at high level.
Overload condition is not detected, because comparator is used for frequency detection.
Frank
What I've found:
I'm measuring the frequency in a step-up converter (around 17.5kHz which is to be expected, C3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R4 and the bases of T3 and T4.
On the other side, when I'm measuring the 50Hz hum with the probe in my hand, the digits will stay.
This may be because you have a DC offset on the signal.
Thanks, you are right. I've put a 4.7µF capacitor between
and the display stays at 17.588kHz without any blinking or something.
Is this a behaviour which should to be expected?
Yes.
That seems to be the very same overload problem (AC +DC) we're discussing in the other thread (new eevBlog DMM).
Op1 inside the HY3131 goes in saturation with DC offset, therefore the comparator which produces the count signal, stays at high level.
Overload condition is not detected, because comparator is used for frequency detection.
Frank
I think the problem here might be slightly different. OP1 does not seem to be involved in the Hz mode. And what puzzled me is in BU508A’s video the frequency is actually measured correctly for 5 sec or so.
If the 121gw schematics is correct - the input signal comes in at R RLD and through the U9 switches to RLD1 and then AC coupled with C32 into the CNT counter pin on hy3131.
(https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=1054040;image)
While U9 will likely clip the signal if it goes beyond 0 - 3.6V. Else D7-D8 will certainly clip it at about -0.6 and 4.2V.
But I’m thinking this is probably a problem also related to non symmetrical pulse shaped signals - which in this case causes C32 to slowly charge to a DC offset level where the signal no longer can trigger the CNT input. According to hy3131 datasheet it requires a high level >2.4V and low level <1.3V, so 1.1V peak to peak for a symmetrical signal.
The 121gw manual does not seem to state minimum voltage required for the Hz mode - but I measured it quite exactly to those 1.1V p-p. And for an asymmetrical signal i.e. square wave with 10% duty cycle it’s about 2.8V p-p.
I would actually recommend using ACV mode if you only want to measure frequency and not the duty cycle and such. In the lowest 5.0000V range the 2nd display for frequency only require about 0.4V p-p to trigger. Though also here a DC offset can/will cause problems.
Has anyone encountered DC VA measurement bug where current and VA values are wrong when current is larger than 2.500A?
Basically few mA over 2.500A makes multimeter value jump from 2.500 straight to 2.657A, display and mem card logging shows the same problem.
Firmware is 2.04
Voltage was about 12.725V and VA reading oscillates between 31,81 and 33,81 when keeping current close to 2.500A.
Seems that all values larger have this offset, so datalogging data is maybe still usable when subracting 157mA from every value bigger than 2.5A. Haven't measured if the offset is indeed fixed or changes over bigger current values.
Error is repeatable after multimeter off/on.
1361,2020/10/15,12:02:37,DCVA,0022.32,VA,DCV,008.401,V,DCA,002.657,A,,
1362,2020/10/15,12:02:38,DCVA,0021.00,VA,DCV,008.401,V,DCA,002.500,A,,
Has anyone encountered DC VA measurement bug where current and VA values are wrong when current is larger than 2.500A?
Basically few mA over 2.500A makes multimeter value jump from 2.500 straight to 2.657A, display and mem card logging shows the same problem.
Firmware is 2.04
Voltage was about 12.725V and VA reading oscillates between 31,81 and 33,81 when keeping current close to 2.500A.
Seems that all values larger have this offset, so datalogging data is maybe still usable when subracting 157mA from every value bigger than 2.5A. Haven't measured if the offset is indeed fixed or changes over bigger current values.
Error is repeatable after multimeter off/on.
Maybe you followed the instructions in the manual? If so, that would give some poor results.
https://www.youtube.com/watch?v=FNsPr1OEq7c (https://www.youtube.com/watch?v=FNsPr1OEq7c)
I was able to reproduce the issue as well. I ran some quick tests with a 66332A at around 2.5V, 4V, 5V, 12V. I did not notice the issue at 2.5V?
I think that J-R is pointing out that the current reading problem in VA mode also depends on the Voltage your around, even a constant voltage. Haven't spent the time to look at it enough but it also may have something to do with what range (voltage & current) you are on. Definitely another small but irritating bug.I was able to reproduce the issue as well. I ran some quick tests with a 66332A at around 2.5V, 4V, 5V, 12V. I did not notice the issue at 2.5V?
2.5V volts? We got issues with current reading, not voltage. It only shows up in VA mode - both on display without data logging and with data logging. The current reads and data logs correctly in current (A) mode.
Code: [Select]1361,2020/10/15,12:02:37,DCVA,0022.32,VA,DCV,008.401,V,DCA,002.657,A,,
1362,2020/10/15,12:02:38,DCVA,0021.00,VA,DCV,008.401,V,DCA,002.500,A,,
I was testing the 12V 35W halogen bulb, using my Agilent E3642A power supply, using 0-8V/5A output.
I was varying the output voltage on the PSU in few mV increments. The PSU would show change from something like 2.500A to 2.503A, or even less. The display of the multimeter will then jump from 20.99W or 21.00W to about 22.0W, or 22.3W.
The 2.657A figure is absolutely wrong
This puts into question months of my data gathering on one of my project.
Maybe you followed the instructions in the manual? If so, that would give some poor results.
I think that J-R is pointing out that the current reading problem in VA mode also depends on the Voltage your around, even a constant voltage. Haven't spent the time to look at it enough but it also may have something to do with what range (voltage & current) you are on. Definitely another small but irritating bug.I was able to reproduce the issue as well. I ran some quick tests with a 66332A at around 2.5V, 4V, 5V, 12V. I did not notice the issue at 2.5V?
2.5V volts? We got issues with current reading, not voltage. It only shows up in VA mode - both on display without data logging and with data logging. The current reads and data logs correctly in current (A) mode.
Got 123V
Have you measured between neutral and PE (ground) in Low Z mode?That's going to show zero, whether the ground is good or bad - unless it is connected to a real source of voltage with a low-ish impedance.
Using low-Z the voltage disappeared. I read up on ghost voltage. Yep, that was what I saw.Surely that means your ground is a high impedance, which means it's not ground at all and could be dangerous if you use it to ground something that needs a ground for safety reasons.
Thanks for your assistance.
Using low-Z the voltage disappeared. I read up on ghost voltage. Yep, that was what I saw.Surely that means your ground is a high impedance, which means it's not ground at all and could be dangerous if you use it to ground something that needs a ground for safety reasons.
Thanks for your assistance.
Plenty of bugs remain. I had issues with capacitance autoranging, some values are impossible to measure with autoranging on.
I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.I’ve been purging my lab of alkaline batteries, which keep leaking, and replacing them with Energizer lithium cells. The only thing I have that can’t handle lithiums is my 121GW, where its ADR3412 will be fed too high a voltage from fresh lithiums. I figured I might as well move the 0-ohm jumper from R94 to R12 to make the meter lithium-safe, as long as that’s not going to cause any other problems.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
Mechanical issue - cracked/broken terminals 2x
#1 occured exactly year down the day of order (#28035) - June 12'th 2019. Therefore still in warranty.
I've reported to Dave but didn't get any response back.
#2 occured just few days ago
The meter is very lightly used. The cables been on/off the terminals max 20x/since new.
Report issue https://www.eevblog.com/product/121gw/ (https://www.eevblog.com/product/121gw/) is broken:
[iframe src=”https://docs.google.com/forms/d/e/1FAIpQLSchJyQwmA8YgbfVQsr-JcJmy0k940EpXPiSu–8bBym4pAkRQ/viewform?embedded=true” style=”min-height:200em;”]
And I'm obviously not pleased $200+ meter which I'm generally happy with falls mechanically apart with very light use after 1 year. This didn't happen with $5 meter good 20y old used around the house.
Hope to get resolution of the situation from Dave.
I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.I’ve been purging my lab of alkaline batteries, which keep leaking, and replacing them with Energizer lithium cells. The only thing I have that can’t handle lithiums is my 121GW, where its ADR3412 will be fed too high a voltage from fresh lithiums. I figured I might as well move the 0-ohm jumper from R94 to R12 to make the meter lithium-safe, as long as that’s not going to cause any other problems.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
Before making the mod, I wanted to check on the forum. I’ve been pondering why the jumper was on R94 and not R12 in the first place. The potential reasons I’ve considered are:There were two other potential solutions I saw, instead of moving that jumper:
- Perhaps AGND goes too high in some mode such that +4V minus AGND becomes less than 2.3V—the min Vin for the ADR3412 (I can’t quite follow the diagram for T1 to see if this is the case)
- Perhaps the +4V output from the NJU7741F-04 (U13) is too noisy, which might cause the 1.2V reference voltage to fluctuate
A voltage divider would need to be chosen carefully such as to not impede the operation of the meter when using alkaline or NiMH cells. I don’t necessarily see any advantage to using VDD over +4V, although that regulator has an added “noise bypass” capacitor that the +4V regulator lacks, which may reduce noise? Could also replace the +4V regulator with a “better” one if noise is a problem, but that’s perhaps getting excessive.
- Add a simple resistive voltage divider to feed perhaps 2/3 the battery voltage into the ADR3412
- Add a bodge wire to feed the 3.6V VDD output of the NJM2870F-36 (U1) into the ADR3412
So I am thinking moving the jumper may be the best choice.
Thoughts? Has anyone else done this mod?
Thanks, that’s exactly the info I needed. It looks like the mod won’t work. With 4V supplying the ADR3412, 4V minus 1.8V gives 2.2V, which is under the 2.3V minimum of the ADR3412.I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.I’ve been purging my lab of alkaline batteries, which keep leaking, and replacing them with Energizer lithium cells. The only thing I have that can’t handle lithiums is my 121GW, where its ADR3412 will be fed too high a voltage from fresh lithiums. I figured I might as well move the 0-ohm jumper from R94 to R12 to make the meter lithium-safe, as long as that’s not going to cause any other problems.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
Before making the mod, I wanted to check on the forum. I’ve been pondering why the jumper was on R94 and not R12 in the first place. The potential reasons I’ve considered are:There were two other potential solutions I saw, instead of moving that jumper:
- Perhaps AGND goes too high in some mode such that +4V minus AGND becomes less than 2.3V—the min Vin for the ADR3412 (I can’t quite follow the diagram for T1 to see if this is the case)
- Perhaps the +4V output from the NJU7741F-04 (U13) is too noisy, which might cause the 1.2V reference voltage to fluctuate
A voltage divider would need to be chosen carefully such as to not impede the operation of the meter when using alkaline or NiMH cells. I don’t necessarily see any advantage to using VDD over +4V, although that regulator has an added “noise bypass” capacitor that the +4V regulator lacks, which may reduce noise? Could also replace the +4V regulator with a “better” one if noise is a problem, but that’s perhaps getting excessive.
- Add a simple resistive voltage divider to feed perhaps 2/3 the battery voltage into the ADR3412
- Add a bodge wire to feed the 3.6V VDD output of the NJM2870F-36 (U1) into the ADR3412
So I am thinking moving the jumper may be the best choice.
Thoughts? Has anyone else done this mod?
I haven't done this mod but here's the possible AGND levels from HY3131:
(https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=1147100;image)
As you can see AGND can be at 1.8V, 1.08V or 0.36V. If I remember correctly it's at 1.8V for all modes except Ohms which is 1.08V and Diode mode that is 0.36V.
One reason I can think of to not supply the ADR3412 reference directly from another regulator would be to avoid injecting noise into AGND via decoupling caps C18 and C62. Also remember it's not just the regulators creating noise - everything they supply power to also comes into the equation.
I am now thinking I may just remove R94, take a $0.10 78L33 (3.3V through-hole voltage regulator) from my parts bin, connect AGND to its GND, B+ to its VIN and have its VOUT go into the ADR3412. That seems simple enough. I might solder a 0.1 to 1 μF SMD capacitor across its VIN and GND pins, but that may not even be necessary. The trickiest part will probably be finding suitably-thin wire to make the connections.I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.I’ve been purging my lab of alkaline batteries, which keep leaking, and replacing them with Energizer lithium cells. The only thing I have that can’t handle lithiums is my 121GW, where its ADR3412 will be fed too high a voltage from fresh lithiums. I figured I might as well move the 0-ohm jumper from R94 to R12 to make the meter lithium-safe, as long as that’s not going to cause any other problems.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
I could not find any hint to this question, so I started to explore the schematics.
First it looked good, all internal voltages came from low drop regulators.
+4V, VDD(3.3V) analog supplies and VDD_P (3.3V) for the 15V booster and the CPU.
So, no problem at all, none of the voltages can go to high.
But wait, what is that?
The voltage reference, ZD1, a ADR3412 reference regulator is connected directly to B+ via R94, a 0 ohm resistor. B+ is the battery voltage. And this is a problem in my opinion. According to the datasheet the input voltage range of the ADR3412 is 2.3V..5.5V, the absolute maximum is 6V.
That means even with alkaline batteries the voltage is above the input range and with new alkaline batteries also above the absolute maximum. With lithium cells it is way off from the allowed input voltage.
Populate R12 instead of R94 will supply the reference with +4V, so no problems in this configuration. But R94 is populated, not only in the schematics. I have checked this in my meter and actually R94 is populated. I will remove R94 and place it in the R12 position.I cannot understand why the reference is connected to B+, that makes no sense for me. Is this really a design flaw or did I overlook something?
Before making the mod, I wanted to check on the forum. I’ve been pondering why the jumper was on R94 and not R12 in the first place. The potential reasons I’ve considered are:There were two other potential solutions I saw, instead of moving that jumper:
- Perhaps AGND goes too high in some mode such that +4V minus AGND becomes less than 2.3V—the min Vin for the ADR3412 (I can’t quite follow the diagram for T1 to see if this is the case)
- Perhaps the +4V output from the NJU7741F-04 (U13) is too noisy, which might cause the 1.2V reference voltage to fluctuate
A voltage divider would need to be chosen carefully such as to not impede the operation of the meter when using alkaline or NiMH cells. I don’t necessarily see any advantage to using VDD over +4V, although that regulator has an added “noise bypass” capacitor that the +4V regulator lacks, which may reduce noise? Could also replace the +4V regulator with a “better” one if noise is a problem, but that’s perhaps getting excessive.
- Add a simple resistive voltage divider to feed perhaps 2/3 the battery voltage into the ADR3412
- Add a bodge wire to feed the 3.6V VDD output of the NJM2870F-36 (U1) into the ADR3412
So I am thinking moving the jumper may be the best choice.
Thoughts? Has anyone else done this mod?
I haven't done this mod but here's the possible AGND levels from HY3131:
(https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/?action=dlattach;attach=1147100;image)
As you can see AGND can be at 1.8V, 1.08V or 0.36V. If I remember correctly it's at 1.8V for all modes except Ohms which is 1.08V and Diode mode that is 0.36V.
One reason I can think of to not supply the ADR3412 reference directly from another regulator would be to avoid injecting noise into AGND via decoupling caps C18 and C62. Also remember it's not just the regulators creating noise - everything they supply power to also comes into the equation.
I’m not really planing for this mod my self - but I would opt for a regulator with as low quiescent current as possible. A regular 78L would dump a few (4-5?) mA into AGND - that perhaps can handle that - I've no idea. But it will probably also add to the overall current consumption in the APO state of the DMM.That’s a good point. I can’t seem to find from the HY3131 datasheet just how much current AGND can handle. So I should match it better to the ADR3412. As far as APO, I suppose it depends on whether the firmware sets AGND to floating or not when entering the APO state. It should, but it may not.
ADR3412 is specified at 70uA (max) quiescent current - so something closer to that perhaps.
I wanted to find out whether the meter can be used with lithium batteries instead of standard cells or not.I’ve been purging my lab of alkaline batteries, which keep leaking, and replacing them with Energizer lithium cells. The only thing I have that can’t handle lithiums is my 121GW, where its ADR3412 will be fed too high a voltage from fresh lithiums. I figured I might as well move the 0-ohm jumper from R94 to R12 to make the meter lithium-safe, as long as that’s not going to cause any other problems.
Problem with lithium cells ist the higher voltage. 4 lithium cells have up to 7.7V when they come out of the package. After a short time the voltage goes back to approximate 6.6V and stays a long time at this value.
Problem or not?
Seem like a 'trend' with EEVblog multimeters, can't handle lithium AA/AAA batteries.... (or does the new one finally handle them properly?)
Does it work well with rechargeable AAA batteries?+1 , and also Lithium cells ? As these have tad higher voltage.
Yes, confirmed ok by Brymen.
I've just tried and no such problem on mine (also running v2.04).
For your meter is the problem with mA/A in DC or AC mode?
If in AC mode, if you wait long enough with the probes shorted, does the reading eventually count down to 0?
UPDATE:
The issue with the cracked input jacks is as several suspected, a molding issue.Quoteinput 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:Quote2. 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
could it be the mode select knob contacts?Altough it cannot be seen in the video (I changed the exposure to -2 otherwise Rigol multimeter couldn't be read), by default the 121GW starts in DC auto. It doesn't matter if I change the range manually, or I change the mode (same in AC, LowZ)...
Hi guys,
I must confess I didn't read all the pages in this thread, but I have this issue with my 121GW (001802) multimeter:
https://www.youtube.com/watch?v=vEawSHvRa1c (https://www.youtube.com/watch?v=vEawSHvRa1c)
The meter is from the kickstarter days (serial number 180701206 / EEVblog 001802 ), it was shipped in July 2018. It was used pretty rarely.
could it be the mode select knob contacts?
I cleaned it, still doesn't work but the shim is not the issue as one could see the above pictures ;D but that lead me to the issue.
At close inspection it doesn't seem that any other component misses the magic smoke, but hey, after an event like that anything could go wrong:
UPDATE:
The issue with the cracked input jacks is as several suspected, a molding issue.Quoteinput 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:Quote2. 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
Hi Dave,
my 121GW seems to be affected as well, however my serial number is 190505920... Do you still have input jacks and would you be willing to send them to Austria? If shipping is more expensive and you don't want to pay for it, I'd do that, if it is not ridiculously expensive. I'd say I'd pay up to about EUR 100,- (LOL) because i don't see another option of repairing this ~EUR 300,- DMM...
Please let me know, I'll then drop you an email with the "121GW Connector" subject...
btw I was using the 121GW with the Probemaster 8043SK kit. https://probemaster.com/8000-series-test-lead-master-kits/ (https://probemaster.com/8000-series-test-lead-master-kits/)
Thanks!
could it be the mode select knob contacts?that's what I meant/what I was saying...
@Dave: have you seen my post/e-mail about the cracked input jack? are you still shipping replacement jacks? I'd even buy one if I had a source. Please, help! Thanks!
I have a 121gw (s/n 180807803) with the dreaded 'disintegrating socket' problem. Surprised it took this long to fail as I use this gem nearly every day on the bench and bought it new from this site.
How do I get replacement parts for this unit? I'm happy to pay for the replacements plus shipping. I just need to know where to get them. From you? From a distributor?
FWIW, all four socket plastic 'tubes' have disintegrated, some entirely. I am using 'shrouded' probe plugs so I don't think it's completely unsafe yet, but it's getting there :-)
Also, I think I'm completely capable of replacing the parts - proper soldering / desoldering workbench here.
Thanks,
Gary
Shouldn't be too difficult to track down if you plan to attempt repairs.Would that be worth it? I fell like I wouldn't trust it anymore...
I'll try to offer some assistance here.
Hi everyone.Wow. Looks like the path was the PTC to the shield down the grounding spring. With that PTC connected right to the input, there's not much to limit the current. I doubt this was any fault of yours. Thanks for posting.
It seems my 121GW just broke, and I have no idea how or why :S
I wanted to measure a simple 230V AC mains socket, so plugged my leads in to the COM and V sockets, set the DMM to V, and the mode to AC, but when I plugged the leads into the mains socket, there was loud POOF and scorch marks on one of the lead tips. Strangly the DMM display kept working, but displaying no voltage. I tried another DMM (Uni-T UT61E) and that one just correctly displayed 230V AC.
So I opened up the 121GW, and to my horror noticed the typicall smell, strangly, both fuses were still intact. Further disassembly showed burned/exploded components at the U17, C61, R131, C69, C68, C80 and PTC3 positions.
So 2 questions here: What have I done wrong? I'm 100% sure I connected the leads to COM and V, the DMM was set to correct mode, I can't think of a reason why something like this would happen.
Secondly, have I got any change at repairing this DMM? Replacing those 7 components at the earlier listed positions (given I can find the correct parts/values somewhere) is something I'd feel confident enough to do, but how high is the chance other components will have failed invisibly, and would the DMM still be thrusworthy calibration-wise afterwards?
I feel really sad about this, It's the most expensive DMM I ever bought, and worked really well for most things I do :(
Looks like the marked part of the shielding should not be there - manufacturing error?
Hi everyone.
It seems my 121GW just broke, and I have no idea how or why :S
I wanted to measure a simple 230V AC mains socket, so plugged my leads in to the COM and V sockets, set the DMM to V, and the mode to AC, but when I plugged the leads into the mains socket, there was loud POOF and scorch marks on one of the lead tips. Strangly the DMM display kept working, but displaying no voltage. I tried another DMM (Uni-T UT61E) and that one just correctly displayed 230V AC.
So I opened up the 121GW, and to my horror noticed the typicall smell, strangly, both fuses were still intact. Further disassembly showed burned/exploded components at the U17, C61, R131, C69, C68, C80 and PTC3 positions.
So 2 questions here: What have I done wrong? I'm 100% sure I connected the leads to COM and V, the DMM was set to correct mode, I can't think of a reason why something like this would happen.
Secondly, have I got any change at repairing this DMM? Replacing those 7 components at the earlier listed positions (given I can find the correct parts/values somewhere) is something I'd feel confident enough to do, but how high is the chance other components will have failed invisibly, and would the DMM still be thrusworthy calibration-wise afterwards?
It appears the edge of the shield was cutting into the heat shrink around PTC3. Assembly or re-assembly error?
Looks like PTC3 was pulled away from PTC4. On mine they are still stuck together, which keeps PTC3 out of the way. So it seems plausible the metal shield had been doing some cutting into PTC3.
Looks like PTC3 was pulled away from PTC4. On mine they are still stuck together, which keeps PTC3 out of the way. So it seems plausible the metal shield had been doing some cutting into PTC3.
Yes, but even if it "cut" into the heatshrink of the PTC you still have the device encapsulent, so that's not enough for a 240V on it's own to cause an issue.
Dunno, that metal seems pretty sharp to me... How much would it need to cut into the PTC before it causes a short?
Could it be a combination of the proximity of the metal and a catastrophic failure of the PTC?
Yes, I can see the plastic pulled away from the metal shield...The hole I mentioned exists in the plastic as well as the metal shield, so would mean the plastic was adhered to the shield when the fault happened. I fumbled a bit when disassembling the DMM yesterday, so might have been me that separated the plastic from the shield.
It seems my 121GW just broke, and I have no idea how or why :SUnfortunately yours is looking way worse than mine, but still, this shouldn't happen. I am in the same situation (Kickstarter, never used it on mains until the incident, just a matter a fact, I used it very rarely)
I'm interested in knowing how it's handled. Granted, there's no warranty but it sure seems like a manufacturing issue and should be covered.looks like you really hate everything about 121GW...hope that you don't hate its designers as well ;D
:-DD :-DDI'm interested in knowing how it's handled. Granted, there's no warranty but it sure seems like a manufacturing issue and should be covered.looks like you really hate everything about 121GW...hope that you don't hate its designers as well ;D
I'd also be happy to settle for an affordable PCB replacement, if that would be an option. Anything really since now I've just got a very expensive paper weight.I would be interested in this option too since my most expensive multimeter is useless. I asked about this option in this thread couple months ago but no response so far...
Is there a board replacement available? That would give me peace of mind...
I've tried to make a bit more targeted photos of my meter (SN 180701835 that is behaving well).
I can see some damage on that PTC and the shrink around it.
(the DMM case side is not damaged. What looks like damage is shadow of the component)
FYI, I have asked KaneTest for comment.
I wasn't asking. Just showing how the PTC area and shield looks like in my meter. It may help in the analysis.I've tried to make a bit more targeted photos of my meter (SN 180701835 that is behaving well).
I can see some damage on that PTC and the shrink around it.
(the DMM case side is not damaged. What looks like damage is shadow of the component)
Not sure if you're asking for info or just pointing this out, but of course future readers should push the metal shield tight against the side of the bottom case before re-assembly to avoid damaging the PTC.
Hi, new user here. Is this the right place to ask if the above issue was related to manufacturing during the kickstarter? Did it result in a fix of some sort? If I were to order a 121GW right now, can I have confidence it won't have such an issue?
Hi, new user here. Is this the right place to ask if the above issue was related to manufacturing during the kickstarter? Did it result in a fix of some sort? If I were to order a 121GW right now, can I have confidence it won't have such an issue?
Sorry to ask here, but where to get this shim? I am one of "early kickstarter users", used multimeter very rarely, and i started to get contact issues (i have to press on knob to make multimeter on after changing mode).Hi, new user here. Is this the right place to ask if the above issue was related to manufacturing during the kickstarter? Did it result in a fix of some sort? If I were to order a 121GW right now, can I have confidence it won't have such an issue?
The PCB shim issues was limited to the first few thousands PCB's. That included all the Kickstarter units and a bunch of the first normal production units. All future PCB's have been the correct thickness and the issue was resolved. All units bought today do not have this issue, no one has old stock.
Using low-Z the voltage disappeared. I read up on ghost voltage. Yep, that was what I saw.Surely that means your ground is a high impedance, which means it's not ground at all and could be dangerous if you use it to ground something that needs a ground for safety reasons.
Thanks for your assistance.
It could be induced voltage from a parallel running cable, however I'd recommend it's investigated by a qualified electrician using an installation tester.
Hi everyone.
It seems my 121GW just broke, and I have no idea how or why :S
...
Did anyone else notice that turning the bluetooth on causes the meter to cool by more than half a degree C and turning it back off causes it to heat back up to previous half a degree higher temperature?
The temperature reading is likely not that accurate anyway, so I would not worry much about this part. The question is if it effects other measurements too ?
Hello — I'm seeing a problem where the 121gw shows incorrect frequency period. From my waveform generator I feed in a 0-5 V square wave at 1 kHz with a 50% duty cycle. The meter correctly shows a 1.0000 kHz for frequency, but a period of half the expected value at 0.4999 ms. Oddly adjusting the duty cycle changes the period measurement as well. With a 70% duty cycle at 1 kHz the period now reads 0.6999 ms. It seems to be missing the later half of the waveform in the period measurement.
Hello — I'm seeing a problem where the 121gw shows incorrect frequency period. From my waveform generator I feed in a 0-5 V square wave at 1 kHz with a 50% duty cycle. The meter correctly shows a 1.0000 kHz for frequency, but a period of half the expected value at 0.4999 ms. Oddly adjusting the duty cycle changes the period measurement as well. With a 70% duty cycle at 1 kHz the period now reads 0.6999 ms. It seems to be missing the later half of the waveform in the period measurement.
Maybe the number on screen is "duty cycle". :popcorn:
Hey Dave! Regarding: https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2792850/#msg2792850 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2792850/#msg2792850)
I sent you couple emails but haven't heard back. I have a broken input jack on my 121GW multimeter SN: 180807570, which is out of the affected range. Can you send me a replacement input jack, I would be happy to pay for it. I couldn't find a replacement jack anywhere online, if you don't want to send one out could you point me in the direction of where I can buy one?
Does anyone else on the forum know of a place to purchase a replacement input jack for my 121GW multimeter?
Thanks so much!
Hi Dave!
Mine has the "cracked plug" problem as well. Serial starts with 1808071__
I would be happy to know which replacement part I could source and where (I'm in the EU).
Thank you!
BR, Hendrik
Hi Dave!
Mine has the "cracked plug" problem as well. Serial starts with 1808071__
I would be happy to know which replacement part I could source and where (I'm in the EU).
Thank you!
BR, Hendrik
🥺 Dave? Or anyone else who knows which part to source?
Wow so first the A/mA jacks cracked at top, now entire Volt jack sleeve came off from next to no use of meter :--Bad batch, see here:
See attached..
https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2792850/#msg2792850 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg2792850/#msg2792850)
I'm having an issue with my 121GW that I can't seem to figure out.
Firmware is v2.05, S/N is 210403337.
When trying to measure frequency, the meter just seems to ignore any signals it's given. I initially noticed it when I was trying to measure the frequency of a composite sync signal to make sure that it was properly tuned, and the meter was constantly reading zero. I then tried attaching the leads to my HP function generator with a 1KHz square wave and the meter just acted like it wasn't there.
It's almost like the leads are completely disconnected when the meter is set to Hz mode. All of the other modes work fine, but for whatever reason, I can't get the thing to respond when measuring frequencies.
Any ideas?
Any ideas?
I'm having an issue with my 121GW that I can't seem to figure out.
Firmware is v2.05, S/N is 210403337.
When trying to measure frequency, the meter just seems to ignore any signals it's given. I initially noticed it when I was trying to measure the frequency of a composite sync signal to make sure that it was properly tuned, and the meter was constantly reading zero. I then tried attaching the leads to my HP function generator with a 1KHz square wave and the meter just acted like it wasn't there.
It's almost like the leads are completely disconnected when the meter is set to Hz mode. All of the other modes work fine, but for whatever reason, I can't get the thing to respond when measuring frequencies.
Are the replacement jacks still available? I've been using Probe Master 8017S test leads and part of the plastic sleeve broke off from the +volts jack. Emailed Dave a while back but didn't get a response.
Are the replacement jacks still available? I've been using Probe Master 8017S test leads and part of the plastic sleeve broke off from the +volts jack. Emailed Dave a while back but didn't get a response.
Emailed.
Are the replacement jacks still available? I've been using Probe Master 8017S test leads and part of the plastic sleeve broke off from the +volts jack. Emailed Dave a while back but didn't get a response.
Emailed.
Same question:
My input jacks on my 121 GW are busted because I used probemaster probes and banana jacks directly in the meter sockets.
Mine is a 2019 built 121gw qith very brittle plastics on the input jacks.
I can't seem to order them from UEI or Brymen EU.
I'd be glad to pay the postage to get my meter repaired.
To which email address?Yep, it's busted. Try a PM instead.
If i click email in the forum, i simply don't get an email address.
I also mailed to your eevblog.com contact address but no reaction yet.
My email is my username at gmail.com
Kind regards
To which email address?
If i click email in the forum, i simply don't get an email address.
I also mailed to your eevblog.com contact address but no reaction yet.
To which email address?
If i click email in the forum, i simply don't get an email address.
I also mailed to your eevblog.com contact address but no reaction yet.
I got it, just very busy right now.
I can understand the 'being busy' part.
Buut... We're a month in so... is there any progress?
I can understand the 'being busy' part.
Buut... We're a month in so... is there any progress?
Sorry. It's in the shipping system now so I can't forget.
Is this model a Back to the Future reference?
Hi Dave. I recently got a broken jack in my 121GW |O. Found this thread through a search engine. Do you still send replacements? I've sent you an email.
I already did. Maybe you missed it because I used a different mail account from what I used to register in this forum, or maybe I didn't send it to the right account. I'll send you it again from the other account. dave at eevblog.com eevblog.official at gmail.com <- is any of these correct?
I cleaned it, still doesn't work but the shim is not the issue as one could see the above pictures ;D but that lead me to the issue.
At close inspection it doesn't seem that any other component misses the magic smoke, ...
(Attachment Link)
Hi everyone,I cleaned it, still doesn't work but the shim is not the issue as one could see the above pictures ;D but that lead me to the issue.
At close inspection it doesn't seem that any other component misses the magic smoke, ...
(Attachment Link)
(https://i.imgur.com/9pSD3Eh.jpeg)
After some fail attempts to source a new board (contacted the distributor (Welectron), they sent me to Brymen, Bryman sent me to eevblog and then was silence) I would like to give it one more try before send it to a better place.
But before going that rabbit hole, I have some questions:
- beside the schematic is there any other documentation to speed up the process?
- does any know if there are internal traces around the affected area?
- some higher resolution photos in the affected area (for a good one :D)?
- pcb parts placement would be great
Any tip will help.
Thank you.
(https://i.imgur.com/9pSD3Eh.jpeg)
After some fail attempts to source a new board (contacted the distributor (Welectron), they sent me to Brymen, Bryman sent me to eevblog and then was silence) I would like to give it one more try before send it to a better place.
But before going that rabbit hole, I have some questions:
- beside the schematic is there any other documentation to speed up the process?
- does any know if there are internal traces around the affected area?
- some higher resolution photos in the affected area (for a good one :D)?
- pcb parts placement would be great
Any tip will help.
Any tip will help.