This behavior to me is completely crazy. I don't quite understand the code behind the rules or what purpose they serve, but they are clearly there. I have no idea why they designed it like this.
I am not suggesting that the original firmware was bug free by any means. It makes me wonder if they (UEI) can't produce firmware for the meter, what's the future plans. It's painfully obvious they are unable to test the code they release. If you are going to charge a premium for it, it should at least perform as well as other meters in that price class and I don't see that happening today.
The card is a pain for logging. I have left the meter apart since starting this little side project. I don't have long enough finger nails to reach the card and my fingers are too large. So needle nose pliers.
It makes me wonder if they (UEI) can't produce firmware for the meter, what's the future plans. It's painfully obvious they are unable to test the code they release.
The other great loss of an open source firmware is that UEI has presumably acres of expensive testing, characterization, and calibration equipment they can use to make the meter the best it can be (whether they use it is another matter). An open source firmware would have to rely on the generous effort of people like joeqsmith and others in this thread who have access to similar equipment in order to make the guarantees that make the equipment worth its price. Will this be practical? I guess we will soon see.
The other great loss of an open source firmware is that UEI has presumably acres of expensive testing, characterization, and calibration equipment they can use to make the meter the best it can be (whether they use it is another matter). An open source firmware would have to rely on the generous effort of people like joeqsmith and others in this thread who have access to similar equipment in order to make the guarantees that make the equipment worth its price. Will this be practical? I guess we will soon see.
UEI are seriously missing a trick here - Open Sourcing their code would make this meter into a unique platform, and the extra eyeballs would quickly solve these niggling firmware issues. They're likely worried about clones, but I doubt keeping the source secret will slow the cloners down much - they need to have more confidence in the value of their offering.
My opinion is that it's probably less about clones and more that UEI probably have quite a lot of routines and generic blocks of code in the meter that they use or want to use in forthcoming products and don't want to give those ideas away...…...I couldn't blame them for that. I think the fully open source idea would only have happened if it had been designed that way from the start......but then price point and timing would have been affected.
I wondering if it is because it is a STM32 inside and they're having issues with development + testing. The 121GW development video mentions that it originally a PIC with a choice of a MSP430 as well but UEI changed it for a STM32 later on.
I doubt that it should be that. Software engineering is a generic skill, just like hardware engineering. Apparently many weaknesses in the code relate to structure and organization, which would point to poor design skills.
Here's the behavior in v1.22. It's the same code as v1.02, except the "mode/range change delay" in ohms is now 0, i.e. the meter will perform an autorange on the next sample. This figure was 1 or 2 in v1.02, depending on range. To replace that, there is now an "autorange lock" function called right before the autorange change happens. Rule A: If not in ohms mode, the change is allowed. Rule B: If in ohms mode and changing to a lower range, deny changes for 1 second, then allow all changes. Rule C: If in ohms mode and changing to a higher range, deny the change, then allow one to happen in 1 sample. This leads to some bizarre behavior. If changing from a lower to a higher range, the meter will switch ranges quickly as expected. However, if changing from a higher to a lower range, Rule B above will force the meter to range down as quickly as possible, until either it's at the lowest range or a new ADC measurement arrives. Then it will use each sample to decide to range up, and eventually end up at the desired range. This behavior can easily be demonstrated by starting with open leads and connecting the meter to something like a 100k resistor.
I've done a complete reverse engineering of the v1.02 firmware, which is how I know basically all the information I've posted in this thread.
how.
I pored over my disassembly for anything that could explain this bug but I don't see anything. The fact that it's writing bogus data but at a consistent interval is really weird. As you can see, someone else reported something similar. It's 100% a fixable software issue, except for maybe cosmic rays or damage to the EEPROM. Could you reprogram your meter with the v1.02 firmware and see if the issue is still there? I understand it a little more than v1.22. If you can't reproduce the issue, then I can look at what's changed between the versions for clues. Is there any chance whatsoever you own an ARM SWD CMSIS-DAP programmer?
There is a way to test if the EEPROM became write protected. Set up your experiment, start logging, wait however long, then hold the MEM button to turn off logging. Without turning off the meter, turn the dial to your favorite selection and note what mode is shown on the screen. Now, press the MODE key to change modes, and note what mode is now shown. Wait a few seconds, turn the dial to another selection, and then back to your favorite. If the mode shown is the one before you pressed the MODE key, the EEPROM is going into write protection somehow.
Hot off the presses is the v1.25 release, which claims to fix this behavior, and in fact does.
Also, auto-ranging seems to work fine now, no false intermediate readings any more, and auto ranging speed seems to be the same as before.
DavidDLC and joeqsmith,
concerning the noise, are you referring to data logged to SD card?
The reading on the display is now stable, compared to 1-22, and as far I could determine.
Frank
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine.
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine.
I bought the meter out of curiosity, and because it might have some useful features.
I have not had time to give it a comprehensive evaluation, but I have decided for now that I don't trust any of the resistance ranges.
So I for one don't think the meter is "fine". So far, it passes as a curiosity, but not as a working tool. For a working tool I trust my Brymen meters.
In my case, I am always referring to the data collected on the SD card. I have no desire to watch the LCD for 40 minutes and try to manually pick out any sort of trend.
Again, keep in mind this is not the same hardware you are testing. I have damaged the meter three times and have changed some of the hardware in an attempt to make it more robust. I have also completely realigned the meter. Maybe there is some other difference.
I would expect with your setup you should easily replicate anything I show. If you are seeing something different there must be something we have not accounted for.
I did make a short video for you. I start out with the modified 1.02 firmware. I just let it run for a few minutes. You can see the drift as the meter warms up. Again, I assume this is caused by the Hycon chip they chose. I always found it strange they used that part after Dave's review of the Keysight meter. Anyway, I then reprogrammed the latest firmware and let the meter run for 15 minutes or so to stabilize. I then captured some video while it continued to run for several more minutes.
One point of interest is that I understood the kickstart to have roughly 2000 participants and that the vast majority have been delivered. I assume very few people have firmware 1.0 installed. Your recent post where you used the 1.9M was really brought my attention to this potential problem. It does not seem to be common. So, it's possible that people are just trusting the meter is fine. Perhaps they really have no need for a higher class meter and bought it for other reasons. Another possibility is they are not seeing the problem. If it's the later, then why.
I wondering if it is because it is a STM32 inside and they're having issues with development + testing. The 121GW development video mentions that it originally a PIC with a choice of a MSP430 as well but UEI changed it for a STM32 later on.