$20 LCR ESR Transistor checker project

[MLXXXp]

Questions about the rotary encoder option:

I've got the simple 2 line, through-hole version of the tester, with an ATmega328P:
http://www.ebay.com/itm/M328-Transistor-Tester-Capacitor-ESR-Inductance-Resistor-LCR-Meter-NPN-PNP-MOS/281538451480
It came with firmware v1.11k but I compiled and installed v1.18m, which I think I like better.

I'm planning to replace the test switch with a rotary encoder. However, examining the documents and schematics shows that, by default, the k firmware uses PD1 and PD3 for the encoder signals whereas the m firmware uses PD2 and PD3. I haven't determined if the phase on PD3 matches.

Is there a good reason for this difference or is it just that the code was developed independently?

Would there be any problem if I change "#define ENCODER_A PD2" to "#define ENCODER_A PD1" in the m firmware's config.h file and then recompile?

There are now versions of the tester being sold with a rotary encoder as standard. On these units, which processor pins are used, and which is assigned phase A and phase B?

[madires]

It came with firmware v1.11k but I compiled and installed v1.18m, which I think I like better.

I'm planning to replace the test switch with a rotary encoder. However, examining the documents and schematics shows that, by default, the k firmware uses PD1 and PD3 for the encoder signals whereas the m firmware uses PD2 and PD3. I haven't determined if the phase on PD3 matches.

Is there a good reason for this difference or is it just that the code was developed independently?

Would there be any problem if I change "#define ENCODER_A PD2" to "#define ENCODER_A PD1" in the m firmware's config.h file and then recompile?

There are now versions of the tester being sold with a rotary encoder as standard. On these units, which processor pins are used, and which is assigned phase A and phase B?

In an older k-firmware version the default I/O pins used for the rotary encoder were also PD2/PD3 and were changed to PD1/PD3 later on. The m-firmware has kept the original I/O pins. Of course you can change the I/O pins in config.h as long as they belong to the same port. I got no idea about the A/B pinout of the Chinese clones. In case it's reversed, simply reverse the I/O pins config.h, problem solved

[MLXXXp]

Of cource you can change the I/O pins in config.h as long as they belong to the same port.

OK, thanks.

I got no idea about the A/B pinout of the Chinese clones. In case it's reversed, simply reverse the I/O pins config.h, problem solved

I only asked this because if it turns out there is a consistent way that these clones are being wired, I may as well wire mine the same.

[eas]

As I prepare to assemble one of these from a kit with a plastic housing, it occurs to me that it might be useful to have an easy way to store and switch between separate sets of calibration data; one set for use with the ZIF socket, the other for use with test leads.

Does this sound useful to anyone else? Is anyone aware of a patch that already does this?

[MLXXXp]

it occurs to me that it might be useful to have an easy way to store and switch between separate sets of calibration data; one set for use with the ZIF socket, the other for use with test leads.

The m-firmware only stores one set of calibration data but you can temporarily re-calibrate without the new data being saved after power off (unless you want override the previous data and save the new).

So you could save calibration data for the ZIF socket and when you wanted to use the test leads, short them out and do a temporary calibration.

[madires]

As I prepare to assemble one of these from a kit with a plastic housing, it occurs to me that it might be useful to have an easy way to store and switch between separate sets of calibration data; one set for use with the ZIF socket, the other for use with test leads.

Does this sound useful to anyone else? Is anyone aware of a patch that already does this?

I think it's a nice idea and will put it on my to-do list.

[eas]

As I prepare to assemble one of these from a kit with a plastic housing, it occurs to me that it might be useful to have an easy way to store and switch between separate sets of calibration data; one set for use with the ZIF socket, the other for use with test leads.

Does this sound useful to anyone else? Is anyone aware of a patch that already does this?

I think it's a nice idea and will put it on my to-do list.

Cool, thanks!

[MLXXXp]

I wired up a rotary encoder to my tester. I then tried to compile v1.18m firmware with the rotary encoder option (HW_ENCODER) but without the frequency counter option (HW_FREQ_COUNTER). When I executed make I got the following error:

Code: [Select]

extras.c: In function ‘SquareWave_SignalGenerator’:
extras.c:335:34: error: ‘T1_Prescaler_table’ undeclared (first use in this function)
       Prescaler = MEM_read_word(&T1_Prescaler_table[Index]);
                                  ^

After investigating the problem, I think it's due to the following code segments in variables.h:

Code: [Select]

  #if defined (HW_FREQ_COUNTER) || defined (SW_SIGNAL_GEN)
    /* Timer1 prescalers and corresponding bitmasks */
    const uint16_t T1_Prescaler_table[] MEM_TEXT = {1, 8, 64, 256, 1024};
    const uint8_t T1_Bitmask_table[] MEM_TEXT = {(1 << CS10), (1 << CS11), (1 << CS11) | (1 << CS10), (1 << CS12), (1 << CS12) | (1 << CS10)};
  #endif


