New EEVBlog-Branded Multimeter Coming?

[HKJ]

from my shop:
(ohms autoranging from open to short)

UT61e - half second, sometimes almost instantly
UT181a - 1.5 second
87V - 1 second
289 - 2 seconds

and AN8008 about four seconds, too slow.

Can someone please try the same (speed of autoranging) on capacitance range, for example from open to 20uF ?

I get about 1.1 sec for UT61E and 2.3s for AN8008, but that is for measuring 100ohm, not a short (The 100 ohm timing is part of my reviews).

[mikeselectricstuff]

Fluke 87 takes a second.
Any more than this is simply broken.

That makes most of the multimeters on the market broken, except the manual range ones.

Any meter that has sampling fast enough to do a bargraph display has no excuse to take longer then a second to autorange

[HKJ]

Fluke 179: 1.4s (100ohm)
Brymen BM869s: 1.9s (100ohm)

They may not have a good excuse for the speed, but they are above 1 second.

[evava]

Capacitance from open to 22uF smd ceramic:

UT61e  - 2 seconds
UT181a - 2 seconds
87V - 1 second
289 - half second max, seems instantly

AN8008  - 5 to 6 second, too long.

[exe]

I think the firmware needs some serious love.  Perhaps an opportunity for a GitHub open-source project once Dave releases the schematics?

Hope current behavior is a bug, not a workaround around a hardware problem or limitation.

[steverino]

I think the firmware needs some serious love.  Perhaps an opportunity for a GitHub open-source project once Dave releases the schematics?

Hope current behavior is a bug, not a workaround around a hardware problem or limitation.

I'm really surprised this behavior wasn't discovered before release...Hopefully fixable in firmware...

[markb82]

Hope current behavior is a bug, not a workaround around a hardware problem or limitation.

I bet alot of it is firmware.  The chipset has the ability to increase the sample rate.  The U1272A also does a 300Mohm to 30ohm in decade steps when auto-ranging, but it does it much faster.  And  a more intelligent auto-ranging method (divide and conquer / binary search or simply get one reading at the highest range and use its result to set the range for the next reading with 50k counts it should converge quickly) would be even faster.

If a GitHub project is started at some point, it would be nice to see if the Bluetooth can be used the implement a simple UART link with SCPI.

[exe]

I'm really surprised this behavior wasn't discovered before release...Hopefully fixable in firmware...

I'm 100% sure they knew about all the problems as they are apparent. I think Dave said firmware was one of the reasons to delay. My guess is they decided to send batch anyway and issue hotfix later. I don't really care about being a beta-tester, but I want to know an estimation when issues gonna be fixed.

