Yesterday I ordered another unit which just might contain the ATmega324. These things are cheap enough that I'll keep at it until I get the one I want!
Call me a sucker for punishment, but after recently failing with my purchase of the LCR-TC2 from this vendor (I wanted an ATmega324 but got the LGT8F328P), I've taken a gamble on the LCR-TC1 model from the same vendor. https://www.aliexpress.com/item/1005004717377243.html
What gives me hope?QuoteLCR-T7 / LCR-TC1:color screen / M644 chip, two functions are the same! T7 is slightly faster! The TC1 screen is slightly larger and they are all powered by lithium batteries. In addition to measuring resistance, capacitance, inductance, diodes, MOS transistors, thyristors, it can also measure additional voltage regulators, infrared decoding (limited to for Hitachi format)
Self test with automatic calibration
In the LCR-TC2 description, it does not mention M644 (since it was delivered with LGT8F328P that makes sense) nor does it mention "Self test with automatic calibration" - this also makes sense as firmware for the LGT8F328P (in my case V3.1e) cannot fit the code for self-calibration. V3.1E firmware is also horrifically buggy, cannot reliability measure ESR, or Darlington transistors, etc. I will definitely be modifying my LCT-TC2 with LGT8F328P to the ATmega328P.
I can only presume (hope) M644 mentioned in the details of the LCR-TC1 description refers to ATMega644 and so far this is the only specific mention of M644 within an advertisement that I can find. Lets see when it arrives.
Luke
I feel like I am walking in your footsteps
My question may have already been answered, but at least I didn't manage to find it in the last couple of days that I'm reading through this thread (10 years old thread, really impressive ). I was wondering maybe someone has already had this issue and could give me some hint to do further troubleshooting.
/* ************************************************************************
* workarounds for some testers
* ************************************************************************ */
/*
* Disable hFE measurement with common collector circuit and Rl as
* base resistor.
* - problem:
* hFE values are way too high.
* - affected testers:
* Hiland M644 (under investigation, possibly poor PCB design)
* - uncomment to enable
*/
#define NO_HFE_C_RL
I can't seem to find any hardware problems on the probe side of the chip.
...
Any ideas welcome at this point because I'd like this particular unit to be running the latest M firmware, not K.
Unmodified (but working) LCR- units with APT32F172K8T6 MCU and the poorly designed U7 circuit will display 5-8V “zener voltage” with the 1k resistor connected to K-A. This is because DC-DC converter U7 actually does function as a constant current source (until it gets damaged).
The tester is rock-solid stable with 1.13k firmware, but with 1.49m sometimes it shows 0pF between probes during self-test while other times is the usual 47-51pF.
I can't seem to find any hardware problems on the probe side of the chip.
...
Any ideas welcome at this point because I'd like this particular unit to be running the latest M firmware, not K.Compare the Show Values with the photo to see if there are significant differences.
The tester is rock-solid stable with 1.13k firmware, but with 1.49m sometimes it shows 0pF between probes during self-test while other times is the usual 47-51pF.
0 pF can happen when some values don't add up during the measurement. You could try ADC_LARGE_BUFFER_CAP to increase the delay for switching the ADC's reference voltage.
The actual cap measures around 1.1nF.
So I'm still stuck.
The tester is rock-solid stable with 1.13k firmware, but with 1.49m sometimes it shows 0pF between probes during self-test while other times is the usual 47-51pF.
2. Done, similar results to the original port. In fact that's what I did earlier, using the "Battery Votage" testing pin. They all have a problem with voltages below 1V(at the pin).
When the voltage at the ADC pin is below the voltage of the internal band-gap reference the tester switches to the band-gap reference for better resolution and accuracy (both OSHW firmwares do this). Most likely there's a problem around the AREF pin. We use a small cap at the AREF pin to buffer the reference voltage (switched between Vcc and internal band-gap).
Eventually I found a workaround- reading more about the internal bandgap reference on atmega chips, I found someone mentioning that switching from VCC reference to bandgap is a lot slower than the other way around.
Now everything works fine.
Eventually I found a workaround- reading more about the internal bandgap reference on atmega chips, I found someone mentioning that switching from VCC reference to bandgap is a lot slower than the other way around. So I just changed the priority( inside ADC.c) from VCC to bandgap(changes shown in orange, original statement in green:
/* wait some time for voltage stabilization */
#ifndef ADC_LARGE_BUFFER_CAP
/* buffer cap: 1nF or none at all */
wait100us(); /* 100µs */
#else
/* buffer cap: 100nF */
wait10ms(); /* 10ms */
#endif
That's one reason why there's an intentional delay when switching the reference voltage and also a dummy conversion. The ADC_LARGE_BUFFER_CAP option is meant for Arduinos with a 100nF cap at AREF and basically increases the delay by a factor of 100. But for investigating the strange behaviour of your tester's MCU you could increase the delay in the unmodified source until the measurements are fine. It would be interesting to know how large the delay needs to be, in case someone else runs into the same problem.
ReadU() in ADC.c:Code: [Select]/* wait some time for voltage stabilization */
#ifndef ADC_LARGE_BUFFER_CAP
/* buffer cap: 1nF or none at all */
wait100us(); /* 100µs */
#else
/* buffer cap: 100nF */
wait10ms(); /* 10ms */
#endif
/* wait some time for voltage stabilization */
#ifndef ADC_LARGE_BUFFER_CAP
/* buffer cap: 1nF or none at all */
wait100us(); /* 100µs */
PS: Without setting the default ADC reference to the internal band-gap reference your changes disable voltage measurements with the band-gap reference.
Well, that's the thing: I doesn't seem to change anything! I am using a 1nF cap(even removed it previously, suggested by @indman), so I'm working within this section:
With default value of 100us, one measurement takes about 2sec, with wait1ms() it takes about 4sec, with wait10ms()- about 6sec, with wait 100ms()- 23sec, and with wait200ms() one measurement took 1min and 3 seconds to complete. For the sake of sanity I stopped it there. The reading is exactly the same.
It looks like the internal reference never gets down to it's intended value.
QuotePS: Without setting the default ADC reference to the internal band-gap reference your changes disable voltage measurements with the band-gap reference.
But isn't the alteration I showed previously doing exactly that: starting the ADC sample with the internal band-gap by default, and only if it reads 1024- switch to the VCC reference? I did a zener test within the whole range: 1 to 24.5 V, and the readings are smack-on. Same with various resistors. I am quite convinced the precision hasn't suffered at all. Semis check fine, only checked few caps, but they look ok too.
/* prepare bitfield for register: start with AVcc as voltage reference */
Channel &= ADC_CHAN_MASK; /* filter reg bits for MUX channel */
Channel |= ADC_REF_VCC; /* add bits for voltage reference: AVcc */
if ((uint16_t)Value < 1024) /* < 1V (5V / 5 samples) */
to if ((uint16_t)Value < 900)
The idea is to check if the voltage of the band-gap reference might by a bit too low.