Code: [Select]

  #if defined (HW_FREQ_COUNTER) || defined (SW_SIGNAL_GEN)
    /* Timer1 prescalers and corresponding bitmasks */
    extern const uint16_t T1_Prescaler_table[];
    extern const uint8_t T1_Bitmask_table[];
  #endif

Since HW_FREQ_COUNTER is not defined, then SW_SIGNAL_GEN needs to be defined in order to create the tables. However, there is no mention of SW_SIGNAL_GEN anywhere else in the code. I believe the two instances of SW_SIGNAL_GEN should be changed to SW_SQUAREWAVE. When I made these changes the code compiled without errors and my tester appears to be functioning properly with it.

P.S. If there's somewhere other than this thread where it would be more appropriate to submit bug reports and discuss software issues, please let me know.

[Messtechniker]

P.S. If there's somewhere other than this thread where it would be more appropriate to submit bug reports and discuss software issues, please let me know.

A good place is:
https://www.mikrocontroller.net/topic/248078?page=8
Its a veeeeeeeeeeeery long thread mostly in German but also with some English and
Karl-Heinz Kübbeler (kubi48) is your man (who works very hard on
the firmware of this thing).

Yours Messtechniker

[tom666]

If there's somewhere other than this thread where it would be more appropriate to submit bug reports and discuss software issues, please let me know.

You should probably get an answer in this thread, because the author of the m-version of the software is user "madires".

[madires]

I wired up a rotary encoder to my tester. I then tried to compile v1.18m firmware with the rotary encoder option (HW_ENCODER) but without the frequency counter option (HW_FREQ_COUNTER). When I executed make I got the following error:

Code: [Select]

extras.c: In function ‘SquareWave_SignalGenerator’:
extras.c:335:34: error: ‘T1_Prescaler_table’ undeclared (first use in this function)
       Prescaler = MEM_read_word(&T1_Prescaler_table[Index]);
                                  ^

Since HW_FREQ_COUNTER is not defined, then SW_SIGNAL_GEN needs to be defined in order to create the tables. However, there is no mention of SW_SIGNAL_GEN anywhere else in the code. I believe the two instances of SW_SIGNAL_GEN should be changed to SW_SQUAREWAVE. When I made these changes the code compiled without errors and my tester appears to be functioning properly with it.

Yes, that's an error. It should be

Code: [Select]

  #if defined (HW_FREQ_COUNTER) || defined (SW_SQUAREWAVE)
in variables.h. It's already fixed in both v1.19m editions (not released yet). BTW, I'm the right person to send bug reports to, regarding the m-firmware 

[madires]

A good place is:
https://www.mikrocontroller.net/topic/248078?page=8
Its a veeeeeeeeeeeery long thread mostly in German but also with some English and
Karl-Heinz Kübbeler (kubi48) is your man (who works very hard on
the firmware of this thing).

... in case of the k-firmware. But we both forward bug reports and what have you to each other.

Some updates about the upcoming v1.19m:
- bug fixes
- updated Czech texts (thanks to Kapa)
- display driver for ILI9341/ILI9342 (trendy edition)
- performance improvements for graphic LCDs (trendy edition)
  A 320x240 ILI9341 is quite restrained when driven via bit-bang SPI, but a 16MHz crystal helps a little bit

I've planned to add the fancy pinout in this release too but had/have to deal with a bereavement, a broken heart and a flu. Why do bad things happen all at once? So I ask you all if I should release v1.19m soon without the fancy pinout or if you are patient to wait another month or so?

[onlooker]

I am toying one of such thing. What should be the correct way to detect a bjt with internal diode between C-E such as 13003?

Apparently, mine will display both PNP and NPN depending on the way the bjt is seated in the lock socket and either way showed a sensible hfe about 15.

[madires]

I am toying one of such thing. What should be the correct way to detect a bjt with internal diode between C-E such as 13003?

Apparently, mine will display both PNP and NPN depending on the way the bjt is seated in the lock socket and either way showed a sensible hfe about 15.

Which firmware (k or m) and which version do you run?

[MLXXXp]

So I ask you all if I should release v1.19m soon without the fancy pinout or if you are patient to wait another month or so?

It depends if any of the "bug fixes" are important.

Since my tester only has a 2x16 character display and thus uses the classic firmware compiled for English, none of the enhancements you mentioned seems to be of any concern to me.

[hapless]