Or I want to try to fix them by myself, but I need FW sources (which they don't want to share). At least could disable that damn beeper. So, I hope this meter won't be yet another good devices destroyed by software problems.

BTW, guys, is it only my meters do not display low voltages in Low Z mode?

[exe]

it would be nice to see if the Bluetooth can be used the implement a simple UART link with SCPI.

AFAIK Dave said the BT chip manufacturer screwed BT firmware and UART mode disappeared. They couldn't replace it because at that point the meter got its expensive certificates, so they decided not to change it to avoid further delays. But may be hardware mods are still possible. Or a good library that would wrap nasty code in a good API.

[dcac]

Do we know the actual update rate on the bargraph?  the manual only states “fast updating" and then there is the “5 times per second nominal”.   

[mikeselectricstuff]

Poor implementation of something as fundamental as autoranging suggests it's more of a software design issue than a bug. 

[IanB]

There are many apparent experts in multimeter design in this thread.

Maybe there is a reason for it being the way it is?

[dcac]

There are many apparent experts in multimeter design in this thread.

Maybe there is a reason for it being the way it is?

At least I’m pretty sure Dave wouldn't like it to be this way, slow that is.

[markb82]

Poor implementation of something as fundamental as autoranging suggests it's more of a software design issue than a bug.

Sadly I have to agree with you.  Without seeing the source code it is tough to say definitively thought.   Would be nice to get the schematics from Dave, and write some test code to show that the hardware can do fast auto-ranging.

[Messtechniker]

it would be nice to see if the Bluetooth can be used the implement a simple UART link with SCPI.

That's precisely what I am waiting for (for adapting a few Profilab programs of mine).
But there does not seem to be much hope. Will have to wait and see.
Will only buy one, if this UART thing (i.e. communication via virtual COM on Windows PC) is working.

AFAIK Dave said the BT chip manufacturer screwed BT firmware and UART mode disappeared. They couldn't replace it because at that point the meter got its expensive certificates, so they decided not to change it to avoid further delays. But may be hardware mods are still possible. Or a good library that would wrap nasty code in a good API.

[EEVblog]

it would be nice to see if the Bluetooth can be used the implement a simple UART link with SCPI.

AFAIK Dave said the BT chip manufacturer screwed BT firmware and UART mode disappeared. They couldn't replace it because at that point the meter got its expensive certificates, so they decided not to change it to avoid further delays. But may be hardware mods are still possible. Or a good library that would wrap nasty code in a good API.

Bluetooth LE does not have serial UART capability. We tried workaround to implement this but it wasn't possible so far as we could find.
The module is using the Bluegiga Cable Replacement interface.
We have talked about using a matching module in a USB dongle and then formatting into a SCPI UART string. i.e. doing it with dedicated hardware. Maybe there is even an off-the-shelf dongle wiht the Bluegiga module that could be re-programmed to do this?

[brainwash]

Bluetooth LE does not have serial UART capability. We tried workaround to implement this but it wasn't possible so far as we could find.
The module is using the Bluegiga Cable Replacement interface.
We have talked about using a matching module in a USB dongle and then formatting into a SCPI UART string. i.e. doing it with dedicated hardware. Maybe there is even an off-the-shelf dongle wiht the Bluegiga module that could be re-programmed to do this?

SPP mode is only specified for BT2.0 (or 2.1?) and not available for BT4.0. Additionally, SPP is not supported on iOS.
It would be relatively easy to write some virtual serial port software for PCs that takes in the meter's BTLE data. I think once the meters become more available, someone will write such an application. Then you have the advantage of being able to emulate almost any meter, if your LabView code (or whatever) depends on special formatting.

[joeqsmith]

should I take your statement as a confirmation that the 121GW is indeed slow?

It didn't seem slow when I watched someone test it.

I guess everything is relative but here it seemed slower than I was expecting from a meter with 5 updates/sec.

I had wondered if it could not run in a low res mode then switch to high res to get it to lock in faster.  The 121GW uses the same front end chipset used in another meter that Dave had reviewed and I though the settling time was discussed back then.   I would guess some of the people who bought one have more than one meter.  Maybe others will do a side by side comparison to give you a better idea how it compares.       

There are more threads on the 121GW than there are meters.  It's getting hard to know where to post.   Because I do not view the slow autorange as a bug, I'll will keep my comments here. 

I don't understand the big surprise about the slow autorange.  I thought we had discussed this some time ago and I certainly showed it in a few of my videos.  I thought I had even made a comment about them using a chip set that Dave had previously commented on it being slow.        Did people not understand what VERY SLOW meant? 

There may have been a way to overcome it as people have suggested but it seems like if it were an easy fix, it would have been addressed prior to the release.  Maybe Dave will comment on it.     

I am looking forward to seeing reviews of the more complex features, for example reading the power of a 110/220 LED bulb, showing  the BT,  trying some long term data logging to the memory card (over night sort of thing).   For those of you who have received their meters and have taken the time to run some  of these early test,  I appreciate your efforts.   

[ez24]

...  trying some long term data logging to the memory card (over night sort of thing).   For those of you who have received their meters and have taken the time to run some  of these early test,  I appreciate your efforts.

I also would appreciate some info on this

[beanflying]

I wouldn't call the slow Auto Range a bug either but certainly the firmware code and or the methodology used for it could stand to be looked at and revised.

Had a quick play with the bluetooth and android app last night, simple enough to drive and use. I will see about maybe running a test for a few hours of raw Temperature data in my shack today (25+ degreesC at 10am and climbing).

Number of threads is simple, this one is pre release IMO. The one I put some test data into is current use and general thoughts and user questions and the bugs one is for simple reporting of issues for Dave to look at not whining and bitching or discussing 

[gnavigator1007]

Which app is the real one on the Google play store?

[beanflying]

Not this one! https://play.google.com/store/apps/details?id=kr.co.finest.eevblog&hl=en 

But this one https://play.google.com/store/apps/details?id=eevblog.x121gw&hl=en 

[gnavigator1007]

Thanks! Yeah that was actually pretty obvious 

[gnavigator1007]

Scratch that. Looks like you've maybe got it backwards? Look at the permissions and number of downloads.

[exe]

I thought we had discussed this some time ago and I certainly showed it in a few of my videos.

It was a pre-production unit and I had an impression that a lot of effort was put to make it clear that "it's not a final performance, do not judge product by those videos". So, sorry, I completely disagree with your comment "you knew what you were buying".

Apart from that, for obvious reasons people had some (imho reasonable) expectations. Because this is Dave, because he knows what he is doing, etc. Even though Dave told it several times that he is only supervising the project and not directly involved in development. It has EEVBlog brand on it, which people trust. Please stop saying "I told you it's a slow meter, watch my videos better next time". That's not nice, not productive and you are not involved in this product (I'm not offending, I'm expressing how it looks to me, sorry if I'm wrong).

Anyway, I personally want to keep the conversation technical. And for me the biggest questions are: 1) can community help somehow with the issues 2) what is next? Shall we wait for firmware updates or this is the final version of the product and no further improvements are to be expected?