Brymen BM789

[NoMoreMagicSmoke]

And what should that response be?
Fluke for example very quietly fixed it in production units about 12 months later and made no mention of it at all to new or existing customers. A customer would have no idea what version they were buying.

A good first step is to take interest in the issue to understand it's impact to the customer and the root cause. After that the response should be commensurate with the impact. Ex. If it's a safety issue then there should be a recall. If it's an edge case that has a material affect on a small number of users it should be handled as warranty on a case by case basis. If it's an oddity quirk that does not have a material effect on end users fix in new.

[Monkeh]

I used to have a 70 series Fluke at work that had an autoranging problem when meanruing mains transformer primaries, it just kept autoranging, displaying nothing.

I've seen a number of meters do similar, it's not uncommon. People just like to get worked up over things.

[floobydust]

If Brymen is scared then let authorized dealers or a repair depot do it. Oh wait there's none in North America.

And who's going to pay for all the shipping and time?

Fluke had top quality firmware, it was tested thoroughly, there is no comparison in that regard.

https://www.eevblog.com/forum/testgear/fluke-87v-87-5-87-v-gsm-interference-fluke-says-firmware-flash-fixes-it/

I used to have a 70 series Fluke at work that had an autoranging problem when meanruing mains transformer primaries, it just kept autoranging, displaying nothing.

Is your position that the firmware is carved in stone, users have to suck it up if there are (non-safety related) bugs, you are stuck with the version you bought?
I can't see Brymen making it to the next level with say a Bluetooth stack, that is carved in stone.

It's not really the bug that is a concern, it's the software testing coming across as weak. Autoranging is not rocket science. You flowchart and test at the boundary conditions such as a range change, and a range change gone wrong. And this issue is only a problem for people working in the 600 ohm world it seems.

A repair depot in North America would not burden customers with the crazy shipping costs/customs paper work to Taiwan. It seems to be that ____ exclusivity agreement blocking that. I think they're playing in dangerous waters, with no formal sales/distribution a recall would be a disaster.

I haven't ever been bitten by Fluke multimeter bugs, and see they dealt with them as a warranty repair.

[NoMoreMagicSmoke]

If Brymen is scared then let authorized dealers or a repair depot do it. Oh wait there's none in North America.

And who's going to pay for all the shipping and time?

Fluke had top quality firmware, it was tested thoroughly, there is no comparison in that regard.

https://www.eevblog.com/forum/testgear/fluke-87v-87-5-87-v-gsm-interference-fluke-says-firmware-flash-fixes-it/

I used to have a 70 series Fluke at work that had an autoranging problem when meanruing mains transformer primaries, it just kept autoranging, displaying nothing.

Is your position that the firmware is carved in stone, users have to suck it up if there are (non-safety related) bugs, you are stuck with the version you bought?
I can't see Brymen making it to the next level with say a Bluetooth stack, that is carved in stone.

It's not really the bug that is a concern, it's the software testing coming across as weak. Autoranging is not rocket science. You flowchart and test at the boundary conditions such as a range change, and a range change gone wrong. And this issue is only a problem for people working in the 600 ohm world it seems.

A repair depot in North America would not burden customers with the crazy shipping costs/customs paper work to Taiwan. It seems to be that ____ exclusivity agreement blocking that. I think they're playing in dangerous waters, with no formal sales/distribution a recall would be a disaster.

I haven't ever been bitten by Fluke multimeter bugs, and see they dealt with them as a warranty repair.

As much as I agree with you, Brymen does not sell in the USA so any meters imported (not unter greenlee or EEVBlog brands) are grey market and therefore it's not Brymens responsibility to cover service or shipping to get them fixed. That's a risk we pay for purchasing grey market goods.

[EEVblog]

And what should that response be?
Fluke for example very quietly fixed it in production units about 12 months later and made no mention of it at all to new or existing customers. A customer would have no idea what version they were buying.