One little enhancement (because it's not really a bug fix) I've been waiting for is the symbol for hfe shown as Greek beta rather than B. This can be configurable in case a certain display has something else in that position, but the cheapest of the Chinese English displays have it at 226 (decimal). Been editing Transistortester.h for a long time to do this.

I've planned to add the fancy pinout in this release too but had/have to deal with a bereavement, a broken heart and a flu. Why do bad things happen all at once? So I ask you all if I should release v1.19m soon without the fancy pinout or if you are patient to wait another month or so?

Work may be able to help with the other two, but the flu? Health is more important. I'm sure waiting a few weeks for a new release won't hurt anyone. Not as much as complications from the flu can, anyway. Get well soon!

[madires]

It depends if any of the "bug fixes" are important.

Since my tester only has a 2x16 character display and thus uses the classic firmware compiled for English, none of the enhancements you mentioned seems to be of any concern to me.

I got following for the classic edition so far:
- Updated Czech texts, thanks to Kapa.
- Fixed variable management bug in config.h.
- Optimized functions for NVRAM management (values stored in EEPROM).

#2 is the error you've spotted.

[madires]

One little enhancement (because it's not really a bug fix) I've been waiting for is the symbol for hfe shown as Greek beta rather than B. This can be configurable in case a certain display has something else in that position, but the cheapest of the Chinese English displays have it at 226 (decimal). Been editing Transistortester.h for a long time to do this.

That seems to be the k-firmware. I've forwarded your suggestion to Karl-Heinz.

Work may be able to help with the other two, but the flu? Health is more important. I'm sure waiting a few weeks for a new release won't hurt anyone. Not as much as complications from the flu can, anyway. Get well soon!

Thanks! Work helps, indeed.

[hapless]

One little enhancement (because it's not really a bug fix) I've been waiting for is the symbol for hfe shown as Greek beta rather than B. This can be configurable in case a certain display has something else in that position, but the cheapest of the Chinese English displays have it at 226 (decimal). Been editing Transistortester.h for a long time to do this.

That seems to be the k-firmware. I've forwarded your suggestion to Karl-Heinz.

You're right, sorry for the confusion. I use both versions and sometimes I'm thinking of one while talking about the other. Thanks for forwarding it! I should have also included that I think an asterisk looks worse than an x for displaying the "times" symbol...

I've got one for you, too though.  When the tester shows that it detected multiple diodes (like 4), the message preceding that says that no component is found. That's rather contradictory: It knows that something is connected, yet says otherwise.

[onlooker]

I am toying one of such thing. What should be the correct way to detect a bjt with internal diode between C-E such as 13003?

Apparently, mine will display both PNP and NPN depending on the way the bjt is seated in the lock socket and either way showed a sensible hfe about 15.

Which firmware (k or m) and which version do you run?

Thanks for replying. I bought mine recently from Ebay due to this thread. But, I may have missed some info here or missed the level of relevance since I only read a very small part of this long thread.

By the seller, my tester is:

1. 2013 latest M328 version of the software ,more functions.Chip: Atmega328.
2. 128*64 big Backlight LCD display,only 2mA when stand by.

When starting up,  it shows "MTester v2.07...by Efan &Haoqixin"

[ralphd]

A good place is:
https://www.mikrocontroller.net/topic/248078?page=8
Its a veeeeeeeeeeeery long thread mostly in German but also with some English and
Karl-Heinz Kübbeler (kubi48) is your man (who works very hard on
the firmware of this thing).

... in case of the k-firmware. But we both forward bug reports and what have you to each other.

Some updates about the upcoming v1.19m:
- bug fixes
- updated Czech texts (thanks to Kapa)
- display driver for ILI9341/ILI9342 (trendy edition)
- performance improvements for graphic LCDs (trendy edition)
  A 320x240 ILI9341 is quite restrained when driven via bit-bang SPI, but a 16MHz crystal helps a little bit

I've planned to add the fancy pinout in this release too but had/have to deal with a bereavement, a broken heart and a flu. Why do bad things happen all at once? So I ask you all if I should release v1.19m soon without the fancy pinout or if you are patient to wait another month or so?

You could use my asm SPI code.
http://nerdralph.blogspot.ca/2015/03/fastest-avr-software-spi-in-west.html

[ralphd]

The BOM is about $3 with the 1602 LCD and atmega328 accounting for $2.5 of that.  Strangely I can't find them for less than $10.

[eas]

The BOM is about $3 with the 1602 LCD and atmega328 accounting for $2.5 of that.  Strangely I can't find them for less than $10.

Um, why do you expect to?

[ralphd]

The BOM is about $3 with the 1602 LCD and atmega328 accounting for $2.5 of that.  Strangely I can't find them for less than $10.

Um, why do you expect to?

Because things like Pro Minis sell for about 25% over their BOM cost.

http://m.aliexpress.com/item/32229454220.html

[eas]

Less specialized / more general -> higher volume -> better economies of scale / more competition -> lower margins