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.
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.
Dave has said that the issue with open sourcing the firmware is that it is 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). Getting this sorted out seems like it will be more trouble than it is worth for UEi, so they are unlikely to do it.
I think Dave mentioned that UEi /might/ be willing to opensource certain bits of the firmware (the LCD driver for instance); he would need to confirm that however.
If you are going to go hacking around, remember a couple of things:
- The STM32 line of mcus offer "read out protection", so directly reverse engineering the firmware from the meter might be tricky (but the protection has been weakened, see paper referencing this
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html),
- Even if a firmware update blob is released (say a v1.02), it will likely not include at least one of the boot loaders, and may not include any bootloader. That means using the existing bootloader as-is might be tricky (i.e. reverse engineering the application might be possible by looking at the firmware update blob),
- There is a JTAG header on the board IIRC, but you can't use it when read-out proctection is enabled (if I'm remembering correctly). But that means re-writing a new firmware from scratch is totally possible (and I am pretty sure this is what the "Hack away!" sentence in the manual refers to).
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 ?
Any more than 1 second is too slow.
The bargraph seems to respond quickly, so why isn't it using that conversion for ranging?
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 ?
He couldn't have, hopefully a last minute change that can be easily fixed, the delay is agonizing.
Joe might be able to comment on how the pre-production 121 behaved?
That autoranging is really atrocious lol. Just raced it against every handheld meter I had nearby (BM235, U1252A, U1273A, UT61E, & a UT210E just for kicks). UT210E was the next slowest, but still seems like a rocket next to the 121GW. Others were all reasonably close with the the BM235 & UT61E appearing slightly faster than the Agilent/Keysights. One of the reasons I was eager to get an early 121GW was for the fun of finding issues like this. Not sure how this slipped past Dave & UEI, but hopefully it's a fairly simple fix.
Okay, we'll not see FW released for opensource, I got it. But I want to roll my own. Please post information how to do this or a minimal buildable example. Like, a zip-archive with a Makefile inside.
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).
Alright, let them ship without that pieces. I can try to write open-source equivalent of that pieces.
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.
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 actually like the feel of the switch quite a bit. Definitely easier to turn on one handed than others. On some of my meters with stiffer switches I'll occasionally use so much force that I turn past the selection I intended. The beeping doesn't bother me, but should definitely have have an option to turn it off. I've been wondering about that backlight flash too. Flashes briefly turning on from either off position. Went back and rewatched one of Dave's videos to make sure others did it. Hard to see in the video, but they did it too.
I am sure Dave will do a full review of the meter in one of his videos after the holidays.
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.
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.
How about the open source-ness of the schematics? It was on the feature list of the Kickstarter.
For people modifying the firmware, I'd say that invalidates the 61010 agency safety approvals.
A multimeter is expected to function a particular way, i.e. display hazardous voltages correctly after test scenarios and who would re-test those after adding a super-fast autoranging hack?
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.
mVA Problem: (Confirmed by DrGeoff)
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.
I have not tested this in AC mode, but assuming the RMS converter is only supplying positive voltages to the measurement chip, I would guess that AC mVA mode probably is fine.
UPDATE:
The same problem happens with the A input when measuring VA. If the current into the A socket reaches -1.0000A it wraps around to zero. -0.9999A is fine. Same thing happens with the mAuA socket at -10mA. Both inputs work perfectly in the mVA/VA modes with positive input currents.
The problem seems to be connected to Autoranging with negative currents - if you use the range button, you can get the right numbers with negative currents. So it seems that the current measurement autoranging for mVA/VA measurements does not work properly for negative currents. It works properly for positive input currents. If the firmware can be fixed to get the measurement chip in the correct range for the applied negative DC current, this problem should be fixed.
It would seem that with negative currents, the mVA get stuck in the 5.4999mA range. It actually seem to keep measuring up to 9.9999mA - that is 80% overrange before rolling over to 0.00000 at 10mA. It then continues to measure correctly to 11mA (with the lost first digit) which is 100% overrange!. After that, I think the poor current input has had enough. At some point, the current input totally overloads and just produces rubbish numbers. The multimeter does not change to the 54.999mA range with mVA negative currents or to the 5.4999A or 10A ranges for VA negative currents at all if Autoranging is enabled.
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.
Can confirm this.
I repeated the experiment using a bipolar supply, leaving the 0V cable intact and switching from the +ve supply terminal to the -ve supply terminal. Same results as you see.
I discovered more details of the DC mVA/VA problem and added it to post (2 posts back). It is an Autoranging bug.
No wonder people want to hack this multimeter - the measurement chip keeps working to the 99999 count and actually keeps working till the 109999 count with the slight problem that the first "1" digit is lost - the 5 digit counter just wraps around. The overload display at 55000 is just a firmware thing.
Until this bug is fixed, you can actually get the meter to read currents to 9.9999mA and 0.99999A right now.
One person on Kickstarter reported a poorly soldered connection to the LCD backlight.
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.
Are the formats of the calibration data, and the firmware update file public yet ?
Those would be prerequisites for a proper OS alternative FW implementation.
Found something interesting on the low Z range with a 100khz squarewave, 5Vpp and 5V offset.
I get a reading of 158V?
Edit. Firmware is 1.01
Mike.
Hi Dave,
I received my unit today, and had some problems with continuity test.
From time to time there seems to be a contact problem related to the rotary switch, which occurs when switching from off to continuity mode. I made a short video showing this problem:
- inputs are shortened.
- version is 1.02
https://youtu.be/cERpnZiUjV4
Hi Dave,
I also got my meter today. Thanks for your effort. I like the probes and the build quality. I have no equipment to test its precision.
Firmware version is: U-1.02
Here are the things I don't like or consider a fault:
- 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.
- Autoranging in the other modes isn't fast either.
- Burden voltage display get's disabled each time the range is switched (eg. mA to uA).
- Burden voltage display slows down the update rate to a crawl (around one update every 2s).
- VA update rate is also very slow. It seems whenever two values are measured the update speed is reduced by a factor of 10.
- When two values are measured, the bar graph "blinks" sometimes. It seems to display the other value for one LCD update frame every now and then. This is annoying if you watch the meter out the corner of your eye.
- 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.
- Bluetooth logging via the app in VA mode is simply broken. The log is from a 12V 10W light bulb on a linear power supply modulated between 6W and 10W by manually turning the knob. The display on the meter is correct, the bluetooth data isn't. There is no way for the bulb to use over 100W without blowing up. (see below)
- Update rate via bluetooth is too low and uneven to be useful. Have a look at the time stamps. (see below)
- There is spurious data corruption in bluetooth packets.
- Creation time of the logfile in the file system is wrong. (See below, the forum seems unable to mix lists and quotes.)
- SD-card logging lacks proper time stamps. There is only one written at the beginning of the file. After that there is no more time information, making the feature useless, since no proper graph can be generated as the delay between the lines is not known when you select the fastest logging mode. When selecting a defined delay, there is no way to tell if the log is accurate or if lines are dropped.
- VA mode is limited to max. 55V (fix it or document it).
- It would be nice if bluetooth VA mode in the App would log at least two values VA + V or VA + A, or V + A, to be able to compute the other value.
- Using a binary coding in bluetooth logging instead of ASCII coding could at least double the update rate.
- The meter crashes immediately if you enable SD-card logging with no SD-card inserted
- When logging to SD-card autoranging stops working even tough it is indicated as active in the display. After stopping logging you have to long press the RANGE button to reenable it.
- When logging a long time to the SD-card the "k" indicator after the record counter is flickering, this indicates issues in the display update routine.
- When logging to SD-card the secondary display is fixed to the log-counter and there is no way to display Hz or A/V in modes where the secondary display is used.
I would be most glad if the logging features could be improved. Please add at least sub-second precision time stamps to the SD-card logfile. I don't care if they are absolute or relative value to the start of the logging but just a counter is not enough. This is the point I care about, since I have no other meter with this capability.
All other points would be nice to have but are not important to me.
A higher bluetooth speed would be second, but I have a meter with a real serial Adapter, so I could live without it. At least a deterministic logging interval would be a win for bluetooth.
Anyway, thanks for the meter, it's fun to play around with.
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
Did anyone checked the quality of the contacts in the rotary switch?
Alexander.
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.