A good first step is to take interest in the issue to understand it's impact to the customer and the root cause. After that the response should be commensurate with the impact. Ex. If it's a safety issue then there should be a recall. If it's an edge case that has a material affect on a small number of users it should be handled as warranty on a case by case basis. If it's an oddity quirk that does not have a material effect on end users fix in new.

Fair enough.
And where would you rank an autoranging hunting issue? For me it's the latter.

[EEVblog]

If Brymen is scared then let authorized dealers or a repair depot do it. Oh wait there's none in North America.

And who's going to pay for all the shipping and time?

Fluke had top quality firmware, it was tested thoroughly, there is no comparison in that regard.

https://www.eevblog.com/forum/testgear/fluke-87v-87-5-87-v-gsm-interference-fluke-says-firmware-flash-fixes-it/

I used to have a 70 series Fluke at work that had an autoranging problem when meanruing mains transformer primaries, it just kept autoranging, displaying nothing.

Is your position that the firmware is carved in stone, users have to suck it up if there are (non-safety related) bugs, you are stuck with the version you bought?

That's how almost every multimeter on the market is, very few have firmware update ability, and if they do like in this case, or the case of Fluke's for example, it's a factory/dealer thing only. Been like this since time immortal.
In an ideal world users would be able to update their own firmware, but I understand why many manufacturers are against this.
As a dealer, I would be out of business if everyone decided to return their meter for a firmware update and I had to pay the cost of shipping both ways. Same goes for the manufacturer.
Best to deal with it on a case by case basis.
If you are unhappy with your meter or it's firmware then I'm happy for you to return it and I'll refund your money.

[tautech]

Best to deal with it on a case by case basis.
If you are unhappy with your meter or it's firmware then I'm happy for you to return it and I'll refund your money.

Would this also apply for the last 2 replies here ?
https://www.eevblog.com/forum/testgear/brymen-bm-235-startup-issues/

[NoMoreMagicSmoke]

And what should that response be?
Fluke for example very quietly fixed it in production units about 12 months later and made no mention of it at all to new or existing customers. A customer would have no idea what version they were buying.

A good first step is to take interest in the issue to understand it's impact to the customer and the root cause. After that the response should be commensurate with the impact. Ex. If it's a safety issue then there should be a recall. If it's an edge case that has a material affect on a small number of users it should be handled as warranty on a case by case basis. If it's an oddity quirk that does not have a material effect on end users fix in new.

Fair enough.
And where would you rank an autoranging hunting issue? For me it's the latter.

In my day job I have to make these type of calls when they come up, so my take on this is definitely more tempered than others that are commenting here. Without full information I am also hesitant to make a definitive statement either. Without knowing the root cause of the issue I can not say for sure which category this issue would fall into. My gut is telling me this is likely a low impact issue, but again it could just be one symptom of a bigger problem somewhere that might place this into a higher impact category.

If it is simply an auto ranging quirk that only affects resistance measurement in one magic count value then, yes, I would put this in the latter category as well.

That being said, as a consumer that owns a BM789 of course I want my meter to be the mythical and unobtainable perfect and without flaw!   

[joeqsmith]

Best to deal with it on a case by case basis.
If you are unhappy with your meter or it's firmware then I'm happy for you to return it and I'll refund your money.

Would this also apply for the last 2 replies here ?
https://www.eevblog.com/forum/testgear/brymen-bm-235-startup-issues/

Wait.... I have a 121GW that is also having a few problems!!   

[EEVblog]

Best to deal with it on a case by case basis.
If you are unhappy with your meter or it's firmware then I'm happy for you to return it and I'll refund your money.

Would this also apply for the last 2 replies here ?
https://www.eevblog.com/forum/testgear/brymen-bm-235-startup-issues/

Any faults would be covered under warranty.

[NoMoreMagicSmoke]

It's not really the bug that is a concern, it's the software testing coming across as weak. Autoranging is not rocket science. You flowchart and test at the boundary conditions such as a range change, and a range change gone wrong. And this issue is only a problem for people working in the 600 ohm world it seems.

