EEVBlog 121GW Discussion thread

[ChrisG]

@DaveJ: will you publish a list at a certain moment which lists the confirmed issues? And which ones can be solved by firmware updates? The issues thread does not seem to have many more new issues coming in so I assume we've captured 90-95% of them by now.

[EEVblog]

Right, no need to maintain two different firmware versions, just a small portion of the firmware has to handle the old and new format. I hope they are experienced firmware developers who versioned the calibration data, because such things always change. But even if they didn't, it shouldn't be a problem: just use something impossible for the old format as the first byte for the new calibration data, to mark it as the new format. Fortunately it doesn't have to be compatible in the other direction, like there is nobody who would use a new set of calibration data with the old firmware. Could be programmed in like an hour.

It might not be that easy.
It might affect calibration of other ranges, because (guessing) it might use a common ADC read averaging routine or something. What if you have to recalibrate the whole meter.
I really think this is bad idea and I am loath to recommend such a thing.

[EEVblog]

@DaveJ: will you publish a list at a certain moment which lists the confirmed issues?

Yes.

[Towger]

To do so would require screwing existing customers, or maintaining two version of the firmware. Either solution is not acceptable.

At worse they just don't update beyond the version of firmware their meter supports.  If the the calibration data structure was well designed it should contain the initial firmware/hardware version it is for.  Newer firmware should be able to check it and decide it is is going to display a meaningful error or use the old method etc.  If they don't currently embed a version number it can be added to the new firmware etc.

At the end of the day if the meter is slow it will greatly impact future sales.

[hwti]

Thank you for the diagram! Some of the parts are not specified or listed in a separate table. Is this on purpose?

AFAIK, the components with an "x" value aren't populated on the PCB.
Some were probably added to allow to change the circuit in case of issues, or to be able to do some tests.
Others like U14 have been used in previous revisions and were removed (even if they didn't plan to reuse it, it's perhaps easier to avoid rerouting the PCB).
For example :
 - adding R142/C108 (and all the others) would do hardware debouncing on the keys (it's probably done in the firmware instead)
 - removing R101/R102 and adding R133 would switch to the AD8436 OUT without the OUTBUF follower
 - many 0 ohm resistor could be removed if someone wanted to test individual components for any reason

[exe]

Does hardware let simultaneous measurement of AC and DC voltage? (I want to measure AC and DC bias at the same time)

Is it possible to do faster sampling at the expense of accuracy/resolution?

[imidis]

At the end of the day if the meter is slow it will greatly impact future sales.

I think this is a very good point. To hinder performance for all future meters doesn't seem the best decision either.

[Iagash]

So the Bluetooth Module is not used in the released meter.   

Well, yes if you look at the bluetooth protocol and the transmission, this feels true. ;-)

[Iagash]

At the end of the day if the meter is slow it will greatly impact future sales.

I think this is a very good point. To hinder performance for all future meters doesn't seem the best decision either.

I would also think about this a little longer. We are talking about 500 meters now. Is it worth to settle for a second choice solution for the rest of the product live or even maybe fix it now before the Jonny be Good batch is shipped and only have to deal with the small amount that is in the wild? Maybe even fix it for the US meters and you reduce the number even further? What would be the cost for an recalibration offer for the existing meters and what would be the sales impact in the future on the product? What would be the cost of maintaining two firmware versions? I don't know the answers but it's something to think about at this point of the live cycle of the meter.

[mikeselectricstuff]

Right, no need to maintain two different firmware versions, just a small portion of the firmware has to handle the old and new format. I hope they are experienced firmware developers who versioned the calibration data, because such things always change. But even if they didn't, it shouldn't be a problem: just use something impossible for the old format as the first byte for the new calibration data, to mark it as the new format. Fortunately it doesn't have to be compatible in the other direction, like there is nobody who would use a new set of calibration data with the old firmware. Could be programmed in like an hour.

It might not be that easy.
It might affect calibration of other ranges, because (guessing) it might use a common ADC read averaging routine or something. What if you have to recalibrate the whole meter.
I really think this is bad idea and I am loath to recommend such a thing.

I think you need to find out more details of the exact reason - maybe "require recal" just means "requires rewriting code we can't be arsed to do"

[exe]

Concerning calibration, may be just implement import of it in, say, json or csv?

[fboehle]

How does it actually function with so many different grounds. From what I can tell, most of the grounds are not directly connected to each other, but at the same time a large potential difference would certainly blow up some ICs. So how is their potential brought close together?

