geoff@sarah-xen:~/Projects/121GW$ arm-none-eabi-objdump -D -b binary -marm -Mforce-thumb EEVBlog.bin | head -n 21
EEVBlog.bin: file format binary
Disassembly of section .data:
00000000 <.data>:
0: 4b78 ldr r3, [pc, #480] ; (0x1e4)
2: 2000 movs r0, #0
4: 2879 cmp r0, #121 ; 0x79
6: 0802 lsrs r2, r0, #32
8: 0e35 lsrs r5, r6, #24
a: 0802 lsrs r2, r0, #32
c: 0e37 lsrs r7, r6, #24
e: 0802 lsrs r2, r0, #32
10: 0e39 lsrs r1, r7, #24
12: 0802 lsrs r2, r0, #32
14: 0e3b lsrs r3, r7, #24
16: 0802 lsrs r2, r0, #32
18: 0e3d lsrs r5, r7, #24
1a: 0802 lsrs r2, r0, #32
...
0x20004b78 - The main stack pointer
0x08022879 - The reset vector (this is thumb, so the address is actually -1)
... etc
That is good news!
Since we now have a FW thread, my 121 came with v1.01 and I've seen references to 1.02? Considering the FW resides on the SDcard I guess someone with a 1.02 could post it for us on 1.01 to upgrade.
Indeed, mine has 1.01 on it, it would be interesting to compare the two.
Gnif, from what you currently know, does it look like we can add our own firmware using the existing bootloader and binary update mechanism? In other words, can we load new experimental firmware and easily return to the official firmware?
I am just hoping that the IAP Binary update mode (Turn on with HOLD and MEM pressed) is completely in the bootloader. It would make sense for this to be so.
If it is, we should be able to switch between the official firmware and experimental with the need of JTAG.
Dave, could you provide us with the pinout of the jtag connector, so I could try to read out the bootloader and the option byte values with my ST-Link dongle?
Here is the schematic which may helpThe CN2 connector seems to be a debug interface for the BLE module.
David2 is working on seeing what we can provide in terms of documentation to help people who want to write their own firmware.
http://www.eevblog.com/files/121GW%20EEVBlog%20Circuit%20diagram.pdf (http://www.eevblog.com/files/121GW%20EEVBlog%20Circuit%20diagram.pdf)
I hooked up the 121gw to my st-link and seem to be able to dump the flash.
# 121gw.cfg openocd config
source [find interface/stlink-v2.cfg]
set WORKAREASIZE 0x4000
source [find target/stm32lx_dual_bank.cfg]
# use software reset
reset_config none
init
reset halt
flash probe 0
/ 1 Vcc -------- 8 3.3V \
| 2 Reset ------ NC |
121gw - + 3 TMS/SWDIO -- 4 SWDIO + ST-Link-v2 mini
CN3 | 4 TCK/SWCLK -- 2 SWCLK |
\ 5 VSS -------- 6 GND /
sudo openocd -f 121gw.cfg
telnet localhost 4444
p.s. - perhaps somebody finds the source for this firmware on a USB-stick in the dumpster (next to a 500k$ scope or something ;-)
If so... it would be a very nice move to upload it here...
I hooked up the 121gw to my st-link and seem to be able to dump the flash.
I also tried to read out the option bytes from the cpu.
I also tried to read out the option bytes from the cpu.
By the way, your meter has version 1.02, correct? That's what the dump seemed to indicate.
I also tried to read out the option bytes from the cpu.
I'm not sure about these if I did it right. I'll look into them tomorrow with the datasheet to see if they make sense.
This is my first encounter with STM32, I just used AVRs up to now. I'll have to do a lot of reading.
And also a lot of thanks to Dave and UEi for not setting the readout protection on the STM32! I sincerely hope they don't regret it.
I've set up a GitHub repository for future development and information, located here (https://github.com/tpwrules/121gw-re). The wiki on it is free to edit for anyone with a GitHub account. I plan to upload my IDA database tomorrow or so and work on documenting what I've found on the wiki. If you would like to help, please check out the Questions (https://github.com/tpwrules/121gw-re/wiki/Questions) page. I haven't got my meter yet so I can't answer them.Looked at your github and am really amazed at all you have figured out and documented. Looks better documented than most new code!
I've got pretty much the entire thing documented in terms of variables and functions. Some algorithms I don't know yet and would like help with. But there's a hell of a lot of information we can use to start our own firmware, which I also hope to do on perhaps a bit of a longer timescale.
And as I mentioned previously, I have some firmwares edited with bugfixes, if anyone would like to test them out?
Looked at your github and am really amazed at all you have figured out and documented. Looks better documented than most new code!
1. Looks like C++ because I see the word 'class' around a lot. Is this why you commented 'everything is global' ie. the decompiler put all the class object data in one big pile?
2. Since you have modified firmware already (and tested by Dave somewhere) does that mean you were able to recompile the code. I don't see how that could happen without all the object definitions, headers ect. Could you illuminate further. Is the binary just patched ? I didn't see any C++ code.
For now, I just hand-assembled ARM instructions and patched the binary. It's a lot easier because the compiler wasn't very efficient and so space can easily be made for new code.
For now, I just hand-assembled ARM instructions and patched the binary. It's a lot easier because the compiler wasn't very efficient and so space can easily be made for new code.
It's been a lot of years since I've done that - and it was on a systems module on an IBM mainframe.
...|O I'm not sure where I got that from either, probably a brain fart although the vapors are still hanging, sorry.1. Looks like C++ because I see the word 'class' around a lot. Is this why you commented 'everything is global' ie. the decompiler put all the class object data in one big pile?
Um I'm not sure where you've seen the word 'class'. I did a search of the repo and could not find that word anywhere. What I mean by 'everything is global' is that there are several functions (e.g. meas_ohms_calc_50M_offset(digits, factor)) where all the intermediate variables are stored as globals and only read/written in that function. This makes no sense and I'm pretty sure it can't be caused by the compiler.
/* This file has been generated by the Hex-Rays decompiler.
Copyright (c) 2007-2014 Hex-Rays <info@hex-rays.com>
Detected compiler: GNU C++
*/
Sorry, I'm a bit late to the party. Is there a version of decompiled sources that could be modified a compiled? Or people directly modify binary code?
arm-none-eabi-gcc -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard --specs=nosys.specs ./EEVBlog.c
(.text+0x44): undefined reference to `main'
/tmp/ccgtjcep.o: In function `function_117dc':
EEVBlog.c:(.text+0x21f0a): undefined reference to `unknown_117bc'
/tmp/ccgtjcep.o: In function `function_158ec':
EEVBlog.c:(.text+0x294c4): undefined reference to `unknown_ff696e8c'
EEVBlog.c:(.text+0x299dc): undefined reference to `unknown_ff696ed4'
EEVBlog.c:(.text+0x299e4): undefined reference to `unknown_ff397cfc'
/tmp/ccgtjcep.o: In function `function_16ac0':
EEVBlog.c:(.text+0x367d6): undefined reference to `unknown_fff9a9c0'
EEVBlog.c:(.text+0x36812): undefined reference to `unknown_fff982e8'
/tmp/ccgtjcep.o: In function `function_1a4e8':
EEVBlog.c:(.text+0x43928): undefined reference to `unknown_fff9b7bc'
/tmp/ccgtjcep.o: In function `function_1b872':
EEVBlog.c:(.text+0x48054): undefined reference to `unknown_110c4c'
EEVBlog.c:(.text+0x48060): undefined reference to `unknown_ffe3ac50'
EEVBlog.c:(.text+0x48068): undefined reference to `unknown_fff71c54'
EEVBlog.c:(.text+0x48074): undefined reference to `unknown_ff6b4c58'
EEVBlog.c:(.text+0x4807c): undefined reference to `unknown_ff801c5c'
EEVBlog.c:(.text+0x4809e): undefined reference to `unknown_fff59c60'
/tmp/ccgtjcep.o: In function `function_1beee':
EEVBlog.c:(.text+0x48934): undefined reference to `unknown_1bf4c'
collect2: error: ld returned 1 exit status
Escape character is '^]'.
Open On-Chip Debugger
> dump_image dump.bin 0x08000000 0x1ffff
dumped 131071 bytes in 6.293624s (20.338 KiB/s)
Does anyone know if there has been an official firmware update released that fixes the slow auto range we can download and use to update our multimeters?
It would be nice if there was a support web page that we could go to for news and updates on current issues being worked on and official updates, instructions, info, etc. Does a page like this exist yet?
But now, there's also an IDE template already set up (https://github.com/tpwrules/121gw-template) for you to write your own firmware. Instructions for setting it up are in the repository README. The best part is that you don't even need a programmer!
But now, there's also an IDE template already set up (https://github.com/tpwrules/121gw-template) for you to write your own firmware. Instructions for setting it up are in the repository README. The best part is that you don't even need a programmer!
Have you decided on a license for your code? FYI, most of the newer ST code is under a 3-clause BSD, but the SD card code in Src/ is not.
With a GPL license, UEI and other companies can still use the code. However, they need to share their improvements to the code, which is just fair. Therefore, I strongly support the use of a GPL license for this.If for internal reasons which is their business, UEi just cannot GPL code, is it better if they can make use of our code and so everybody gets our improvements, plus their secret source, or is it better that they ignore our code.
Personally, as someone who's been writing both opens-source and commercial software for a couple of decades now, I use GPL and accept only code with a copyright assignment to me when I'm interested in preserving my own ability to exploit the code commercially at a later date.If the GPL license is used, this is the exact model I would like to see. Almost certainly, one person will be responsible for making this code into a quality reality and they deserve to have the copyright assignment. It would mean that they would be able to offer companies an alternate paid commercial license if that is what the companies need.
I'd still be in favour of a copyleft license. Maybe LGPL is a good compromise?It could be used, but given that static linking is used:
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.UEI (or anyone else using the code) would be forced to distribute the objects from its application (and possibly any special tool needed for the relinking, but not 100% sure).
On the subject of firmware, has there been any official/stable release of firmware beyond 1.01? Forgive me if details have been posted elsewhere.
I wonder what's new in 1.22.
https://www.eevblog.com/wp-content/plugins/download-attachments/includes/download.php?id=13423 (https://www.eevblog.com/wp-content/plugins/download-attachments/includes/download.php?id=13423)
Any chance we will see the images for the BLE112 released as well?
v1.25 is out and new manual with changelog...
https://www.eevblog.com/product/121gw/ (https://www.eevblog.com/product/121gw/)
No problem for me. Did you rename the file to EEVBlog.bin?
Alexander.
v1.26 is now on the website for download. We have not tried it yet, but UEi have said that it now logs the displayed data instead of the bargraph data. There should now be no noise on the logged data as per previous versions. Please try it and report.
Have anyone decoded the binary file with the calibration data?
Alexander.
The offset number is directly added to the adc result? Is the function that involves the values read form the adc, the calibration data and the displayed number known?
I was wondering if it is possible to recalibrate offset by hand editing the calibration data. Because someone (Dr. Frank) mentioned that someone might have to complete and the full scale gain calibration in order the meter to save and accept the zero offset data. But this mean specialized equipment
I installed v1.52 , so far I see a big improvement in reducing the 50Hz noise in resistance mode , now when measuring Mohm resistors you can touch the probes and cables .
The beep sound in diode mode is still laggy ...
I installed v1.52 , so far I see a big improvement in reducing the 50Hz noise in resistance mode , now when measuring Mohm resistors you can touch the probes and cables .
The beep sound in diode mode is still laggy ...
Did it report 1.53 when when you first started it? I think resistance resolution seems faster. I don't think that beep is supposed to happen with all diodes. Beep happens only when resistance is very low. It's responding to apparent continuity.
Yes of course it display 1.53 ...
The beep when you are shorting the probes is laggy , so when measuring a shorted transistor or diode you have to wait a moment ... not good at all . Every other multimeter is much responsive .
In continuity mode the beep is very fast responding , so I don't see any reason why in diode mode is laggy .
Every decent multimeter has the beep in diode mode ... and is fast , feature or not :D
If you really work with the multimeter repairing something you will know why .
I agree.Every decent multimeter has the beep in diode mode ... and is fast , feature or not :D
If you really work with the multimeter repairing something you will know why .
I have repaired a lot of things. I have repaired many things for many weekly pay checks. I like numbers a lot. I like to see that the device has the numbers it should. A beep is simply low resistance. Do you get a reassuring "unbeep" when you measure in the opposite polarity?
If it doesn't say it on the tin (and it doesn't in this case) then you have no right to expect it. What I have learned is to read the manual before I make a purchase. If it says "it beeps for diodes" on some other device, I would want to know EXACTLY what constitutes "beep worthy". What would a diode beep mean to me diagnostically?
Can you offer a link to a multi-meter online manual (or spec) that satisfies your diode beeping needs? I'd be interested to see how it is specified.
A delayed beep is annoying , or is fast or not at all ... Fluke behavior is what should be expected from a decent multimeter .
When you work on a board you want to find fast the shorted semiconductors , you don't have time dicking around waiting for the meter ... and you don't want to switch all the time to continuity mode and back because is faster or has the beep :-\.
For those who don't like the beep should be very easy to add a way to disable/enable it .
No beep above 0.85 ish volts
Short beep from 0.84 to 0.10 ish volts
Below 0.1 volts, a continuous beep.
Maybe I wasn't clear enough for you , a laggy beep ( 0,5sec or more ) is not something good or normal . ...
And for sure this can be corrected in firmware with a little effort ... just one more small issue on the list
Then how is possible to be fast in continuity mode ? It's the same ADC . Please stop the nonsense and watch your own business .
A delayed beep is annoying , or is fast or not at all ... Fluke behavior is what should be expected from a decent multimeter .
When you work on a board you want to find fast the shorted semiconductors , you don't have time dicking around waiting for the meter ... and you don't want to switch all the time to continuity mode and back because is faster or has the beep :-\.
For those who don't like the beep should be very easy to add a way to disable/enable it .
Just received my 121GW it has v1.54 FW - just for info - I have no idea what have been changed in the FWOr perhaps you have 1.53 going by the recent 1.52 release reporting as 1.53 :D :P.
BTW, I wonder if someone wants to actually write some firmware for it.Did you actually run your own code on the 121GW? And if so can you revert back to stock firmware afterwards?
I recently tried ChibiOS and made a very trivial hello-world interface using threads+queues. So far I like it much more than CubeMX. I may want to try to write firmware using it, threads and C++. If someone wants to join let me know.
Did you actually run your own code on the 121GW? And if so can you revert back to stock firmware afterwards?
If that's possible, and you could provide some instructions to do so, I'll bet it would just be a matter of time before others hop on.
Oh great! I totally missed that one (here: https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-firmware-details/msg1418335/#msg1418335 (https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-firmware-details/msg1418335/#msg1418335))
Well, actually, this thread used to be about development :). Just read a few pages back, Mr. @tpw_rules did a great job at reverse engineering firmware, dumping calibration data, and even prepared a demo firmware with an lcd driver using cubemx. I tried to continue development, but cubemx and C is just not my thing.
I hope enthusiasm is still there :)I hope improvements are still there >:D
Firmware version 1.57 at https://www.eevblog.com/product/121gw/ (https://www.eevblog.com/product/121gw/)
And I hadn't even heard of ChibiOS. Can you share what you have so far?
is there an improvement of the slow reading of resistance?
What versions of firmware were you testing? What were the values reported for that version? How long did you allow the 121 to settle?
Hi joeqsmith,
to make that more clear: Normaly I do not use a multimeter for measuring low pF values, I have other instruments for this.
But that is not the point. Also the drift is not my major problem.
The problem is: I Connect a capacitor in the pF range to my meter, switch it on and it shows (mostly) the correct value at the first try. Then I switch it off and on again while not touching anything except the switch and now I get a totally different value. Do the same again and I get another different value. When I switch off the meter again, wait some time, switch it on I get the correct value ....and so on...
That is a very strange behavior. I don't know whether this issue was from begin on or not, because I had never tried to measure a capacitor in the low pF range. I noticed this first time after you have mentioned the higher resolution in the capacitor mode and I checked this to look how the 121GW now performs compared with my other meters.
Just for fun.. I did not expect such a crazy behavior.
First I thougt that is a firmware bug of rev. 1.57, but it seems not so.
Your meter seems not affected from this issue as I can see in your video. But CDaniel seems to have the same problem like me.
BTW: Try also the mode button, does this also not affect your meter?
Quote... gave correct reading but a short time later the reading started to display approx 82 pF instead.
If you watch that short clip I made, do you feel I was not waiting long enough?
About three hours now at 27C. The 121GW proto still has not budged off 16pF. Looks like 27C was too low of a setpoint. The camera, meter and fan are more than what all that insulation will carry away.
The one problem I have noticed is how far off the meters internal temperature is. About 10C low. It may have always been this far off or maybe they changed the thermistor. The schematics are the same. There appears to be no way to align it outside of changing R38. May be nice to have a way to trim it as part of the alignment.
Hi Joe can I ask a very beginner question? Do you use the 2 x BNC to 4mm connectors to give a more stable reading of the cap under test and eliminate the capacitance that would be in the leads if you used them? Sorry for the dumb question but I would like to learn these things. ???I started out with an old VTVM and later a Radio Shack analog meter.
The leads can interact with themselves and their surrounding environment. Looking at extreme values of anything makes the setup more critical. In short, I would say stability is a good word.
If you have a way to take some high resolution pictures of the switch contacts, it would be interesting to see how they are wearing.I actually had an occasion to have the switch out and not having any means to take a high res pic. I tried to get the best with the crummy camera I had to hand. See image attached.
I got mine around a week ago from Welectron too but it's only been used a few times since so the contacts will still probably be "as new" so hardly worth showing just yet. I'll wait till I've had it for 6 months or so then i'll open it up and post a few photos.
I got mine around a week ago from Welectron too but it's only been used a few times since so the contacts will still probably be "as new" so hardly worth showing just yet. I'll wait till I've had it for 6 months or so then i'll open it up and post a few photos.
Might be worth it to open it now and grab some pics to compare down the road. Obviously, should still look new with no wear, but you don't really know without a peek.
My meter 180701918 from WelectronSo they went from all single dimples to double dimples and now they are back to single dimples?? It looks like the dimples are showing some wear on yours as well as the pads. Are we starting to see some copper exposed on the pads?
My meter 180701918 from WelectronSo they went from all single dimples to double dimples and now they are back to single dimples?? It looks like the dimples are showing some wear on yours as well as the pads. Are we starting to see some copper exposed on the pads?
That is "black dirt " , after a wipe with alcohol looks like new , no sign of wear on pads .
But I didn't work with it much , as we know has "some" bugs and I don't like this ...
I'm more worried about this issues ...
I would like to see a comparation with other multimeters using HY3131 , Keysight U1282A for example ...
I have Keysight U1273A...does that have HY3131?
I upgraded the 121GW regularly and now from 1.51 to 1.57 it's done. It stuck for 20 minutes without any progress. So I did need to switch it off (sorry). Wanting to go back to 1.51 is to no avail and it seems bricked now. What should I do? What should I check? The download option is still available though.
I have Keysight U1273A...does that have HY3131?
Yes , it should have HY3131 , but I think you can easily take a peek inside to confirm .
Ah ok, I can do that no probs at all but you'll have to just take my word for the results as I don't have any recording gear to make a decent video of the outcome. :(
Ah ok, I can do that no probs at all but you'll have to just take my word for the results as I don't have any recording gear to make a decent video of the outcome. :(
Terry01 , we don't need proofs , user observations and feeling is enough .
With a power supply adjust the voltage up and down to see when is switching ranges .
With a power supply adjust the voltage up and down to see when is switching ranges .
To be clear here:
Step 1: Use an adjustable power supply that can at least go from 3V to 7V. Start at 3V or so and increase the voltage until you see the range change on the meter (watch the units and decimal point). Make a note of the voltage when this happens.
Step 2: Continuing on from Step 1 - From the 7V level, decrease the voltage until you see the range change. Make a note of this voltage.
The difference between these two voltages is the "hysteresis". This is a designed behaviour meant to stop the frequent range changes you would get from a meter without this feature when a measured voltage fluctuates either side of the range switching point.
The issue is the magnitude of this hysteresis. If it's too big then you could have a transient (for example) trigger a switch to a higher range and when the voltage settles it is under that "range up" switching point, but not below the "range down" switching point. As well as being visually distracting, it also means you lose a whole digit of resolution.
This behaviour and the issues associated with it apply to all measurements and ranges - whether voltage, current, resistance or whatever. I just used an easily achievable example for voltage.
If the cover is not in place then the batteries are not securely in place. If the battery is interrupted for even a moment while loading, that would explain your issue. Remove the cover and check how well the batteries stay in. You will see what I mean.
I had a close call on that myself once. Keep the cover on when installing new firmware.
Good idea. I ran the meter a fair amount with the back cover removed in order to have access to the SD card and have not had a problem with them falling out but I normally have the meter face up and flat down on the table. If the battery is pulled, I would expect the meter to have no problems. I assume the boot loader runs a CRC on the application area before trying to run it. If it fails, it should just wait for the new image to be loaded. It sounds like there is a fear that the meter actually has been bricked doing this. So, do we know if this is actually a problem or not?
I do not know this no. What I could do is start to retest and check and fiddle around with other FW updates with the risk that I eventually brick it. So mwahhhh not sure. Also my selector knob is still quite crusty in terms of rotation and not up to standard for a 239.00 € item IMHO. In other words the shim solution did fix one thing and made something else worse. I do like the meters form factor, options, features though and I believe we should continue to develop on this going to version 2.0 in 2019 or so.
Is anyone else having the problem I had yesterday with their meter not measuring in mA range? My 121GW was measuring 87mA in the A range but when I changed range to mA it would not measure. It kept showing OFL. :-\
If anyone has bricked one from upgrading the firmware, chime in.
Is anyone else having the problem I had yesterday with their meter not measuring in mA range? My 121GW was measuring 87mA in the A range but when I changed range to mA it would not measure. It kept showing OFL. :-\
Did you change the current socket on the meter?
Yes, just did it again and also with my 87v too. The Fluke did it no probs and the 121GW showed OFL. I used a half-"ish" used 9v battery and a 4 ohm power resister as a load.
Well there's why it won't measure 90 mA in the mA range then! :-DD
Well there's why it won't measure 90 mA in the mA range then! :-DD
That is part of the "Low burden voltage", the high mA range is moved to the A input.
It is not that the meter is missing a range, it has one or two current ranges more than most other multimeters. It has 7 current ranges, typically a meters has 5 or 6 current ranges.
Cool, thanks for the information. I would never have guessed that as there is no indication on the meter around the jacks and I haven't read the manual.
Cool, thanks for the information. I would never have guessed that as there is no indication on the meter around the jacks and I haven't read the manual.
There is a indication, the A terminal is marked "A 500mA", because it is both ampere and 500mA range.
Cool, thanks for the information. I would never have guessed that as there is no indication on the meter around the jacks and I haven't read the manual.
There is a indication, the A terminal is marked "A 500mA", because it is both ampere and 500mA range.
I agree that 500mA is clearly marked on the A jack but can't see how that would indicate the mA jack is only good for 55mA.
I also see no one else has told me that and I have made a couple of posts about trying to feed 90mA into the mA jack so it can't be that obvious or well know or someone else would have said.
Cool, thanks for the information. I would never have guessed that as there is no indication on the meter around the jacks and I haven't read the manual.
There is a indication, the A terminal is marked "A 500mA", because it is both ampere and 500mA range.
I agree that 500mA is clearly marked on the A jack but can't see how that would indicate the mA jack is only good for 55mA.
I also see no one else has told me that and I have made a couple of posts about trying to feed 90mA into the mA jack so it can't be that obvious or well know or someone else would have said.
The "OFL" that the meter displayed means exactly that you have exceeded the current limit in the selected range. What else could OFL mean in an amps setting? That was a good indication, but you incorrectly assumed the meter was lying to you.
Yes I agree. I incorrectly assumed the meter was lying to me but lets be clear the meter is hardly 100% trust worthy is it? There are loads of posts of the meter lying or not doing what it's supposed to or whatever. I can hardly be faulted for thinking it was just something else wrong with it.
It's clearly (at least to me) stated in the manual. …
It's clearly (at least to me) stated in the manual. …
Where in the manual is it clearly stated? I just searched the latest manual (revised 04 Dec. 2018) for things like "55" and "current" and had no returns relating to a 55 mA maximum.
Yes I agree. I incorrectly assumed the meter was lying to me but lets be clear the meter is hardly 100% trust worthy is it? There are loads of posts of the meter lying or not doing what it's supposed to or whatever. I can hardly be faulted for thinking it was just something else wrong with it.
I have not seen that, in some extreme cases the meter shows wrong values, in normal usage it may be slow or it may be unstable, but it do not show wrong values.
This is something you have to know about every meter you use, where is it correct and stable, where may it show wrong value and where is it wrong most of the time. I do not remember it for all my meters, but if the value is outside expected values I check with another (or more, even a scope) meter.
You say it shows wrong values then it doesn't show wrong values in the same sentence. You say it is slow or unstable... this is not wrong values??
I did check it with another meter, 2 in fact U1273a and 87v.
next..... :horse: :horse: :horse: :horse:
On this we agree :)
I like to use all my meters.
Unreliable is just a word , at the end of the day the firmware is at least very "unfinished" after 1 year in production ...
Even the sensitivity to noise could be just software related ...
...Thought you'd figure it out. Didn't want to make you feel like an idiot :D
I also see no one else has told me that and I have made a couple of posts about trying to feed 90mA into the mA jack so it can't be that obvious or well know or someone else would have said.
For those interested, we (Kane & EEVblog) are now setting up a shared git (not public) for firmware version control with the intention that we (EEVblog) now have full visibility on all firmware changes, and in time will be able to make our own changes and compile ourselves etc.
At present we have almost no real visibility into their internal firmware environment.
The hardware too requires your input and direction toward meeting quality and performance requirements. If UEI want to carry on with 700 out of spec PCBs requiring shims then maybe they should put their brand on it. IMHO get quality into the meters that carry your branding and be prepared for a lot more sales.
The hardware too requires your input and direction toward meeting quality and performance requirements. If UEI want to carry on with 700 out of spec PCBs requiring shims then maybe they should put their brand on it. IMHO get quality into the meters that carry your branding and be prepared for a lot more sales.
I've heard you a dozen times now, no need to continue to repeat it.
... how much does the PCB cost as a percentage of the bill?
I'm participating in the forum and if you dont like my suggestions thats fine, but I dont think I'm repeating myself as much as many others do around here.
For those interested, we (Kane & EEVblog) are now setting up a shared git (not public) for firmware version control with the intention that we (EEVblog) now have full visibility on all firmware changes, and in time will be able to make our own changes and compile ourselves etc.
At present we have almost no real visibility into their internal firmware environment.
If anyone has bricked one from upgrading the firmware, chime in.
Uhm, it's a standard stm32 mcu, can be reprogrammed via the swd intarface using a $5 programmer (but header is not soldered). I did brick it many times and was able to restore the original firmware and bootloader. Just be sure to dump the calibration table, I lost mine during experiments.
Good to know that it can be bricked this way. Saves me the time of checking it. I have not looked into programming the meter and wouldn't have expected $5 would get me setup. Could you please provide a link to the tools and programmer I would need? Even just part numbers and the manufactures would be great.
Concerning stm32 programming, any generic "st-link v2" adapter will do. I have similar to this one: https://www.ebay.com/itm/ST-Link-V2-Programming-Unit-mini-STM8-STM32-Emulator-Downloader-M89-New/401088363326?hash=item5d62babb3e:rk:1:pf:0 (https://www.ebay.com/itm/ST-Link-V2-Programming-Unit-mini-STM8-STM32-Emulator-Downloader-M89-New/401088363326?hash=item5d62babb3e:rk:1:pf:0) . Also any stm32 development board will work as they have st-link interface on the board.
For those interested, we (Kane & EEVblog) are now setting up a shared git (not public) for firmware version control with the intention that we (EEVblog) now have full visibility on all firmware changes, and in time will be able to make our own changes and compile ourselves etc.
At present we have almost no real visibility into their internal firmware environment.
Thats great news Dave!
This meter carries your name and brand, (EEVBlog) so its good that you are in the loop with the development of the firmware. It seems to me that with responsible management this meter could develop to its true potential.
The hardware too requires your input and direction toward meeting quality and performance requirements. If UEI want to carry on with 700 out of spec PCBs requiring shims then maybe they should put their brand on it. IMHO get quality into the meters that carry your branding and be prepared for a lot more sales.
I will tell you that the thing I have never understood when looking at the prototype is why the board thickness will matter. The bosses that the board is mounted to are molded to the front of the case. The mechanical loop is all on the switch side of the PCB. (Added cutaway showing the stackup)
We do know that the original contacts have changed a few times, even after the kickstart. We also know the knob was loose. I assume the shim was added to increase the contact force (which making the board thicker will not effect).
Are they suggesting that the PCB is actually deflecting (bowed) in the area of the switch because it is so thin? That would seem easy enough to measure. Maybe the case changed and somehow the board is mounted differently that causes the thickness to matter. Looking at various pictures from the kickstart, this doesn't seem to be the case. If the board is not deflecting, then it seems more of a case design problem (case meaning the plastic parts).
Any MEs here that care to take a crack at some measurements?
It doesn't say no where about the 55mA limit on the mA jack!
...Thought you'd figure it out. Didn't want to make you feel like an idiot :D
I also see no one else has told me that and I have made a couple of posts about trying to feed 90mA into the mA jack so it can't be that obvious or well know or someone else would have said.
Don't feel bad though, Iv'e done the same thing a few times but usually RTFM. |O
LOL... Nice one! :)
I still haven't read the manual but someone posted saying they searched the newest revision of the manual and it doesn't mention it anywhere.
I haven't checked so I don't know if it says so or not, but i'll stick with the guy who says "it doesn't mention it anywhere", makes me feel a little less stupid!
Ha Ha! :-+
So I went and read the latest updated manual for the 121GW today, dated 4th Dec 2018.
https://www.eevblog.com/wp-content/plugins/download-attachments/includes/download.php?id=19232 (https://www.eevblog.com/wp-content/plugins/download-attachments/includes/download.php?id=19232)
It doesn't say no where about the 55mA limit on the mA jack! It does however clearly say you should stick to alkaline and give lithium a miss.
I found it to be a good well set out manual and as someone who isn't so well experienced with these things as others here on the forum, I found it very easy to understand and get to grips with.
This meter really does have all the bells and whistles if you take the time to learn how to use it "properly" and understand all the features.
I did think "the meter" had a couple problems at first so that kind of put me off it. Turns out RTFM is very important indeed for this meter!
I stand corrected and the lithium mistake was mine but i still think the 55mA thing should be pointed out more obvious somewhere in the manual or even on the meter it's self as it is a rather neat niche function.
I will make the changes needed as set out in the manual and give it another chance as it seems one of the main the things I thought were wrong with the meter were actually my being naïve or mistake and not the meter.
I'll report back soon now I know how to operate it properly! I have a feeling I will be referring back to the manual a few times! :)
Now it is pointed out though I see it is a 50mA limit and not a "55mA limit" as someone else stated to start this whole thing.
A question about logging:
Is it possible to log both frequency and voltage simultaneously in ac mode and automatic logging?
START 2018/12/10 10 21 24
ID 170800121
INTERVAL 10 sec
MAIN SUB-1 SUB-2 Remark
No. Func. Value Unit Func. Value Unit Func. Value Unit
1 ACV 0.0046 V FREQ. 0 Hz
2 ACV 0.0114 V FREQ. 0 Hz
3 ACV 0.0122 V FREQ. 0 Hz
4 ACV 0.027 V FREQ. 0 Hz
5 ACV 0.0413 V FREQ. 0 Hz
6 ACV 0.2659 V FREQ. 59.996 Hz
7 ACV 0.2724 V FREQ. 59.999 Hz
8 ACV 0.0245 V FREQ. 0 Hz
MAX 7 ACV 0.2724 V
MIN 1 ACV 0.0046 V
A question about logging:
Is it possible to log both frequency and voltage simultaneously in ac mode and automatic logging?
yesCode: [Select]START 2018/12/10 10 21 24
ID 170800121
INTERVAL 10 sec
MAIN SUB-1 SUB-2 Remark
No. Func. Value Unit Func. Value Unit Func. Value Unit
1 ACV 0.0046 V FREQ. 0 Hz
2 ACV 0.0114 V FREQ. 0 Hz
3 ACV 0.0122 V FREQ. 0 Hz
4 ACV 0.027 V FREQ. 0 Hz
5 ACV 0.0413 V FREQ. 0 Hz
6 ACV 0.2659 V FREQ. 59.996 Hz
7 ACV 0.2724 V FREQ. 59.999 Hz
8 ACV 0.0245 V FREQ. 0 Hz
MAX 7 ACV 0.2724 V
MIN 1 ACV 0.0046 V
You may have a look on this concerning burden voltage:
https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg2213955/#msg2213955 (https://www.eevblog.com/forum/testgear/eevblog-121gw-discussion-thread/msg2213955/#msg2213955)
Anyone extensively tested 1.58 beta please? Any drawbacks?
Is the firmware source code available?No, and it will likely never be. It contains proprietary content from UEI - and they are somewhat coy about sharing it.
Are the comments inside good?No idea.
What development environment is best?
Is the firmware source code available?No, and it will likely never be. It contains proprietary content from UEI - and they are somewhat coy about sharing it.QuoteAre the comments inside good?No idea.
What development environment is best?
When did "Hackable" imply complete information on what is to be hacked?Point taken, of course.
Don't confuse user programmable (it isn't) with hackable (which most things actually are, this one more than others).
What I'm looking to do is actually to be able to automate measurements.
I e be able to read data from the unit and possibly "press some buttons" from say a python program.
Maybe something like this can be done via bluetooth?
Hacking (or modifying) the software can interfere with reliability as well. I think the real point here is that you need to acquire something other than a hand held DVM.
I just bought the 121GW from Welectron here in Europe and it came with firmware 1.61 so the 1.58 is already "old"
I just bought the 121GW from Welectron here in Europe and it came with firmware 1.61 so the 1.58 is already "old"On the SD card you should finde a file called EEVBlog.bin that you may upload here for us. This is the firmware file.
I just bought the 121GW from Welectron here in Europe and it came with firmware 1.61 so the 1.58 is already "old"Interesting!
I bought a new 121GW today and I have Firmware u-2.01 installed.
The manufacturer.Correct.
Dave has a copy of the source filesDoes he? I may have missed something, but I didn't think he did. As I understand it, the manufacturer has some "secret sauce" code that they are not willing to share (which, even if frustrating, is completely understandable).
but I don't think he will ever something with the code. I guess this is probably far too much work.Having the source code is only one part of the puzzle. You need to have a compatible development environment that has been configured appropriately before you start. Then you would need full details of every element of the hardware being controlled before even being able to code anything. Add to that the experience required to write effective and efficient code for this type of environment as well as dealing with idiosyncrasies of the component parts and you have quite the challenge.
.... has anyone created a hacked FW?We have had some enterprising souls hack the binary from earlier versions - but I think the latest official manufacturer version makes them obsolete.
I think too he mentioned he has sources.
I tried to write my own firmware, but failed due to underestimation of effort and lack of knowledge of stm32. I thought I'd write a basic firmware in a few evenings, but failed even to get LCD working :/. Then I realized that I don't know how to control the main IC, and its datasheet was uncomfortably big.... So, many things it seems need to be implemented from scratch, it's not like an arduino-style development when all it takes is just install libraries and bind them all together in main().
"I just bought the 121GW from Welectron here in Europe and it came with firmware 1.61 so the 1.58 is already "old""
I just bought mine (June 2019) directly from Dave, and it is running 1.57 Firmware. I find the resistance mode very sluggish. Maybe new firmwar would fix that? I need to locate firmware and then I guess go buy a micro-sd card.
I see firmware V2.02 is available!And a new manual update.
https://www.eevblog.com/product/121gw/ (https://www.eevblog.com/product/121gw/)
Since v2.0 the SD card logging stops working properly after a while. I haven't tried that in 2.02. The last time I recorded voltage for 19.5-20 hours with interval 2 seconds, fixed range. I monitored the display - the battery dropped gradually with cut off at about 10.8V. At about 19.5 hours the voltage was 11. At 19.0 hours - 11.8V. However since about 2h 40min (about 4800 recods) the value in csv is 12.529V +/- 3 LSD. The last digit keeps moving around like it's recording real data, but it has nothing to do with what's on the display.
I've reported this before, but I don't see it in firmware change log. Is this fixed? Does anyone else have similar problems?
Edit: Also since v2.0 the multimeter will occasionally freeze when I start logging - switching ranges, pressing buttons have no effect, until I turn it off.
P.S. Yes, I know that bluetooth exists. I don't want to rely on wireless for long term logging.
Can anyone who has updated to v 2.2 say how long to expect the process to remain in the "douun" mode?I am assuming you mean firmware version 2.02?
Thanks, Scottjd, yes, I followed the instructions to a Tee, but it stayed in DOUUN mode for at least 6 hours. It started at 9 PM, but I couldn't sleep well, so up at 3 am to check. No change, still DOUUN, except the display contrast was changing as the batteries dropped from ~ 1.54 v at the start, to 1.47.Can anyone who has updated to v 2.2 say how long to expect the process to remain in the "douun" mode?I am assuming you mean firmware version 2.02?
First make sure the new firmware file on the SD card is named “EEVBlog.bin” with no spaces in the file name or the meter might hang and just display down. If the current installed firmware is old then you might want to make sure you have a fresh set of batteries installed before running the firmware update. I think I’ve read the newer firmware will check the battery level first.
1. Turn the meter off then hold down MEM and HOLD while turning on the meter. You will see IAP on the display.
2. Press the “SETUP” button and it will display “DOWN / DOUUN” and after 5 seconds the meter bar should start rising from the left to right.
3. Once the bar hits the end the meter will restart displaying the new version of firmware installed.
This whole process after it displays “DOWN / DOUUN” shouldn’t take more then 15 seconds.
Just received my 121GW with firmware version 2.04. No issues discovered so far during first day of use.
These results were obtained with a recently delivered 121GW running upgraded 2.04 firmware** and an Agilent U8001A power supply. I was pressing the "Output On/Off" button with the voltage set to 20 Volts (1 Amp current limit). When pressing "On" the meter's digital readout blanks in most cases and just after 1 second displays 19.992 volts. The indicator bar goes fully to the right then drops back to the correct position in probably 1/3 second. Once in a while a voltage in the 8 to 9 volt range pops up momentarily before showing the correct voltage. Pretty well the same thing happens in reverse when I press the "Off" button, but it is more likely to show a lower voltage momentarily and the bar indicator drops to zero more or less immediately. The ambient temperature was around 17C .
** Somewhat worryingly the meter was delivered with 2.01 firmware which is listed in the manual as "do no use".
Plus I would guesstimate a similar 1 second delay while the digital readout was blank when pressing the Range button on the 121GW. One range indicated overflow (the press after showing "20.0"). The bar indication moved promptly.
I ask myself this question, why the firmware version 2.04 is not included on Dave's EEVBlog site?
The latest firmware on EEVBlog being 2.02?
I ask myself this question, why the firmware version 2.04 is not included on Dave's EEVBlog site?
The latest firmware on EEVBlog being 2.02?
I'm a slack arse.
It's now updated.
I ask myself this question, why the firmware version 2.04 is not included on Dave's EEVBlog site?
The latest firmware on EEVBlog being 2.02?
I'm a slack arse.
It's now updated.
The manual on the site doesn't seem to mention 2.04. Has it been updated (if only to tell us what's new in 2.04), and if so can it be made available please?
ow, c'mon
Just got a new 121GW and it is displaying 2.05 - not sure if its a beta release?
I ask myself this question, why the firmware version 2.04 is not included on Dave's EEVBlog site?
The latest firmware on EEVBlog being 2.02?
I'm a slack arse.
It's now updated.