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.
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.
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?QuoteFluke 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.
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?QuoteFluke 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.
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.
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?QuoteFluke 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?
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.
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.
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/
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/
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.
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.
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.
Are you able to share their response?
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.
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.QuoteAfter 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.
FYIQuote78608 version is only to enlarge allowance range for OHM hardware offset to reduce production failure rate. It does not affect meter performance.
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.QuoteAfter 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.
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.
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.
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.