🤣🤣🤣👌🏼 Klaus.
Boleslaw J. schrieb: > Such a graphic form of the result has no substantive justification. It > adds nothing to the result of the remote control test. This is an > unnecessary, but attractive addition to encourage a potential customer > to buy something that other Chinese products with a similar purpose do > not have. The same applies to the color barcode when measuring > resistance. Since I already know the resistance value, I do not need a > color code. > I took up this topic only because I wanted to occupy my free time with > something interesting. I find it useful when I am new to a protocol to get a quick glimpse of how the data is encoded. I find it useful, and I would appreciate if you share the code so that the firmware developers can pick up. That is "hacky thinking" also: Do not assume the usefulness of a feature, because someone else might find a use you never could think of. Regards!
Holger B. schrieb: > I find it useful, and I would appreciate if you share the code so that > the firmware developers can pick up. That's what I was going to do. But first I need to finish implementing these graphics for all IR protocols. Regards, Boleslaw
The original, complete information about the data sent from the remote control, which Mr. Reschke fit in one line, will be supplemented with graphics simulating the image from the oscillograph.
I finished implementing graphics for the IR detector. I ran the tests on several remote controls to which I have access. The remaining tests will be performed after receiving the m328-644 adapters from China. They are already after customs clearance. For testing, I will use a second AY-AT tester on ATmega644. I already have an additional tester and microcontroller. For testing, I will use the IR RC function of the second tester. I will give the modified files to the author of the program, Mr. Reschke. He will decide whether to include the changes in the next version of the program. I have no right to publish modifications without the program author's permission.
Boleslaw J. schrieb: > I have no right to publish modifications without the program author's permission. Why this? As I see, the license is EUPL 1.1 (see file "EUPL-v1.1.pdf" in the source code directory), and it allows > *modify the Original Work, and make Derivative Works based upon the Work,* under some conditions (which mainly are about notices in derived work, license of derived work, ...)
:
Bearbeitet durch User
Holger B. schrieb: > Why this? > > As I see, the license is EUPL 1.1 (see file "EUPL-v1.1.pdf" in the > source code directory), and it allows > >> *modify the Original Work, and make Derivative Works based upon the Work,* > > under some conditions (which mainly are about notices in derived work, > license of derived work, ...) You are right, but Mr. Markus Reschke has been conducting this topic for many years, he does it, as I noticed, very well and in addition selflessly, so he has the moral right to decide what will be included in the program, which he signs with his own name. That is my opinion. Otherwise, there will be a mess in the software that will be difficult to control.
Carsten W. schrieb im Beitrag #7077914 > Aber sieht interessant aus. Würde ich gerne mal aufmachen und reinschauen. besser spät als garnicht! Die eine Version verwendet zwei ARM Controller, bei der anderen ist nur ein Controller verbaut wobei die Type unbekannt ist (nicht lesbar)! https://de.banggood.com/FNIRSI-DSO-TC2-Handheld-Digital-Oscilloscope-LCR-Meter-Graphic-Display-Transistor-Tester-2_4-inch-TFT-Color-Screen-LED-Backlight-for-Auto-Repair-Appliance-Repair-p-1955385.html https://de.banggood.com/FNIRSI-DSO-TC3-Digital-Oscilloscope-Transistor-Tester-Function-Signal-Generator-3-in-1-Multifunction-Electronic-Component-Tester-p-1982523.html
:
Bearbeitet durch User
R. H. schrieb: > besser spät als garnicht! :-) Wäre mal interessant, die Mess-Schaltung des 122er zu sehen. Der µC wird ja 3.3V als I/O-Spannung haben und eine sich sehr vom Atmel unterscheidende interne Portstruktur. Aber bei dem 2523 sind dem Designer wohl die Pferde durchgegangen. Wozu braucht man 30 Transistoren in der Mess-Schaltung?
Beitrag #7420347 wurde vom Autor gelöscht.
Da der Vorgänger TC2 zwei ARM µC STM32 verwendet hat (einen für das DSO und den kleineren für den T-Tester) gehe ich mal davon aus das man das jetzt alles in einen großen gepackt hat z.B. STM32F407VET6. Vor 2 jahren hat ja schon mal jemand die T-Tester SW auf einen STM32F103/GD32F103 oder GD32F303 portiert, vllt. hilft das ja weiter (für Leute die sich damit auskennen) ;-) https://github.com/mean00/stm32ComponentTester
Hello Boleslaw 43, Do you also sell any of these boards, if so, I would like to buy two? Greeting Horst
Hello Boleslaw_43, if you sell some of this boards, I also would like buy two pieces of them. Best regards
Thank you for your interest. Since this is my first PCB project, I treat it as a training material. Therefore, to Forum users residing in the EU, as part of the promotion, I send the adapter for free. Please send postal addresses for shipping to my PM.
I have finished the implementation of the graphical form (a la oscillogram) of the data read from the remote control for the "IR detector" function, for the protocols entered into the Component Tester. It took me a while because I ran into a problem reading data according to the Motorola protocol that I could not understand. On my 8 megahertz AY-AT tester, the IR receiver was unable to read the data transmitted by the second Component Tester, set in the "IR RC" function to the "Motorola" protocol. I understood the reason by analyzing the IR protocol provided by Motorola. After a short press of a key on the remote control, its transmitter sends three packets of bits at strictly defined intervals. The first package contains 9 ones - this is a starter package. The second package contains the right command, and the third package, also containing 9 ones - is a package ending the data transmission from the remote control. By holding down the remote control key for a longer time, the remote control repeats the command packet until the key is released, which results in sending the end package (9 ones). Well, the time that elapses between sending the first packet of bits and sending the second packet of bits is too short for the receiver to notice it, busy at that time interpreting the received first packet. This second packet, containing the command, was simply lost. This critical time can of course be extended in the "IR RC" function, which I did, but the real Motorola remote control does not have such a possibility - it sticks to the established protocol. The elegant, multi-packet handling of received packets did not work in this case. The solution to the problem may be to receive three or at least two packets in one cycle and remember them in RAM for later analysis. This is a proposal to be included in the To-Do list for the author of the program.
Transistortester AVR Windows-Software !? Hallo bin beim stöbern im Netz zufällig über diese Software gestolpert: https://disk.yandex.ru/d/MHdHzZehqqzUi scheint aus einer russ. Quelle zu stammen und ist wahrscheinlich mit Profilab von ABACOM erstellt!? kennt die zufällig jemand und weis über die Funktion, Anschluss an den T-Tester (seriell), Änderung an der Firmware usw. bescheid? Gruß
Das sieht ganz nach der Software vom "Messtechniker" aus. Musst mal hier im Faden suchen. Ist aber "einseitig", also nur RX vom Tester. Testerausgang ist Pin26 vom 328. Gruss Asko
For people to whom I sent adapters m328_m644 for AY-AT, I share the modified firmware. The firmware has been supplemented with a graphical result of remote control tests, SPI hardware support for the ST7735 display and generator output from the OC1B port of the microcontroller. The zip archive also contains the current adapter connection table for version 1.03 (white).
Boleslaw J. schrieb: > For people to whom I sent adapters m328_m644 for AY-AT, I share the > modified firmware. I think now you must also share the source, as it is required by the license of the code you build upon. This will also help others to adapt to their setups. :-).
Holger B. schrieb: > share the source,... > This will also help others to adapt to their setups. And please use up-to-date technologies for this, e.g. github. This will help you keep track and allow others to contribute.
I passed the changes I've made in the software to the author of the program. If the author decides that these changes have any substantive value, he will certainly publish them in the next version of the software.
Boleslaw J. schrieb: > I passed the changes I've made in the software to the author of the > program. The idea of the license is that people who distribute binary code based on code under the license also publish the source. This is not meant as a benefit to the author, but the author chooses to make the software free in the sense that no-one can claim ownership of the software so everyone is free to build upon it (also the author cannot revoke the free-nes of the software). That is the idea of this type of licenses, and that is why you now need to also publish the code once you have published the binaries. Maybe someone else can explain the idea of those "non-ownership" license better?
Hallo Nachdem User Boleslaw J hier eine Adapterplatine vorgestellt hat, beschäftige ich mich wieder mit dem Teil. Ich wusste, dass ich noch eine "Leiche" im Bestand hatte. Also habe ich mal gekramt, und auch gefunden! Es ist ein AY-AT mit bedrahteten Bauteilen. Damals gab es einen Kurzschluss mit einem Knall weil ein vagabundierendes Drähtchen sich unter die Leiterplatte des Testers verirrt hatte. Ich hatte sämtliche Transistoren getauscht, nichts hat geholfen. Immer kam die Ausschrift: "5,01V - Spannung zu gering". Auf die Idee den Spannungsregler zu prüfen bin ich einfach nicht gekommen! Weil ja eben immer die Ausschrift kam "5,01V". Jetzt (Jahre später) stellte ich eben fest, auch der Regler 7550 war durchgeschlagen. An der CPU lagen >7,5V an!!!! Der ATMega328P-PU hat das ausgehalten! Es ist erstaunlich was die so wegstecken können. Nach auswechseln gegen einen MCP1702-5002 ist alles wieder im Lot. Mein Multimeter sagt jetzt 5,019 Volt am ATMega328. Na, das passt doch eher. Dann wollte ich auch gleich die Referenzspannungsquelle ändern. Also habe ich einfach 1:1 den TL431 gegen einen LM4040 ausgetauscht. Denkste, nachdem es nicht funktioniert hatte, stellte ich fest, dass die beiden unterschiedlichen Typen auch unterschiedliche Footprints haben. (TO92) Ich wusste, das LM336 und LM4040 die gleiche Pinbelegung haben. Also bin ich in meinem jugendlichen Leichtsinn davon ausgegangen, das es beim TL431 auch so ist. Nachdem ich auch das richtiggestellt hatte läuft wieder alles prima. Was mir aber mit erschrecken aufgefallen ist: https://www.reichelt.de/at/de/shunt-spannungsreferenz-fest-2-5-v-0-1-to-92-lm-4040-aiz2-5-p109411.html?&trstct=pos_15&nbc=1 Kosteten die Dinger nicht mal ca. 60 Cent? Mir war jedenfalls so. Jetzt bin ich ja mal gespannt, ob Boleslaws Platine mechanisch auf meinen Tester passt. Ich habe ja die Version mit bedrahteten Bauteilen, er dagegen mit SMD-Bestückung. Bei mir stehen ja ein Paar Bauteile hoch. Gruss Asko
Asko B. schrieb: > Kosteten die Dinger nicht mal ca. 60 Cent? auch jetzt noch 60Cent wenn man die SMD Version verwendet ;-) https://www.ebay.de/itm/124934946426 > Bei mir stehen ja ein Paar Bauteile hoch. ich besitze beide Versionen, bei der SMD bestückten passt es. bei der bedrahteten Version passt es auch wenn man die beiden 10µF "flachlegt" (den einen 10k Widerstand habe ich auf die Unterseite verbannt) und die Transistoren ggf. "tieferlegt". Wer das chinesische Steckgehäuse verwendet hat ja genug Platz unter der Platine und könnte auch die Elkos von unten einlöten. Ich habe außerdem nur Pinns in den Adapter gelötet, da wäre dann theoretisch noch Platz für eine 2. Platine!
:
Bearbeitet durch User
Hallo Ich bin verwirrt mit WITH_SamplingADC im Makefile, wenn es aktiviert ist, was bewirkt es? ob mit dieser Einstellung bei der Messung der Induktivität die Einheit von Milihenry (mH) auf Microhenry (µH) geändert werden soll ? Vielen Dank im Voraus Yenk, Indonesia :)
Hallo Boleslaw, ... auf Wunsch von... hört sich ja gut an. ;-) Aber es sollte eigentlich einfach nur ein Vorschlag sein. So das man den schon verbauten 8MHz-Quarz für den M328 drinlassen kann, und nach umstecken auf den M644 dann halt 16MHz nutzen kann. Auch dachte ich eher an eine SMD-Ausführung um die Platine nicht grösser werden zu lassen. Übrigens müssen dann auch die zwei markierten Leiterbahnen entfernt werden. Gruss Asko Hello Boleslaw, ... at the request of... sounds good ;-) But it should really just be a suggestion. So that you can leave the already installed 8MHz-quartz for the M328 in and after changing to the M644 you can use 16MHz. I was also thinking of a SMD version so that the board would not be not to make the board bigger. By the way, the two marked tracks must also be removed. be removed. Greetings Asko
@snapper Bei mir sind die beiden Elkos genauso hoch wie die Transistoren/Spannungsregler. Gruss Asko
Auslöten und entweder ganz bis auf die Platine drücken oder auch von der Unterseite einlöten (auf die Polung achten!). Wenn Du kein chinesisches Steckgehäuse hast brauchst Du dann aber 4 Abstandshalter. Aber Vorsicht beim entlöten/löten das Du keine Durchkontaktierungen mit rausreißt und das die Transistoren nicht überhitzt werden!
Asko B. schrieb: > By the way, the two marked tracks must also be removed. There is no need. Just do not solder pins 9 and 10 of the DIP28 connector. However, in this version, PCB is universal. When you want to use the 8 MHz quartz resonator installed on the main PCB, just do not solder the quartz resonator and capacitors to the adapter.
Boleslaws Firmware-Mod und Adapterplatine sind nun im Repo: - Platine: https://github.com/madires/Transistortester-Warehouse/tree/master/Hardware - Firmware-Mod: https://github.com/madires/Transistortester-Warehouse/tree/master/Firmware/m-firmware
Yenk schrieb: > Hallo > Ich bin verwirrt mit > WITH_SamplingADC im Makefile, wenn es aktiviert ist, was bewirkt es? > ob mit dieser Einstellung bei der Messung der Induktivität die Einheit > von Milihenry (mH) auf Microhenry (µH) geändert werden soll ? > Vielen Dank im Voraus > > Yenk, Indonesia :) Die Sampling ADC Methode erreicht eine schnelle ADC Abtastung durch Wiederholung der gleichen Messung mit verschobenem Abtastzeitpunkt des ADC. Dadurch kann eine Abtastung des Signals im Abstand der Taktfrequenz des ATmega erreicht werden. Damit ist eine schnelle Abtastung der Ladekurve eines Kondensators möglich und die Meß-Auflösung kann dadurch bei kleinen Kondensatoren bis zu 0.01 pF betragen (bei 16 MHz Takt). Mit der gleichen Methode (SamplingADC) können auch kleinere Induktivitäten gemessen werden, wenn ein Kondensator mit hoher Güte (10nF - 30nF) parallel geschaltet wird. Dann wird aus der Induktivität ein Schwingkreis. Aus der Schwingfrequenz wird dann die Induktivität berechnet. Daneben wird auch die Güte des Schwingkreises bestimmt. Bei einer hohen Güte des parallel geschalteten Kondensators ist die Güte des Schwingkreises praktisch identisch mit der Güte der Induktivität. Der parallel geschaltete Kondensator wird bei der Induktivitätsmessung automatisch erkannt.
If it is not possible to mount a quartz resonator either on the bottom layer of the PCB or on the top layer, you can try to place it on the side of the PCB, as in the attached figure.
Asko B. schrieb: > I was also thinking of a SMD version so that ... > not to make the board bigger. To reduce the dimension of the adapter, I moved the quartz resonator Y1 and capacitors C2, C3.
I added the inscription: "If Y1, C2, C3 installed, do not solder pins 9 & 10"
Two suggestions: * Make Y1 a SMD version * Cut the tracks to the adapter pins. Not soldering them does not make sure, that there is no contact at all. You might need to cut off the adapter pins before soldering.
Carsten W. schrieb: > Two suggestions: > * Make Y1 a SMD version > * Cut the tracks to the adapter pins. Not soldering them does not make > sure, that there is no contact at all. You might need to cut off the > adapter pins before soldering. Thank you for your valuable suggestions. The basic design of this adapter in the source version (.lay6) is placed in the Markus R. repository. Everyone can download and modify this project for their own needs and self-assembly capabilities.
I'm only an observer in this thread and I do not intend to use the adapter. I'm just suggesting some improvements, since it's not good design practice to make a circuit's functionality dependent on whether two pins of a larger component are soldered or not. People who a not familiar with the circuit will search themselfs to exaustion if the oscillator is not working as intended or will stop to work at some point. They will simply overlook these two pins. And like I wrote before: Even if not soldered, there is no guarantee at all, that those plated holes and pins will stay out of contact forever.
...sry, a little bit more soup in the brain then after primary school may be expected by persons using such testers AND at least in combination with this adapter. But anyway this discussion might be OT. Klaus.
... von Anfang an gefiel mir Boleslaw 's Projekt mit dem Erweiterungs-Adapter. Im Laufe der letzten Jahre kamen immer mehr Messmöglichkeiten für den Componenten-Tester hinzu, z. B. auch ein kleine Adapter zum Test von Optokopplern. Der begrenzte Speicherplatz beim Atmega328 zwang nun zum Auswählen der Funktionen und zum Vorhalten mehrere 328er mit unterschiedlichen Funktionen, die bei Bedarf dank IC-Fassung Auswechselbar waren. Der o.a. 644er/1284er Adapter bringt da Abhilfe. Boleslaw war so freundlich, mir 2 PCB 's zu überlassen. Am Montag waren die in der Post und ich habe gleich 'nen Atmege644 aufgelötet. Der Platz unter dem Display ist nicht so üppig und ich endschied mich, den Adapter von unten mittels einer zweiten IC-Fassung einsteckbar anzubringen. Zunächst gab es ein Problem bei der Inbetriebnahme - keine Anzeige auf dem Display? Eine eingesteckte LED in den ZIF-Testsockel zeigte durch ihr Aufflackern das das Programm schonmal lief. Am Oscilloscope sah man auch die Impulse der Display-Ansteuerung. Zum Glück habe ich ja zwei dieser Tester und das andere Display funktionierte auf Anhieb. Da beide Displays an den 328er Controllern arbeiten, stellte sich durch Vergleich der Ansteuer-Impulse heraus, das nur eins dem schnelleren HARDWARE-SPI folgen konnte. Habe dann zum Test den Adapter auf BITBANG-SPI umgestellt und das "langsamere" Display funktioniert nun auch am 644er Adapter. Der momentane Füllstand des Atmega644 liegt bei Program: 74,4%, Data: 7,0% und EEPROM: 73,5% Der zweite Adapter bekommt dann einen Atmega1284! Gruß Horst ... from the beginning I liked Boleslaw's project with the expansion adapter. Over the last few years, more and more measurement options for the component tester have been added, e.g. B. also a small adapter for testing optocouplers. The limited storage space of the Atmega328 now forced the selection of the functions and the provision of several 328s with different functions, which were interchangeable if necessary thanks to the IC socket. The 644/1284 adapter mentioned above will help. Boleslaw was kind enough to let me have 2 PCB's. They were in the mail on Monday and I immediately soldered an Atmege644 on. The space under the display is not that plentiful and I decided to attach the adapter from below using a second IC socket. At first there was a problem when starting up - nothing on the display? An LED plugged into the ZIF test socket showed that the program was already running by its flickering. On the oscilloscope you could also see the impulses of the display control. Luckily I have two of these testers and the other display worked right away. Since both displays work on the 328 controllers, a comparison of the control pulses showed that only one could follow the faster HARDWARE SPI. I then switched the adapter to BITBANG-SPI for the test and the "slower" display now also works on the 644 adapter. The current fill level of the Atmega644 is at Program: 74.4%, Data: 7.0% and EEPROM: 73.5% The second adapter then gets an Atmega1284! Greeting Horst
Horst O. schrieb: > Der Platz unter dem Display ist nicht so üppig und ich endschied mich, > den Adapter von unten mittels einer zweiten IC-Fassung einsteckbar > anzubringen. Prima Idee! Da wäre ich jetzt nicht drauf gekommen. ;-) Gruss Asko
Horst O. schrieb: > Der zweite Adapter bekommt dann einen Atmega1284! Gerade frisch eingetroffen. Nach dem Motto wenn schon, denn schon. Ich habe ja auch von Boleslaw zwei Platinchen bekommen. Aber einlöten werde ich die nicht gleich, da muss ich eine "ruhige Minute" abwarten. Sonst zitter ich den irgendwohin, aber nicht dahin wo er hin soll. Jetzt muss ich erst mal die Compilierumgebung wieder flott machen. Ist ja schon ein paar Jahre her, wo ich damit rumgemacht hatte. Mal sehen ob ich das mit Win11 hinbekomme. Oder würde das auf einem Raspi auch funktionieren? Ich bin aber nicht so der Linux-Freak. Wegen SSD-Absturz und später Rechnerwechsel ist so gut wie nix mehr da. Selbst meine eigenen Layouts habe ich hier aus dem Forum wieder zurückgelesen. ;-) Ich hab den gesamten Faden jetzt mal neu von vorne bis hinten gelesen. Da hab ich über 2 Wochen für gebraucht. Angestachelt wurde ich von Boleslaw und R. H. mit Ihrem Addon-Board. Deswegen hatte ich auch meine "Leiche" wieder herausgekramt. Ich hatte mir damals ein fertiges Board mit M644 zugelegt, und der AY-AT verschwand in irgendeiner Kiste. Aber beschriftet mit "T-Tester". Deswegen musste ich auch nicht besonders lange suchen. Beruflich bedingt, ich habe beruflich nichts mit Elektronik zu tun, hatte ich auch jahrelang gar keine Zeit/Ambitionen/Lust die Sache weiter zu verfolgen. Jetzt habe ich wieder Zeit (und Lust) für sowas. Genau zu dem Zeitpunkt der Wiederinbetriebnahme des AY-AT kam eine Bekannte mit einer defekten Pumpensteuerung. Und siehe da, ich konnte einen defekten Elko ausfindig machen. Ersatzteil war bei der heutigen Lieferung dabei. Mal sehen ob das Ding morgen funktioniert. Bevor ich hier weiter schreibe muss ich mich wohl erst einmal bei Boreslaw persönlich bedanken. Gruss Asko
Horst O. schrieb: > Der Platz unter dem Display ist nicht so üppig und ich endschied mich, > den Adapter von unten mittels einer zweiten IC-Fassung einsteckbar > anzubringen. hi, total überflüssiger Aufwand und zudem sieht die Lösung nicht gerade gut aus. Auch mit dem etwas dickeren PCB Material von Boleslaws Adapter ist da noch genügend Platz unter dem Display wenn man den Adapter nur mit kurzen Stiften bestückt so wie in meinen Bildern vom 02.06. zu sehen.
:
Bearbeitet durch User
Es tut mir leid, dass ich diesen ungeheuer langen Thread mit meinem Anliegen einfach kapere. Hintergrund ist, dass ich die Transistortester-Entwicklung einfach ein paar Jahre nicht verfolgen konnte. Ich hatte ursprünglich eine Platine mit ATmega328 und DOGM-Display und PWM-Helligkeitsknopf. Moritz Augsburger hatte das entwickelt und hier überflüssige Platinen verkauft. Der Transistortester funktionierte hervorragend, nur war der Einbau in ein Gehäuse sehr schwierig (Zugänglichkeit der Bedienknöpfe). Daher habe ich das ganze Projekt demontiert und mir folgenden von Reichelt gekauft: JOY-IT LCR-T7 Komponententester kurzes Fazit: - Grafik-Display großes Plus - LiPo-Akku mit USB-Lademöglichkeit schön und gut - Messstrippen etwas billig - Gehäusetechnik hakt (Bedienknopf) ABER: Es können keine J-FETS gemessen werden! Es wird immer "Z-Diode" angezeigt. Messgenauigkeiten überhaupt etwas fraglich, es wird hier und da auf "falsche Bauteiltypen eingerastet", so kommt es mir vor. Ich habe lieber einen Transistortester, bei dem ich Hardware UND Software genau kenne. Frage (nach so vielen Jahren der Abstinenz vom Thema): Was muss ich tun, um einen genauen, zuverlässigen Tester zu bekommen, der robust in ein Gehäuse einbaubar ist? Notfalls entwerfe ich mir selbst eine Platine mit KiCAD, die ich bei JLCPCB oder PCBway fertigen lasse. Ich habe nur den Anschluss zu der neuesten Hardwareversion verloren. "Boleslaw" sagt mir nichts. Kennt noch jemand die Vorteile von DOGM-Displays? Die sind taghell und glasklar, aber sehr zerbrechlich. Oder den Ansatz von Moritz Augsburger? Jegliche Hilfe ist willkommen! Christian
Christian S. schrieb: > "Boleslaw" sagt mir nichts. Bei dem Adapter Projekt von Boleslaw und mir geht es um den Austausch des ATM328 gegen den ATM644 wegen des größeren Speichers und Boleslaws Firmware zum messen von IR Komponenten. Die Platine passt aber nur zum AY-AT Tester und ggf. anderer Tester mit gesockeltem ATM328 siehe die Beiträge ab 28.03.2023! Als DIY Projekt mit ATM644 kenne ich nur den MEGA4GSL --> Beitrag "Re: Transistortester AVR" Dein LCR-T7 sollte auch einen ATM644 haben, schon mal mit einer anderen Firmware versucht? Sitzt da ein ATM324 drin lässt er sich gegen den ATM644 problemlos austauschen (vorausgesetzt man kann SMD löten)!
:
Bearbeitet durch User
Vielen Dank R. H., die Fingerzeige helfen mir schon mal. Ich bin im Allgemeinen firm mit avr-gcc, WinAVR, avrdude und so weiter. Löten von SMD-ICs bekomme ich auch hin. Nur mit dem Weg, den das Hardwareprojekt im Groben und Ganzen genommen hat, kenne ich mich weniger aus. Ich nehme an, dass "AY-AT" mal eine kommerzielle erhältliche Hardware mit ATmega328 war, oder? Beim compilieren der Firmware wird ja allgemein folgendes gemacht:
1 | cflags+=-Dhardwarefeature1 |
2 | cflags+=-Dhardwarefeature2 |
3 | ...usw. |
Wo kann ich nachlesen, welche -Dhardwareflags mein LCR-T7 benötigt? Danke schon mal im Voraus! Christian
Christian S. schrieb: > Jegliche Hilfe ist willkommen! Hallo, ich verfolge die Diskussion hier auch eher sporadisch, aber ich denke die beste Dokumentation, um auf den "neuesten" Stand zu kommen, ist immer noch die "offizielle" Doku https://raw.githubusercontent.com/Mikrocontroller-net/transistortester/master/Doku/trunk/pdftex/german/ttester.pdf und der Artikel https://www.mikrocontroller.net/articles/AVR_Transistortester Wenn es um konkrete HW geht, musst Du Dir überlegen, welche Zusatzfunktionen (z.B. LC-Messung etc.) Dir wichtig sind und dann z.B. diese Diskussion vom neuesten Beitrag hin zu älteren Beiträgen auf ein Platinenlayout durchforsten - oder hier nochmal fragen.
Christian S. schrieb: > Jegliche Hilfe ist willkommen! Hallo Christian, Dein Tester hat einen kleinen Haken. Dort wird ein extra Controller für die Tastensteuerung benutzt. Bei Softwareänderungen ist dieser Chip entweder neu zu programmieren oder zu entfernen und durch eine Transistorschaltung zu ersetzen. Egal ob jetzt da ein M324 oder M644 drin werkelt. Genauere Hinweise können Dir Markus(madires) oder Horst O.(obelix2007) geben. Im eevblog zum gleichen Thema hat User Indman mal eine Liste der meistgehandelten Transistortester veröffentlicht. Allesamt Made in China. Die hänge ich mal an. Gruss Asko
Christian S. schrieb: > Jegliche Hilfe ist willkommen Hallo Christian, Asko hatte erste Hinweise gegeben - um die Software zu ändern, muß zunächst die Hardware geändert bzw. ergänzt werden: Die Einschaltdauer wird von einem kleinen Chip gesteuert und ist nicht mit der Standartsoftware kompatibel. Man kann den neu programmieren oder gegen eine kleine 2-Transistorschaltung tauschen. Desweiteren muss ein Programmier-Steckverbinder angebracht werden. Beitrag "Re: Transistortester AVR" Abhängig von deiner bevorzugten Software (Karl-Heinz Kübbeler KH-1.13 oder Markus Reschke CT-m1.49) ist die Konfiguration etwas unterschiedlich - bei KH nur über das Makefile, bei Markus über Makefile, config.h und config_644.h. https://github.com/madires/Transistortester-Warehouse/tree/master/Firmware/m-firmware Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > Die Einschaltdauer wird von einem kleinen Chip gesteuert und ist nicht > mit der Standartsoftware kompatibel. Man kann den neu programmieren oder > gegen eine kleine 2-Transistorschaltung tauschen. Desweiteren muss ein > Programmier-Steckverbinder angebracht werden. Ich habe im EEVblog ein wenig weiter gelesen. Es gibt wohl mittlerweile ein paar Ausführungen die diesen Chip nicht mehr benutzen. Dafür aber ein paar Ausführungen, die einen anderen Controller verwenden, der (noch) nicht "upgradable" ist. Und die dazu noch "Fake" beschriftet sind. Es betrifft wohl die Boards, die mit 32-poligen Controller ausgeliefert werden. das "kann" ein originaler Atmel ATMega328 sein, muss aber nicht. Es wird Christian nichts weiter übrig bleiben nach dem Erhalt des Gerätes, das Ding erst mal aufzuschrauben und nachzusehen. Und am besten Fotos machen und hier teilen. Und dann zu entscheiden, behalte ich es, oder schick ich es als unbrauchbar zurück. Es gibt ja von den ganzen Testern eine schier unendliche Variantenvielfalt, gerade bei den als TC-xy bezeichneten. Ich hatte ja letztens eine Liste hier angehängt. Die war von 2021, die hat sich ja mittlerweile mehrfach überholt. Ich hänge mal die Liste von Ende letzten Jahres an. (falls die noch jemand nicht kennt) Und es kommen immer noch neue Clone hinzu. Letztens fand ich dieses hier, was ich noch nicht kenne: https://www.amazon.de/Transistor-Tester-Frequenz-Englische-Vollversion/dp/B0BTT5H1CC/ref=rvi_sccl_2/259-6963354-0944345 Dort sind im Gegensatz vom AY-AT alle Schraubanschlüsse auf der User-zugewandten Seite. ich bin ja mal gespannt, was da für ein Controller drauf ist. Gruss Asko
Hello everyone, could you help me to modify the language of the TransitorTest. Since when you want to compile it with WinAVR it throws an error I leave a block of notes for you to review the error..
Anything you want to modify or compile don't do I have uploaded modification video
DiagSoftware schrieb: > Since when you want to compile it with WinAVR it throws > an error > I leave a block of notes for you to review the error.. Some time ago my Windows PC came up with the same error (for short: =================================================================== 0 [main] sh 5812 sync_with_child: child 1264(0x1D4) died before initialization with status code 0xC0000142 35305 [main] sh 5812 sync_with_child: *** child state waiting for longjmp) =================================================================== Start a Windows Console and type "make --version". make should answer with the following message: =================================================================== C:\Users\md\console2>make --version GNU Make 4.2.1 Built for Windows32 Copyright (C) 1988-2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =================================================================== If you get a different prompt, you're having the same problem that I had, i.e. the wrong make utility. I traced down this error to a make utility that was incompatible with avr-gcc since it doesn't understand the gcc make syntax, it issues the cited error messages. The Delphi IDE that I had installed, changed - without warning of course - the default path environment variable to point to its own make.exe. So when I called "make xyz", the Delphi make.exe was run. So, imho, what you can try is to edit your path variable to put the avr-gcc related parameters before any other compiler's perameters. You might also try to call make and all other GNU utililities with a fully specified path. I don't know if thats possible with winavr. In any case, the test call of make must give the result above. What I finally did is to cut the gordian knot all together, and I now use the Windows Subsystem for Linux to compile avr-gcc source files. When you grant access to your linux user folders, where avr-gcc stores its results, you can read the compiled files from windows. I hope this helps, derri
:
Bearbeitet durch User
Marcel D. schrieb: > DiagSoftware schrieb: >> Since when you want to compile it with WinAVR it throws >> an error >> I leave a block of notes for you to review the error.. > > Some time ago my Windows PC came up with the same error (for short: > =================================================================== > 0 [main] sh 5812 sync_with_child: child 1264(0x1D4) died before > initialization with status code 0xC0000142 > > 35305 [main] sh 5812 sync_with_child: *** child state waiting for > longjmp) > =================================================================== > > Start a Windows Console and type "make --version". > make should answer with the following message: > =================================================================== > C:\Users\md\console2>make --version > GNU Make 4.2.1 > Built for Windows32 > Copyright (C) 1988-2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html>; > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > =================================================================== > > If you get a different prompt, you're having the same problem that I > had, i.e. the wrong make utility. > > I traced down this error to a make utility that was incompatible with > avr-gcc since it doesn't understand the gcc make syntax, it issues the > cited error messages. The Delphi IDE that I had installed, changed - > without warning of course - the default path environment variable to > point to its own make.exe. So when I called "make xyz", the Delphi > make.exe was run. > > So, imho, what you can try is to edit your path variable to put the > avr-gcc related parameters before any other compiler's perameters. You > might also try to call make and all other GNU utililities with a fully > specified path. I don't know if thats possible with winavr. In any case, > the test call of make must give the result above. > > What I finally did is to cut the gordian knot all together, and I now > use the Windows Subsystem for Linux to compile avr-gcc source files. > When you grant access to your linux user folders, where avr-gcc stores > its results, you can read the compiled files from windows. > > I hope this helps, > derri C:\WINDOWS\system32>make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32
I have solved the compilation using Win7.. The problem I have now is that when I changed the language some characters disappeared... Link video the error https://mega.nz/file/qtIGnRwD#0xP_Qwhrt2_Yz4XMayIOXxPZRly7LgNIcMBDz51E0OA
DiagSoftware schrieb: > when I changed the language some characters disappeared... This may be a feature of this 2x16 LCD display, which in the second half of the character table (codes 128 to 255) does not contain the characters used here, instead has spaces, filled with bytes of 0xFF.
Boleslaw J. schrieb: > DiagSoftware schrieb: >> when I changed the language some characters disappeared... > > This may be a feature of this 2x16 LCD display, which in the second half > of the character table (codes 128 to 255) does not contain the > characters used here, instead has spaces, filled with bytes of 0xFF. With the default language it works perfectly. It only fails when I select another language already modified
DiagSoftware schrieb: > With the default language it works perfectly. It only fails when I > select another language already modified Quote from the file "language-dependent_characters.h": #elif defined LANG_SPANISH PIX_a_acute /* 0x80 a_acute e1 */ PIX_c_cedil /* 0x81 c_cedil e7 */ PIX_e_acute /* 0x82 e_acute e9 */ PIX_i_acute /* 0x83 i_acute ed */ PIX_o_acute /* 0x84 o_acute f3 */ PIX_u_acute /* 0x85 u_acute fa */ PIX_u_uml /* 0x86 u_uml fc */ PIX_A_acute /* 0x87 A_acute c1 */ PIX_E_acute /* 0x88 E_acute c9 */ PIX_I_acute /* 0x89 I_acute cd */ PIX_O_acute /* 0x8a O_acute d3 */ PIX_U_acute /* 0x8b U_acute da */ /* PIX_a_super */ /* 0x8c a_super */ /* PIX_o_super */ /* 0x8d o_super */ /* PIX_n_tilde */ /* 0x8e n_tilde */ /* PIX_N_tilde */ /* 0x8f N_tilde */ /* PIX_updown_exclam */ /* 0x90 updown_exclam */ /* PIX_updown_question */ /* 0x91 updown_question */ All the above listed characters of the Spanish alphabet are included in the second half of the ASCII character table. The default language (English) does not use them. Change the LCD to the correct one or use the default language.
DiagSoftware schrieb: > that when I changed the language some characters disappeared... With the "k" software only the cyrillic characters are supported for a special version of character displays (2x16 lines). For all other languages besides Russian and Ukrainian, special characters are replaced by ASCII characters for the character displays. Please see the lines 405 to 533 in lcd_defines.h! Language-dependent special characters are only supported for graphic displays. For the spanish language (langSPANISH.h) special characters are not implemented now. Please see the czech language (langCZECH.h) how special characters must be handled correctly. You can find the supported special characters for all languages in the file fonts/std_defines.h ! But you should keep in mind, that all special characters are only operative for graphical displays. For character displays these special characters are replaced by ASCII characters automatically. So I don't understand, why your character display make problems with other languages. Probably you can send your Makefile to my email address, which you can find at the title page of the documentation. I will send you the compiled files back and can also test them with other hardware.
For such a popular language in the world as Spanish, it is worth implementing this language into the T-Tester program. Most character LCD displays include Spanish characters in their maps (in addition to Cyrillic and other national characters). Since it is possible to implement the Cyrillic alphabet, it is also possible to implement the Spanish. In this forum, there are certainly many developers who use Spanish on a daily basis ( in addition to C :) ) who could (and should) do so. Don't wait for someone to do it for you!
Boleslaw J. schrieb: > For such a popular language in the world as Spanish, it is worth > implementing this language into the T-Tester program. > Most character LCD displays include Spanish characters in their maps (in > addition to Cyrillic and other national characters). > Since it is possible to implement the Cyrillic alphabet, it is also > possible to implement the Spanish. > In this forum, there are certainly many developers who use Spanish on a > daily basis ( in addition to C :) ) who could (and should) do so. > Don't wait for someone to do it for you! Excellent, just got to work
Kleine Erfrischung für die Sommerpause: v1.50m - Temporäre Option UI_PROBE_REVERSED_X entfernt, da nicht länger benötigt. - Option zur Ausgabe vom Batteriestatus in der letzten Zeile nach der Ergebnisanzeige (UI_BATTERY_LASTLINE). - Option zur Anzeige eines kleinen Batteriesymbols für den Batteriestatus (UI_BATTERY). - Batterie-Symbole in den meisten Zeichensätzen ergänzt. Und manche Zeichensätze mit Testpin-Nummern mit verdrehtem Vordergrund/Hintergrund erweitert. - Option für langen Reset-Puls für LCD-Controller NT7538 im ST7565R-Treiber eingebaut (LCD_LONG_RESET). - Test-Funktion für Fotodioden (SW_PHOTODIODE). - Option für seitenweises Blättern von Menüs (UI_MENU_PAGEMODE, Vorschlag von indman@EEVblog). Beschleunigt die Menübedienung bei Grafikanzeigen. - Zwei neue Farben für colors.h (COLOR_PALE_GREEN, COLOR_PALE_RED, Vorschlag von .RC.@EEVblog). - Brasilianisch-portugiesische Texte aktualisiert (Dank an wandows@EEVblog). - Russische Texte aktualisiert (Dank an indman@EEVblog). - Polnische Texte #2 aktualisiert (Dank an Jacon@EEVblog). - Spanische Texte aktualisiert (Dank an pepe10000@EEVblog). Download auf: - https://github.com/madires/Transistortester-Warehouse/tree/master/Firmware/m-firmware - https://github.com/kubi48/TransistorTester-source/tree/master/Markus (demnächst)
Hi Boleslaw, hast Du für Markus' neue 1.50 FW-Version schon eine Anpassung für Deinen AY-AT auf Admega644/1284 Adapter? Gruß Horst Hi Boleslaw, Do you already have an adjustment for your AY-AT to Admega644/1284 adapter for Markus' new 1.50 FW version? Greeting Horst
Horst O. schrieb: > hast Du für Markus' neue 1.50 FW-Version schon eine Anpassung für Deinen > AY-AT auf Admega644/1284 Adapter? Hi, Obelix ich dachte bisher immer das wäre eh eine spezielle Anpassung der Software. Gruss Asko
Asko B. schrieb: > spezielle ... schon „speziell“, aber läuft auch auf anderen 644/1284er Testern, man muss halt die Portbelegungen anpassen. Gruß Horst
Horst O. schrieb: > Hi Boleslaw, > > Do you already have an adjustment for your AY-AT to Admega644/1284 > adapter for Markus' new 1.50 FW version? I'm working on it. Greetings, Boleslaw
Total novice here. Could anyone help me understand what might be needed to adapt or integrate this for use with the flipper zero? Is this a totally foolish thought? I figure with the GPIO and LCD alone, an addon board could be created using a standalone ATmega, etc... additionally, you can optionally set 5v on GPIO, which iirc would be of benefit. I saw other project that use the STM32 to lesser effect and seeing that the Flipper Zero uses the STM32WB55, I was curious if that could be leveraged too. welcoming any input, even if it's confirming this as a foolish idea.
...why do you want to use this if you have no clue, where is the benefit for you? Just because you have the proto board? Klaus.
The C. schrieb: > Could anyone help me understand what might be needed to adapt or > integrate this for use with the flipper zero? Is this a totally foolish > thought? The OSHW Transistortester firmwares are optimized for the ATmega architecture and it would take a major effort to port them to another MCU family. > I figure with the GPIO and LCD alone, an addon board could be created > using a standalone ATmega, etc... additionally, you can optionally set > 5v on GPIO, which iirc would be of benefit. Both OSHW firmwares already support serial output, and the m-firmware additionally remote commands. However, controlling the Transistortester from another gadget with a small screen doesn't provide any benefit over using the tester with a screen directly, IMHO. > I saw other project that use the STM32 to lesser effect and seeing that > the Flipper Zero uses the STM32WB55, I was curious if that could be > leveraged too. The Flipper Zero costs 170 bucks. A Transistortester clone is much less. It doesn't make much sense to follow that route. BTW, if you buy a Transistortester clone make sure to get one with a genuine ATmega. The models with alternative MCUs are junk.
Markus R. schrieb: > Kleine Erfrischung für die Sommerpause: > > v1.50m > ... > Download auf: > - > https://github.com/madires/Transistortester-Warehouse/tree/master/Firmware/m-firmware > - https://github.com/kubi48/TransistorTester-source/tree/master/Markus > (demnächst) Und in „gitifizierter“ Form auch bei mir, das Original: https://github.com/Ho-Ro/ComponentTester und meine Anpassung für den AY-AT (Pinbelegung leicht anders) mit 20 MHz Takt: https://github.com/Ho-Ro/ComponentTester/tree/AY-AT_20MHz
Horst O. schrieb: > ... guter Tip, mit 'CFLAGS += -flto' werden die Dateien nochmal kürzer! > Mein 'avr-gcc-7.3.0' stammt aus der Arduino-Installation. Ja, man sollte diesen Monster-Thread wirklich mal in Ruhe durchlesen, da kommen so einige gute Tips um Vorschein. Wilhelm K. schrieb: > Die alten Toolchains sind wahrscheinlich hochoptimiert von AVR. Kommen > die neuen nicht mit. Ich hatte vor einigen Tagen alle für Linux verfügbaren avr-gcc Versionen mit der Software 1.50m getestet - identische Konfiguration (aber noch ohne link time optimization „-flto“). Aufgrund der Ergebnisse habe mich dann auf die letzte 8er (8.3.0) als Default festgelegt (jetzt natürlich mit „-flto“). Danach wurde es deutlich schlimmer, die 11er und 12er genehmigen sich sogar mehr Daten als alle Vorgänger (?), bin aber dazu nicht weiter eingestiegen. Martin
1 | avr-gcc v. 12.1.0 |
2 | Program: 35988 bytes (109.8% Full) |
3 | Data: 269 bytes (13.1% Full) |
4 | EEPROM: 22 bytes (2.1% Full) |
5 | |
6 | avr-gcc v. 11.1.0: |
7 | Program: 35252 bytes (107.6% Full) |
8 | Data: 269 bytes (13.1% Full) |
9 | EEPROM: 22 bytes (2.1% Full) |
10 | |
11 | avr-gcc v. 10.1.0 |
12 | Program: 35196 bytes (107.4% Full) |
13 | Data: 251 bytes (12.3% Full) |
14 | EEPROM: 22 bytes (2.1% Full) |
15 | |
16 | avr-gcc v. 9.2.0 |
17 | Program: 35190 bytes (107.4% Full) |
18 | Data: 251 bytes (12.3% Full) |
19 | EEPROM: 22 bytes (2.1% Full) |
20 | |
21 | avr-gcc v. 9.1.0 |
22 | Program: 35190 bytes (107.4% Full) |
23 | Data: 251 bytes (12.3% Full) |
24 | EEPROM: 22 bytes (2.1% Full) |
25 | |
26 | avr-gcc v. 8.3.0 |
27 | Program: 32546 bytes (99.3% Full) |
28 | Data: 251 bytes (12.3% Full) |
29 | EEPROM: 22 bytes (2.1% Full) |
30 | |
31 | avr-gcc v. 8.2.0 |
32 | Program: 32536 bytes (99.3% Full) |
33 | Data: 251 bytes (12.3% Full) |
34 | EEPROM: 22 bytes (2.1% Full) |
35 | |
36 | avr-gcc v. 8.1.0 |
37 | Program: 32536 bytes (99.3% Full) |
38 | Data: 251 bytes (12.3% Full) |
39 | EEPROM: 22 bytes (2.1% Full) |
40 | |
41 | avr-gcc v. 7.3.0 (Arduino-Version) |
42 | Program: 32612 bytes (99.5% Full) |
43 | Data: 251 bytes (12.3% Full) |
44 | EEPROM: 22 bytes (2.1% Full) |
45 | |
46 | avr-gcc v. 5.4.0 (Debian-Stable-Version) |
47 | Program: 32742 bytes (99.9% Full) |
48 | Data: 251 bytes (12.3% Full) |
49 | EEPROM: 22 bytes (2.1% Full) |
Horst O. schrieb:
> ... guter Tip, mit 'CFLAGS += -flto' werden die Dateien nochmal kürzer!
und 'LDFLAGS += -Wl,--relax' reduziert nochmal um ca. 500 Bytes.
Attached are modified files for ComponentTester version 1.50m for m328-m644 (AY-AT) adapter.
Martin H. schrieb: > Danach wurde es deutlich schlimmer, die 11er und 12er genehmigen sich > sogar mehr Daten als alle Vorgänger (?), bin aber dazu nicht weiter > eingestiegen. Interessanterweise wird es mit Version 13 wieder deutlich kleiner, Grundlage ist dieses Setup https://github.com/Ho-Ro/ComponentTester/tree/77066735c597e81ee78742bb1c902b6356520e12
1 | avr-gcc v. 13.2.0 |
2 | Program: 33246 bytes (101.5% Full) |
3 | Program: 32524 bytes (99.3% Full) -flto |
4 | Program: 32090 bytes (97.9% Full) -flto; -Wl,--relax |
5 | |
6 | avr-gcc v. 12.1.0 |
7 | Program: 36834 bytes (112.4% Full) |
8 | Program: 35592 bytes (108.6% Full) -flto |
9 | Program: 35162 bytes (107.3% Full) -flto; -Wl,--relax |
10 | |
11 | avr-gcc v. 8.3.0 |
12 | Program: 33262 bytes (101.5% Full) |
13 | Program: 32562 bytes (99.4% Full) -flto |
14 | Program: 32044 bytes (97.8% Full) -flto; -Wl,--relax |
15 | |
16 | avr-gcc v. 7.3.0 |
17 | Program: 33332 bytes (101.7% Full) |
18 | Program: 32588 bytes (99.5% Full) -flto |
19 | Program: 32094 bytes (97.9% Full) -flto; -Wl,--relax |
20 | |
21 | avr-gcc v. 5.4.0 |
22 | Program: (> 100% Full) |
23 | Program: (> 100% Full) -flto |
24 | Program: 32034 bytes (97.8% Full) -flto; -Wl,--relax |
Hallo, mal eine kleine Frage in die Runde. Hat jemand den 644 mit der Frequenz- Quarzmessung im Einsatz? Habe mir den damals 2015 mit allen Erweiterungen aufgebaut und nun endlich etwas Zeit mich damit wieder zu beschäftigen. Ich frage deshalb, weil bei mir die Umschaltung nicht funktioniert. Soweit ich dass verstanden habe, wird über die Pins 22, 23 und 24 des Atmega644 der analoge Schalter betätigt (siehe Doku von K. H. Kübeler, Version 1.12k; Seite 32). Jedoch egal was ich im Menü auswähle, die Pins 22 - 24 bleiben auf 0V. Über eine Rückmeldung würde ich mich freuen. Jörg
Ja, zwei Pins steuern die Eingangswahl und der dritte den Vorteiler. Welche Firmware hast du laufen?
Markus R. schrieb: > Welche Firmware hast du laufen? Version 1.13k. Sollte die aktuellste Version von Hr. Kübbeler sein. MfG Jörg
Suche in config.h nach FDIV_PIN und du findest den Block mit den Pin-Zuordnungen für den erweiterten Frequenzzähler. Bei Bedarf die Ports/Pins anpassen.
Markus R. schrieb: > Suche in config.h nach FDIV_PIN und du findest den Block mit den > Pin-Zuordnungen für den erweiterten Frequenzzähler. Bei Bedarf die > Ports/Pins anpassen. Ah, danke. Werde mal gleich auf die Suche gehen.
> Markus R. schrieb: >> Suche in config.h nach FDIV_PIN und du findest den Block mit den >> Pin-Zuordnungen für den erweiterten Frequenzzähler. Bei Bedarf die >> Ports/Pins anpassen. Also gerade mal überprüft, eigentlich stimmen alle Zuordnungen. Werde mir mal einen neuen Prozessor besorgen, nicht dass der den Schlag hat. Wobei alle anderen erweiterten Funktionen gehen ja. MfG Jörg
Nochmals zu der Frequenzmessung. Mir war so, als hätte ich irgendwo mal was gelesen, dass diese Funktionalität 16 MHz benötigt. Kann das jemand bestätigen, denn dann muss ich erst den Quarz wechseln. MfG Jörg
Jörg S. schrieb: > eigentlich stimmen alle Zuordnungen ... hallo Jörg, die Zuordnungen beziehen sich einmal auf das TQFP Gehäuse und zu andern auf die PDIP
Hallo, wollte nur mal 'Entwarnung' geben. Das Problem saß wie immer vor dem Bildschirm! Wenn man die Eingänge für die Frequenz- bzw. Quarzmessung vertauscht, kann das nichts werden. Wie sagt man so schön: Kaum macht man es richtig funktioniert es auch :-) MfG Jörg
... hallo Jörg, ist Dein Transistor Tester Clon denn ein Clon vom Hiland M644 und benutzt Du die "Hiland-Software von Karl-Heinz K. (kubi48)" oder hast Du die Software auch selbst "gestrickt"? Ev. zeigst Du uns mal ein Foto? Gruß Horst
... hallo Horst, ich weiß nicht, ob es 2015 schon den Hiland gab. Mein 'Clone' ist eine komplette 'Eigenentwicklung' basierend auf dem Schaltungsdesign aus der Doku von K.H.Kübbeler, Seite 33, eingebaut in ein Hammond Gehäuse. Betrieben mit 3 LiFePO4 AAA Zellen, erweitert mit Lade- und Schutzschaltung derselben. Die Software ist die originale Version von Karl-Heinz mit einer klitzekleinen Änderung in Bezug auf die Initialisierung des DOGM-LCD. MfG Jörg
:
Bearbeitet durch User
Jörg S. schrieb: > ob es 2015 schon den Hiland gab Hallo Jörg, mein 'Hiland' habe ich Ende 2018 gekauft, das Datum vom Vorteiler IC4 entspricht wohl 27ste Woche 2017. Im Anhang einige Fotos vom Einsatz des 'Hiland'. Das Hammond Gehäuse macht einen sehr professionellen Eindruck, kann man das so noch kaufen und hast Du das selbst Beschriftet und die Durchbrüche/Bohrungen eingebracht. Auf der Hammond-Seite im Netz sehe ich es leider nicht. Gruß Horst
:
Bearbeitet durch User
Hallo Horst, hier findest Du es. Es sollte also noch verfügbar sein. http://www.hammondmfg.com/1553T.htm Ich hatte es damals bei Digikey gekauft, ist jedoch schon 8 Jahre her. Die Beschriftung habe ich auf selbstklebende, transparente Etiketten im A4 Format gedruckt. Die Schablone für die Ausbrüche hatte ich mir damals als PCB fräsen lassen. MfG Jörg PS.: Im Moment bin ich an einer neuen Version dran, welche über USB-C PD geladen werden kann und die Daten ebenfalls über diesen USB-Stecker ausgibt.
Jörg S. schrieb: > Im Moment bin ich an einer neuen Version dran ...wenn Du schon dabei bist, könntest Du doch auch noch auf ein grafisches Display umsteigen und einen Drehgeber vorsehen. So ausgerüstet kannst Du Dir auch mal die Firmware von Markus installieren? Gruß Horst
Horst O. schrieb: > ... grafisches Display umsteigen und einen Drehgeber das mit dem grafischen Display bin ich noch am überlegen, den Drehgeber finde ich an diesem Gehäuse fehl am Platz. MfG Jörg
...der ist aber "leider" super praktisch. Außer man nutzt eh fast ausschließlich den normalen Test-Mode. Klaus.
Jörg S. schrieb: > Drehgeber > finde ich an diesem Gehäuse fehl am Platz. ... man kann statt dessen "Up Down Key's" benutzen, macht die Menübedienung einfacher. Makefile: # You can also use two separate push-buttons for Up and Down instead ot the rotary encoder. # You must set the WITH_ROTARY_SWITCH to 4 for the UP/DOWN push-buttons. Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > ... man kann statt dessen "Up Down Key's" benutzen, macht die > Menübedienung einfacher. So mache ich es im Moment auch, funktioniert bestens und passt irgendwie zum Gerät. MfG Jörg
In version 1.08 of the m328/m644 adapter for AY-AT tester I used a 16 MHz SMD quartz crystal, which doubled the data transfer speed to the display on the SPI bus. Increasing the clock frequency also allows you to use additional capabilities of the tester, such as increasing the accuracy of measuring capacitors with a capacity below 100 pF and checking quartz resonators. The original 160x128 display, 1.77 inch of the AY-AT tester is too small and too dark for me. In daylight, you can't see much on it. I replaced it with a larger and brighter display - TFT 320x240, RGB, 2.8 inch with ST7789 controller. When designing the interface for the new display, I tried to take full advantage of its capabilities - also the touch screen and SD card reader. The 2.8 inch TFT display with my interface can work: - in a common, enlarged housing with the AY-AT tester, using the same 8-pin socket as the original display - in a separate housing, using an additional connection socket (on the side of the tester) and a cable connecting the tester to the display. - as a standalone device for displaying a sequence of photos from an SD card, i.e. Photo-Album. This is where the touch screen comes in handy to control the display.
...respect! Picture frame might not be a killer feature for a component tester but SD card might be interesting for reading configs / batch jobs or saving measurement data or even maybe curve traces? We just wait for some more weeks and then even tubes are testable ;) Klaus.
Klaus R. schrieb: > Wir warten einfach ab > Noch ein paar Wochen und dann sind sogar Röhren testbar ;) Hihi ;-)
Asko B. schrieb: > Klaus R. schrieb: >> Wir warten einfach ab >> Noch ein paar Wochen und dann sind sogar Röhren testbar ;) > > Hihi ;-) The idea is not as stupid as it looks. In view of the fashion for retro tube devices, a special adapter for the T-Tester could measure the amount of electron emission by the cathode of the lamp. It is possible. However, it is easier to do it in the way proposed by the authors of the following publication, using a multimeter and a lamp data sheet: https://www.bastelnmitelektronik.de/basteleien-ger%C3%A4te-und-schaltungen/basteln-mit-r%C3%B6hren/r%C3%B6hren-%C3%BCberpr%C3%BCfen/
Hallo Markus, ich möchte mit deiner Software Version einen China Clone reparieren. Sehe ich das richtig, dass man für das Erzeugen des Binaries sich die Clones Datei ansieht und alle defines an den richtigen Stellen der config.h eintragen muss? Gibt es einen Grund, warum die aktiven #define nicht mit #if !defined() geklammert sind?
1 | #if !defined(ZENER_R1) |
2 | #define ZENER_R1 180000 |
3 | #endif |
4 | ... |
5 | #if !defined(SW_IR_RECEIVER) && !defined(HW_IR_RECEIVER) |
6 | #define SW_IR_RECEIVER |
7 | #endif |
Mit Klammerung bräuchte man ja bloß den Block aus Clones oben in die config.h kopieren und wäre fertig. Ich kann das auch gerne machen und einen PR dazu.
Hi Armin! Armin J. schrieb: > Sehe ich das richtig, dass man für das Erzeugen des Binaries sich die > Clones Datei ansieht und alle defines an den richtigen Stellen der > config.h eintragen muss? Aktivieren bzw. anpassen. Und Makefile nicht vergessen! > Gibt es einen Grund, warum die aktiven #define nicht mit #if !defined() > geklammert sind? > ... > Mit Klammerung bräuchte man ja bloß den Block aus Clones oben in die > config.h kopieren und wäre fertig. Die Idee ist, dass sich jeder seine gewünschten Optionen selber aussucht. Der eine möchte unbedingt den IR-Dekoder, ein anderer vielleicht etwas anderes.
Markus R. schrieb: > Die Idee ist, dass sich jeder seine gewünschten Optionen selber > aussucht. Der eine möchte unbedingt den IR-Dekoder, ein anderer > vielleicht etwas anderes. Das verstehe ich, da schadet die Klammerung ja aber nicht, macht es vielleicht nicht mehr so gut lesbar. Mit Klammerung kann man vorgefertigte Parametersätze für Clones, was ja doch häufiger vorkommt, leichter verwalten. Wärst du bereit, die Klammerung in dein Git Repo aufzunehmen, wenn ich sie machen würde? Horst O. schrieb: > läuft also auf versch. Testern: Hallo Horst, wie verwaltest du die Parametersätze für deine Clones? Gruß Armin
Armin J. schrieb: > wie verwaltest du die Parametersätze für deine Clones? ... in Ordnern für TransistorTester und Componententester getrennt und dann nach Versionsnummer und Gerätekürzel in Unterordnern, z.B. CT-1.47m_M1284_T7_16MHz oder TT-KH-1_13_M-f_T-TC1-Mod_M644 Gruß Horst
Nochmals eine Frage in die Runde; lässt sich bei dem Referenzdesign aus der Doku von K.H.Kübbeler auch die IR-Funktionalität nachrüsten? Habe ich bis jetzt noch nichts darüber gefunden oder ist dies ein Alleinstellungsmerkmal von dem M-Tester? MfG Jörg
...naja, grdstzl geht doch immer alles - kommt halt auf den Aufwand an. HW nachrüsten, config file passend einstellen, compilieren, flashen, fertig. Klaus.
Jörg S. schrieb: > auch die > IR-Funktionalität ... die K-Software für mega644_T7_Mod gibt es, aber keine IR-Unterstützung. (der T7 und der TC-1 sind m.W. die einzigen Clone mit integr. IR-Empfänger) Gruß Horst
Klaus R. schrieb: > HW nachrüsten, config file Genau deshalb ja meine Frage, ich habe keinen Schaltplan mit IR-Unterstützung gefunden oder aber übersehen. Wenn Du einen Link hättest, der Rest ergibt sich. MfG Jörg
Jörg S. schrieb: > lässt sich bei dem Referenzdesign aus der Doku von K.H.Kübbeler auch die > IR-Funktionalität nachrüsten? Bei der m-Firmware gibt es zwei Varianten. Bei der einen wird das IR-Empfängermodul fest verdrahtet. Und bei der anderen wird das IR-Empfängermodul einfach an die drei Testpins geklemmt. > Habe ich bis jetzt noch nichts darüber gefunden oder ist dies ein > Alleinstellungsmerkmal von dem M-Tester? Der "M-Tester" ist eine modifizierte Firmware, welche nur ein IR-Protokoll (NEC) unterstützt.
Armin J. schrieb: > Das verstehe ich, da schadet die Klammerung ja aber nicht, macht es > vielleicht nicht mehr so gut lesbar. Und das dürfte zum Problem werden. Der bisherige Weg hat sich bewährt, auch wenn er nicht sonderlich anfängerfreundlich ist. Wenn ich das nun einfach ändern würde, gäbe es garantiert jede Menge Kritik von anderen Benutzern. Es ist halt einfach so, dass man es nicht allen recht machen kann. Und deshalb werde ich es auch erst gar nicht versuchen.
Markus R. schrieb: > Und deshalb werde ich es auch erst gar nicht versuchen. Never change a running system Jörg
Kann ich ein bischen verstehen. Aber die Pro's sollte das ja nicht stören, und die Anfänger werden dabei ja mitgenommen. Ausserdem ist es ja dein Code :-). Schade eigentlich, so muss jeder, so wie Horst, mit verschiedenen Kopien in verschiedenen Ordnern leben. Trotzdem Danke Armin Jörg S. schrieb: > Never change a running system So geht innovation ;-)
Markus R. schrieb: > Der "M-Tester" ist eine modifizierte Firmware, welche nur ein > IR-Protokoll (NEC) unterstützt. Ich meinte mit dem M-Tester einen Tester basierend auf dem Referenzdesign und der originalen FW von Markus, nicht so einen China-Klon. MfG Jörg PS. Habe mir jetzt nochmals die Dokumentation von M. Reschke V 1.50 durchgelesen. Dort wird immer nur auf optionale Hardware hingewiesen, jedoch kein Schaltplan. Vielleicht bin ich auch nur zu blöd.
Armin J. schrieb: > Mit Klammerung bräuchte man ja bloß den Block aus Clones oben in die > config.h kopieren und wäre fertig. > Ich kann das auch gerne machen und einen PR dazu. Gute Idee! Und wenn der PR nicht akzeptiert wird, mit ein zwei Mausklicks wird ein fork daraus...
Armin J. schrieb: > Schade eigentlich, so muss jeder, so wie Horst, mit verschiedenen Kopien > in verschiedenen Ordnern leben ... ich finde das nicht "Schade", habe 'nen großen Bildschirm und habe die Ordner übersichtlich vor mir, funktioniert seit Jahren bestens. Im übrigen ist die Anordnung in den config.h - config_xxxx und Makefile in der M-Software und in der Makefile in der K-Software ganz übersichtlich und beides ist hinreichend dokumentiert! Es gibt Beispiel-Dateien für die verschiedenen Tester-Modelle auf denen der Neuling hier leicht aufbauen kann. Gruß Horst
Horst O. schrieb: > Es gibt Beispiel-Dateien für die verschiedenen Tester-Modelle auf denen > der Neuling hier leicht aufbauen kann. Super, wo finde ich die?
:
Bearbeitet durch User
Armin J. schrieb: > Super, wo finde ich die? ... https://github.com/kubi48/TransistorTester-source Viel Freude beim Ausprobieren. Gruß Horst
Jörg S. schrieb: > PS. Habe mir jetzt nochmals die Dokumentation von M. Reschke V 1.50 > durchgelesen. Dort wird immer nur auf optionale Hardware hingewiesen, > jedoch kein Schaltplan. Vielleicht bin ich auch nur zu blöd. Für das IR-Empfängermodul braucht es nicht wirklich einen Schaltplan. Masse, Plus und Daten. Im README ist unter "IR-Empfängermodul an Testpins" beschrieben, wie das IR-Modul an die Testpins angeschlossen wird. Zu diversen Hardwareoptionen findest du unter https://github.com/madires/Transistortester-Warehouse/tree/master/Hardware Beispiele; und auch in der Doku von Karl-Heinz.
Markus R. schrieb: > Beispiele; und auch in der Doku von Karl-Heinz. Diese Dokus habe ich soweit alle durch und die Erweiterungen, welche in K.H. Doku eingezeichnet sind, sind auch soweit umgesetzt. Auch der von dir angegeben Link habe ich schon durch. Mir ging es nur darum, ob es eine Zusammenfassung der 'optionalen Hardwarerweiterungen' gibt oder ob ich diese jeweils aus den unterschiedlichen Readme's, Bildern usw. heraussuchen muss. Wie ich schon weiter oben geschrieben hatte, bin ich gerade dabei, mein Layout auf den aktuellen Stand zu bringen und da wollte ich halt alle bis jetzt erhältlichen 'Updates' einfliessen lassen. Aber so wie es jetzt aussieht, werde ich wohl 2 Tester bauen, einen mit dem normalen DOGM-Display(k-FW) und eines mit der Grafikversion, incl. dem IR-Modul und was ich sonst noch so finde mit der m-FW. MfG Jörg
Horst O. schrieb: > Viel Freude beim Ausprobieren. Das macht keine Freude :-(. "make all" im Verzeichnis mega328_T3_T4_st7565
1 | F:\Downloads\TransistorTester-source-master\trunk\mega328_T3_T4_st7565>make all |
2 | Das System kann den angegebenen Pfad nicht finden. |
3 | rm -rf ../Obj/mega328_T3_T4_st7565 |
4 | mkdir -p ../Obj/mega328_T3_T4_st7565 |
5 | Syntaxfehler. |
6 | make: *** [objdirect] Error 1 |
make Version ist: GNU Make 3.82 Built for x86_64-w64-mingw32
Armin J. schrieb: > Das macht keine Freude ... bei mir läuft das in einer "WinAVR-20100110" Umgebung mit entsprechender path-Variablen. Die mußt Du bei Dir sicher noch anpassen? Gruß Horst
Making a virtual model of graphical display with its interface is very helpful when designing a display housing for the Transistor/Component Tester. Author of the housing design - KS.
Horst O. schrieb: > ... bei mir läuft das in einer "WinAVR-20100110" Umgebung mit > entsprechender path-Variablen. Die mußt Du bei Dir sicher noch anpassen? Das ist angepasst, denn es gibt ja keinen not found sondern einen syntax Fehler.
Armin J. schrieb: > Das System kann den angegebenen Pfad nicht finden. ... Du schreibst es doch selber?
Horst O. schrieb: > Armin J. schrieb: >> Das System kann den angegebenen Pfad nicht finden. > > ... Du schreibst es doch selber? Und welcher Pfad fehlt denn nun, mal so für Anfänger? Und der Syntaxerror kommt auch wenn der Pfad nicht stimmt? "rm" und "make" (und "gcc") findet er ja anstandslos!
Armin J. schrieb: > rm" und "make" (und "gcc") ... das sind ausführbare Dateien, die beim kompilieren aufgerufen werden. bei den älteren Releases der kh-software wurden während des Kompilierens in die Obj-Ordner eine Art von Kontrolldateien geschrieben z.B. CheckRotaryEncoder.o und in einen weiteren Unterordner Dep die zugehörige CheckRotaryEncoder.o.d Datei. Bei den neueren Rev. passiert das nicht mehr. Damit wir die gleiche Sprache sprechen, sollten wir zunächst Betriebssystem, Arbeitsumgebung, und Kompilierwerkzeug abklären?
Horst O. schrieb: > bei den älteren Releases der kh-software Komisch, ich wollte eigentlich die m-Software für den TC1 Clone kompilieren (Windows, Gcc von Arduino) und das erstmal mit T3_T4_st7565 testen. Nun treffe ich auf komische Fehler und den Hinweis, dass ich wohl die k-Software am Wickel habe. Wenn das nicht mal anfängergeeignet ist! Schade eigentlich.
Armin J. schrieb: > TC1 Clone ... in den Component-Tester-Verzeichnissen von Markus befindet sich eine Datei "Clones" mit den Portbelegungen und Einstellungen für übliche Clones, u. A. auch für TC-1. Meine Mod am TC-1 u. T7: Beitrag "Re: Transistortester AVR" T3_T4_st7565 hat andere Anschlußbelegungen. Gruß Horst P.S. ev. im angef. Verz. Drehgeber rausnehmen und M644 gegen M324 tauschen. Hoffentlich hast Du keinen der neuen Fake-TC-1 mit unbekannter CPU! Übrigens läuft die K-Software auch auf dem TC-1, auch in Farbe.
:
Bearbeitet durch User
Markus R. schrieb: > Für das IR-Empfängermodul braucht es nicht wirklich einen Schaltplan. > Masse, Plus und Daten aber es ist immer empfohlen VCC vom IR Dekoder über 100 Ohm und 4,7µF Elko anzuschliessen. https://cdn3.botland.store/img/art/inne/04931_3c.jpg hat sich bei mir bewährt, ich nehme gerne den TSOP 31236 weil der mit 3,3V und 5V arbeitet und 36kHz mehr mittig liegt als übliche 38kHz TSOP und man so auch von 30-40 kHz dekodieren kann. Sehr geholfen hat die LIB von Frank ukw Forumsmoderator. https://www.mikrocontroller.net/articles/IRMP Meein Wunsch wäre eine modifizierte Transistortester Version mit dem ATmega1284p, aber ich bin zu faul oder sagen wir zu alt um das zu bauen. Sämtliche SW anzupassen und noch TFT LIB für die Grafik..... Puh ich bin kein Softi
Joachim B. schrieb: > eine modifizierte Transistortester Version mit dem > ATmega1284p Hallo Joachim, gibt es schon als DIY-Version. Ist zwar ein heftiger Drahtverhau, aber funktioniert sehr gut.
In der Doku von Karl-Heinz ist eine Schaltung mit ATmega644; und im Repo ist ein 644-DevKit (kicad). Beides kann gerne als Vorlage für einen Tester mit ATmega644/1284 genommen werden.
Schematic and PCB of 2.8 inch color TFT display interface for Transistor / Component Tester. The option with Arduino is used to display a sequence of photos from an SD memory card.
Hi B. schön das du noch so aktiv bist (an dem Sprint-Layout hast du ja auch sehr großen Gefallen gefunfen wie ich sehe) aber das wäre mir dann doch zuviel Aufwand nur um damit Bilder anzusehen, dafür habe ich ein Smartphone ;-)) ich hatte die Idee mit einem größeren Display auch schon mal und hab da den Beitrag von Yuriy_K aus dem EEVBLOG Forum gefunden wo er das an den HILAND-644 angeschlossen hat, leider sehr umständlich mit einer Adapterplatine. ich hatte dann die original HILAND Platine kopiert, vergrößert und die Anschlüsse für ein 2.4/2.8" Display sowie einen fertigen LIPO Lader von Aliexpress vorgesehen (den kann man für das Geld nicht selber bauen !) https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg4882043/#msg4882043 https://de.aliexpress.com/item/1005005278905855.html aber ich hab ja jetzt mein DSO-TC3 mit 2.4" und bin damit eigentlich ganz zufrieden. Gruß
:
Bearbeitet durch User
R.H. Thank you for your comment. I owe my progress in using SprintLayout to your valuable advice in private correspondence. I used THT technology for the display interface PCB, taking into account people with poor eyesight who would like to solder the elements on their own. In addition, there was no need for miniaturization - there was more than enough room. I like your PCB design for the Transistor Tester. However, for controlling the 3.3 volt display lines I would use a different method, not 10k series resistors. The cheap Chinese LiPo battery charger you linked to is OK, but... the battery charger should be able to equalize the voltages on the individual cells. This charger does not have that capability. Greetings, Boleslaw
Hi. B. bei Aliexpress gibt es dafür kleine PCB´s in zig verschiedenen Größen und Ausführungen die sich direkt an die Akkus löten lassen: https://de.aliexpress.com/item/1005001645794453.html Wie sollte deiner Meinung nach die Anbindung des Displays denn aussehen ? Gruß
R. H. schrieb: > Hi. B. > bei Aliexpress gibt es dafür kleine PCB´s in zig verschiedenen Größen > und Ausführungen die sich direkt an die Akkus löten lassen: > https://de.aliexpress.com/item/1005001645794453.html > Wie sollte deiner Meinung nach die Anbindung des Displays denn aussehen > ? > Gruß For two cells, I would choose a charger with a 4.2V (balanced) terminal. Q: What do you think the connection of the display should look like? A: Same as in tester AY-AT. If the Vcc of the display is 3.3 V and the Vcc of the controller is 5 V, then the display can be controlled, for example, by a 74HC4050 chip, powered by 3.3 V.
R. H. schrieb: > hatte dann die original HILAND Platine kopiert Hallo R. H., hast Du von der Platine welche anfertigen lassen und ev. ein Exemplar für mich zum Verkauf? Meinen org. Hiland-M644 hab ich schon sehr "verbastelt" und 'ne Version mit größerem Color-Display fände ich sehr schön. Gruß Horst
Hello Horst, Pay attention to the supply voltage of the display on this PCB from R.H. If you have a display at 3.3 volts on Vcc, that could be a problem, because that's where the 5 volt power line comes in on the PCB. Greetings, Boleslaw
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.