I think you are underestimating the complexity of that simple statement. I tested my meter, and I found the following:
- My meter ranges up when the 66000 count threshold is reached
- My meter ranged down when the 61000 count threshold is reached
- My meter shows 6xxxx when the resistor is applied above the 63100 count reading
- My meter shows 06xxx when a resistor is applied below the 63100 count reading

None of these values correlate with the other users "magic values" that cause this issue which range from 65000-67000 counts. Now which "boundary condition" should they be testing to?

I expect that this bug is probably related to some perfect combination of hardware tolerance and firmware logic. It is highly probable that they did test the expected boundaries but the hardware in the test meters did not hit the magic values to cause this issue. Additionally, it is possible that they did test what they expected to be the boundaries, but the boundary might be slightly different than expected due to some tolerance related variance.

Yes, a company should test the boundaries. The problem is it is very likely that the test engineers performed extensive testing, but they missed that one magic permutation that caused some unfortunate bug to exist.

There is no complex product in existence that is without bugs. The important part is does the device have a bug that significantly affects it fit for use and end user satisfaction. Equally important (as I have said before) is how the company responds and what they do when a bug is discovered.

[floobydust]

You decide to autorange up or down, on Ohms function. This is the boundary to test, in both directions that I'm talking about.
It involves changing the current-source (likely a resistor switched) and possibly the PGA and to a different (range) calibration factor, all at the same time (I don't have the Brymen chip datasheets to peruse but this is typical).
SURPRISE! This leaves you needing to range change in the opposite direction - which leads you to changing range again etc. and you see it's oscillating back and forth. As I've mentioned if you measure Ohms test current (using another DMM) while playing around with the potentiometer you should be able to see the changing/hunting. It could show up in other places at those boundaries as well.
No programmer expects to get stuck in a loop lol, that's why they have piles of hysteresis i.e. 66,000 vs 61,000 counts you mention.
Firmware algorithms around this can simply count the number of consecutive range changes done to see the hunting, the code itself can see what users are seeing and make an adjustment. It might be related to that range's calibration factor- unique to each multimeter. It can be a time delay needed to be added for settling time. Many hardware issues can cause it- but the point is it's too bad the bug is not easily fixed and slipped through testing.

[joeqsmith]

There is no complex product in existence that is without bugs. The important part is does the device have a bug that significantly affects it fit for use and end user satisfaction. Equally important (as I have said before) is how the company responds and what they do when a bug is discovered.

I have heard back from Brymen and they explained in detail the problem as well as their corrective action.  Indeed, some meters will not exhibit the inability to converge. 

[NoMoreMagicSmoke]

There is no complex product in existence that is without bugs. The important part is does the device have a bug that significantly affects it fit for use and end user satisfaction. Equally important (as I have said before) is how the company responds and what they do when a bug is discovered.

I have heard back from Brymen and they explained in detail the problem as well as their corrective action.  Indeed, some meters will not exhibit the inability to converge.

Good to hear. Are you able to share their response?

[joeqsmith]

Are you able to share their response?

This will require a change to the firmware.  In the future I hope to do a short clip showing the 789 before and after this update.

After switching from 600Ω Range to 6kΩ Range, firmware used the first hi-speed AD conversion data to deduct "600Ω Range Offset" to check if further Range-Switching was in need. In case "600Ω Range" and "6kΩ Range" have significant offset difference, the unit may not be able to converge the measurements at around 640Ω ~ 660Ω region in auto-ranging operation mode. Thus not every unit will have this bug. Only the unit with extreme offset difference case has this bug.

[NoMoreMagicSmoke]

Are you able to share their response?

This will require a change to the firmware.  In the future I hope to do a short clip showing the 789 before and after this update.

After switching from 600Ω Range to 6kΩ Range, firmware used the first hi-speed AD conversion data to deduct "600Ω Range Offset" to check if further Range-Switching was in need. In case "600Ω Range" and "6kΩ Range" have significant offset difference, the unit may not be able to converge the measurements at around 640Ω ~ 660Ω region in auto-ranging operation mode. Thus not every unit will have this bug. Only the unit with extreme offset difference case has this bug.

That makes sense. It also likely means that the root cause is an unexpected condition as a result of a manufacturing tolerance stackup.

I am really suspicious if it isn't a direct result of:

FYI

78608 version is only to enlarge allowance range for OHM hardware offset to reduce production failure rate. It does not affect meter performance.

Which would mean that the statement of "does not affect meter performance" isn't exactly true.   

The following is pure speculation, but I can certainly see how this can happen. R&D designed the meter and developed their tests around the design. The engineers may have even developed the original specifications to ensure that this scenario could not happen. After they start production the are seeing a higher than expected reject rate, and the process engineers determine that they can increase the tolerance to resolve the issue. The tests may have passed due to the test developers designing the bounds conditions around the original design, which might now no longer be the correct bounds conditions.

Regardless of how they got here. Based on Brymen's response to your previous inquiries, I would not be surprised if Brymen is currently in the process of developing new production change procedures to be absolutely certain this can't happen again.

[NoMoreMagicSmoke]

Are you able to share their response?

This will require a change to the firmware.  In the future I hope to do a short clip showing the 789 before and after this update.

After switching from 600Ω Range to 6kΩ Range, firmware used the first hi-speed AD conversion data to deduct "600Ω Range Offset" to check if further Range-Switching was in need. In case "600Ω Range" and "6kΩ Range" have significant offset difference, the unit may not be able to converge the measurements at around 640Ω ~ 660Ω region in auto-ranging operation mode. Thus not every unit will have this bug. Only the unit with extreme offset difference case has this bug.

Since I have a meter that does not exhibit this behavior, are you willing to compare your meter with the issue to mine?

- My meter ranges up when the 66000 count threshold is reached
- My meter ranged down when the 61000 count threshold is reached
- My meter shows 6xxxx when the resistor is applied above the 63100 count reading
- My meter shows 06xxx when a resistor is applied below the 63100 count reading

I am curious how close your transition threshold is to the offending reading.

[joeqsmith]

At 649.53 ohms it is stable.  Add one more ohm and it will hunt until 0.6759 where it is once again stable.   I'm sure it would change depending on the direction and range.   

[NoMoreMagicSmoke]

At 649.53 ohms it is stable.  Add one more ohm and it will hunt until 0.6759 where it is once again stable.   I'm sure it would change depending on the direction and range.   

Interesting. Does it only oscillate when going up? Or does it happen when going down as well?

[joeqsmith]

I think it cleaned switched (no oscillation) going back down and the threshold was a different value all together. 

[AVGresponding]

One wonders if the same mod as applied to the 869S for the same problem (on a higher range, granted) might work to prevent this?

[EEVblog]

For those interested in the exact details here:

uses hi-speed AD conversion data to do Auto-ranging mechanism. After switching from 600Ω Range to 6kΩ Range, firmware used the first hi-speed AD conversion data to deduct "600Ω Range Offset" to check if further Range-Switching was in need. In case "600Ω Range" and "6kΩ Range" have significant offset difference, the unit may not be able to converge the measurements at around 640Ω ~ 660Ω region in auto-ranging operation mode. Thus not every unit will have this bug. Only the unit with extreme offset difference case has this bug.

Our engineer has modified the firmware to fix this bug. After switching from 600Ω Range to 6kΩ Range, the update firmware version uses the first hi-speed AD conversion data to deduct "6kΩ Range Offset" instead to check if further Range-Switching is in need.

[NoMoreMagicSmoke]

Our engineer has modified the firmware to fix this bug. After switching from 600Ω Range to 6kΩ Range, the update firmware version uses the first hi-speed AD conversion data to deduct "6kΩ Range Offset" instead to check if further Range-Switching is in need.

[/quote]

Well, that blowa.a hole in my theory. That sounds like a straight up copy paste typo...

[pazuwu]

Did Brymen say in which firmware version was this corrected?

[J-R]

Couldn't reproduce the issue on my 78905 at any of the range transitions.

~655.xx does show as 0.622xx for a full second before settling on 0.655xx.  Also noticed the same behavior if you switch to mV and back at that approximate value.