Thread restored after being accidentally deleted. A bug in SMF means big threads can't be restored using the Restore Topic admin option. But gnif worked his magic on the database manually and it's back!
Great!
And please, remember to make it sticky!
Thanks for getting the thread restored.
One issue I've noticed is my post count seems to have dropped 40 odd posts - but I just checked my posting list and all posts are there and I can access them from the list. So no big deal really.
Post counters wouldn't have been incremented by manually restoring just the topic.
Yeah I figured it was something like that - and like I said all my posts seems intact now - it’s just the counter that’s of.
Hi, I have found a bug in the iOS app. App version 1.1 The date and time don't display properly in the upper right of the app. See attached pic. Meter firmware 2.04.
This is also present in the 3rd party app Meteor version 0.2.
@DavidWC
No. The official firmware is proprietary.
The reason given is that there are some "secret sauce" routines that UEI consider commercially valuable. These would have been developed for their own use and would have been a significant investment - and they are not prepared to make those known to the world.
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).
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.
No. The official firmware is proprietary.
The reason given is that there are some "secret sauce" routines that UEI consider commercially valuable. These would have been developed for their own use and would have been a significant investment - and they are not prepared to make those known to the world.
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).
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.
After messing quite a bit with the disassembled version of the FW - I’m really not sure if any part looks like "secret sauce" or appear particularly ‘developed’. It seems more like an added (often unnecessary) layer of complexity in many routines - even i.e. in the more straight forward ones like setting up the stm32 HAL. So if you were to exclude all of these - I’m afraid not much would be left.
Still the official FW must have taken some man hours to put together. And then there’s all the testing needed to be done. I can understand that they are reluctant to release the source code.
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, C
3=2.2nF) and after a few seconds the display is showing only zeros. I'm measuring between R
4 and the bases of T
3 and T
4.
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:
This is the schematics:
https://www.mikrocontroller.net/attachment/133498/nixie-wandler.pdfHere 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=1052136What 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.
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?
A lot of meters require zero crossing for accurate frequency measurements.
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?
Meters basically comes in 3 variations:
1) Capacitor coupled input where they do not care about DC voltage
2) A circuit that can compensate for a "small" DC offset
3) A circuit that requires the frequency swings around zero.
The 121GW is 2)
Also be aware that frequency input with the selector on AC voltage and on frequency is very different, the later works for low voltage (Overload protection kicks in at a few volts and reduces the input impedance dramatically) and often up into the MHz range. The AC voltage input can maintains high input impedance, but cannot handle high frequencies.
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
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:
This is the schematics:
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
What do you think? Did I do something stupid?
Thanks for your comments etc.
As others have said, this is likely a DC offset issue.
I just tested the 121GW with a 5Vp-p sine wave and it stop displaying the frequency when the DC offset gets to about 4.8V.
The BM235 has the same issue, and actually stops at about 2.8V offset.
So you should be able to confirm this by swapping the meters you have.
For comparison I tried the new 500 series design Kane meter (see other thread) and it worked fine with up to 7.5V DC offset (the limit of my function gen).
The new $150 class meter also has no problem.
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.
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.
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.
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.
Thanks for looking into it. I did a screenshot of the signal at the exact same point. Looks like it comes with a reasonable DC amount.
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.
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.
Holly shit. You are right.
My multimeter is also doing this:
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.
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.
could it be another hardware bug?
Maybe you followed the instructions in the manual? If so, that would give some poor results.
Maybe you followed the instructions in the manual? If so, that would give some poor results.
This is totally unrelated.
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 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.
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.
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.