EEVBlog 121GW Discussion thread

[Seppy]

I've received my meter together with the probes from UEI. I can take of a kind of plastic / rubber cap to get to the thread on the tips. I assume that the idea behind these threads is to be able to screw a banana plug tip to it to be able to connect it to some clamps for example (to to to ;-) ).

When I'm checking out the Brymen test leads online, it looks to me like they always come with those banana plug tips.
https://www.welectron.com/Brymen-BL21S2-T4SC-Silicone-Test-Leads
I've assumed that the UEI leads would come with something like that too.

Are they missing in my package or does nobody have received them?

Max

Edited: misread your comment.

The UEI leads do not come with the banana plug tips, however the bryman leads do.

[JS]

Again, I am not suggesting this is a problem.  Obviously, if you are expecting data to be collected with tighter sampling, it could be a problem. 

I was original going to modulate the frequency and amplitude but the results from my initial test was so poor, you could not make sense of the data.  So I simplified it to two states at a fixed frequency.   

  If you are talking about my posts (I haven't seen any other FFT on the data) I was trying to characterize the filtering and define where the noise was coming. In your test, in the samples between one resistor and the other doesn't make much sense to talk about noise, that's the response of the filter which will show intermediate data in the step, so that's what's closing your eyes (in the diagram, not that you are becoming blind).

  From a datalogging point of view I like the 1.26 signal better as it has raw-er data, looking at the meter the 1.00 looks better as you can get a more stable reading, but what is more evident in the eye diagram is that V1.00 is "over simplifying" the data as it's showing one value or the other, and I think there are traces that might look like the intermediate step I see while switching between one value and the other. The closer values (than some random one and a short) and repeated it over time gives more data on that step. Also, the longer run might start to show the glitches on the V1.26.

  I haven't made my mind yet on which one I prefer, as I suggested, if it were in my hands I'd make a selection on speed for that and any other range as I expect a similar behavior (I tested the noise in the mV range with similar values, glitches are observed to be more periodical here, in the 50Ω looks more random to me)

JS

[M4x]

I've received my meter together with the probes from UEI. I can take of a kind of plastic / rubber cap to get to the thread on the tips. I assume that the idea behind these threads is to be able to screw a banana plug tip to it to be able to connect it to some clamps for example (to to to ;-) ).

When I'm checking out the Brymen test leads online, it looks to me like they always come with those banana plug tips.
https://www.welectron.com/Brymen-BL21S2-T4SC-Silicone-Test-Leads
I've assumed that the UEI leads would come with something like that too.

Are they missing in my package or does nobody have received them?

Max

Edited: misread your comment.

The UEI leads do not come with the banana plug tips, however the bryman leads do.

Alright, thank you very much!

[JS]

In your test, in the samples between one resistor and the other doesn't make much sense to talk about noise, that's the response of the filter which will show intermediate data in the step, so that's what's closing your eyes (in the diagram, not that you are becoming blind).

When evaluating the Fourier transform the samples must be evenly spaced.   This noise I am interested in is the jitter.   The purpose of the two resistors is only to provide a known step change at discrete intervals.   It could have been voltage or any other mode.   That assumes that they all have the same jitter.

When Dave had first sent the meter, the fastest it could sample the data was at a one second interval.  I had mentioned that there seemed to be a problem when writing to the SD card that it would hang (crash eventually).   I suspect the some of this large error in sampling (time) is due to writing to the SD card.   The BT may have less jitter.  The prototype does not currently have the ability to use this feature.

Again, I am not normally concerned with noise in the time domain when using a handheld meter.   It does make me wonder why they added the ability to log faster than a second with such high jitter.


****************
I should have made one other small point clear.  The reason I am using the two small resistors close to the same value is that I did not want to add the effects of the auto range into the mix for this test.

  I understand the problem with jitter with the FFT, but I don't see such high jitter in the plots you make, in V1.00 is pretty easy to see the each sample might be within ±50ms at most while your plots suggests 10 times that, I'm not sure how you generated the PLL, but it does trigger in 4 different samples going each way. Also, the 1.26 version plot gets dirtier but that has to do with the levels for the intermediate samples between one value and the other, where the V1.00 is staying for about 3 samples while V1.26 isn't. I think your PPL is messing with in which sample the read reflects the resistor change, which very well be within a few samples with no problem, and you are confusing that with sampling jitter. I don't understand how you could evaluate jitter from the sampled data, you need a reference clock to work that, maybe a smooth voltage ramp could show it, knowing the linearity of the reference ramp is good and the deviation from there is coming from the meter measuring at different points. What I can see is the meter can miss a few samples from the time the resistor was swapped and the reading is shown, I can live with that. Maybe I'm missing the point here and you did used the reference signal going to the switch to lock your PLL, but I don't know how would you correlate that with the samples from the meter.
  Would be nice to see those plots with aligned rising edges, meaning the last sample within specs for each resistor is aligned between all steps, which will show a bit better the step response than the single step measurement I did.

  In my plots I get two peaks in noise, which might very well be just one but due to this jitter appears as two different ones in the FFT. Even then, if what I want to see is the digital filtering made with the samples, an FFT will still show that pretty well, as the firmware will process sample by sample and wouldn't care varying sampling time, so you could have much bigger phase noise than you say and what I'm looking for  in the FFT still be useful.

  In any case, as you said, and I agree with you, the time data isn't the important factor in a DMM reading, the amplitude value is what's useful here, and my complain has to do with glitches in the measured data which are not in the input signal, as I had correlated the effect between different ranges and in different environments. Then, if I'm logging I don't want the meter to do any filtering with the samples, I want the raw data so I can choose to see small changes fast and try to make sense from it out of the noise or filter and get a more steady value, but also I don't want the readings to be false, as it does when it jumps up to 50 counts, well outside the 10 specified counts. I also don't care when it changed value (precisely in time, within a few samples should be good enough most of the time).

JS

[firewalker]

What quantity is the vertical axis?

Alexander.

[firstcolle]

I'm trying to connect the meter with my desktop using a BT dongle but I can't pair them. I'm using an old dongle. can you suggest me one working dongle?
no problem with my smartphone.

[IanB]

I'm trying to connect the meter with my desktop using a BT dongle but I can't pair them. I'm using an old dongle. can you suggest me one working dongle?
no problem with my smartphone.

I just did the same thing using this dongle, so I know it works:

http://www.hornettek.com/wireless-networking/hornettek-ultra-mini-usb-bluetooth-v4-0-dongle-ht-bt40b.html

I paid $18 for it, not the $40 list price. It uses a Broadcom chip, in case that helps.

In order to successfully use the dongle I had to shut down the Windows app, then pair the meter, then restart the app. When I first paired the meter while the app was running the app couldn't see the meter until I restarted it.

[JS]

Let's start by just looking at some raw data.  Again, the actual period of the toggle is fixed.  Because the jitter in the meters sampling, it is not a nice periodic waveform.   Should be easy enough to replicate.

  I see, there are flats from 10 to almost 20 samples. Are you suggesting the ADC reading is in such different intervales? I don't think the ADC would change so much, the readings from the µC is more likely the problem. Also, from the smaller look at your older pict of the raw data, V1.26 seems much more stable, isn't? The conversion results are jittery, no doubt, I wouldn't lock my clock onto the readings of that taking the reference somewhere else. My question now would be if the readings are shifting badly or the long term average out to a fixed-ish sampling rate.

  I do think V1.00 is using some non linear filter, I read somewhere it was a moving average which resets when a big change is detected, but I don't know the version corresponding to that. V1.26 response looks pretty different, much sharper edges (without the step in the middle which drives me nuts when I see it) and tighter when crossing from one to the other.

  I should replicate the test and check for myself, I will at some point, busy weekend for me this time.

JS

[firewalker]

What quantity is the vertical axis?

Alexander.

Are my previous posts not clear enough?

Yes it is! I had both 121GW threads opened and thought I read that one to the issues thread...

[IanB]

Here's a repeat of a test I was performing earlier. I wanted to compare the 121GW with something else for reference, so I dug out the interface cable for my BM869.

Here I show the results of logging a 500 microvolt source over a period of about 1000 seconds. I set up both 121GW and BM869s to measure the same voltage source at the same time with the same arrangement of meters and test connections, as near identical as I could manage. Both meters are sampling about twice per second at the maximum rate the software supports. The 121GW has the v1.26 firmware.

The average reading of the BM869s is nearly flat over the test duration, starting out at about 0.492 mV and ending at about 0.4925 mV. There are no glitches or outliers in the data.

The average reading of the 121GW shows a significant upward trend, starting at about 0.481 mV and ending at about 0.4865 mV. There are several apparent artifacts in the data where the meter deviates widely from the average reading. No explanation exists as yet for these glitches.

[IanB]

I have not ran a test like this with any of the other handheld meters I have.  None of them can capture data this fast.   It would be a nice feature if the meter could actually keep up storing the data or getting it across the wireless link.    It is a bit odd that the resistance seems to have higher jitter than the voltage mode.

The BM869s can sample data over the USB cable at a rate of 4 or 5 samples per second if you write your own software for it. The standard software is limited to twice per second. I have not yet explored the maximum capability of the meter (whether the meter's acquisition rate is as fast as the output data rate).

[IanB]

I had the 121GW switched on in mV DC mode with the BT interface running for quite some time before starting this test. As described in another thread I couldn't get it to connect to Windows 10 and I spent about 20 minutes trying to get it to work. So it should have warmed up reasonably well before I started.

The upward drift could conceivably have been due to a change in ambient temperature affecting my voltage source, but the BM869s as a control suggests this was not the case.

BTW, my Radio Shack 22-812 meters can log about 5 samples per second at a smooth, even cadence. I like them so much as data logging meters that I bought three of them. (I made my own logging software so that I can record from several meters at the same time to the same log file for multi-variable experiments.)

[IanB]

I neglected to record the on screen temperature display over the duration of the test. However, the temperature would have been reasonably constant (no AC running during or before the test).

Here is a sample of the raw data from around the 550 second mark. You can see the data is being sampled twice per second, but apparently quite heavy filtering is being applied, so the update rate appears slower than that. The filtering is quite apparent from the spike contained within this sample. The time constant appears to be in the order of a few seconds.

Code: [Select]

550.0406, 0.485
550.525, 0.485
551.0563, 0.485
551.5406, 0.484
552.025, 0.484
552.5563, 0.484
553.0406, 0.484
553.525, 0.484
554.5422, 0.484
555.0266, 0.484
555.5578, 0.483
556.0422, 0.489
556.5266, 0.489
557.0578, 0.489
557.5422, 0.489
558.0266, 0.489
558.5578, 0.488
559.0422, 0.488
559.5176, 0.487
560.0645, 0.487
560.5488, 0.486
561.0266, 0.487
561.5578, 0.487
562.0422, 0.486
562.5891, 0.486
563.0579, 0.486
563.5385, 0.486
564.0295, 0.486
564.5608, 0.486
565.0475, 0.485
565.5787, 0.485
566.104, 0.485
566.5461, 0.485
567.0305, 0.486
567.5618, 0.486
568.0421, 0.486
568.5889, 0.486
569.5421, 0.485
570.0264, 0.485
570.5665, 0.485
571.0352, 0.485
571.5821, 0.486
572.0665, 0.486
572.5352, 0.485
573.0821, 0.485
573.5665, 0.485
574.0352, 0.485
574.5352, 0.485
575.5352, 0.485
576.0821, 0.485
576.5665, 0.485
577.0352, 0.485
577.5821, 0.484
578.0665, 0.484
578.5352, 0.484
579.0821, 0.484
579.5665, 0.484
580.0352, 0.484


[IanB]

Here is estimating a time constant from one of the spikes:

[JS]

  From the sine wave it's pretty clear the loss in samples, I see how that can become a problem, in fact is about half period, so 5s or 20 samples. I'd expected to see a sample or two missing in case on some calibration routine, but the spikes bother me more than the jitter, which can also be a serious problem for some measurement but I think we agree the timing is not so important while data-logging with a DMM as the value.

  Those spikes appear at a pretty constant rate in mV range, but looks pretty random in the 50Ω, that might have something to do with the difference in jitter between both ranges.

  About the drift, I've seen some in the 50Ω range at start up, but not so much once warmer, haven't tested in mV range, I should put a stable reference to work...

  All and all, I find the meter pretty useful as it is, but I think it has the potential to polish this rough edges and would be nice to have it as nice as it can be.

JS

[IanB]

The noise of the 121GW prototype dominates the signal.  The higher amplitude spikes appear very periodic.

That noise is extreme. It's like you have a totally different meter. Maybe I should try logging to the SD card instead of BT and see what difference it makes with my one.

You show about 8uV of drift over that 1000 seconds.  It looks like my HP is about 4uV.   It's strange how different the two meters behave.

If the HP is the red line, it seems to drift down by less than half a division in 4000 sec, and one division is 5 µV, so that is about 2 µV in 4000 sec, or 0.5 µV in 1000 sec. Or am I reading it wrong?

[darik]

Periodic spikes and dropped samples could be related to the logging. Like for example the SD card could be buffering writes and then flushing them when they get to a certain size, which would be at regular intervals. And those particular writes would take longer than others and maybe cause a spike in power consumption.

I have written Arduino based apps for logging sensor data to SD cards. It took a little finesse to make sure the file I/O didn't throw off the sample timing too much and when monitoring the current use, there was a noticeable power spike (around 15 mA IIRC) when the buffers were flushed and SD writes happened.

The Bluetooth interface could be doing the same thing but differently. It must have it's own weird power consumption issues as it surely must be doing a lot of asynchronous radio transmission to send whatever packets it needs to to maintain the connection.

[IanB]

I believe the spikes happen the same way whether logging is happening or not. Logging is merely a good way to make the spikes visible. So I am not sure the logging is the cause of the spikes.

[joeqsmith]

The noise of the 121GW prototype dominates the signal.  The higher amplitude spikes appear very periodic.

That noise is extreme. It's like you have a totally different meter. Maybe I should try logging to the SD card instead of BT and see what difference it makes with my one.

You show about 8uV of drift over that 1000 seconds.  It looks like my HP is about 4uV.   It's strange how different the two meters behave.

If the HP is the red line, it seems to drift down by less than half a division in 4000 sec, and 1 division is 5 µV, so that is about 2 µV in 4000 sec, or 0.5 µV in 1000 sec. Or am I reading it wrong?

The X-axis is in samples, not seconds.  At 4Hz we have 1000 seconds.  So the same as your setup.   Yes, the Y-axis is 5uV per division.  The HP's output is too small to read on the screen but there is a readout in the lower right.  The max is 501.05 and the min is 497.63 or 3.42.  That's with the noise and everything included.  Then I padded it up to 4uV. 

I do have a totally different meter.  It's a prototype that has been damaged three times, repaired by me and then modified.  Then it was completely realigned to a NON-NIST traceable standard.    So I can fully believe this meter behaves differently in any of the data I show.   Which is why I started out stating there is nothing to take away with this.  In other words, don't read more into it than what's there.   

Again, sadly no image is available for the BT so I have yet to see it work.  So any results I show in for foreseeable future will be from logging on the SD card.   

[IanB]

I find it amusing that you now seem to have three production samples of the Fluke 189 and as yet no production sample of the 121GW. Can we infer that you don't think the 121GW is worthy of being owned? 

(I am slightly envious of your 189 ownership, by the way.)

[JS]

The noise of the 121GW prototype dominates the signal.  The higher amplitude spikes appear very periodic.

That noise is extreme. It's like you have a totally different meter. Maybe I should try logging to the SD card instead of BT and see what difference it makes with my one.

You show about 8uV of drift over that 1000 seconds.  It looks like my HP is about 4uV.   It's strange how different the two meters behave.

If the HP is the red line, it seems to drift down by less than half a division in 4000 sec, and one division is 5 µV, so that is about 2 µV in 4000 sec, or 0.5 µV in 1000 sec. Or am I reading it wrong?

I've done a test in the other topic, I see spikes up to 50 counts down in the mV range,  I didn't say anything about drift as it was with shorted inputs, just 200 samples 3 spikes are observed, in samples 61, 121 and 181. Mine is from the kickstarter, so noise still there.. I run the comparison with V1.00 and the spikes are also there but muffled. In the 50Ω range the spikes are also present but the interval is much random. A few of my measurements are in the other topic. I live a link to the message of the mV range.
https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1767461/#msg1767461

JS

[joeqsmith]

Feeding the 121GW prototype with a chirp and comparing firmware 1.0 with 1.26.  The chirp is from 20mHz to 5Hz with a 500 second sweep time. The meter is sampling at 4Hz.  X-axis is in samples.   Y-axis is in voltage.  Arb is programmed to 100mVp-p.   

[FrankBuss]

Sorry, I'm a bit slow, if this was already mentioned: I just realized that "121GW" sounds pretty much like 1.21 gigawatts

[1anX]

Sorry, I'm a bit slow, if this was already mentioned: I just realized that "121GW" sounds pretty much like 1.21 gigawatts

You got it right Frank, and as the saying goes, "better late than never"!

[Brumby]

Exactly right.

Some time ago there was a discussion about naming the meter and the "121GW" proposition took an unbeatable lead in its support.