Ohms autoranging has been improved down to just under 4.5sec or so. They claim any faster and the meters would require recalibration. I don't know why they can't at least partially use the bargraph ADC for this.
Great news.
Will it be further reduced for the 2nd batch? Calibration will not be a problem since it would be from the factory.
The speed is basically based on algorithm used, a binary tree search would result in log(n) base2 where as linear (n). For example if linear search was taking 7 sec to reach extreme end (lowest range), then after binary search you can basically reduce time to 2.8 sec (log base 2 of 7 is 2.807355)
Now Dave is saying it is 4.5 sec, with a improved algorithm it can reduce to 2.16 sec. There are many ways to improve firmware speed, essentially they need to profile the code, reduce string copies if any, use all constant time data structures, remove unwanted calls to memory allocator (rather use object pools), check for cache hit analysis .. use simple array structures when possible and so on.
If they can install valgrind under quemu (if thats ported to STM32) you can do a much detailed profiling of the code. That way you can optimize the portions that are slowing down the meter. Not only it will make it run faster, it will also increase battery
Ohms autoranging has been improved down to just under 4.5sec or so. They claim any faster and the meters would require recalibration. I don't know why they can't at least partially use the bargraph ADC for this.
Great news.
Will it be further reduced for the 2nd batch? Calibration will not be a problem since it would be from the factory.
The speed is basically based on algorithm used, a binary tree search would result in log(n) base2 where as linear (n). For example if linear search was taking 7 sec to reach extreme end (lowest range), then after binary search you can basically reduce time to 2.8 sec (log base 2 of 7 is 2.807355)
Now Dave is saying it is 4.5 sec, with a improved algorithm it can reduce to 2.16 sec. There are many ways to improve firmware speed, essentially they need to profile the code, reduce string copies if any, use all constant time data structures, remove unwanted calls to memory allocator (rather use object pools), check for cache hit analysis .. use simple array structures when possible and so on.
If they can install valgrind under quemu (if thats ported to STM32) you can do a much detailed profiling of the code. That way you can optimize the portions that are slowing down the meter. Not only it will make it run faster, it will also increase battery
I suspect the limiting factor may be the time it takes to settle after re-ranging, rather than actual acquisition rate or any code speed limitations, though it may also be doing stupid things like excessive screen redraws
The speed is basically based on algorithm used, a binary tree search would result in log(n) base2 where as linear (n). For example if linear search was taking 7 sec to reach extreme end (lowest range), then after binary search you can basically reduce time to 2.8 sec (log base 2 of 7 is 2.807355)
You do not do a binary search on a multimeter.
The speed is basically based on algorithm used, a binary tree search would result in log(n) base2 where as linear (n). For example if linear search was taking 7 sec to reach extreme end (lowest range), then after binary search you can basically reduce time to 2.8 sec (log base 2 of 7 is 2.807355)
It may not be possible to leap around randomly if there's much internal capacitance, etc.
The trick will be to short-circuit the A->D conversions and switch range as soon as possible when you see the range is obviously wrong (eg. look at the initial slope of the ADC charge curve?)
It may
never be super-fast no matter what the firmware. It's easy to imagine clever tricks from the comfort of an armchair but the hardware is already built and you have to work with what you've got. eg. Looking at slopes sounds good but there may be too much variation between individual meters to make it reliable, or the ADC might not be suitable.
OTOH 4.5 seconds is a loooong time. I'd bet they're erring on the side of caution in the current firmware.
There are many ways to improve firmware speed, essentially they need to profile the code, reduce string copies if any, use all constant time data structures, remove unwanted calls to memory allocator (rather use object pools), check for cache hit analysis .. use simple array structures when possible and so on.
If they can install valgrind under quemu (if thats ported to STM32) you can do a much detailed profiling of the code. That way you can optimize the portions that are slowing down the meter. Not only it will make it run faster, it will also increase battery
None of that will be applicable here. It will be down to the hardware design, knowledge of the hardware, etc.
The front end chip has a slow and a fast ADC. No need to figure out how to trick the slow if the fast is available. Is the fast ADC used for the bargraph?
I suspect the limiting factor may be the time it takes to settle after re-ranging, rather than actual acquisition rate or any code speed limitations, though it may also be doing stupid things like excessive screen redraws
Yes, there will be some sort of chipset limit based on range switching and settling time. I don't know what that is.
I do know that Hycon recommended switching between constant voltage and constant current modes at the 500k range, so that may impact things.
I'm hoping that further tweaks are possible, and I've asked them to try some more, but it's almost certain we won't be able to magically get it to down to say 1 second.
There is likely a good reason why the Keysight U1282A isn't hugely faster using the same chipset.
The front end chip has a slow and a fast ADC. No need to figure out how to trick the slow if the fast is available. Is the fast ADC used for the bargraph?
Yes, and I have asked them to consider that.
Another data point : I have a meter here using the same chip that ranges from open to 0R in 2 seconds.
The trick will be to short-circuit the A->D conversions and switch range as soon as possible when you see the range is obviously wrong (eg. look at the initial slope of the ADC charge curve?)
In ohm mode I can see two strategies:
1) Du a full measurement and select range depending on the result, this allows you to go down 3-4 decades at once.
2) Use the bargraph converter to change range, that is only on decade at a time.
Each range shift requires some settling time and I have no idea if 1) or 2) would be fastest.
I'd like the option of recal to even further reduce the auto ranging time.
Another data point : I have a meter here using the same chip that ranges from open to 0R in 2 seconds.
Very interesting!
http://www.hycontek.com/wp-content/uploads/DS-HY3131_EN.pdfI wonder what clock rate the HY3131 in 121GW is running? - typical is 4.9152MHz but max is 8.0MHz according to the datasheet. If higher clock rate would mean faster auto-ranging (my guess is that it would) but then also less battery life - I would really go for faster auto-range as long as the 121GW has a auto-power off function.
One aspect of autoranging with a faster but lower precision ADC is that the meter might select a range that is not optimal. If for example the fast ADC measures 4.9999 as 5.04 it will select a range to high. More problematic is if the difference is the other way, then a low range is selected with overflow. The fast ADC could be tweaked to always read slightly too high.
This could be a user selected feature. Reasonable fast autoranging with precise range selection or very fast autoranging with imprecise range selection?
One aspect of autoranging with a faster but lower precision ADC is that the meter might select a range that is not optimal.
You could always detect that and change range...
You could always detect that and change range...
Yes, there are several options.
1. SLOW: Use the slow high precision ADC for ranging.
2. FAST: Use the fast low precision ADC for ranging, then switch to the high precision ADC and eventually make an additional step up or down.
3. EXTRA FAST: Use the fast low precision ADC for ranging. Use a slight offset to avoid over range.
I wonder what clock rate the HY3131 in 121GW is running? - typical is 4.9152MHz but max is 8.0MHz according to the datasheet. If higher clock rate would mean faster auto-ranging (my guess is that it would) but then also less battery life - I would really go for faster auto-range as long as the 121GW has a auto-power off function.
It's 4.9152MHz
And I don't think that's how it work, it doubt it would magically make the autoranging faster. The micro controls the autoranging, not the HY3131.
I'd like the option of recal to even further reduce the auto ranging time.
There are production meters in the field now, so we can't release firmware that would break the calibration, that would be very foolish.
How is the range switch modification going to be implemented? Who is doing the replacement for the US meters, and will you send replacement parts to customers who've already received theirs?
Any news on the US meters?
Yes, sorry but the US meters will be delayed, they want to make some small tolerance changes to the range switch. We'd rather have them delayed a bit than to have any more potential range switch issues.
I'd like the option of recal to even further reduce the auto ranging time.
There are production meters in the field now, so we can't release firmware that would break the calibration, that would be very foolish.
One would of-course put this FW behind a warning of such. If the improvement is negligible then who cares, but if significant it would be a shame to censor it for those of us capable of a full cal, which could be quite a few as we now pass cal standards around.
All depends on how much improvement is hiding behind the recal FW, which might be ~2sec as Mike suggested, making it very worthwhile.
Any news on the US meters?
Yes, sorry but the US meters will be delayed, they want to make some small tolerance changes to the range switch. We'd rather have them delayed a bit than to have any more potential range switch issues.
Does the US batch include the EU ones that didn't pre-pay VAT? - ISTR you said some other countries were being fulfilled via US.
I wonder what clock rate the HY3131 in 121GW is running? - typical is 4.9152MHz but max is 8.0MHz according to the datasheet. If higher clock rate would mean faster auto-ranging (my guess is that it would) but then also less battery life - I would really go for faster auto-range as long as the 121GW has a auto-power off function.
It's 4.9152MHz
And I don't think that's how it work, it doubt it would magically make the autoranging faster. The micro controls the autoranging, not the HY3131.
Yeah you’re probably right, I notice now from the datasheet that range selection seems to be fully under software control by the MCU. So possibly only the actual ADC conversion would speed up with higher clock rate.
Great to see UEi responded so quickly and if FW ver 1.04 achieved auto-ranging in 4.5 sec it’s a significant improvement over the 7.4 sec we saw before. More useful now for sure but still annoyingly slow. The prototype 121GW was 3.8 sec and U1282A about 3.0 sec in its fastmode, so there’s still room for improvement with a tweaked/hacked FW which I'm sure the programming wizards here at EEVblog eventually will provide.
Does the US batch include the EU ones that didn't pre-pay VAT? - ISTR you said some other countries were being fulfilled via US.
No, we shipped those from here.
I see an app in the iOS App store called "EEVBlog 121GW" by Cheon Myoung-kun. That doesn't sound legit, does it?
And it looks bloody awfull.
Ben
I'd like the option of recal to even further reduce the auto ranging time.
There are production meters in the field now, so we can't release firmware that would break the calibration, that would be very foolish.
One would of-course put this FW behind a warning of such. If the improvement is negligible then who cares, but if significant it would be a shame to censor it for those of us capable of a full cal, which could be quite a few as we now pass cal standards around.
Almost all users do not have the ability to calibrate the meter themselves, and you would be effectively forcing those users to do that if they wanted to upgrade their firmware in the future. That would be very poor form.
I see an app in the iOS App store called "EEVBlog 121GW" by Cheon Myoung-kun. That doesn't sound legit, does it?
And it looks bloody awfull.
It is bloody awful which is why we wrote our own. But yes it is "legit". UEi got that person to write it.