Have anyone decoded the binary file with the calibration data?
Alexander.
Have anyone decoded the binary file with the calibration data?
Alexander.
Sure have. If you've got python 3 or above, run
this script with the first argument pointing to the file.
Thank you!!! <3 <3 <3
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?
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?
Yeah, it's all detailed in the reverse engineering. I suggest you consult that if you are curious because I'm too lazy to explain everything. But to put it in a sentence, bargraph = (ADC - offset) * gain, and screen = smooth(average(bargraph) - nonlinearity_corr), where average is the average of 8 or 16 bargraph samples, nonlinearity_corr is some nonlinearity offset calculated using some data tables and the listed coefficients in a manner that I don't entirely understand, and smooth is a rolling average that resets if the difference between samples is too large.
May I ask why you are interested in knowing all this?
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.
Alexander.
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
It would be possible. However, according to my knowledge of the firmware, the corresponding factor is saved before the G-END or OFF-E message is displayed. So you can just turn off the meter after offset calibration to skip gain calibration. But of course, the offset factor is used when calibrating the gain factor, so one would be advised to do gain as well. Maybe someone can work out the math to adjust the gain factor, and hand edit that in.
Hi all
I have finally had time to sit down and start playing with the meter properly, although I would love to have completely open source firmware I also know that I don't have the skill or knowledge to write it, I also don't have the time or equipment to do the extensive testing required but thought that I could contribute by at least dumping out the firmware from the BLE112 blue tooth module (I know that at least Joe has a meter with an un-programmed module and though it would be useful in case anyone bricks one).
I did this using the "Texas Instruments Smart RF Flash Programmer" software with a "CC Debugger" connected to the CN2 port in the 121GW - connections as below:
121GW <=> CC Debugger
Pin 1 <=> Pin 7
Pin 2 <=> Pin 2 + 9
Pin 3 <=> Pin 1
Pin 4 <=> Pin 3
Pin 5 <=> Pin 4
In time I may try to reverse engineer it a bit more but I suspect that my lack of expertise will hinder me there.
Jem
P.S. this was dumped from meter no 180701854 running firmware version 1.26
I found that I was struggling to understand the official Packet protocol document so as I don't currently have a blue tooth interface for the PC I have been looking at the UART streams between the STM32 processor and the BLE112 blue tooth interface on the meter and am slowly creating a more detailed document about the 19 byte packet.
I have attached what I have got so far below along with a screen shot of a packet as captured from my meter.
Note: Meter Firmware Version 1.51
Jem
Its a 19 byte packet from the STM32 to the BLE112 inside the meter, I don't know if the BLE112 adds any packets before it transmits it to the receiving device, I intend to try and look at the transmitted data as well at some point to see if it does add stuff but don't have a compatible blue tooth receiver for the PC.
Jem
Now version 1.51 is gone from
the product page, and 1.26 is the newest. What happened?
So as a 121GW user I would like to hear about the reason or at least if I should downgrade to 1.26.
I figured it was just an oversight with managing the web page. Possibly still there may be problems with attending to this due to the move. I wish someone would comment on this matter. I did install 1.51 in my meter. I see no problems but I'm wondering what's what.
I've installed the 1.51 FW, a month ago, without any issues. I want to know why the FW
was removed. There is another thread, where a user complains that the calibration data is
partly wrong after upgrade to 1.51.
Maybe someone can bring a little bit clarity about the background. I'm afraid that my calibration
data is also corrupt.
I also upgraded to 1.51, but didn't use the meter post upgrade. I'd love to know if I should downgrade.
And now 1.52 is out there. Could someone please give us an update?
Being of an empirical and somewhat adventurous nature, I decided to install the firmware labeled 1_52. The meter started back up just fine but comedy ensued, the firmware revision is reported as 1_53. I checked this several times lest my eyes deceived me. 1_53. I suppose I can state the result is better than expected, at least numerically.
Cursory examination, the meter seems OK. I'm still wondering if, after 1_51, it's still calibrated. but I think it is. I'd like a way to verify that - what a "bricked calibration" looks like is not what mine looks like. I'm thinking that the incident that initiated pulling 1_51 was fairly anomalous but can we get confirmation?
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.
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 .
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 .
I am using Probemaster probes but even with the ones which came with (that I believe are UEI Test) - I have found no lag at all on beep, simply striking the probe tips against one another or bring the tips together, is an immediate beep. Something may be off with your unit. When you short the probes, what is the resistance reading?
The beep lag is only in diode mode ( maybe 0.5sec ) , in continuity mode is very fast .
Resistance is zero when shorting the probes
There is no mention of diode beep in the manual. According to the manual there is a 2.2k resistor and a PTC in series with the DUT. Literally the diode test is not supposed to Beep except that is a side effect of the continuity function for diodes with low enough forward current to trigger it. It's hardly surprising that when the beep happens - it is "laggy". it's not a simple continuity test.
You are wanting something to work that is not part of the published feature set.
Every decent multimeter has the beep in diode mode ... and is fast , feature or not
If you really work with the multimeter repairing something you will know why .