(I couldn't find a connection between AGND, GND, VSS)

[Fungus]

a large potential difference would certainly blow up some ICs.

The meter is battery powered and the only connection to the outside world is the input jacks. Where would a large potential difference come from?

[Kean]

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.

Joe, I can confirm this issue is still present in FW1.01.
I generated a 2.8Vpp 60Hz (& 1kHz) sine wave with my MSO1104Z-S and it read 0V in LowZ mode.
When I upped the freq to 389kHZ and I got a reading of 189.2Vac.  See photo...

Edit: and it correctly read ~1V AC without LowZ up to maybe 100kHz, but that dropped to 0.773V AC at 389kHz

[maukka]

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.

With a 1Vrms signal the LowZ mode stays at 0V until 28kHz where it jumps to 10.4V. At 389kHz it shows 195.7V. This on v1.01.

[Towger]

I think you need to find out more details of the exact reason - maybe "require recal" just means "requires rewriting code we can't be arsed to do"

Probably true 'can't be arsed' programmers are very common   

[tpw_rules]

I don't buy the 'requiring recal' excuse either.

The meter has three sources of autocalibration delay. The first is an enforced delay on changing mode or range, which depends on the switch that was performed. When this delay is active, the display is blanked and the autocalibration routine does not run. The second is a sample averager, which is 8 samples for OHMS range and 16 for every other. This average value controls the screen display, and the current sample controls the bargraph. The same calibration factors are applied to both numbers. The third is a rolling average applied to the screen display, which depends on the mode and range as well. This should not be a factor, as the average resets on overrange or a large measurement delta.

The autorange is performed on the final displayed screen number that you see, after all three sources have been factored in. There is little to no software or calibration reason they couldn't shorten the delay during autoranging (which is what I think the v1.04 firmware does) or use the bargraph value initially. The calibration factor applied is the same for both measurements.

I've made a patch which removes that mode/range change delay while autoranging, but I can't test it without a meter. I'm now wondering if anybody would be willing to sell me their meter for testing purposes?

[dcac]

Dave posted the schematic in the firmware thread, but I reply here since my questions would be off-topic there :

Here is the schematic which may help
http://www.eevblog.com/files/121GW%20EEVBlog%20Circuit%20diagram.pdf

Is it safe to let 4053 logic input pins floating (C pin of U11, A pin of U14 if it was populated) ?
Usually it's not recommended, so unless the 4053 is special it's strange.

Yes that seems strange - C is pin9 on U11 and is a digital cmos input and really shouldn't be left floating. Schematics error? should it be connected to A and B which already are connected together.

[exe]

I've made a patch which removes that mode/range change delay while autoranging, but I can't test it without a meter. I'm now wondering if anybody would be willing to sell me their meter for testing purposes?

Well, I have two, I can sell one. It cost me ~194 euros each delivered (I had to pay VAT and "processing" fee), I ask 180euro+delivery. The one I can sell was never used except a few power ups just to check. Please let me know (here or PM) if you are interested.

PS did other guys from EU also paid VAT? I though it supposed to be delivered from Germany via a distributor...

EDIT: I calculated price wrong first time.

[Smokey]

Oh man... can't wait for firmware version ...

v1.21

I hope it includes some serious shit!

[hwti]

Yes that seems strange - C is pin9 on U11 and is a digital cmos input and really shouldn't be left floating. Schematics error? should it be connected to A and B which already are connected together.

I don't see any obvious trace connected to the pin.
I didn't want to reopen the whole meter, but by just removing the backcover the pin is accessible : I measured 13MOhm to ground, so it really seems to be floating (so no connection to ground under the chip, which could have been another option).

[dr.diesel]

Oh man... can't wait for firmware version ...

v1.21

I hope it includes some serious shit!

I just about spilled my Beer, well done Sir. 

[logictom]

You are missing something. Multimeter specifications always refer to the ranges - not to currents or voltages you are measuring. So this table is talking about the 50uA to 10A ranges.

Thanks amspire, that makes sense and it is what I see in the manual for my fluke, but what I still don't get is, why is the range specified with the lower value, so the 5mA value, when it can measure down to 500uA?

[Kal]

Just want to add that rotary switch wobble issue exists also with my meter (EU shipped). https://youtu.be/pjaWWMoPMsE
Is this same for everyone or only part of the already shipped meters?

[EEVblog]

I've made a patch which removes that mode/range change delay while autoranging, but I can't test it without a meter. I'm now wondering if anybody would be willing to sell me their meter for testing purposes?

If you upload the firmware file then we can test it.
I'd get you a meter, but we only have two production units left here.