Announcement: there is an English version of this forum on 
Hallo zusammen ich habe mit einem Projet angefangen, mit dem man die Kapazität von Akkus messen kann. Eine genaue Beschreibung des Projekts findet ihr in der Artikelsammlung "Akku Tester". http://www.mikrocontroller.net/articles/Akku_Tester Vieleicht habt ihr ja lust euch das anzusehen. Ich würde mich über jede Art von Feedback freuen und auch gerne Fragen beantworten. MfG Philipp
Hi, Ich finde das Projekt eine gute Idee! Was mir daszu noch einfällt: 1. Weiß nicht ob du das machst, aber die Spannung der Akkus sollte Stromlos gemessen werden damit die Übergangswiderstände die Messung nicht verfälschen. 2. Bildet eine Impulsförmige Entladung das selbe Ergebnis wie eine Gleichbleibende Entladung? 3. Wäre cool wenn man am PC die Kiste Parametrieren könnte, denke da an Einstellung der Entladeschlussspannung, Entladestrom evtl. max Akkutemperatur. Automatisches Entladen / Laden mit unterschiedlichen Entladeströmen. 4. Bei einem dicken Akkupack macht manchmal nur 1 Akku schlapp. Wäre gut wenn beim Entladen alle Zellspannungen gemessen werden können. 5. Eine Ladefunktion für Lipo mit Balancer, NiCD, NimH wäre auch praktisch, ist nur viel Arbeit.
>Klaubunde
Könntest Du das BITTE mal korrigieren :(
Das erste 'u' gehört da nicht hin.
Michael wrote: > Hi, > Ich finde das Projekt eine gute Idee! > Was mir daszu noch einfällt: > > 1. Weiß nicht ob du das machst, aber die Spannung der Akkus sollte > Stromlos gemessen werden damit die Übergangswiderstände die Messung > nicht verfälschen. Gut wäre auch eine sog. Kelvin-Verbindung, d.h. eine extra Leitung für plus und minus für die Spannungsmessung, die exakt am Akku befestigt wird. So kann der Spannungsabfall in den Leitungen abgefangen werden. ( Ich hab fast das gleiche in der Arbeit gebaut und entlade ca. 20W. Da erreiche ich fast 0.5V und mehr Spannungsabfall auf der Leitung. > 2. Bildet eine Impulsförmige Entladung das selbe Ergebnis wie eine > Gleichbleibende Entladung? Ist keine Impulsförmige Entladung, da die PWM über ein RC-Filter geglättet wird. > 3. Wäre cool wenn man am PC die Kiste Parametrieren könnte, denke da an > Einstellung der Entladeschlussspannung, Entladestrom evtl. max > Akkutemperatur. Ja, find ich auch. > Automatisches Entladen / Laden mit unterschiedlichen Entladeströmen. Nö, find ich nicht > 4. Bei einem dicken Akkupack macht manchmal nur 1 Akku schlapp. Wäre gut > wenn beim Entladen alle Zellspannungen gemessen werden können. Ich sehe aber noch ein Problem: Bei meiner Schaltung hatte ich Probleme mit Schwinugungen, d.h. der ganze Lastkreis hat bei verschiedenen Situationen zu schwingen begonnen, ich habe einen Kondensator von ca. 470n als Gegenkopplung beim OPAMP eingebaut. Dann funktionierte es einwandfrei! Die SD-Karte find ich geil. Ich werd mal den Souce code anschauen. Ich verwende für mein Projekt den MSC1210 der hat nen 24bit ADC. Ich kann die Spannung ohne grossen Stress auf 1mV genau messen. Den Strom ebenfalls mit 1mA Genauigkeit. Kannst Du deine Schaltung auch kalibrieren? Ich habe bei mir einen Offset und ein Gain vorgesehen, diese Faktoren linke ich in einer *.h-Datei dazu. Somit kann ich das exakt kalibrieren, wenn ich will.
Die Wunschvorstellung eine Akkukapazität so einfach ableiten zu können wie z.B. mit einem Voltmeter die Spannung zu messen, (Drannhalten und ablesen) wird wohl für immer ein Traum bleiben. Wenn man sich mit den Akkuherstellern unterhält bekommt man meisst eine lapidare Aussage im Sinne von: "Kapazität hängt von Einsatzzweck, Alter, Lade-/Entladestrom ab". Nur leider habe ich noch nie eine Kapazitätskurve eines Akkus entdeckt die auch nur von einem angenommenen Fall ausgeht, und einem eine ungefähre Schlussfolgerung über die verbleibende Kapazität verrät. Insbesondere über die Lebensdauer von Solarakkus wurde ich schon oft schockiert. Teilweise erreichten diese nicht einmal die halbe angegebene Lebensdauer. Mein lauter Verdacht ist einfach das, a) die Hersteller-Kapazitätsangaben weit nach unten korrigiert werden müssten, wenn wir die Kapazität einfach messen könnten. b) Die Hersteller bewusst eine längere Lebensdauer angeben, da man sich ja immer auf "falschen Einsatzzweck" hinaus reden kann. (Diese Standardaussage habe ich nur leider schon all zu oft gehört). -> Stichwort Autobatterie! Wenn man das zu Grunde legt, denke ich, Akkuhersteller haben sehr wohl die Möglichkeit die verbleibende Akkukapazitäten bereits beim Ladevorgang hoch zu rechnen. Sie würden sich damit nur selbst Schaden wenn sie diese Techniken veröffentlichen würden. Besonders in dynamischen Prozessen wie z.b. Solarakkuladung, würde sich eine ständige Messung von Ladung - Entladung anbieten, aus der sich dann alle herstellerspezifischen Unbekannten wie Alter, Einsatzzweck ect. ganz einfach Ableiten lassen. Ich geh sogar noch einen Schritt weiter, daraus könnten sogar Pflegetips für Akkus automatisiert ausgegeben werden. Aber bissher hab ich noch kein Solarakkuregler gesehen der eine Auskunft über die Verfassung seines "Schützlings" preisgibt. Bleibt nur zu hoffen das jemand eine geniale Schaltung entwirft die aus der Ladestromkennlinie eine "reale" Kapazitätsangabe berechnet. Gruss Chriss
Angehängte Dateien:
-
Sallen-Key-Filter.png
1,22 KB, 2800 Downloads
Hi, den Apparat aus modernster Hochtechnik* habe ich mir gestern/vorgestern schonmal angekukkt, sowas suche ich noch, sowas universelles eben. Es reicht mir vollkommen aus, wenn ich die Akkus mit verschiedenen Strömen entladen kann, also nen 14Ah Akku z.b. mit 200mA oder auch mit 3A. Noch cooler wäre, wenn mehr als ein Akku gleichzeitig gehen würde. Anhand der Meßwerte kann ich ja selber entscheiden, ob ich die Akkus weiter benutze oder weg damit. Außerdem weiß ich dann auch, welcher Akku unter Last bei einem 4er Pack z.B. als erster abschlafft. Von der Rechenleistung schafft der Prozessor das, aber wie es mit dem Handling dann aussieht...... Der Tiefpaß zur Generierung einer Gleichspannung aus einer PWM läßt sich sehr gut mit einem Sallen-Key-Filter machen, besser als mit einem einfachen RC-Tiefpaß. Siehe Anhang & Wikipedia, auch zur Berechnung. Die Formeln bzw. Rechenschritte dazu: 1) Cutoff-Freq. festlegen, z.B. f_o = 10kHz wegen Störungen bei 50 kHz f_Sig < 5 kHz (input) 2) C2 = 10 pf .... 100 nF 3) C1 = 2x C2 4) R1 = R2 = 1/(2*pi*f_o*C1*sqrt(2)) Wie das jetzt genau zusammenhängt mit C2 von 10 pF bis 100 nF weis ich auch nicht mehr, habe hier nur meine Notizen abgeschrieben. Aber ich denke mit Filter ist schon vorteilhafter. Dann wäre noch super, wenn man zur Log-Datei einstellen könnte, ob mit Semikolon die Werte getrennt sind oder mit Tabulator. Mit Tabulator hat den Vorteil, daß man die Datei direkt ankukken kann und die Meßwerte spaltenweise passend übereinander stehen. Außerdem kann man die Daten dann mit gnuplot sich ausgeben lassen, auch wenn es mehr als 16000 Zeilen an Daten sind. Office-Proggis machen da schlapp. Und Office-Proggis können auch mit Tabulator getrennte Datenfelder importieren. Dann wäre vllt. noch vorteilhaft, den Akku wahlweise mit einem konstanten Strom oder mit einem konstanten Widerstandswert zu entladen. Achso, bevor ich's vergesse. Den Namen.... >>Klaubunde >Könntest Du das BITTE mal korrigieren :( >Das erste 'u' gehört da nicht hin. ....ich hab's mal eben schnell korrigiert. Mehr fällt mir zu dem allermodernsten Hochtechnologiemaschienegerät* nicht ein, so spontan. *) Begriffierungen geklaut aus Ion Tichy Raumpilot, Teil 1-6
Erstmals danke für die zahlreichen Antworten @Michael 1. Ich habe meinen Akkutester für grosse Ströme ausgelegt, damit ich die Akkus realistisch Belasten kann. Ich habe das vorallem gemacht, um Modellbauakkus zu Testen, und da will ich wissen, wann er auf einer gewissen Spannung entladen ist. Es nützt mir nichts, wenn er sich nach einer Gewissen Zeilt erholt, denn bis dann habe ich den Akku gewechselt. Wenn du die Kapazität dennoch genau wissen möchtest, dann kanst du ihn mit einem kleinen Strom entladen, damit es keine grossen Verlüste an übergangswiderständen gibt. 2. Wiss ich nicht genau, wenn du mit einem Impulsförmigen Strom aber grosse Stromspitzen meinst, dann wird das Resultat sicher anders rauskommen, denn je grösser der Strom desto grösser der Verlust im Akku drinnen. 3. Eine grosse Sache wäre das eigentlich nicht, doch wennschon dann möchte ich das ganze Plattformenunabhängig und OpenSource machen. Ich kenne mich da leider nur mit VB6 aus und das läuft nur auf Windows, wobei Vista auch schon ein Problem ist. Falls aber jemand lust hat so ein Programm in JAVA zu schreiben, dann werde ich das in der uP-Software gerne ergänzen. 4. Wäre schön, gibt aber viel Hardwareaufwand und ich wollte es so einfach wie möglich halten, damit es auch etwas für nicht sehr versierte Elektrobastler ist. 5. Laden ist eigentlich nicht vorgesehen, und LiPo ist da eh heikel. (Temperatur >70°C = Booomm) @Holger Sorry. Da war jemand schon schneller als ich. @Frank 1. Mit Schwingungen hatte ich bis jetzt noch kein Problem, hängt aber wahrscheinlich auch vom OP ab. 2. Externer ADC ist zar toll kostet abe besonders wenns ein 24bit ist. Mit meiner schaltung kann man auf 10mA und 53mV genau messen. Ich denke das reicht, da andere Einflüsse (z.B. Temperatur, vorheriger Ladezustand usw.) grössere Einflüsse auf das Resultat haben. 3. Kalibrierung ist bei mir überflüssig, da alleine die Tolareanz des Leistungswiderstandes einiges über dem des ADC liegt. @Chris Herstellerangaben sind immer so eine Sache. Die Kapazität und Lebensdauer hängt von so vielem ab, und das ist auch der Punkt warum ich sagte, dass ich die Spannung nicht im Stromlosen Zustand messe, denn dann wäre es meiner Meinung nach nicht mehr Realitätsgetreu. Hilt also nur eines, den Akku unter Realen bedingungen ausmessen, und das ist genau das, was ich mit diesm Projekt erreichen will. @Hegy 1. Die Schaltung werd ich mir mal genauer ansehen und ausmessen. 2. Ich hab da einfach mal das ";" genommen, aber du hast gute gründe füe einen Tabulator, ich werde das in der nächsten Version ändern. 3. Wenn du den Akku mit einem konstante Widerstand entladen möchtest, ist das ganze nicht mehr universell einsetzbar oder wa spricht für einen konstanten Widerstand? @Alle Bei den Logdateien hatte ich mir überlegt, für den Dateinamen einen Zähler anzuhängen, der bei jeder Messung eins raufzählt, damit man mehrere Messungen auf einer Karte speichern kann. Der Zähler wird dann ebenfalls im EEPROM abgespeichert. Oder hat sonst jemand eine Idee, wie man einen Dateinamen mit einem Drehknopf und einer Taste einstellen kann?
Mit Drehgeber und Taster (als Teil des Drehgebers) kann man mehrere unterschiedliche Eingabeformen unterscheiden: - nur drehen (links / rechts) - gedrückt drehen (links / rechts) - kurz drücken (ohne drehen) - lang drücken (ohne drehen) - mehrmals kurz hintereinander drücken (vor Anlauf eines Timeouts) KH
Die Antwort zu deiner Frägh >3. Wenn du den Akku mit einem konstante Widerstand entladen möchtest, >ist das ganze nicht mehr universell einsetzbar oder wa spricht für einen >konstanten Widerstand? Warum nicht mehr universell einsatzbar? Jeden Akku kann ich mit einem Widerstand (z.B. Glühlampe) entladen. So habe ich bisher meine Akkus auf Funktion gecheckt. Ist zwar nicht korrekt bzgl. Ah auszurechnen, aber mir ging es darum, wielange der ungefähr hält und als Vergleich gegenüber den anderen. Mal nen paar Fragen/Anmerkungen zur Projekt-Hardware. a) Was, wenn der Akku verpolt angeschlossen wird? b) wenn ein Hochstrom-Akku angeschlossen ist, eine einzelne Zelle mit 1,24V, und soll z.B. mit 1A oder mehr entladen werden. Da stört dann der R17 mit 1R8. Läßt sich das noch optimieren? c) der Spannungsteiler aus R12 und R13, der die Akku-Spannung an den Controller zürckmeldet, scheint mir sehr hoch dimensioniert zu sein. Angenommen, der Eingangspin kann nur 5V ab (max. ADC Input Voltage lt. Datenbladl ist max. AVCC = Ub), dann wird es erst bei Akkuspannungen von 55V kritisch. Ich denke mal bei 15V (Kfz-Akku + Reserve) wäre schon ok, dann wäre auch die Spannungsauflösung höher. Um den Eingangspin zu schützen, eine Z-Diode davor. Warum ist überhaupt der 100nF Kondensator C17 drin? d) der Elko C10 am Ausgang für den Lüfter ist mir noch ein Rätsel. Warum soll der den Transistor entlasten. Ist der Elko etwas entladen und wird der T1 durchgesteuert, wird der Lüfter mit Strom versorgt und auch der Elko geladen, wobei diese Stromspitze bei fast leerem Elko und 100µ ziemlich heftig ausfällt. Ich weiß nicht, wie hoch die PWM dazu ist, aber aufgrund der Massenträgheit des Lüfterrads würde ich den Elko weglassen oder aber, die PWM mit jenem Sallen-Key-Filter zu einer sauberen Gleichspannung machen, die den Transistor und damit den Lüfter steuert. Oder direkt die PWM auf einen MOSFET, BS170 oder sowas.
Nochmal was zur Plattformunabhängigkeit. Ich habe das Projekt nicht "gemaket" bekommen, weil es unter modernen Dateisystemen ein Unterschied ist, ob es KS0108.h heißt oder ks0108.h. Daher bitte drauf achten, wenn es denn wirklich Plattform unabhängig sein soll, daß im Makefile und in den Include-Statements die Dateinamen gleich GROSS oder klein geschrieben sind und mit dem Ist-Bestand auf der Platte checken. Ich habe jetzt kurzerhand alle Dateinamen klein geschrieben und auch in den Files das mal geändert, um mal zu sehen, wie groß das ganze teil wird. Lösung 25996 Byte. Und dann mal ne Frägh: So'ne Dingers versteht mein avr-gcc nicht (Ver. 4.10) data |= 0b00000010; Die Schreibweise 0bxxxxxx ist es, mußte ich auch manuell ändern. Was muß ich tun, damit der's frißt?
Das Projekt ist doch in der Rubrik "Wettbewerb". Sind da auch Gemeinschaftsprojekte vorgesehen?
Hegy wrote: > Und dann mal ne Frägh: > So'ne Dingers versteht mein avr-gcc nicht (Ver. 4.10) > data |= 0b00000010; > > Die Schreibweise 0bxxxxxx ist es, mußte ich auch manuell ändern. > Was muß ich tun, damit der's frißt? Einen passend gepatchten gcc nehmen. Ich habe meinen vor einem halben Jahr selbst uebersetzt und musste auch erst die neusten AVR-Patches manuell hinzufuegen. Die aktuellen Versionen im Studio sollten aber AFAIK o.k. sein...
Hallo zusammen @Hegy 1. Du kannst den Widerstand auch durch eine Lampe ersetzen und den Strom voll Raufdrehen, daher wird der PWM auf 100% nun du entlädst mit deinem Widerstand. 2. Mit dem Verpolungsschutz hab ich mir zuerst auch den Kopf zerbrochen, aber ich habe jetzt eine Lösung. Man kann vor den Transistor eine Diode oder besser eine Schottkydiode einbauen. Der Proz schützt sich selber, da er am Eingang zwei Dioden hat und da der Spannungsteiler Hochohmig ist fliesst da nur wenig Strom 3. Ein 1.24 V kann man eben nicht mit vollem Strom entladen und irgendwo hat jedes Gerät seine Grenzen. 4. Um die Spannung un den Strom zu messen verwende ich die interne 2.56V Referenz oder AVCC (5V) somit ist die Auflösung bei kleinen Spannung hoch und bei den höheren Spannung ist dann der Prozentuale Fehler etwa gleich gross, obwohl die Auflösung weniger genau ist. Der Kondensator C17 ist um Störungen vorzubeugen. 5. Auch in der Lüfterschaltung arbeitet der Transistor als Spannungsfolger. Der Kondensator soll die Stomspitze abfangen, die der Lüfter duch das interne Schalten verursacht. Der PWM hat mit dem ganzen eigentlich wenig zu tun, da der Transistor mit einer Analogspannung angesteuert wird. 6. Das mit den Dateinamen ist mir noch gar nicht aufgefallen, aber auch das werde ich in der nächsten Version ändern. 7. Ich verwende den AVR-GCC 4.3, daher würde ich dir raten ein Update zu machen. Ich werde noch ein Hinweis anbringen, dass der Source mit AVR-GCC 4.3 kompiliert ist. @Anna Ja, das ist erlaubt. Zudem ist das hier eine Community und der Sinn einer Community ist, dass man sich gegenseitig hilft. mfg Philipp
Hallo Hegy ich hab jetz mal probiert meine Dateien auf kleinschreibung umbenennt aber jetzt funktioniert nichts mehr mit kompilieren. Könntest du deine Dateien hier posten? mfg Philipp
> aber jetzt funktioniert nichts mehr mit kompilieren.
Wie lauten denn deine Fehlermeldungen?
Ich habe mir nochmal die Ver. 0.6 gezogen und mit den
Original-Dateinamen versucht zu übersetzen. Hier mal nacheinander die
Fehlrmeldungen und Gegenmaßnahmen.
$ make -------- begin -------- avr-gcc (GCC) 4.1.0 [....] Compiling C: main.c avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d main.c -o main.o main.c:1: error: target system does not support the "dwarf-2" debug format make: *** [main.o] Error 1 |
Verstehen tue ich das nicht wirklich. Vermutlich liegts an meiner Version. Also aus dem Makefile, sorry, makefile das DEBUG=dwarf-2 auskommentiert.
$ make
Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -g -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d main.c -o main.o
In file included from KS0108.h:21,
from Init.h:18,
from main.c:24:
ks0108_def.h:11:21: error: ks0108.h: No such file or directory
In file included from main.c:24:
Init.h:22:18: error: FAN.h: No such file or directory
In file included from main.c:25:
GLCD.h:97:7: warning: no newline at end of file
make: *** [main.o] Error 1
|
>ks0108_def.h:11:21: error: ks0108.h: No such file or directory es heißt KS0108.h >Init.h:22:18: error: FAN.h: No such file or directory es heißt Fan.h Und weil das ja ewig lang werden könnte, hier meine Änderungen:
In File ks0108_def.h, Line 11: #include "KS0108.h" In File ks0108.c, Line 9: #include "KS0108.h" In File Init.h, Line 22: #include "Fan.h" |
Das sind die 3 Änderungen, die notwendig sind.
GLCD.h:97:7: warning: no newline at end of file |
Das ist ja ganz fix gefixd.
dir.c:59: warning: pointer targets in passing argument 2 of 'MakeFileName' differ in signedness dir.c:59: warning: pointer targets in passing argument 3 of 'MakeFileName' differ in signedness dir.c:225: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness dir.c:447: warning: pointer targets in passing argument 2 of 'strncmp' differ in signedness dos.c:514: warning: pointer targets in passing argument 2 of 'MakeFileName' differ in signedness dos.c:514: warning: pointer targets in passing argument 3 of 'MakeFileName' differ in signedness ..... |
von den Warnungen bzgl. "differ in signedness" bekomme ich eine ganze Latte. Abhilfe: File fat.c, Line 112 und 113 ändern, das "unsigned" rausschmeißen, z.b. so:
/*unsigned*/ char FileName[8];^M /*unsigned*/ char FileExt[3];^M |
File fat.h, Line 172 und 173, hier auch das "unsigned" rausschmeißen
/*unsigned*/ char DIR_Name[8]; //8 chars filename^M /*unsigned*/ char DIR_Ext[3]; //3 chars extension^M |
Line 260 und 261 ändern, das "unsigned" rausschmeißen
extern /*unsigned*/ char FileName[];^M extern /*unsigned*/ char FileExt[];^M |
Wenn das alles geändert ist, dann rödelt das bei mir in einem rutsch durch, ohne Warnungen & Fehlermeldungen. Einzige Fehlermeldung, die ich bekomme, ist aus dem Makefile. Ändere mal Zeile 436 von
ELFSIZE = $(SIZE) --mcu=$(MCU) --format=avr $(NAME).elf^M |
auf
ELFSIZE = $(SIZE) -A $(NAME).elf |
Dann kommt auch was zum schluß raus
Size after: AkkuTester.elf : section size addr .text 25960 0 .data 36 8388704 .bss 1316 8388740 .noinit 0 8390056 .eeprom 0 8454144 .stab 46692 0 .stabstr 17481 0 Total 91485 |
und jetzt poofen!
Hallo Hegy ich hatte mein Fehler gefunden, ich hatte eine Datei falsch umbenennt und somit konnte ich nicht kompilieren und bekam auch keine Fehlermeldung, ausser dass er das elf File nich fand. Danke noch für deine anderen Anregungen. Ich habe sie in die Version 0.7 einfliessen lassen. Gruss Philipp
@Chris D. Wenn die Hersteller das wüsten, würden schon viel mehr elektroautos unterwegs sein. Problem bei den Litium akus ist momentan der Alterungsprozess. Da solche Akkus für den automobileinsatz recht teuer werden, kann man die nicht alle 2 jahre austauschen (beim handy egal, da die meisten sich nach der zeit ein neues holen). Sie muessen somit die lebenszeit eines PKWs ueberleben (ca 8 Jahre stellt sich der hersteller da so vor). Und alter, restkapazitaet, ... lassen sich leider nicht durch einfaches messen von aussen ermitteln den ladezustand ggf ja. Es ist vielmehr der interne zustand der zelle gefragt, der sich momentan nur durch eine externe simulation erfassen laest (temeratur, spannung, und lade und entladestroeme). und selbst das ist momentan noch forschungs gebit. (Ein bekannter schreibt darueber gerade seine doktor arbeit) z.B. Sind entladungen in bestimmten situationen gift fuer so eine zelle. Lagerung im vollgeladenen zustand sowie im lehren zustand sind auch nicht gesonders gut fuer die Zelle, tiefe temperaturen sowieso, ... fuer den obimalen betrieb solcher zellen, laest sich der interne zustand vorraussagen, nur hat der mit der realitaet nich viel zu tun. gruss
Angehängte Dateien:
-
Spannungsverstaerkung.png
7,83 KB, 3659 Downloads
Mit den Dateinamen in komplett kleingeschrieben in der Ver. 0.7..... naja, so war das nicht gemeint. Ich hatte für MICH die Dateien alle in kleingeschrieben umbenannt, damit ich das compiliert bekommen. Damit du dir die scheiß Arbeit sparen kannst, habe ich ja nochmal die 0.6 Version ausgepackt und nachmal mit make rumgekachelt und mal genauer hingekukkt, was da faul ist. Du hättest alles beim alten lassen können, nur in 2 oder 3 Dateien was ändern, ne Kleinichkeit, das wärs dann schon gewesen. Also, schreib so wie du willst, ich will die nicht unbedingt in kleinschrift haben die Dateinamen. Deine Schreibweise war schon voll ok. Nochmal was zur Projektseite, Abschnitt Speicherung der Daten Ich war mal so frei und habe die einzelnen Leerzeichen durch TAB ersetzt, zumindest optisch. Somit steht das erste Zeichen in Spalte 1, nach dem 1. Tab das nächste Zeichen in Spalte 9 usw. Dann wüder ich noch vorschlagen, die Spaltenüberschriften abzukürzen, also t für Zeit (müßte es nicht Entladezeit heißen statt Ladezeit?), U für Spannung usw. So sähe das aus:
t[s] U[mV] I[mA] C[mAs] E[mWs] 11 660 22 73 46 31 660 33 358 226 |
Ganz Allgemein finde ich, daß grundlegende Angaben, wie z.B. - min. & max. Entladestrom, - min. & max. Akkuspannung, - Schrittweite der Einstellung, - verwendbar für welche Akkutypen fehlen. Falls diese Werte noch nicht festgelegt sind, festlegen! Is unheimlich wichtich, darauf baust du dein Projekt auf! Ich versuche gerade einen der ToDo Punkte auszuradieren, daher nehme ich mal folgende Werte an: minimaler Entladestrom 10 mA max. Entladestrom 10 A über bei allen Spannungen (1.2V bis 12V)! Schrittweite zur einstellung des Entladestroms 10 mA. Damit gehts schon los, 10A Entladestrom bei 1.2V Akku. Es gibt ja so größere Tonnen, die können das. Oder auch einzellige Blei-Akkus. Es soll ja universell vielseitig sein. ...ca. 3 Std. später.... So, feddich gemalt. Ich habe meine Ergüsse mal gemalt! Kukkense mah in Anhang. Muß ich das jetzt erklären? Ok, Kurzform, schon wieder so spät, ich will inne Poofe und nicht erst noch was essen, krich wieder schmacht. Zum Themer. Aufgrund meiner gemachten Annahmen habe ich 2 Entladestrompfade gebaut. Der obere Zweig (L für Low Current) ist für max. 100mA Entladestrom und sollte auch mit 1,2V Akkus erreichbar sein. Am Shuntwiderstand des T1d (10 ohm) wird bei 100 mA max. 1V abgegriffen, mit nicht invertierendem OP und Verstärkungsfaktor 5 auf max. 5V für den AD-Wandler hochgebracht. Selbiges mit den untern Strompfad (H wie High Current), ausgelegt (theoretisch) für max. 10A und mit Umschaltung auf max. 1A für bessere Auflösung. Die generelle Umschaltung zw. H und L geschieht mit TTL-Pegel an T5, der als Inverter arbeitet. Somit kann nur einer der MOSFETS, die übrigens bei U_GS=5V schon fast voll durchschalten, durchschalten und die aus der PWM generierte Gleichspannung zum entsprechenden Transistor durchschalten. Somit ist entweder der L- oder H-Strompfad aktiv. Je nach dem, wie beim Setup der Entladestrom gewählt ist, wird per SW der Verstärkungsfaktor der H-Strompfades umgeschaltet (und generell die H/L-umschaltung entsprechend gesetzt), Faktor 8 im Bereich über 1A bis 10A, sonst Faktor 80. Das ist nur erstmal ein Entwurf. Wahscheinlich fehlt am S-Pin von T3 ein Widerstand nach GND (oder Widerstand von Basis T1a/b/c nach GND wie bei T1d). Dann noch offen sind die 3 Entkoppelwiderstände zu je 1k an den Emittern von T1a/b/c zum OP. Ob das funktioniert, weis ich nicht. Den H-Strompfad habbich übrigens mal aus 3 Transistoren aufgebaut. Grund ist, daß die Wärmeverteilung besser ist, also nicht ein Hot-Spot in schweineheiß, sondern 3 Hot-Spöttchen in etwas wärmer. vllt. sind auch die errechneten Werte allesamt für die Tonne...... Außerdem hat der TIP142 eine parasitäre Diode zw. E und C in Sperrichtung drin. Wenn jetzt also der Akku verpolt angeschlossen wird, sind die Dioden leitend oder auch schon tot und der Transistor übrigens auch! Aber auch dafür gibt es Möglichkeiten, das zu verhindern. Z.B. vorher abchecken, ob überhaupt ein Akku angeschlossen ist und wenn, die Polung feststellen. bei falscher Polung darf dann eben der Lastkreis nicht bestromt werden. Achso, die 3 Shunts am T1a/b/c sind 5 Watt Geräte (0.18 Ohm × (3.33A)² = 2W) und brauchen nicht mehr auf den Kühlkörper montiert zu werden.
So ich hab jetz nach einigen Test, auch mit grossen Batterien (Autobatterie 12V 50Ah) noch einen Fehler in der Anzeige korrigiert. Einen weiteren habe ich bei der Mittelwertbildung korrigiert, der aber scheinbar keine Auswirkung auf die Funktion hatte. Ich hoffe, dass ich alle Fehler gefunden habe und alle Funktionen richtig funktionieren. Falls jemand noch andere Sprachen als Deutsch und Englisch beherrscht und lust hat mir zu helfen ist er/sie gerne willkommen.
Hallo zusammen. Ich bin Einsteiger im Thema Elektronik und der Akkutester soll mein erstes Projekt werden, bei welchem ich mich mit dem Thema "Microcontroler" beschäftige. Eine Frage hab ich aber vorher noch zur Funktionweise des Akkutester, leider konnte ich es nicht wirklich herauslesen: Entläd der Akkutester den Akku komplett und sagt mir dann, wieviel Strom geflossen ist? Oder hat er ein anderes Prüfverfahren? Wir würden damit gern Akkus testen die 5 oder 6 Ah haben. Das dauert dann ja ganz schön... Vielen Dank für die Hilfe. mit freundlichen Grüßen Akron
Akron wrote: > Eine Frage hab ich aber vorher noch zur Funktionweise des Akkutester, > leider konnte ich es nicht wirklich herauslesen: Aus der Einleitung im verlinkten Artikel Die Idee ist, dass man einen Akku den man testen möchte zuerst mit einem Ladegerät voll lädt. Der Akku Tester entlädt dann den Akku und misst die Kapazität [mAh] die entnommen wurde, und die Energie [mWh]. Diese Werte kann man dann mit den Herstellerangaben vom Akku vergleichen und so sehen, wie fit der Akku noch ist.
Okay, ich geh mein Kopf jetzt mal auf den Tisch hämmern. Man sollte wahrscheinlich immer am Anfang beginn mit dem Lesen. Ich danke für die Hilfe mfg Akron
Hallo Philipp, sehr gute Arbeit, die du da mit deinem Akkutester geleistet hast. Genau sowas wollte ich mir auch bauen - jetzt werd ich wohl deinen Ansatz erst mal nachbauen. Es gibt da nur einen Punkt, der mich davon abhält. Und zwar hast du ja ein glcd mit 128x64 pixeln und ks0108 controller verwendet. Ich habe hier eins mit 160x160 pixeln und lc7981 controller. Bevor ich mir jetzt die Arbeit mache und das Projekt portiere, frage ich doch lieber erst mal nach: Hat das schon jemand auf ein Display mit lc7981 portiert?
Philipp Kälin schrieb: > Hallo zusammen > > ich habe mit einem Projet angefangen, mit dem man die Kapazität von > Akkus messen kann. ... > auch gerne Fragen beantworten. > > MfG Philipp > Hallo und Danke, schön das Du dir die Mühe für uns gemacht hast. Hatte vor einiger Zeit mal in einem anderen Forum versucht etwas ähnliches zu finden. http://www.heise.de/ct/foren/S-Akku-Zustandsautomat/forum-116199/msg-17030830/read/ Hoffe das ich es erstmal einfach nachbauen kann. Fragen tauchen erst bei wirklich auftretenden Problemen auf. Bernd_Stein
Bernd Stein schrieb: > > Hoffe das ich es erstmal einfach nachbauen kann. > Fragen tauchen erst bei wirklich auftretenden Problemen auf. > Hi, geht schon los. Wollte mir die Hardware-, und Softwaredateien herunter laden. Dazu bin ich unter " hardware/tags/HW_2010_09_15_V1.2.zip " gegangen. Ich sehe allerdings nur Zeilennummerierungen und wirre Zeichen. Dachte ich lade dort EAGLE-Dateien oder PDF-Dateien herunter. Was muss ich nun tun um den Schaltplan, Layout, Bestückungsplan sowie den Softwarequellcode herunterladen zu können ? Bernd_Stein
lad dir den tarball (unten links, wenn du auf den link zum svn rep. klickst) 7 zip kann das entpacken. MfG
dunno.. schrieb: > lad dir den tarball (unten links, wenn du auf den link zum svn rep. > klickst) 7 zip kann das entpacken. > > MfG > Danke, mit " Download GNU tarball " geht es. Bernd_Stein
Ich habe noch eine Frage. Würde es ein ATmega16 auch tun ? Und was müsste dann geändert werden ? Da der Quellcode in C geschrieben ist, kann ich es schlecht selber machen, da ich mich noch in Assembler übe. Die Unterschiede liegen in den Speichergrößen und in den Interruptvectoradressen. http://atmel.com/dyn/resources/prod_documents/doc2538.pdf Bernd_Stein
@MarioG Selber gehört habe ich noch nie etwas von einem LC7981 Controller, auf die schnelle habe ich aber den Thread hier gefunden: Beitrag "GrafikDisplay mit LC7981; Darstellungsprobleme" Allerdings möchte ich dich darauf hinweisen, dass du da mehr als nur den Hardware Treiber ändern musst. Ich muss zugeben, dass die Menü Funtionen nur genau für ein LCD mit 128x64 Pixeln zugeschnitten sind, es gäbe also eine gröbere Arbeit die zu ändern. Ich wüde dir empfehle ein günstiges LCD z.B. bei eBay zu kaufen Ebay-Artikel Nr. 160491739561
@Bernd Stein Nein, der würde nicht reichen. Vom Flash Speicher vieleicht noch, aber um auf die SD-Karte zu speichern brauchst du mehr als 1K RAM. Alleine der schreib buffer für FAT ist 512 Byte gross. Wenn du auf die logging Funktion verzichtest, könnte es jedoch ev. gehen.
Danke Philipp für deine Antwort! Daß das nicht so einfach wird, hab ich bereits feststellen müssen. Hab mich heut mal hingesetzt und das ganze angeschaut. Die Änderungen wären viel zu tiefgreifend, als daß es sich lohnen würde. Deswegen hab ich das ganze auch sein lassen und mir das von dir verlinkte Display bei ebay gekauft. Von dem, was ich jetzt gesehen habe, würde ich den lc7981 klar bevorzugen - aber hilft jetzt nicht. Jetzt hilft nur auf die Post aus HongKong warten...
Philipp Kälin schrieb: > @Bernd Stein > Nein, der würde nicht reichen. Vom Flash Speicher vieleicht noch, aber > um auf die SD-Karte zu speichern brauchst du mehr als 1K RAM. Alleine > der schreib buffer für FAT ist 512 Byte gross. Wenn du auf die logging > Funktion verzichtest, könnte es jedoch ev. gehen. > Danke für die Antwort. Naja, da muß ich halt in den sauren Apfel beissen und ein paar ATmega32 kaufen. Brauche ja eh noch den SD-Card-Slot. Hoffe diese ist geeingnet : http://www.pollin.de/shop/dt/MjU4ODQ1OTk-/Computer_und_Zubehoer/Hardware/Speicherkarten/SD_Speicherkarten_Sockel_ATTEND_104H_TDA0_R.html Bernd_Stein
@Bernd Stein Der SD-Adapter sollte passen. Noch zwei Tipps, kauf von denen auch mehr als einen. Bei meinem war der Kunststoff so billig, dass der gerade wegfloss wenn ich mit dem Lötkolben in die Nähe kam. Der zweite Tipp, mach die Leitungen zum Prozessor wirklich kurz, ich musste es zeitintensiv erfahren, dass die kurz sein müssen.
Hallo, der TLC272 ist ja gar kein " Rail to Rail " ist es trotzdem egal ? Der LM336 soll der 2,5V oder 5,0V sein ? Bernd_Stein
Angehängte Dateien:
-
Webbild_Akkutester_005.jpg
745 KB, 3286 Downloads -
GLCD-TG12864B-05_128x64_Pixel.PDF | anzeigen
110 KB, 550 Downloads
Bernd Stein schrieb: > Hallo, > > der TLC272 ist ja gar kein " Rail to Rail " ist es trotzdem egal ? > > Der LM336 soll der 2,5V oder 5,0V sein ? > Mit dem LM habe ich mich vertan ist ein LM335 ( Temperatursensor ). Erste Frage bleibt. Nun habe ich, sagen wir mal die " Steuerung " aufgebaut und den µC geflashed. Wer kann mir sagen warum bei dem von mir verwendeten GLCD ( 128x64 Pixel ) vom Typ : TG12864B bei Pollin gekauft dieses Bild zeigt ? Datenblatt im Anhang Bernd_Stein
MS schrieb: > CS vertauscht? > Wundere mich hatte doch schon darauf geantwortet. Ja stimmt vielen Dank. CS1 und CS2 vertauscht danach i.O. oder war es CS0 und CS1 ? Werde in später Zukunft die Endstufe nachbauen bzw. überlege evtl. diese hier aus der FUNKAMATEUR zu benutzten. "Einstellbare elektronische Last für maximal 20 A und 24 V" FA 3/11, S. 269 Bernd_Stein
Angehängte Dateien:
-
Akku_Tester.pdf | anzeigen
104 KB, 450 Downloads
Bernd Stein schrieb: ... > > Werde in später Zukunft die Endstufe nachbauen bzw. überlege evtl. diese > hier aus der FUNKAMATEUR zu benutzten. > > "Einstellbare elektronische Last für maximal 20 A und 24 V" > FA 3/11, S. 269 > Hallo zusammen, möchte mich nochmal bei dem Ersteller des Projekts bedanken. Suche schon seit einiger Zeit nach so etwas, womit man feststellen kann was meine Akkus noch taugen. Mit der Bedienung bin ich zufrieden, den SD-Kartenslot habe ich nicht verdrahtet, arbeite mit der SW-Version 1.6 vom 28.11.2010. Ich möchte herausfinden wie ich die Anzeige von Spannung und Strom mit meinem Multimeter in Einklang bringen kann. Habe den Leistungsteil wie im Anhang Seite 1 aufgebaut. Habe dann Versuche mit einem NiMH 1600mAh Akku gemacht und einige Dinge bemerkt. 1. Im Ruhezustand fließt bereits ein Strom von 3,7mA. An IC4A Pinn 1 messe ich auch 0,7 Volt. Mit dem Multimeter ( Mum ) messe ich am Akku selbst eine Spannung von 1,277V und am µC selbst ( UBATT ) 116mV, was auch passt. Am Shunt messe ich 6mV was am µC als IBATT mit 3,5mV ankommt und ja auch richtig ist. Ok, diese Sachen sind nicht so wichtig, da ja der Akku getestet werden soll und nicht ständig am Akkutester hängt. 2. Bei der Messung vom Ri bekomme ich für den Max,- und Mittelwert Null milliohm angezeigt. Entladeschlußspannung ist 1V, Entladestrom 160mA und das Messinterval 30s. Bei der Anzeige 0% messe ich mit dem Mum das was ich unter Punkt 1 beschrieben habe. Wenn anscheinend die erste Messung erfolgt ist, bekomme ich bei 0%, 2mA, 445mV angezeigt. Mit dem Mum 9,6mA, 1,246V. bei 5%, 8mA, 445mV mit dem Mum 15,7mA, 1,239V, bei 10%, 12mA, 450mV 28,1mA, 1,230V, bei 15%, 23mA, 450mV 34,3mA, 1,225V, bei 20%, 29mA, 445mV 46,5mA, 1,216V, ... ab 55%, ca. 90mA, ca. 440mV ca. 59mA, ca.1,200V Stellt sich für mich zum einen die Frage, warum erreiche ich den eingestellten maximalen Entladestrom von 160mA nicht ? Zum anderen, die Frage die mir erstmal wichtiger ist : " Wo muß ich im C-Quellcode ansetzen, damit die angezeigten Werte von Spannung und Strom mit meinem Mum übereinstimmen " ? Der Akku selbst brachte beim Kurzschliessen einen Strom von 5,4A und die Akkuspannung war bei 0,356mV, was einem Ri von 170mOhm entspricht. Den Akkutester habe ich mit den 5V vom Spannungsregler IC2 von Seite 4 des PDF-Anhangs auf der Platine kalibriert. Dazu habe ich die Senseleitungen ( Akku+ / Spannung- ) dort angebracht und kalibrieren gestartet. Habe von C keine Ahnung und übe mich in Assembler. Hoffe trotzdem da durchzusteigen, falls mir jemand schreiben kann, wo ich im C-Programm ansetzen muß. Bernd_Stein
Hallo Bernd Zu der Frage warum du die 160mA nicht erreichst, als ich den AkkuTester gemacht habe war der Einsatzzewck für höhere Spannungen. Die Leistungstransistoren können nicht mehr als voll schliessen. Wenn du von den 1V Endspannung etwa 0,3V für D3 noch weg nimmst, dann bleibt nicht mehr viel für die Transistoren übrig. Wenn du den Akku Tester nur für kleine Spannungen verwendest wüdre ich als erstes D3 entfernen, und ev. den Leistungswiderstand R17 durch einen kleineren ersetzen oder ganz weg lassen. Die ungenauigkeit des Stromes kommt daher, dass als Mess-Shunt der Leistungswiderstand verwendet wird, der ist an sich nicht genau und driftet bei Belastung zusätzlich. Hier der selbe Grund, ich hatte ihn für Strome 2-5A ausgelegt. Wenn du den Leistungsteil anpassen möchtest, dann helfe ich dir nachher gerne beim anpassend der SW. Intern wird alles in mV / mA gerechnet, es muss also nur die Umrechnung vom AD-Wert in mV /mA geändert werden, was eine kleine Sache ist. Die 0,7V am IC4A Pin 1 kann ich mir im Moment nicht erklären. Hast du da den TLC272 verwendet, oder sonst einen der sauber gegen GND kommt? Wenn ich mich richtig erinnere funktioniert die Ri-Messung nur wenn der Endwert des Stromes erreicht wird. Gruss Philipp
Entschuldigung das ich jetzt erst antworte. Philipp Kälin schrieb: > Hallo Bernd > > Zu der Frage warum du die 160mA nicht erreichst, als ich den AkkuTester > gemacht habe war der Einsatzzewck für höhere Spannungen. Die > Leistungstransistoren können nicht mehr als voll schliessen. Wenn du von > den 1V Endspannung etwa 0,3V für D3 noch weg nimmst, dann bleibt nicht > mehr viel für die Transistoren übrig. > Oh ja. Hatte nicht weiter überlegt. > > Wenn du den Akku Tester nur für kleine Spannungen verwendest wüdre ich > als erstes D3 entfernen, und ev. den Leistungswiderstand R17 durch einen > kleineren ersetzen oder ganz weg lassen. > Ja, will einzelne Akkus auf ihre Kapazität hin überprüfen, überwiegend NiMH, NiCd in Größen AA, AAA und SubC. > > Die ungenauigkeit des Stromes kommt daher, dass als Mess-Shunt der > Leistungswiderstand verwendet wird, der ist an sich nicht genau und > driftet bei Belastung zusätzlich. Hier der selbe Grund, ich hatte ihn > für Strome 2-5A ausgelegt. > Ich denke die Ursache liegt wo anders. Habe nochmals eine Messreihe bezüglich des Ri ermittelns durchgeführt. NiMH 1600mAh mit Entladestrom 160mA, Entladeschlußspannung 1V, Meßintervall 30s. Diesmal habe ich die Spannung an Pinn 40 des µCs gemessen - Sprich IBatt, welche ja über einen Spannungsteiler erzeugt wird. Die Spannung IBatt ist somit die halbe Spannung am Shunt R17 ( 1,8 Ohm ). Das bedeutet : Bei 5%, 6mA, 451mV in der Anzeige => gemessen und errechnet 13,2mVx2 / 1,8 = 8,8mA 10%, 12mA, 450mV => 23,3mVx2 / 1,8 = 25,8mA 15%, 24mA, 461mV => 31,5mA 20%, 29mA, 445mV => 43,0mA 25%, 42mA => 48,lmA 30%, 46mA => 60,3mA 35%, 56mA => 66,1mA 40%, 64mA => 77,6mA 45%, 75mA => 83,5mA 50%, 81mA => 94,8mA 55%, 92mA => 100,5mA 60%, 99mA => 111,7mA 65%,110mA => 117,3mA 70%,116mA => 122,5mA 75%,122mA Ich denke die Meßreihe zeigt deutlich, das die Genauigkeit gut ist. Jedoch scheint die Meßwertausgabe um einen Schritt versetzt angezeigt zu werden. Zum Beispiel wird bei 60% 99mA angezeigt und errechnet habe ich 111,7mA. Der Wert passt gut zu der Anzeige bei 65% 110mA und dies ist bei jeder Messung so. > > Wenn du den Leistungsteil anpassen möchtest, dann helfe ich dir nachher > gerne beim anpassend der SW. Intern wird alles in mV / mA gerechnet, es > muss also nur die Umrechnung vom AD-Wert in mV /mA geändert werden, was > eine kleine Sache ist. > Warum jedoch die Akkuspannung immer als ca. 450mV angezeigt wird, obwohl diese ca. 1,2V beträgt habe ich noch nicht untersucht. > > Die 0,7V am IC4A Pin 1 kann ich mir im Moment nicht erklären. Hast du da > den TLC272 verwendet, oder sonst einen der sauber gegen GND kommt? > Ja ich habe den TLC272CP, jedoch ist bei mir IC4A als IC5B ausgeführt, da ich die hintereinander geschalteten OpAmps in dem selben Gehäuse verwende ( IC5A und B ). Die Platine ist in Fädeltechnik ausgeführt. Bei mir schwingt jedoch IC5A pinn 1 mit ca. 0,2Vss und ca. 625Hz, obwohl dies sicherlich durch die 100nF Kondensatoren C1 am +Input gegen GND und C18 an den -Input gegen GND verhindert werden sollte. Dies dürfte der Grund sein warum an IC4A Pinn1 ca. 0,7V mit dem Mum ( Multimeter ) zu messen sind. > > Wenn ich mich richtig erinnere funktioniert die Ri-Messung nur wenn der > Endwert des Stromes erreicht wird. > Ach so. Ich denke den Ri kann man am genausten bestimmen, wenn der Entladestrom der Kurzschlußstrom ist. Deshalb denke ich das die eingabe eines Entladestromes unnötig ist und der maximal mögliche ( Kurzschlußstrom ) erzeugt werden sollte. Bernd_Stein
Ich habe deinen Aufbau bei mir mal nachgebaut und habe folgendes festgestellt: Bernd Stein schrieb: > Ich denke die Meßreihe zeigt deutlich, das die Genauigkeit gut ist. > Jedoch scheint die Meßwertausgabe um einen Schritt versetzt angezeigt zu > werden. Zum Beispiel wird bei 60% 99mA angezeigt und errechnet habe ich > 111,7mA. > Der Wert passt gut zu der Anzeige bei 65% 110mA und dies ist bei jeder > Messung so. Ich war selber erstaunt ab der Genauigkeit bei kleinen Spannungen, es ist auch tatsächlich so, dass auf dem Display der letzte gemessene Wert angezeigt wird und nicht der aktuelle. Für den mittleren Ri habe ich einen Vorzeichenfehler in der Software entdeckt und die Kriterien für die Gültigkeitsprüfung der Messwerte angepasst, bei mir funktioniert es jetzt korrekt. Bernd Stein schrieb: > Warum jedoch die Akkuspannung immer als ca. 450mV angezeigt wird, obwohl > diese ca. 1,2V beträgt habe ich noch nicht untersucht. Kann ich bei mir nicht nachvollziehen, wäre interessant ob das nur bei der Innenwiderstandsmessung auftritt oder auch beim Akku testen? Als Anhang habe ich ein korrigiertes HEX-File, kannst du das bei dir mal testen und bescheid geben, wenns geholfen habe lade ich es ins SVN hoch. Gruss Philipp
> > Bernd Stein schrieb: >> Warum jedoch die Akkuspannung immer als ca. 450mV angezeigt wird, obwohl >> diese ca. 1,2V beträgt habe ich noch nicht untersucht. >> >Philipp Kälin schrieb: > > Kann ich bei mir nicht nachvollziehen, wäre interessant ob das nur bei > der Innenwiderstandsmessung auftritt oder auch beim Akku testen? > Seltsamerweise ist es beim Endladeprogramm nicht so gravierend, ich würde sogar sagen tolerierbar. Hier mal ein paar Messwerte : Anzeige => gemessen 1155mV => 1160mV 1127mV => 1140mV 1127mV => 1136mV 1100mV => 1126mV 1100mV => 1118mV 1100mV => 1108mV Habe diese Messwerte in unregelmäßigen Abständen überprüft. > > Als Anhang habe ich ein korrigiertes HEX-File, kannst du das bei dir mal > testen und bescheid geben, wenns geholfen habe lade ich es ins SVN hoch. > Habe mit der Programmversion 1.7 und dem selben Akku bei gleicher Einstellung ( NiMH 1600mAh Enladestrom 160mA, Messintervall 30s ) die Ri-Messung durchgeführt : Mum = Multimeter V_Mum ist an Pinn 40 ( I_Batt ) gemessen worden. I_errechnet = V_Mum*2 / 1,8 Ohm. Der Spannungsteiler für I-Batt besteht aus 1%igen Widerständen. I_Anzeige/mA I_Mum/mA V_Mum/mV I_errechnet/mA 0% Nichts 4,3 3,7 4,11 0% 2 10,34 8,7 9,67 5% 8 16,21 13,8 15,33 10% 13 28,4 23,9 26,55 15% 23 34,4 28,9 32,11 20% 30 46,2 39,3 43,67 25% 41 52,0 44,5 49,44 30% 47 62,9 54,6 60,67 35% 58 64,5 60,0 66,67 40% 63 56,6 70,0 77,78 45% 75 52,0 75,0 83,33 50% 80 48,3 79,0 87,78 55% 86 " 78,8 87,55 60% " " 78,7 87,44 65% " 48,2 78,5 87,22 70% " " " " 75% 85 48,1 78,4 87,11 80% 86 " 78,3 87,00 85% 85 48,0 78,2 86,89 90% 86 " 78,1 86,78 95% 85 47,9 78,0 86,67 Ri Maximal = 8800mOhm, Ri Mittelwert = 2140mOhm Wenn man sich die Tabelle anguckt sieht es immer noch so aus, als ob der angezeigte Wert versetzt angezeigt wird. Zum Beispiel bei 0% mit 2mA in der Anzeige, wird ein Strom mit dem Mum von 10,34mA gemessen und der errechnete Strom beträgt 9,67mA. Das kommt den bei 5% angezeigten 8mA näher als den Angezeigten 2mA. Dies kann man fortlaufend bis 35% beobachten. Desweiteren läßt sich erkennen das der errechnete Stromwert ( U_Batt*2 / 1,8 Ohm ) dem mit dem Mum gemessenen ( I_Mum ) ebenfalls bis 35% sehr nahe kommt. Somit möchte ich behaupten, das die Spannung am AD-Wandler des µCs korrekt ist. Ab 40% sieht es so aus als ob das Mum für die Strommessung spinnt. Habe deshalb die Mum gegeneinander getauscht, so das das Voltmeter nun den Strom misst und umgekehrt. Die Werte sind jedoch bis im Unterschied bei der Kommastelle genau gleichgewesen. Mit dem Osziloskop konnte ich sehen das I_Batt mit ca. 5mVss verrauscht ist. Dies macht ja so ca. 5mA aus - also nicht so schlimm ist. Ab 50% bleibt der Strom konstant, was ja mit dem durchsteuern der Leistungstransitoren zusammenhängt. Seltsamerweise ist hier der errechnete Strom immer passend zum Angezeigten jedoch nicht mehr zum Gemessenen. Warum hier beide Mum bei der Strommessung so reagieren kann ich mir nicht erklären. Die Ri-Messung beim vertauschen der Mum brachte auch einen unerwarteten Wert für Ri-Maximal, nämlich fast den doppelten 15090mOhm. Ri-Mittelwert war 2299mOhm, was ja nicht so sehr abweicht. Werde demnächst mal gucken, was die neue Programmversion ( 1.7 ) beim Entladeprogramm macht. Bernd_Stein
Zu den versetzten Werten habe ich ja schon geschrieben, dass auf dem Display nicht der aktuelle Wert sndern der zuletzt gemessene steht, was mit deiner Beobachtung übereinstimmt. So wie ich dich verstanden habe hast du ein Amperemeter in Serie zum Akku geschaltet, die Ri-Abweichung kommt daher wahrscheinlich vom Multimeter. Mich hat es auch schon verarscht,da ausgerechnet teure Fluke MM bei der Strommessung extrem schlecht sind. Ev solltest du da falls vorhanden den 10A Bereich nehmen, ist zwar weniger genau, dafür hat der aber einen relativ kleinen Innenwiderstand.
Philipp Kälin schrieb: > Zu den versetzten Werten habe ich ja schon geschrieben, dass auf dem > Display nicht der aktuelle Wert sndern der zuletzt gemessene steht, was > mit deiner Beobachtung übereinstimmt. > Dachte das hättest Du mit dem Softwareupdate auch korrigiert. Das war wohl Wunschlesen, denn im Post steht es ja eigentlich nicht - schade. Es wäre schön falls Du das mit dem versetzten Anzeigen vom Strom und wahrscheinlich auch der Spannung bei deinem nächsten Update korrigieren würdest. Dies vermeidet bestimmt Verwirrung bei den Nachbauern, die sich erst durch meine langen Posts durchlesen müssen, um zu verstehen wie es dazu kommt. > > So wie ich dich verstanden habe hast du ein Amperemeter in Serie zum > Akku geschaltet, die Ri-Abweichung kommt daher wahrscheinlich vom > Multimeter. Mich hat es auch schon verarscht,da ausgerechnet teure Fluke > MM bei der Strommessung extrem schlecht sind. Ev solltest du da falls > vorhanden den 10A Bereich nehmen, ist zwar weniger genau, dafür hat der > aber einen relativ kleinen Innenwiderstand. > Schande. Schon wieder so eine banale Sache an die ich nicht gedacht habe. Habe erst gedacht - dann schau ich mal in die Bedienungsanleitung von den Mum was die für Innenwiderstände in den einzelnen Strombereichen haben. Aber dann ist mir eingefallen, das der Innenwiderstand des Akkus ja auch von seinem Ladezustand abhängig ist. Somit nützt mir ja das herausnehmen des Mum Innenwiderstandes bei der Strommessung nicht viel, da nach der Messung mit dem anderen Mum sich der der Ladezustand des Akkus ja verändert hat. Habe bereits Spannungsmessungen mit der Version 1.7 durchgeführt. Werde hoffentlich heute Nachmittag bzw. Abend dazu kommen, die Ergebnisse hier im Forum mitzuteilen. Bernd_Stein
Angehängte Dateien:
-
Akku_Tester.pdf | anzeigen
104 KB, 407 Downloads
Bernd Stein schrieb: > > Habe bereits Spannungsmessungen mit der Version 1.7 durchgeführt. > Werde hoffentlich heute Nachmittag bzw. Abend dazu kommen, die > Ergebnisse hier im Forum mitzuteilen. > Hier nun die Ergebnisse : Ri-Messung mit NiMH 1600mAh, eine Zelle, Enladestrom 160mA, Messintervall 30s I_Anzeige = Auf dem Display angezeigter Stromwert U_Anzeige = Auf dem Display angezeigter Spannungswert U_Akku = Spannung direkt am Akku gemessen U_Batt = Spannung direkt am Mikrocontrollerpinn 39 ( U_Batt ) gemessen U_Batt errechnet = Da U_Batt dem µC über einen Spannungsteiler zugeführt wird, ist mit folgender Formel gerechnet worden U_Batt * 11, um zu ermitteln welche Spannung am Spannungsteiler ankommt bzw. wie hoch die Akkuspannung als Rohwert ist. I_Anzeige/mA ; U_Anzeige/mV U_Akku/V U_Batt/mV U_Batt errechnet/mV 0% - - 1,208 109,6 1206 0% 2 440 1,202 109,1 1200 5% 8 " 1,196 108,5 1194 10% 12 396 1,185 107,6 1184 15% 24 440 1,179 107,0 1177 20% 29 352 1,167 105,9 1165 25% 42 230 1,161 105,3 1158 30% 47 241 1,149 104,3 1147 35% 59 236 1,143 103,8 1142 40% 64 230 1,132 102,8 1131 45% 74 220 1,127 102,3 1125 50% 82 225 1,132 102,8 1131 55% 94 " 1,139 103,4 1137 60% 88 " 1,143 103,8 1142 65% 101 " " " " 70% 102 230 " " " 75% " 225 1,142 103,7 1141 80% 101 230 " " " 85% 100 241 1,141 " " 90% " 230 " 103,6 1140 95% 99 241 " " " Maximaler Ri = 17600mOhm Mittlerer Ri = 4511mOhm Die Tabelle zeigt ganz deutlich das U_Batt errechnet maximal 2mV von dem Wert der am Akku ( U_Akku ) gemessen wurde abweicht. Somit ist der angezeigte Spannungswert falsch, da U_Batt ja richtig am AD-Wandlereingang ( Pinn 29 ) ankommt. Somit liegt der Fehler in der Software bei der Ri-Messung, so wie es auch zuvor bei der Ri-Messung mit dem Strom bei der Version 1.6 festgestellt wurde. Beim Entladeprogramm in der Version 1.7 ist die Spannungsanzeige tolerierbar, wie zuvor auch bei der Version 1.6. Mit dem Strom habe ich das bei der Version 1.7 noch nicht getestet und warte erstmal, auf ein neues Update wo diese Fehler behoben worden sind. Philipp Kälin schrieb: > > Wenn du den Leistungsteil anpassen möchtest, dann helfe ich dir nachher > gerne beim anpassend der SW. Intern wird alles in mV / mA gerechnet, es > muss also nur die Umrechnung vom AD-Wert in mV /mA geändert werden, was > eine kleine Sache ist. > Ja ich würde gerne den Leistungsteil anpassen. Und zwar möglichst das auch einzelne Zellen getestet werden können bzw. wie schon mal erwähnt - den Artikel aus der Funkamatuer-Zeitschrift hier einfließen lassen. "Einstellbare elektronische Last für maximal 20 A und 24 V" FA 3/11, S. 269 Das jedoch erst, wenn bei dem jetzigen Aufbau auch das im Display angezeigt wird was ich mit dem Multimeter ( Mum ) messe. Sowohl bei der Spannung wie auch beim Strom. Bernd_Stein
Ich werde mir das mit der falschen Spannung mal ansehen, auch dass die aktuelle Spannung angezeigt wird und nicht der letzte Wert, werde ich ändern. Im moment habe ich wegen der Semesterprüfungen nicht so viel Zeit und die Hardware gerade nicht zur Hand, ev. komme ich am Wochenende dazu. Gruss
Philipp Kälin schrieb: > > Ich werde mir das mit der falschen Spannung mal ansehen, auch dass die > aktuelle Spannung angezeigt wird und nicht der letzte Wert, werde ich > ändern. > > Im moment habe ich wegen der Semesterprüfungen nicht so viel Zeit und > die Hardware gerade nicht zur Hand, ev. komme ich am Wochenende dazu. > Schön. Lass Dir Zeit ich schaue ja bereits seit ( siehe Link ) nach so etwas. Wenn es dann meine Wünsche, die ich im vorherigen Post geschrieben habe erfüllt, bin ich schon ziemlich zufrieden da ich merke das es ein Weiterkommen in dieser Richtung gibt. Kümmere Dich lieber intensiv um deine Semesterprüfungen, die sind wichtiger. Nutze besser das Wochenende zum Üben. Verschiebe dieses Projekt, bis Du wirklich einen freien Kopf dafür hast. Und noch mals Danke für dieses Projekt. http://www.heise.de/ct/foren/S-Akku-Zustandsautomat/forum-116199/msg-17030830/read/ Bernd_Stein
Hallo Philipp, bin erst heute auf den Artikel zum Thema Akkutester gestoßen, habe die Dateien runtergeladen, in ein Directory für Studio 4 gepackt und versucht das Ganze zu kompilieren. Hatte wenig Erfolg. Die Fehlerliste ist lang, habe sie angehängt. Als Studio4 benutze ich die Version "AVR Studio V 4.18 Build 716". Habe dann mal die ganzen Vorschläge mit den Dateien überprüft, konnte aber keine Fehler feststellen. Alle Dateien, die mit error angemahnt werden sind vorhanden im Header-Ordner von Studio 4 und die Schreibweise ist ebenfalls korrekt. Noch nicht überprüft habe ich die Thematik mit "unsigned char" bzw nur "char" von Hegi. Gibt es eine Lösung zum Problem? Eine weitere Frage ist, ob es eine Bedienungsanleitung zu dem guten Stück gibt? Eine 3te Frage ist, warum Du mit PWM die Entladung steuerst, die Du sofort wieder per Hardware in Gleichspg wandelst? mfG und Prost Neujahr frewer
frewer schrieb: > Eine 3te Frage ist, warum Du mit PWM die Entladung steuerst, die Du > sofort wieder per Hardware in Gleichspg wandelst? Sorry, die Frage ist natürlich blöd. Die PWM wird sicher für das Einstellen unterschiedlicher Entlade-Ströme benötigt. mfg frewer
Hallo frewer 1. Hast du im AVR Studio eingestellt, dass das vorhandene makefile verwendet werden soll oder lässt du dir eins von AVR Studio erstellen? Ansonsten wenn du WinAVR installiert hast sollte auch ProgrammesNotepad mitinstalliert worden sein, probier da mal ob make funktioniert wenn du das main.c öffnest. Wenn beides nicht klappt dann zip mal alle Dateien inkl. Projektdateien zusammen und hängs hier an, dann schau ich mir das mal an. 2. Als Doku gibt es nur den Wiki Beitrag Akku Tester. Die bedienung ist so einfach, dass sie eigentlich selbsterklärend ist. Ansonsten schreib mir dann werd ich den Beitrag erweitern. 3. Hast du dir selber schon korrekt beantwortet mfg Philipp
Hallo Philipp, vielen Dank für Deine Erklärungen. Haben geholfen und bin auch schon etwas weiter gekommen. Ja ich benutze Studio4 und lasse den makefile vom Studio erstellen. Das funktioniert jetzt auch mit Deinen Dateien. Der Fehler war, dass die Dateien für das Studio offenbar alle im selben Verzeichnis sein müssen. Damit war ich schon einen ganzen Schritt weiter. Ich habe keinen Encoder und auch keinen SD-Karten-Anschluss. Das erscheint mir zunächst auch nicht so wichtig. Den Enkoder möchte ich durch Tasten ersetzen, deshalb hatte ich nach der Bedienung gefragt. Das Nachvollziehen des doch recht langen Programms nimmt halt enorm viel Zeit in Anspruch (allein schon das Auffinden der einzelnen Routinen-wo steht was-). Für meine vereinfachte Version habe ich mal die Programme fat.c, fat.h, dos.c dos.h, dosdefs.h, dir.c, logger.c, logger.h, mmc-spi.c, mmc-spi.h entfernt, um ein bisschen mehr Übersicht zu gewinnen. Der nächste Schritt, an dem ich jetzt bin, ist die Anpassung an mein GraphikDisplay DM19264A-02 (mit controller ks0108 aber anderer Beschaltung und 3 Chip statt 2 - 192 x 64). Das müsste mir gelingen, da ich mit dem Display schon etwas rumgespielt habe. Wo ich gedanklich hänge, ist z.B. die Frage, wie die Daten ins EEPROM kommen, da Du schon im <main> aus dem EEPROM ins RAM liest aber noch nichts dahin geschrieben wurde. Das Nächste ist der Encoder, den ich noch nicht kapiere, dazu werde ich aber erst mal die Funktion eines Encoders studieren. Dann kommen vielleicht noch Fragen. mfG frewer
Hallo frewer 1. Zum EEPROM ist es richtig, dass die Daten schon beim main gelesen Werden. Für jeden Wert der abgespeichert wird gibt es einen Wertebereich, ist der gelesene Wert ausserhalb des Gültigkeitsbereich wird ein ebenfalls festgelegter Standardwert genommen. Da das EEPROM nach dem Programmieren alles auf 0xff steht werden beim ersten Aufsarten die Standardwerte geladen. 2. Wenn du ein Display mit einer anderen Auflösung willst, musst du die gesamte Grafische Oberfläche anpassen. (Das wird weder eine kleine noch schöne Aufgaben sein ;-) 3. Den Encoder kannst du einfach zu Tasten umbauen: - Wenn der eine Taster gedrückt rufst du die Funktion AuswahlUp auf, beim anderen Taster die Funktion AuswahlDown - EncoderEinlesen und alle lokalen Variablen bis auf enc_time kannst du löschen - Die dritte Taste (OK) bleibt gleich Gruss Philipp
Hallo Philipp, merci, bin wieder einen Schritt weiter (Tasten ist klar). Übrigens meine Anerkennung für Deine saubere und klare Programmierung. Es macht richtig Spass mal einem Experten in C zu folgen. Bin halt selbst noch nicht allzu lange dabei und mache erst noch meine Erfahrungen. Nun doch noch eine Frage zum Beschreiben des EEPROM mit den Basisdaten: Ich finde in der main nur eine Routine, die Daten aus dem EEPROM ins SRAM liest, nicht das erstmalige Laden des EEPROM. Auch in applcation.c finde ich das nicht, denn unter global settings finde ich nur Language und Kalibrierung. Die Basisdaten der Akkus finde ich allerdings in application.h. Nun vielleicht bin ich noch nicht soweit mit dem Durchforsten der Routinen. Zum Display: Mit dem Display wird das noch so eine Sache. Ich habe mal Deine Version compiliert und in einen ATMEGA32 geladen (ohne Beschaltung außer meinem Display DM19264A von Pollin). Obwohl auch bei mir die 3 Controller vom Typ ks0108 sind (wie bei Dir), hat nichts funktioniert (natürlich habe ich die Ports angepasst). D.h. ich muss mich jetzt in die Routinen stürzen. Da ich aber eine funktionierende Ansteuerung des Displays habe, müsste die Portierung machbar sein. mfG Frewer
Beim ersten lesen aus dem EEPROM werden jeweils die Standardwerte ins RAM geschrieben, da die Werte im EEPROM ungültig sind. Wenn du im Menü Werte veränderst, dann werden die neuen Einstellungen erstmal im RAM gespeichert. Erst wenn dann der Testvorgang gestartet wird, werden alle Einstellungen ins EEPROM zurückgesichert. Wenn du nach jedem ändern der Werte die Daten ins EEPROM schreiben würdest, dann ergäbe das viel mehr Schreibzyklen und die sind ja auf ca. 100 000 beschränkt. Solange du keinen Test startest, wird also nichts ins EEPROM geschrieben. Gruss Philipp
Hallo Philipp, nach viel Programmieren bin ich nun mit dem Grafik-Display soweeit, dass ich zumindest eines Deiner menüs mal darstellen konnte (allerdings ohne große Buchstaben). Soweit so gut. Jetzt bin ich daran, die Tasten UP und DOWN einzubauen und da haberts, weil ich trotz vieler Mühe bisher noch nicht kapiert habe, wie die tasten UP / DOWN in den Funktionen "DrawMenueEntries" bzw "DrawMenue" eingebaut sind. Ich habe nämlich das ganze Thema Sprachen entfernt - im enum "AnswMenue_GlobaleEinstellungen" die erste Aufzählung entfernt und die 2te auf 1 gesetzt - (weil ich halt Deutscher bin, Platz sparen will und Dein vorzügliches Programm verstehen möchte). Deshalb muss ich nun natürlich auch die Bewegungen der UP/DOWN Taste irgend wie anpassen. Aber zunächst die Frage nach dem Entprellen der "neuen" Tasten. Überall im Progarmm finde ich den Aufruf OKEntprellen() für die TasteOK; heißt das, dass ich in dieser Routine auf die gleiche Weise das Entprellen für die neuen Tasten mach? und dann einfach wie in der encoder.c je nach taste UP / DOWN das entsprechende "AuswahlUP() /DOWN() aufrufe? Was passiert denn mit Auswahl.count, Auswahl.change etc? Setze ich die in der neuen Tastenroutine und wenn ja, wie groß ist denn der wert für Auswahl.count? Übrigens fiel mir auf, dass in Deiner init.c nach meiner Lesart des ATMEGA32 Datenblattes ein Fehler ist. M.E. muss es beim Timer1 heißen: // Prescaler = 1, Auswertemodus WGM12, 11,10 =H TCCR1B |= ((1 << WGM12) | (1 << CS10)); // Fast PWM 10bit TCCR1A |= ((1 << WGM11) | (1<<WGM10)); weil das WGM12 Bit im TCCR1B sitzt und nicht im TCCR1A. Tut mir leid für meine Fragen aber Dein Programm ist ja eine richtige Lehrstunde in C-Programmierung. Das fordert. mfG frewer
Der Trick an den Tasten ist, dass jedes Menü nur den Struct Auswahl aufsetzt und dann auf OK Taste wartet. Die Tasten (Encoder) werden im Hintergrund abgefragt und der Struct Auswahl dementsprechend angepasst. Die ganzen Menüfunktionen kommen deshalb mit der Hardware an der die Taster hängen nie in berührung. Die Sprache würde ich erstmal drinlassen, Platz solltest du genug haben, und ich bin mir nicht sicher, ob ich das ganze sauber genug gemacht habe, damit man sie so einfach entfernen kann. Das Entprellen der Tasten solltest du in der Funktion EncoderEinlesen machen. Diese Funktion wird ja alle 1ms aufgerufen. Eine einfache entprellung kannst du machen indem du die Anzahl Aufrufe zählst in der die Taste immer gedrückt war, z.B. 200 was dann ja 200 ms entspricht. Falls du dich dann definitiv entscheidest, dass die Taste gedrückt ist, genügt jeweils nur AuswahlUp() bzw. Down aufrufen. Im Struct Auswahl solltest du nichts ändern müssen. P.S. Das Entprellen von Tasten ist keine so einfache Sache wie es klingt, da scheitern auch erfahrene Entwickler. Es kommt auch immer auf den Typ der Tasten an wie viel bzw. lange die Prellen, da hilft meist nur Ausprobieren. Mit dem Timer hast du recht, das ist ein Fehler. Scheinbar funktioniert es aber auch so wie ich es gemacht habe, einfach nich ganz so wie ich es ursprünglich geplant habe ;-)
Hi Philipp,
vielen Dank für Deine rasche Antwort. Nach Deinem letzten Schreiben habe
ich die Routine "EncoderEinlesen" entfernt und nur "enc_time" belassen.
Dann habe ich in OKEntprellen navh der gleichen Art auch meine beiden
zusätzlichen Tasten angefügt. Die Routine "TasteEinlesen" habe ich wie
folgt geändert:
void TasteEinlesen(void)
{
// Taster einlesen
if (!(TASTER_PIN & (1 << TASTE1)))
{ // Taste gedrückt
TasteOK.Counter++;
if (TasteOK.Counter > 50) // = Entprellen?
{
TasteOK.Kurz = TRUE;
TasteOK.Counter = 201; // warum??
}
}
else
{ // Taste nicht gedrückt
TasteOK.Counter = 0;
}
// Taster DOWN einlesen ohne Entprellen
if (!(TASTER_PIN & (1 << TASTE2)))
{ AuswahlDown(); } // Taste gedrückt
// Taster UP einlesen ohne Entprellen
if (!(TASTER_PIN & (1 << TASTE3)))
{ AuswahlUp(); } // Taste gedrückt
}
Nun bin ich jedoch im Unklaren woher z.B. BigStep oder Step kommen
sollen, die in AuswahlUP/DOWN benötigt werden? Konnte das Programm in
der jetzigen Form nur teilweise (Menüdarstellung) testen, weil mir noch
die spezielle Verdrahtung am ATMEGA fehlt der PWM Ausgang muss natürlich
mitten im PortD liegen, den ich als DatenPort benutzt habe (der
einfachheit halber nicht in HByte/LByte aufgesplittet).
Mit der Sprache hat bisher alles gut geklappt und mit dem Billig-Display
von POLLIN bin ich recht zufrieden. Den Platz des dritten Controllers
kann ich jetzt noch mit Bildern ausschmücken. Aber zuerst muss das Ding
jetzt mit den Tasten laufen.
mfG
frewer
KPhilipp schrieb: > ... > P.S. Das Entprellen von Tasten ist keine so einfache Sache wie es > klingt, da scheitern auch erfahrene Entwickler. Es kommt auch immer auf > den Typ der Tasten an wie viel bzw. lange die Prellen, da hilft meist > nur Ausprobieren. > Hier mal ein kugelsicheres entprellen, so hoffe ich wenigstens, da ich nicht durch den Code durchsteige, aber die Kritik hierzu ganz gut ausfällt von Leuten von denen ich denke das Sie ahnung von der Materie haben. Beitrag "Re: Tasten entprellen - Bulletproof" Bernd_Stein
Hallo, Also das Entprellen hab ich im Griff (allerdings viel einfacher -> Bernd) und auf meinem Display sehe ich jetzt auch schon ganz schön viel. Völlig in die Hosen geht allerdings der Scrollbalken. Wenn ich zB die Down Taste drücke, springt alles gleich zum letzten Eintrag im Menü. Drücke ich die UP Taste, dann bin ich im Wald (leeres Menü mit alter Überschrift und dicker Scrollbalken). Nach Studium von DrawMenue und DrawMenueEntries kann ich allerdings nicht erkennen, wieso Auswahl.count um 2 erhöht wird, wenn ich die Taste DOWN drücke. Dabei habe ich noch nicht geklärt, zu was die Variable "Zeit.totSekunden" gut ist. Kann es sein, dass dadurch vermieden wird, dass Taste nur 1x pro Drücken Auswahl.count hochzählt? Dann muss ich aber meine Taster-Abfrage Routine entsprechend ändern. Philipp gibr es da einen heißen Tipp? mfG frewer
Zeit.totSekunden wird jede Sekunde um 1 erhöht. Die Variable kann von allen Programmteilen verwendet werden, die Idee ist aber das sie gleichzeitig nur von einem Programmteil verwendet wird, und der die sie zu beliebigen Zeitpunkten auf 0 setzen kann um einen Zeit zu messen. (eigentlich ein hässlicher Programmierstil aber ich habs vor langer Zeit noch nicht besser gewusst) Von wo die erhöhung um zwei kommt solltest du mit einem Debugger herausfinden können. Mal Angenommen es wird AuswahlStruct so initialisiert:
Auswahl = {
2, /** Maximalwert von Counter */
0, /** Minimalwert von Counter */
0, /** Counter */
1, /** Schrittaenderung bei normalem drehen */
1, /** Schrittaenderung bei schnellem drehen */
TRUE, /** Wenn TRUE wird bei einem Counter ueberlauf am anderen Ende weitergezaehlt */
FALSE,/** TRUE wenn Counter geaendert hat */
TRUE, /** TRUE falls Aenderungen am Encoder ausgewertet werden sollen */
}
|
Der Counter ist momenten bei 0, wenn jetzt DOWN gedrückt wird, so wird der Wert (da Roll==TRUE) auf den Maximalwert 2 gesetzt. Ev. passiert in deinem Menü genau das.
Vielen Dank Philipp für die rasche Antwort.
Habe gestern abend noch lange gesucht, bin aber nur einen kleinen
Schritt weiter gekommen. Mit Deiner Anregung werde ich heute mal weiter
studieren, um die Technik en detail zu verstehen. Es macht Spass, Deine
Gedanken nachzuvollziehen.
Trotzdem noch eine Frage zum Thema Debugger. Was ist das und wie wird er
eingestellt. Habe zwar gesehen, dass Du irgendwo den Befehl DEBUG
ausmaskierst hast, zu was das allerdings gut ist, ist mir unklar.
Ich benutze Studio4, das ja einen Debugger beinhaltet, habe aber bisher
nur mit wenig Erfolg und ganz einfachen Programmen damit gearbeitet.
Was mich nur wundert ist, dass ich ja am Programmgefüge außer bei
Tasten.c nichts geändert habe, was mit dem Fortschreiben von
Auswahl.Count oder Roll zu tun hat. Beim Grafikdisplay habe ich
lediglich die Routinen ks0108 an mein Display angepasst und das sind ja
vom Programm unabhängige Routinen. Das klappt auch prima bisher. Bei dem
Rest habe ich lediglich in tasten.c aus der encoder.c den Teil
enc_time++;
if (enc_time > 50) // =50
{ enc_time = 50; }
eingebracht, weil in den Auswahl-Routinen enc_time ja abgefragt wird und
dann das Entprellen eingeführt - wie Du es bei der Taste OK gemacht hast
- und gehe dann je nach TastDOWN oder TasteUP in die Routine AuswahlDown
bzw AuswahlUP.
Na ja mal sehen, was heute passiert.
mfG
frewer
Hi Philipp,
bin am Verzweifeln!!!!
Trotz vieler Recherchen (bin offenbar noch ein zu großer laie) kriege
ich die Funktion Auswahl.Count nicht korrekt hin. Im Modul tasten.c fiel
mir auf, dass, nachdem das Prellen mit 50msec abgewartet wurde, die
Funktion zB AuswahlUP aufgerufen und dort Auswahl.Count fortgeschrieben
wird. Dies passiert aber danach jede weitere msec wieder, so dass
Auswahl.Count nur durch die Abfrage nach der max Anzahl von Einträgen
begrenzt wird und so sieht es bei mir auch aus.
Danach habe ich versucht die Tastenabfrage auf 1x zu begrenzen indem ich
die Abfrage "if ((TasteDOWN > 50)" durch "& (Aufruf.Changed==FALSE))"
ergänzt habe und dachte, damit die gedrückte Taste nur 1x abzufragen (in
AuswahlUP wird dann Aufruf.Changed = TRUE gesetzt). Die Änderung bewirkt
aber nur, dass der Balken jetzt 2x geschrieben wird statt nur 1x. Die
Positionen 1 und 3 des Balkens bleiben unverändert, was mir total unklar
ist. Hast Du zu diesem Thema eine Idee?
Beim Umschreiben von tasten.c habe ich den Teil für die TasteOK einfach
vervielfältigt und für TasteUP/TasteDOWN angepasst (eigene msec Zähler
eingebaut). Dabei sind 2 Fragen offen:
1. warum nach den Entprellen (>50msec) das Setzen von TastOK.Counter =
201??
2. warum im Modul OKEntprellen die Warteschleife, die unabhängig von der
Tastenstellung erfolgt (( while(....) {;} _delay_ms(..); die Bedingung
von while wird nicht berücksichtigt )). Für mich ist das einfach eine
Verzögerungsschleife aber warum an so vielen Stellen und meist vor der
Abfrage von TateOK.KURZ ??
Zu Deiner Information hier meine Tastenabfrage UP/DOWN in tasten.c
Routine "TasteEinlesen()":
// Taster DOWN einlesen
if (!(TASTER_PIN & (1 << TASTE3)))
{
// Taste gedrückt, dann Zeit zählen in msec
TasteDOWN++;
// Entprellt, wenn 50msec vorbei
if (TasteDOWN > 50)
{
TasteDOWN = 201;
AuswahlDown();
}
}
else
{ TasteDOWN = 0; } // Taste nicht gedrückt
Aber wie gesagt, es bleibt das Problem, dass Auswahl.Count immer extrem
springt und das in allen Menüs.
Falls Dir dazu was einfällt - Du hattest ja wohl auch mal nur Tasten
benutzt -, wäre ich Dir für Hilfe sehr dankbar.
mfG
frewer
Also in tasten.c wird nie etwas an Auswahl.count verändert. Wie ich dir empfohlen habe würde ich die Tasten jedoch in encoder.c in der Funktion EncoderEinlesen() abfragen. Die Funktionsweise der TasteOK ist grundverschieden von deinen neuen Up/Down Tasten. Ich würde daher diese nicht einfach gleich implementieren wie TasteOK. Der Encoder wird komplett im Hintergrund eingelesen, bei der TasteOK ist es jedoch nötig diese "von Hand" zu entprellen indem man OKEntprellen() aufruft und aktiv wartet. Da deine Tasten sich jedoch gleich verhalten sollten wie der Encoder, dürfen diese nicht mit aktivem warten entprellt werden. Du nmusst ebenfalls beachten dass wenn bei der TasteOK ein drücken erkannt wurde, dann wird nur ein Flag gesetzt mittels
TasteOK.Kurz = TRUE; |
. Wenn das Flag auf TRUE ist und die Funktion beim nächsten mal durchlaufen wird und der Taster immer noch gedrückt ist, dann wird das Flag eben immernoch auf TRUE gesetzt. Bei deinem Code wird hingegen bei jedem Durchlauf
AuswahlDown() |
aufgerufen, was die Variable jedesmal um eins runterzählt ergo --> Du hast die Taste faktisch nicht entprellt
Hallo Philipp, vielen Dank für Deine "warmen" Zeilen. Ich habe das Gefühl, dass ich nerve oder!! Aber ich bitte Dich, Geduld zu haben. Bin nicht mehr der Jüngste (70) und deshalb vielleicht ein bisschen schwer von Begriff. Bei einem Großteil Deiner Module konnte ich alles nachvollziehen, nur mit dem Tastenkram habe ich halt noch Schwierigkeiten (und wegen des mir nicht bekannten Encoders wollte ich keinen Einkauf riskieren - meine Überlegung: 2 Tasten für UP und DOWN müssten genügen). Ich werde jetzt mal wieder die Routine EncoderEinlesen studieren, was ich bereits einmal ohne Erfolg gemacht habe (weil ich trotz Wikipedia nicht weiß, wie so ein Encoder funktioniert und wo die verschobenen Impulse herkommen, wenn man nur 2 Pins und GND belegt - das kann ja nur durch zeitlich versetztes Kurzschließen von jeweils einem Pin geschehen). Dabei muss man aber wissen, warum enc_delta stets auf 100 und enc_last auf 1 gesetzt wird und dann natürlich wie man auf enc_Zcount ==104 bzw 96 kommt, um die beiden Routinen UP DOWN aufzurufen. Na ja, die Nacht ist ja noch lang. melde mich wieder, wenn ich neue Erkenntnisse habe. mfG vom kalten Rhein-Lahneck frewer
Eigentlich hast du dir die Antwort wie so ein Encoder Funktioniert bereits gegeben. Es ist korrekt das die Signale zeitlich verschoben gegen GND kurzgeschlossen werden. Im Artikel Drehgeber hat es ein Bild auf das ich mich nun beziehe. Prinzipiell nimmt man z.B. das Signal A als Refernz und wählt z.B. die positive Flanke. Wenn nun eine positive Flanke auftritt, schaut man welche Flanke beim Signal B als nächstes auftritt. Daraus kann man entscheiden ob die Drehrichtung links oder rechts war. Mein Code basiert übrigens auf dem Beispielcode von Peter Dannegger in diesem Artikel. Der Grund für die 96 bzw. 104 ist, dass die meisten Encoder pro mechanische Rasterung entweder 2 oder 4 solche Pulse rausgeben. Der Counter für das Menü soll also nur alle 4 Pulse hochgezählt werden. enc_Zcount wird also dazu verwendet die Zwischenschritte zu zählen und falls man 4 hoch oder runter gezählt hat den richtigen Counter zu erhöhen. Da ich keine Lust katte mich mit Vorzeichen im Bereich -4 bis +4 herumzuschlagen habe ich einfach einen Offset von 100 dazugezählt. Ich gebe zu durch meine Erweiterungen ist der Code nicht gerade leserlicher geworden. Warum genau enc_last auf 1 initialisiert wird kann ich dir nicht sagen. Der Encoder arbeitet mit GrayCode und um den auszuwerten gib es zwei Möglichkeiten: LookUp Tabelle oder Binäre Logik, und hier wurde binäre Logik verwendet. P.S. Code von Peter Dannegger kann man generell blind übernehmen, der weiss was er schreibt ;-)
Hallo,
Problem gelöst! Den Einbau der beiden Tasten Up / DOWN habe ich in
tasten.c realisiert und gleichzeitig die beiden Routinen
AufrufUp/AufrufDown mit rübergenommen. Zusätzlich habe ich noch 2 Zähler
TCtrUP/TCtrDOWN und ein struct für 2 Flags (UP/DOWN) eingebaut.
Für die Taste UP sieht das in der Routine TasteEinlesen() wie folgt aus:
// Taster UP einlesen und entprellen
if (!(TASTER_PIN & (1 << TASTE_UP)))
{
// Taste gedrückt
TCtrUP++;
if ((TCtrUP > 150) && (Flag.UP==FALSE)) // mehr als 150 Interrupts
{
Flag.UP = TRUE; // sperre für die Zeit in der Taster gedrückt
AuswahlUp(); // schreibe Auswahl fort
}
}
else
{
if(Flag.UP==TRUE) // Taste nicht mehr gedrückt
{ TCtrUP=0; }
Flag.UP=FALSE;
}
// dito für Taster DOWN nur für UP stets DOWN!!
"Flag" ist ein struct, das in tasten.h eingebaut ist (2 Bit in einer
8Bit Variablen)
struct {
unsigned UP:1;
unsigned DOWN:1;
} Flag;
Jetzt laufen die Menüs ordnungsgemäß ab, bei mir allerdings geht der
Bildaufbau der Zeilen/Menüs auf dem Display recht langsam. Mal sehen,
was da zu tun ist.
Nochmal vielen Dank an Philipp für seine Hilfestellungen.
mfG
frewer
Hallo Philipp, habe noch einmal ein Frage und zwar zum Verständnis. D inkrementierst alle Sekunde die Zähler Zeit.totSekunden und Akku.Entladezeit in der IRQ Routine SecTick(). Jetzt finde ich aber zusätzlich in der Routine Entladen() nach dem if(Zeit.changed == TRUE) und vor "Einlesen und Mittelwerte .." erneut Zeit.toSekunden++ bzw Akku.Entladezeit++ . Das Hochzählen von Akku.Entadezeit benutzt Du für die 30 Sekunden Wartezeit bevor Du die Schlussspannung überprüfst. M.E ist das wegen der doppelten Hochzählerei ist das bereits nach 15sek der Fall. Liege ich da falsch mit meiner Annahme?? Das Entladen funktioniert jetzt einwandfrei und durch Einführen des Löschens einer Zeile mittels KS0108_WriteData(0) ist die Anzeige jetzt richtig fix. Es bleibt jetzt noch insbesondere die Hardwareanpassung (Strom-/ Spannungs-Messung) an meine Situation (mein Aufbau ist bescheidener, weil ich eigentlich nur normale Akkus (NiCD,NiMH bis 2800) messen will. Mich fasziniert noch immer Deine Programmierleistung!!! Da gibt es noch viel zu lernen. mfG frewer
Hallo zusammen, nicht nur für einen Modellbauer ist das ein sehr interessantes Projekt. Bisher konnte ich allerdings nur die Schaltpläne sehen. Mit der Software habe schon ein grundsätzliches Problem... Ich kann die Dateien (.zip) vom SVN-Server nicht richtig downloaden. Beim Entpacken gibt es jedesmal eine Fehlermeldung, bzw. die Links führen auf eine Log-Seite im Browser - z.B. Log of /software/tags/Fusebits.pdf Bis jetzt konnte ich keine der Dateien entpacken. Könnt Ihr mir bitte einen Tip geben, was ich falsch mache? Wäre sehr nett... Danke und schöne Grüße Alfred
Hallo Alfred Das ist in der Tat unschön, dass man die einzelnen Dateien übers Webinterface nicht herunterladen kann. Anstatt die zip-Datei im tags ordner kannst du auch die Source Dateien aus dem trunk Ordner nehmen (ist die selbe Revision wie die neueste zip-Datei) dazu einfach in den trunk Ordner wechseln und dann unten auf "Download GNU tarball" klicken, dann werden alle Dateien in eine .tar.gz Datei gepackt. Falls du unter Windows arbeitest und (auch Windoof 7 ist immer noch nicht in der Lage .tar.gz Dateien zu öffnen) empfehleich dir 7zip. Gruss Philipp
Hallo Philipp, vielen Dank für die schnelle Antwort. Da werde ich mich gleich mal dranmachen. Eigentlich verwende ich 7-zip. Komisch, dass das die Datei auch nicht kannte. Hatte ich schon mal runtergeladen. Das krieg ich jetzt schon gebacken, hoffentlich. Naja, Win und seine "Nebenwirkungen". Schöne Grüße Alfred
Hi, also noch einmal zu meiner Feststellung bezüglich der Entladezeit. Wie bereits beschrieben wird "Akku.Entladezeit" beim Entladen sowohl im SecTick() hochgezählt als auch in der Entladefuntion Entladen(). Gebraucht wird die Entladezeit eigentlich nur zur Bestimmung der 30sec in der Prüf-Funktion Abschaltung(). Bei der Überprüfung mittels Anzeige der Entladezeit bestätigt sich meine Feststellung - sie wird zu schnell hochgezählt. Da sie nur im Programmteil Entladen() benutzt wird, habe ich das Hochzählen in SekTick() nunmehr gelöscht und damit funktioniert die Zeitangabe auch richtig. Bei meinem "großen Display" habe ich die Entladezeit nunmehr im "leeren" Sektor angezeigt -bringt etwas Bewegung ins Spiel -. mfG frewer
Hallo frewer Danke für die Fehlerbeschreibung. Ich habe den Fehler mit der fasch hochgezählten Zeit korrigiert und die neue Version ins SVN-Repository hochgeladen. Gruss Philipp
Hallo Philipp,
ok, prima, dann habe ich ja schon Einiges gelernt. Übrigens habe ich
weiter festgestellt, dass zumindest bei meiner Hardware der Entladestrom
nicht linear eingestellt werden kann. Bei kleinen Akkuspannungen liegt
das anders als bei mehrzelligen Akkus. Deshalb bin ich hergegangen und
habe zunächst mal die Strommessung penibel mit der Hardware (Toleranzen)
abgeglichen und dann in die Routine Entladen() noch eine PWM-Regelung
eingebaut. Ich vergleiche stets den gemessenen Strom mit dem gewünschten
Strom und regle bei Abweichungen nach. das funktioniert auch ganz
ordentlich und ich komme auf Abweichungen von wenigen mV mal drüber mal
drunter.
// DAC nachregeln
if(Akku.Strom > Akku.Entladestrom)
{ DAC(strom-=1); }
if(Akku.Strom < Akku.Entladestrom)
{ DAC(strom+=1); }
wobei ich zu Beginn natürlich die Variable "strom" auf den Sollwert
"Akku.Entladestrom" setze.
mfG
frewer
Philipp Kälin schrieb: > Ich werde mir das mit der falschen Spannung mal ansehen, auch dass die > aktuelle Spannung angezeigt wird und nicht der letzte Wert, werde ich > ändern. > > Im moment habe ich wegen der Semesterprüfungen nicht so viel Zeit und > die Hardware gerade nicht zur Hand, ev. komme ich am Wochenende dazu. > Hallo, ich hoffe Du hast inzwischen deine Semesterprüfungen gut überstanden. In der Zwischenzeit habe ich mir das unten im Link stehende Ladegrät gekauft. Beitrag "POWEREX MH-C 9000 NiCd / NiMH Ladegerät" Problem ist nur, das meine wirklich schlechten Akkus von diesem Ladegerät abgelehnt werden, so das es mir nicht möglich die Kapazität zu prüfen. Bitte lese Dir noch mal dieses Posting durch: Beitrag "Re: Projet um die Kapazität von Akkus zu messen" Bernd_Stein
Hallo, nach vielen versuchen und Einstellungen läuft das Gerät, dennoch bin ich nicht so richtig zufrieden. Die von mir vorgeschlagene PWM-Steuerung habe ich wieder entfernt, weil sie zum Schwingen neigte. Daneben habe ich aber noch folgende Schwierigkeiten: 1. Z.B. schaltet der Analogteil den Entladedarlington nicht völlig ab, es bleiben ca 20mA, die immer fließen. Statt dem TLC272P verwende ich allerdings den CA358E (war gerade da). Das jedoch kann eigentlich m.E. nicht dan Mangel hervorrufen. Wo kommt das her: Ich messe an den Eingängen 3 und 2 des OpAmp (5A) je 0,09mV (so zeigt es jedenfalls mein Multi im kleinsten Spgsbereich an). Daraus ergibt sich aber am Ausgang 1 1,25V und die stehen auch am Ausgang 1 des OpAmp (4A) und damit fließt natürlich ein kleiner Strom. Wegen des geringen Messwiderstandes von nur 1 Ohm (1,8 war nicht da) gibt es die kleine Spg am Eingang. Hat das Problemchen noch jemand und wenn ja, wie konnte es gelöst werden? 2. Mit vielen Messungen habe ich jetzt auch eine einigermaßen genaue Anzeige der Messwerte einstellen können. Da der Messwiderstand zumindest bei höheren Strömen (1A) warm wird, ändert sich auch sein Wert und damit die Anzeige des Stromes. Elegant wäre deshalb, wenn man auch den Strom und die PWM kalibrieren könnte. In einem ersten Schritt habe ich sowohl in der Routine DAC() als auch ReadCurrent() die Berechnung der werte mit Rmess eingeführt, den ich dann einfach anpassen kann. Das klappt auch ganz gut. Im nächsten Schritt werde ich eine Kalibrierung der Strommessung ähnlich der Spgsmessung machen (5V mit einem bekannten Vorwiderstand), so dass ich den Widerstand Rmess und das teilerverhältnis automatisch ermittle. Daran arbeite ich aber noch. 3. nehme ich während des Entladevorgangs die Batterie mechanisch weg, dann bleiben bei mir ca 0,6 V Restspannung am Spgsmeßpunkt zurück und das obwohl die Pullups bei Strom und Spannung ausgeschaltet sind. Auch dieser Effekt ist noch unklar. mfG frewer
Viele deiner Probleme liegen wahrscheinlich gerade am CA358. Das ist ein Low-Cost Op der den Ausgang nicht sauber auf 0 ziehen kann. Im Datenblatt http://www.datasheetcatalog.org/datasheets/90/62591_DS.pdf Seite 4 ist die Ersatzschaltung. Wenn der Q13 den Ausgang auf V- zieht bleiben immer noch die ca. 0.7V Vbe am Ausgang 1. Das ist genau der Grund warum ich den TLC272P verwendet habe. Entweder taschst du den OP oder baust eine negative Speisung für V- ein. Grüsse Philipp
Vielen Dank Philipp für Deine Analyse. Ich werde das gleich mal in der Richtung untersuchen und eine neg Versorgung dran hängen. Den TLC werde ich bei der nächsten Bestellung mal anschaffen. mfG frewer
Hallo Akku-Entlader, also habe viele Versuche gemacht und stelle nunmehr Folgendes fest. Der verwensete CA358E scheint durchaus geeignet, sein Ausgang gegen GND ist ein pnp Transistor, der den Emitterfolger gut sperren müsste. Das tut er auch, wenn ich die Schaltung vom PWM Impuls trenne. Messe ich am PWM Ausgang PortD.5 OC1A, dann sehe ich dort auch bei Current = 0 am DAC Impulse mit einer Breite von ca 130 nsec, die natürlich am Eingang des OpAmp anliegen. Zunächst habe ich dann die Software überprüft, kann jedoch keine Unstimmigkeiten zum Datenblatt feststellen. Offenbar ist diese Impulsbreite das Minimum. Im übrigen kämpfe ich noch mit einer Brummspannung von 20nsec Impulsbreite und 400 mV Spitze-Spitze Amplitude an der Basis des TIP142 (bei mir TIP120). Auch ein Kapazitäten-Friedhof hat bisher nicht geholfen. Nächster Schritt wird mal noch die Untersuchung der leitungsführung sein, denn der Brumm scheint vom ATMEGA32 zu kommen. In einem zweiten Schritt denke ich daran, das Ganze über einen Spannungsteiler dem Lasttransistor anzubieten, was dann breitere PWM-Impulse zur Erzeugung des Stromes bedarf. Damit sollte der sog 0-Impuls dann auch die 10 mA Messung nicht stören. mfG aus der bastelbude frewer
Werner Freytag schrieb: > ... > Das tut er > auch, wenn ich die Schaltung vom PWM Impuls trenne. Messe ich am PWM > Ausgang PortD.5 OC1A, dann sehe ich dort auch bei Current = 0 am DAC > Impulse mit einer Breite von ca 130 nsec, die natürlich am Eingang des > OpAmp anliegen. Zunächst habe ich dann die Software überprüft, kann > jedoch keine Unstimmigkeiten zum Datenblatt feststellen. Offenbar ist > diese Impulsbreite das Minimum. > Diesen Fehler müsstet Du dadurch wegbekommen, indem Du den OC1A Pin als Tri-State Eingang umschaltest wenn die PWM Null sein soll. Im übrigen - hast Du eine Softwareversion die den Fehler der hier im letzen Abschnitt beschrieben ist beseitigt ? Philipp hat wohl keine Lust mehr dazu. Beitrag "Re: Projet um die Kapazität von Akkus zu messen" Bernd_Stein
Hallo Bernd, erstmal vielen Dank für den rat, ich werde das heute mal mit Deiner idee testen. Was die Software angeht, so bin ich schon etwas weg von Philipps Versionen. Ich hatte zuerst mal an ein anderes Display - 194x64 - angepasst und dann einige kleinere Änderungen vorgenommen. So kann ich jetzt die Entladezeit anzeigen und habe festgestellt, dass da was nicht stimmt, denn der Zähler zählt etwas zu schnell. Da ja aber die Zeit nicht benötigt wird, ist das wohl nicht so wichtig. Dann habe ich auf eine 3 Tastenbedienung umgestellt und die SD-Karte sowie die zweite Sprache mit dem ganzen Software-drum und dran rausgenommen. Mir scheint das für meinen Zweck ein bisschen übertrieben. Und im EEPROM speichere ich eigentlich nur den Wert für die Kalibrierung. Alle anderen werte stehen ja im Flash und nehmen dort auch kein "RAM" weg. Mit Deiner vergleichenden Messreihe habe ich noch nicht angefangen, weil ich relativ lange für das Verstehen und Nachvollziehen der Anzeigemethode von Philipp gebraucht habe. Seine Programmtechnik finde ich interessant und ich lerne immer was dazu. Die ganze Rechenlogik ist bei mir noch Original Philipp. Wie ich schon sagte, will ich erst mal das Problem mit dem "Reststrom" lösen, da ich eigentlich das Ganze für das Testen von 1 zelligen NiCD Akkus verwenden wollte und da stört mich dieser Reststrom. Das Analogteil habe ich dann auch vereinfacht und habe für die Tests nur 1 BD639-Darlington mit 1 Ohm Messwiderstand. Falls jemand an der geänderten Sotware Interesse hat, bin ich bereit sie weiterzugeben, wenn Philipp zustimmt. mfG frewer
Den Reststrom messe ich bei mir auch mit ca. 6mA an einem 12V Akku. Etwa 2.3mA kommen vom Spannungsteiler für die Spannungsmessung die restlichen rund 3.7 mA weiss ich nicht genau wo die hinfliessen, im Datenblatt habe ich jedoch gesehen, dasss die beiden Transistoren je einen CutOff Strom von 2 mA haben. Um die Spitzen weg zu bekommen könnt ihr mal versuchen die DAC Funktion wie folgt zu ändern:
if (Current != 0) { if ( !(TCCR1A & COM1B1) ) { TCCR1A |= (1 << COM1B1); } PWM = Current / 5.425; OCR1B = (unsigned int) PWM; } else { // Wenn der Strom 0 sein sollte den // PWM Ausgang deaktivieren und // manuell auf Low TCCR1A &= ~(1 << COM1B1); PORTD &= (1 << 4); OCR1B = 0; } |
dann noch hier änder
void Application(void) { AnswMenue_Betribswahl answer; DAC(0); ... } |
Die Spitzen sollten nun weg sein. Bei mit hatte es jedoch keinen Einfluss auf den Reststrom. Gruss Philipp
Hi Philipp,
Mir sind 2 Dinge bei Deinem Vorschlag aufgefallen:
1. if ( !(TCCR1A & COM1B1) ) { TCCR1A |= (1 << COM1B1);} funktioniert
bei mir nicht, ich habe deshalb einfach nur "TCCR1A |= (1 << COM1B1);"
verwendet ohne mir Gedanken zu machen und
2. "PORTD &= (1 << 4);" muss wohl "PORTD &= ~(1 << 4);" heißen.
Mit den Änderungen verhält es sich bei mir so, wie Du es beschreibst.
Die Impulse sind jetzt zwar im Leerlauf weg, trotzdem bleibt ein
Reststrom - allerdings weniger als zuvor - bestehen. Das muss also vom
Transistor oder vom OpAmp herrühren oder wie ich noch eher vermute von
dem "Dreck" auf den Leitungen. Da muss ich nochmal ran. Ich komme mit
der Änderung auf etwa die 10mA jetzt aber definiert.
Bei meinem 1 Ohm Messwiderstand schlage ich mich natürlich in den
Bereichen unter 200 mA und geringer zellenzahl laufend mit dem "Dreck"
auf den Leitungen rum. Bei 50mA Entladestrom bekomme ich Anzeigen des
Entladestromes von 49 - 71 mA (dabei ist allerdings noch keine
Kalibrierung des Strommesspfades gemacht).
Falls Du weitere Erkenntnisse hast, bin sehr interessiert.
mfG
frewer
Werner Freytag schrieb: > Hallo Bernd, > > ... > erstmal vielen Dank für den rat, ich werde das heute mal mit Deiner idee > testen. Wenn ich die nachfolgenden Postings richtig verstanden habe, ist dies ja nicht mehr nötig. > > Mit Deiner vergleichenden Messreihe habe ich noch nicht angefangen, weil > ich relativ lange für das Verstehen und Nachvollziehen der > Anzeigemethode von Philipp gebraucht habe. Seine Programmtechnik finde > ich interessant und ich lerne immer was dazu. Die ganze Rechenlogik ist > bei mir noch Original Philipp. > Tja, da werde ich wohl noch ein wenig warten müssen, denn C kann ich nicht und kann Euch somit auch nicht in dieser Weise unterstützen. > > Wie ich schon sagte, will ich erst mal das Problem mit dem "Reststrom" > lösen, da ich eigentlich das Ganze für das Testen von 1 zelligen NiCD > Akkus verwenden wollte und da stört mich dieser Reststrom. > Dies ist auch meine erste Anwendung hierfür, um überhaupt mal eine Aussage zu haben was meine Schrottakkus noch können. Meine LED-Nachttischleuchte kann ich damit noch wunderbar über Wochen betreiben, da die Einsatzzeit relativ kurz ist. Auch meine Telefonakkus machen noch ein paar Tage mit, nur leider merke ich das einige Akkus für diese zweite Anwendung nicht mehr ganz so gut zu gebrauchen sind, da beim Klingeln einfach ein Reset erzeugt wird. Und von diesen möchte ich nun die wirklich nicht mehr Brauchbaren entsorgen. Bernd_Stein
Hi Bernd, mich interessiert als Erstes, ob Du exakt das Original von Philipp nachgebaut hast und auch dessen Firmware verwendest. Dies ist deshalb wichtig zu wissen, weil ich schon viele Änderungen gemacht habe, weil ich auf Vieles verzichte. Dann ist wichtig zu wissen, wie Du die Tabelle aufgenommen hast und ob Deine Tabelle noch dem letzten Firmwarestand entstanden ist. Wenn ich das Thema so richtig durchlese, dann hat doch Philipp auf Deine Anmerkungen reagiert und eine neue Version herausgegeben. Beim Entladen stelle ich noch fest, dass offenbar die Uhr nicht richtig geht. Bei meiner Anzeige der Entladezeit werde ich das Gefühl nicht los, dass der SekTakt zu schnell ist. Das werde ich als Nächstes mal abklären. Könnte natürlich mit meiner Quarznutzung zusammenhängen, denn ich verwende den reichelt 24MHz 3. Oberwelle Quarz als 8MHz Quarz. Das hat bei meinen anderen projekten auch prima funktioniert, trotzdem werde ich mal die Timer-Einstellungen genau unter die Lupe nehmen. Nachdem ich dann mit dem Entladen einigermaßen klarkomme, werde ich mich mal an die Ri-Messung machen und Dein Problem angehen. Übrigens, wenn Du mit C noch nicht klarkommst, dann ist das Programm von Philipp wirklich eine gute Schule - allerdings nicht ganz so einfach nachzuvollziehen, wie ich es anfangs dachte (bin auch kein c-Experte sondern mach mal Assembler, dann mal wieder C, dann mal AVR oder C51) -. mfG frewer
habe im init.c für die Einstellung des Timer2 eine kleine Änderung eingeführt, die ich mal aus einem anderen Projekt mit einer genauen Quarzuhr hatte. Dort wurde der OCR2 auf statt auf 250 auf 249 eingestellt. Offenbar wird erst beim nächsten Clock der IRQ ausgelöst. Mit dieser Änderung scheint die Uhr jetzt korrekt zu sein. mfG frewer
hi Bernd, hab mal Deine Textstellen nachgelesen und gesehen, dass Du Dich dafür interessierst, wo Du die Anzeigekorrekturen machen kannst, damit Anzeige und Messwert übereinstimmen. Es gibt 2 Spannungsteiler. Einer für die Spannung, der wird kalibriert duch die Kalibrierung, also ist klar (Fehler nur, wenn die 5V nicht 5V sind). Der 2te Teiler für den Strom ist nicht kalibrierbar - ich erwähnte das schon -. Philipp arbeitet mit einem fest eingestellten Spgsteiler mit dem Wert 2 (2x 1kOhm). Den Wert findest Du im Programmteil adc.c in der Routine 'Read_Current()' ziemlich weit unten. Mit dem Spgsteiler rechnet Philipp zunächst aus dem ADC-Wert die Spg aus und teilt diese dann durch den Messwiderstand (1,8 Ohm). Soweit so gut, aber weder der Widerstand ist so genau (bei mir 10% und mit meinen Mitteln nicht messbar) und natürlich sind die Widerstände am Spgsteiler auch nicht genau. Also muss man pfriemeln, wie wir sagen. Ich habe dazu zunächst einen 'float Rmess' eingeführt, weil Rmess ja auch bei der PWM Einstellung in der Funktion DAC() - zu finden in application.c - benutzt wird. Dann brauch ich zunächst mal nur meinen RMess ändern, der Rest geht automatisch. Bleibt der Spgsteiler, der mit dem wert 2 angegeben ist. Ich habe da viel rumprobiert, weil bei 1 Zelle und den ganzen "Restströmchen" ich einfach keine saubere Lösung hinbekam. Ich habe verschiedene gebrochene Werte für den Spgsteiler errechnet (messe am Widerstand und am ADC Eingang die Spannungen und gebe das Ergebnis ein) und dann Auge zu und durch. Na ja, es scheint einigermaßen zu funktionieren, wenn ich auch Nichtlinearität bei verschieden eingestellten Strömen feststelle. Zum Glück wird der Spgsteiler nur in der Read_Current() Funktion gebraucht. Soviel zum "wo finde ich was" und soweit ich helfen konnte. mfG frewer
Werner Freytag schrieb: > Hi Bernd, > mich interessiert als Erstes, ob Du exakt das Original von Philipp > nachgebaut hast und auch dessen Firmware verwendest. > ... jaein. Die Schottky-Diode D3 im Leistungskreis ist bei mir eine MBR10100. IC4A ist bei mir IC5B, somit sind beide OpAmps in einem Gehäuse ( IC5A und IC5B ). IC5B bzw. nun eigentlich IC4A für die Lüfteransteuerung ist bei mir ein altbewährter 741, wobei natürlich die Versorgungsspannung +12V an einem anderen Pin liegt und auch die anderen Pinne anders belegt sind. Die Emitterwiderstände des Lastkreises R23 und R24 sind bei mir nur 2W und R17 der Shunt ist eine aus Widerstandsdraht gewickelte Luftspule um die 1,8 Ohm zu erreichen. Den Spannungsteiler ( R12 und R13 ) für die Akkuspannung ( UBATT ) habe ich mit 0,1%igen Widerständen aufgebaut. Die Resetbeschaltung des µCs ist etwas anders. In Reihe zu R1 ist eine weisse Ultra helle LED mit der Anode an +5V. Parallel zu diesen beiden ist eine Si-Diode oder Shottky Diode ( 1N4148 oder BAT41 ) mit der Kathode an +5V. Am Resetpin ist zudem ein Elko mit seinem Plusanschluß und der Minus- anschluß geht an GND. Er besitzt einen Wert von 4,7µF. Weiterhin ist am Resetpin ein Taster gegen Masse ( GND ) und eine Schottky-Diode( BAT 41 ) mit ihrer Anode angeschlossen. Ihre Kathode geht an den Pin 5 ( /RESET ) eines Standardmäßigen 10-Poligen ISP ( In System Programable ) Anschlusses für die AVR-Controller. Ich habe also einen ISP Zugang geschaffen ( durch umstecken von drei Jumpern realisiert, wobei Änderungen an den Leitungszuführungen zum SD-Karten Slot gemacht werden mussten ), da ich von diesem JTAG keine Ahnung habe. Die Resetbeschaltung ist also ebenfalls Standard bis auf die weiße LED die den Resetzustand anzeigt. Die Anschlußbelegung für das Grafik LCD ( GLCD => X3 ) musste auch angepasst werden bzw. die Verdrahtung von dort zu den Anschlüssen des GLCD, um das Pollin GLCD nutzen zu können. Den SD-Karten Slot habe ich noch nicht aufgelötet jedoch alle notwendigen Vorbereitungen dafür schon gemacht. Bei der Spannungsversorgung habe ich zu IC2 ( 7805 ) eine Diode des Typs 1N4007 parallel zu Vin und Vout geschaltet, wobei die Kathode an Vin angeschlossen ist. Den Ausgangselko C12 habe ich auf 220µF erhöht. IC3 ( LM317 ) holt sich seine Eigangsspannung nicht mehr von den +12V sondern von den +5V die von IC2 erzeugt werden. Er besitzt ebenfalls die Schutzdiode 1N4007. An seinem ADJ pin hängt ein 100nF Kerko gegen GND und der Mittelabgriff eines Spannungsteilers aus den Widerstandswerten 240 Ohm und 390 Ohm. Wobei der 390 Ohm an GND angeschlossen ist und der 240 Ohm an Vout des LM317. C6 ist somit anders angeschlossen worden ( zwischen ADJ und GND ). Den Ausgangselko des LM317 ( C13 ) habe ich ebenfalls auf 220µF erhöht und da ich dort eine Grüne LED verwende, ihren Vorwiderstand ( R3 ) auf 10 Ohm geändert. Ist also auch eine Standardbeschaltung, um die 3,3V zu erzeugen. Dies liest sich alles bestimmt sehr kompliziert, doch wenn man es in die vorhandenen Schaltpläne einzeichnet wird einem die Beschreibung viel verständlicher. > > Dann ist wichtig zu wissen, wie Du die Tabelle aufgenommen hast und ob > Deine Tabelle noch dem letzten Firmwarestand entstanden ist. Wenn ich > das Thema so richtig durchlese, dann hat doch Philipp auf Deine > Anmerkungen reagiert und eine neue Version herausgegeben. > Als Firmware benutze ich die Version 1.7. Bei der Ri-Messung besteht immer noch ( Version 1.7 ) das Problem der versetzen Anzeige des Stromes ( Stromanzeige stimmt erst zu der nachfolgenden Prozentanzeige ). Der Wert selbst geht in Ordnung ( i.O. ). Die Spannung wird total falsch angezeigt ( Spannung am µC ist i.O. ), somit ein reiner Softwarefehler. Beim Entladeprogramm gibt es seltsamerweise kein Problem mit der Spannungsanzeige, dort stimmt die Spannungsanzeige auf dem GLCD. Mit dem Strom habe ich in dieser Betriebsart keine Untersuchungen angestellt, möchte nämlich zuerst die vorhandenen Mängel beseitigt haben bevor ich wieder noch mehr Zeit in dieses Projekt stecke. > > ... > Übrigens, wenn Du mit C noch nicht klarkommst, dann ist das Programm von > Philipp wirklich eine gute Schule - allerdings nicht ganz so einfach > nachzuvollziehen, wie ich es anfangs dachte (bin auch kein c-Experte > sondern mach mal Assembler, dann mal wieder C, dann mal AVR oder C51) -. > Da ich keine Ahnung von C habe will ich daran eigentlich nicht herumfuschen, da ich mich noch in Assembler übe und dort bereits merke was so kleine Programmänderungen ausrichten können. Somit ist meine vorherige Aussage nicht mehr aktuell, das ich da selbst dran rumfuschen möchte. Bernd_Stein
Hi Werner und Philipp, tut mir leid das ich das jetzt erst bzw. im Posting davor erwähne, aber mal eben ein Programm zu ändern ist fast unmöglich, wenn man nicht einmal das " Alphabet " der Programmiersprache kennt. Da ich mich noch in Assembler übe, denke ich nun nicht mehr daran das C-Programm von Philipp sinvoll ändern zu können. Ich finde es wirklich ein sehr gutes Projekt und würde mich deshalb auch freuen, wenn die von mir bemerkten Mängel abgestellt würden. Finde es auch ein wenig schade, das Du Werner etwas eigenes gemacht hast ( Taster an stelle von Impulstaster usw. ), da dies ja auch in der Software berücksichtigt werden muss und dies zu ganz unterschiedlichen Versionen führt und nicht nur zu " Updates ". Bernd_Stein
Hi Bernd
ok, kann Deine Bedenken gut nachvollziehen. Aber ich wollte halt für das
Display keine 17€ ausgeben, wenn es ein anderes für 7€ gibt. Und dann
wollte ich auch nicht auf die Beschaffung von 1 Encoder warten, Porto
viel mehr als Produkt, daher die Tasten. Deshalb musste ich einige
Änderungen eben machen. Macht übrigens Spass ein bisschen mit Philipps
Software zu arbeiten und man lernt ungemein viel. Dabei habe ich die
Systemprogramme von Philipp nicht angetastet, weil ich mit dem Rest
genug zu tun hatte. Ein Update mit meinem Programm ist nicht möglich,
weil ich wegen des Display z.B. auch auf den Lüfter verzichtet habe.
Vielen Dank für Deine Schaltungsbeschreibung. Werde davon einige Dinge
übernehmen. Ich hänge immer noch am Problem der Restströme. Bei kleinen
Akkuspannungen 1,2V ist die ganze Messerei schwierig.
Nun zur Ri Messung:
Ich habe mal mit einem 3zelligen NiCD Akku die Aufzeichnung nach Deinem
Muster gemacht.
Ich stelle fest, dass mein Teilerverhältnis (11,5) nicht korrekt ist und
ich besser auf 11,03 gehe. Diese Änderung ist bei Deinen
Präzessionwiderständen nicht nötig.
Zwar habe ich auch noch nicht kapiert, warum der Anzeigestrom vom
vorgegebenen Entladestrom so horrent abweicht, aber das wird wieder ein
interessantes Studium von Philipps Software (application.c Routine
RiMessen().
Ubat = am Akku gemessen
Upin = Spg an Pin 39
Ipin = Spg an Pin 40
Uanz, Ianz = die angezeigten Werte
Ugerechnet = Upin * Teiler hier 11,5
% Ubat Upin Ipin Uanz Ianz Ugerechnet
11,5
0 3,84 348 9 3909 7 4002,00
15 3,82 346 19 3886 41 3979,00
20 3,80 345 24 3886 39 3967,50
25 3,79 345 29 3881 52 3967,50
30 3,79 343 34 3875 75 3944,50
35 3,78 344 34 3875 75 3956,00
40 3,78 343 39 3863 77 3944,50
45 3,78 343 43 3857 86 3944,50
50 3,77 341 48 3852 101 3921,50
55 3,77 342 48 3846 113 3933,00
60 3,75 341 53 3852 106 3921,50
65 2,14 341 58 3846 126 3921,50
70 3,75 340 63 3834 133 3910,00
75 3,74 340 63 3834 145 3910,00
80 3,74 339 68 3828 146 3898,50
85 3,73 339 73 3823 157 3898,50
90 3,73 337 78 3806 169 3875,50
95 3,72 338 77 3817 182 3887,00
Rimax = 6000 mOhm
Rimittel = 1068 mOhm
Ich stelle doch fest, dass Uanz durchaus mit Ubat in einem Zusammenhang
steht. Die Abweichung kommt sicherlich von meinem Spannungsteiler, den
ich jetzt korrigiert habe.
Wenn ich die Routine RiMess() kapiert habe, melde ich mich wieder.
frewer
Werner Freytag schrieb: > Hi Bernd > > ... > Ich hänge immer noch am Problem der Restströme. Bei kleinen > Akkuspannungen 1,2V ist die ganze Messerei schwierig. > Schade. Da ich bei Deiner Messreihe erstmal den festgestellten Mangel nicht erkenne und dies wahrscheinlich nur in der Software zu finden ist warum dies bei nur einer Zelle bzw. geringeren Akkuspannungen auftritt. > > Nun zur Ri Messung: > Ich habe mal mit einem 3zelligen NiCD Akku die Aufzeichnung nach Deinem > Muster gemacht. > Ich stelle fest, dass mein Teilerverhältnis (11,5) nicht korrekt ist und > ich besser auf 11,03 gehe. Diese Änderung ist bei Deinen > Präzessionwiderständen nicht nötig. > Hätte mir auch gern die Präzisionswiderstände gespart, denn Softwareänderungen brauchen keine besonderen Bauteile bzw. dessen Beschaffung. > > Zwar habe ich auch noch nicht kapiert, warum der Anzeigestrom vom > vorgegebenen Entladestrom so horrent abweicht, aber das wird wieder ein > interessantes Studium von Philipps Software (application.c Routine > RiMessen(). > Schön das ich Dich auf eine interessante Sache hinweisen konnte. Ich sehe das an Hand der Tabelle nicht. Muß wahrscheinlich den Strom ausrechnen. Mal sehen wann ich mir dafür Zeit nehme. Wenn Du den Strom errechnet hättest, wär er sicherlich mit in der Tabelle, deshalb nehme ich an das Du ihn gemessen hast. Dabei muß man natürlich beachten, ob der µC auch den Spannungsfall über dein Strommessgerät mitbekommt. Das heißt dieses muß entweder vor oder hinter R17 in Reihe liegen und sein Widerstand sehr viel geringer sein als der von R17, da die Software ja sicherlich von 1,8 Ohm ausgeht. Bernd_Stein
So, jetzt habe ich die Routine < void RiMessen(void) > mal analysiert. Dabei ist mir nichts Besonderes aufgefallen. Die Anzeige von Strom und Spannung geschieht stets nach demselben Vorgehen sowohl beim Entladen als auch der Ri Messung. Ich habe die Routine mal detailliert beschrieben, vielleicht findet ja jemand noch einen Haken: Die Routine unterteilt das vorgegebene Messintervall in 21 Intervalle zu denen je ein Messstrom gehört. Der Messstrom wird von 0 beginnend 20 mal um 1/20 des vorgegebenen Messstromes erhöht. Für jedes Intervall wird im letzten Viertel 5 mal der Strom und die Spannung gemessen und abgespeichert. Wenn das vorgebene MessIntervall abgelaufen ist, werden aus je 2 aufeinanderfolgenden Messwerten das Strom- und Spannungsdelta gebildet und aus diesen der maximale und der mittlere Widerstand berechnet. Für die Berechnung ist wichtig, dass sowohl das Stromdelta als auch das Spgsdelta > 0 sein muss. Der Ablauf im Detail: · Fußzeile schreiben, dann Menüaufruf, wenn ‚ändern’ gewählt (sonst werden die voreingestellten Werte (Werkseinstellungen) benutzt). · Ri.currentStep = 1/20 des vorgegeben Stromes · Füllen des Arrays Ri.currentPoints[] beginnend bei 0 mit 20 Messstrom-Vorgaben Ri.currentStep (0..20 = 21 mal Ri.currentStep) · Ri.startTime = Messintervall (vorgegeben) * 750 => Beschränken auf das letzte Viertel der Messung (bei 30sec Miv Beginn nach 22500 msec) · Zeitspanne zwischen den Messungen = ((Messintervall * 1000)-startTime) / 5 bei 30sec MIv = 1500msec · 21 Messvorgänge (i=0..<21) mit 30 sec Dauer und jeweils ansteigendem Strom (1/20 des max. Stromes). Gemessen wird immer erst im letzten Viertel. · 5 mal nacheinander Strom und Spannung messen, dann das Ende des MessIntervalls warten (wobei jede Messung aus 4 Abtastungen besteht – ADC_Read() im Programmteil adc.c - ). · Jetzt den Strom 5 und die gemessene Spg 5 in den beiden Arrays Ri.voltagePoints[i] und Ri.effectiveCurrentPoints[i] abspeichern = je 21 Werte. · Anzeigen der Ergebnisse Strom und Spannung sowohl mit Text als auch im Bargraph. · Wenn 21mal abgeschlossen, dann den DAC sperren Berechnung des Innenwiderstandes: · für die 21 Messwerte bestimme jeweils das Delta des Stromes und der Spannung zwischen 2 Messungen (= 20 Werte). Bei der Spg Wert(i) - Wert(i+1), beim Strom Wert(i+1) - Wert(i). · Wenn beide Deltas >0 sind, dann sind es gültige Messwerte und der Innenwiderstand ri = Delta Spannung / Delta Strom. Der max Innenwiderstand = der größte gemessene Innenwiderstand ri. Der mittlere Innenwiderstand = Aufsummierung aller ri geteilt durch die Anzahl der Messungen. · Sind die Deltas nicht beide >0, dann wird die Auswertung übersprungen. · Mit der Anzeige des max und des mittleren Ri wird die Routine abgeschlossen. Jetzt habe ich das Verfahren mal auf meine Messung angewandt und dabei festgestellt, dass der Ri max aus einem einzigen Wertepaar besteht, weil entweder ein Delta = 0 ist oder aber alle anderen Ri kleiner sind. Daraus erklärt sich auch der mittlere Ri-Wert, der bei allen Messungen bedeutend kleiner ist als der max Ri-Wert. Mir scheint, dass der mittlere Ri-Wert wesentlich mehr Aussagekraft hat. Wie sieht man das in Expertenkreisen? Mir ist nicht bekannt, wie man vernünftig den Innenwiderstand eines Akkus misst. frewer
Werner Freytag schrieb: > Hi Bernd > ... > Ich stelle doch fest, dass Uanz durchaus mit Ubat in einem Zusammenhang > steht. Die Abweichung kommt sicherlich von meinem Spannungsteiler, den > ich jetzt korrigiert habe. > Bin jetzt mal Deine Tabelle mit dem Taschenrechner nachgegangen. Nach den ersten Berechnungen für den Strom hab ich dann aufgehört, da ich erkennen konnte das es da Deine beschriebenen " horrenden " Abweichungen gibt. Und bei der Spannung reicht mir ein Zusammenhang auch nicht. Ich möchte möglichst genaue Werte. Von einer schönen Anzeige und einer guten Bedienung des Gerätes habe ich also nicht viel. Beitrag "Re: Projet um die Kapazität von Akkus zu messen" Schade das Philipp hierauf nicht reagiert hat. Vielleicht kannst Du ihn ja nochmal darauf hinweisen. So lange jedoch die dort geschilderten Probleme nicht ausgemerzt werden, ist das Projekt leider für mich uninteressant, da ich die nötigen Programmänderungen nicht selbst vornehmen kann. Bernd_Stein
Hallo Bernd Ich habe die Beiträge verfolgt und mir ein paar Gedanken dazu gemacht: * Wie schon erwähnt habe ich die Schaltung für GROSSE Ströme und Spannungen konzipiert. Das heisst etwa 24V 5A. Die Leckströme habe ich wie beschrieben auch, nur stören die bei mir nicht. * Die Spannungsmessung wird kalibriert und sollte daher auch in gewissem Masse genau sein. Es ist jedoch ausdrücklich keine High End Schaltung. Dazu fehlen externe Spannungsreferenz und ev. auch ein höher auflösender AD-Wandler. * Die Strommessung wird nicht kalibriert und mir fällt bei der jetztigen Schaltung auch keine Kalibrationsmöglichkeit ein. Nur schon der Temperaturdrift des 1.8Ohm Widerstands macht dies unmöglich. Da müsste man z.B. einen 0.01Ohm Messwiderstand mit nachgeschaltetem OP nehmen. Wenn du aber die ganze Schaltung umbaust wirst du um Softwareänderungen nicht herumkommen. * Zuguter letzt bin ich zwar gewillt bei Problemen zu Helfen, grundsätzlich ist aber der Source offen da, damit jeder selber damit machen kann und soll was er will. Wenn du die Idee "zweckentfremdest" kannst du nicht erwarten, dass ohne Änderungen gute Resultate dabei herauskommen. Grüsse Philipp
Philipp Kälin schrieb: > Hallo Bernd > > Ich habe die Beiträge verfolgt und mir ein paar Gedanken dazu gemacht: > * Wie schon erwähnt habe ich die Schaltung für GROSSE Ströme und > Spannungen konzipiert. Das heisst etwa 24V 5A. > ... > Danke das Du doch noch auf mein Posting geantwortet hast. Habe auch noch mal Deine Beiträge gelesen. Entschuldigung. Das mit den hohen Spannungen, war mir im Laufe der Zeit wieder entgangen. Beitrag "Re: Projet um die Kapazität von Akkus zu messen" Das kann ja dann auch nicht hinhauen. Ich möchte einzelne Mignon,- und Microakkus auf ihre Kapazität hin überprüfen. Der Strom von bis zu 5A ist da zwar im Moment etwas überdimensoniert, aber die Akkutechnologie entwickelt sich ja weiter. Werde hoffentlich im Herbst bzw. Winter mal nach einer Endstufe gucken die dieses möglich macht. Bis dann Bernd_Stein
Bernd Stein schrieb: ... > Ich möchte einzelne Mignon,- und > Microakkus auf ihre Kapazität hin überprüfen. Der Strom von bis zu 5A > ist da zwar im Moment etwas überdimensoniert, aber die Akkutechnologie > entwickelt sich ja weiter. Werde hoffentlich im Herbst bzw. Winter mal > nach einer Endstufe gucken die dieses möglich macht. > > Bis dann > Bernd_Stein > Ich denke die ganze Sache ist hiermit abgehakt auch wenn dieses komerzielle Ladegrät diesen für mich kleinen nicht änderbaren Schönheitsfehler hat ( default Wert für den Ladestrom selbst vorgeben ). Beitrag "POWEREX MH-C 9000 NiCd / NiMH Ladegerät" Bernd_Stein
Schickes Projekt, eigentlich genau was ich suche aber mal eine Frage: Wie sähe denn die LV Variante zusammen mit der letzten Revision mit 2 Stück TIP142 aus? IBATT direkt auf GND zu klemmen macht ja wohl keinen Sinn, und direkt an die Emitter, damit würde ich ja die Emitterwiderstände brücken - auch nicht Sinn der Sache. Und nur einen Emitter anzapfen? Müsste man nicht strenggenommen - wenn man den 3055 um jeden Preis vermeiden möchte - den Messwert mit zwei OpAmps seperat erfassen?
Holger K. schrieb: > Wie sähe denn die LV Variante zusammen mit der letzten Revision mit 2 > Stück TIP142 aus? Zwei Transistoren parallel schalten würde ich bei der LV/Variante nicht machen. Bipolartransistoren und auch Dioden haben einen Wärmekoeffizient von -2mV/°C. Das heisst, dass die Kollektor-Emitter Spannung bei steigender Temperatur sinkt. Das bedeutet, dass wenn ein Transistor einen grösseren Strom abbekommt, sich dieser stärker erwärmt und dann noch mehr Strom abbekommt, da sein Spannungsabfall niedriger ist als beim "kalten" Transistor. Dieser Teufelskreis endet meist mit dem Tod aller beteiligten Transistoren :-( Der Emitterwiderstand muss also so gross sein, dass er den oben genannten Effekt kompensiert. Bipolartransistoren darf man daher nur mit "grossen" Emitterwiderständen parallel schalten (alles über ca. 1 Ohm gilt in diesem Anwendungsfall als gross). Welche Spannungen und Ströme stellst du dir denn vor?
Hallo Philipp, Ja, ich hab mittlerweile auch mal geschaut, da es sich bei mir in erster Linie um AA und AAA Akkus dreht, dürfte ein TIP142 völlig ausreichen, die 5A die der 3055 mehr abkann schöpfe ich sowieso nicht aus. Von daher war meine Frage eigentlich schon wieder obsolet. Ich sollte mir mal angewöhnen mich nicht immer nur "abends" zwischen 01 und 03 Uhr mit solchen Sachen zu beschäftigen, dann findet meine CPU auch schneller solche Erkenntnisse. Ich sträube mich ja auch nur gegen den 3055 weil der auf/durch nen CPU Kühler echt blöd zu montieren wäre. Beste Grüße Holger Edit: Spannung, das sind Packs a zwei Zellen also 2,4V. Leider haben Sie keine Mittenanzapfung, sonst konnte ich irgend so kommerzielles Teil von Conrad oder so benutzen.
:
Bearbeitet durch User
Philipp K. schrieb: > Zwei Transistoren parallel schalten würde ich bei der LV/Variante nicht > machen. Bipolartransistoren und auch Dioden haben einen Wärmekoeffizient > von -2mV/°C. Das heisst, dass die Kollektor-Emitter Spannung bei > steigender Temperatur sinkt. Hmmm, habe mir jetzt nochmal die Dateien im SVN angesehen. Auch wenn es für mich jetzt irrelevant ist, aber nur des Verständnis halber: In der letzten Version sind in der Standardendstufe doch nun aber auch zwei BJT paralell geschaltet; mit kleinen Emitterwiderständen. Der Einfluss des Temperaturkoeffizienten mit den beschriebenen Auswirkungen (die mir wohlbekannt sind :-) müsste doch hier ebenso zum tragen kommen, bei hohen Strömen sogar noch schneller, oder - Achtung, ist schon wieder Mitternacht durch :-) - übersehe ich wieder was? Gruß Holger
Hallo Holger, Ich hatte die Schaltung auch nicht mehr so ganz im Kopf, sind doch schon ein paar Jahre seither. Eigentlich hätte im ersten Post schreiben sollen, dass 1 Ohm in diesem Fall riieesengross sind. Damit ein Transistor 1A mehr abbekommt müsste er ja 50°C wärmer sein als der andere bei den 0.1 Ohm Kompensationswideständen. Nun zurück zur LV Variante. Ich würde die unabhängig der aktuellen Version auf dem SVN umsetzen, die betrifft ja nur hohe Ströme. Mit meiner Schaltung hatte ich 24V Batterien bei 5A getestet, da waren die 1.8 Ohm Widerstände und zwei Transistoren nötig. Als einzelnen Transistor kannst du so ziemlich alles nehmen, das muss kein TIP142 sein. Gruss Philipp
Hallo Philipp, okay, danke für Dein Feedback. Dann werde ich das mal in Angriff nehmen. Beste Grüße Holger
Hallo Philipp oder Ihr anderen die diese feine Teil bereits nachgebaut haben. Ich hatte jetzt endlich die Zeit gefunden ebenfalls die Schaltung nachzubauen. Im Grunde funktioniert sie soweit auf bis auf zwei Dinge. Wenn ich den Entladevorgang durchführe und beispielsweise einen Entladestrom von 400mA eingestellt habe, wird der Akku laut DMM nur mit 268 mA entladen. Ich führe dies aber darauf zurück, dass ich anstatt einem teuren 8K Messwiderstand ainen normalen 8,2K Widerstand im Spannungsteiler verwendet habe. Das sollte sich aber in der read_current() anpassen lassen. Was mich aber irritiert ist, dass der am Akkutester angezeigte Entladestrom ständig hin und her hüpft (bei einem entladen mit 2000mA werden ständig andere Werte etwa zwischen 1800 und 2200mA angezeigt. Der gemessene Entladestrom bleibt aber gleich (bei 2000mA wären es am DMM tatsächliche 1650mA) Ich kann mir kaum vorstellen dass das so sein soll, oder? Gruß Holger
Hallo Holger Wo ist eigentlich genau dieser 8k Widerstand verbaut, ich wüsste nicht das ich so einen krummen Wert irgendwo verbaut habe. Bezüglich dem schwankenden Messwert könnte folgendes eine Erklärung sein: Zur Erhöhung der Genauigkeit habe ich 2 Referenzspannugnen verwendet. Einerseits ist das AVCC (die normale 5V Spannungsversorgung) und die Interne Referenz (2.56V). Wenn dein Messwert genau da zu liegen kommt wo die Umschaltung stattfindet, dann könnte das eine Erklärung für das Schwanken sein. Ich würde allgemein mal die Spannung am AVREF Pin ansehen, ob die sauber ist. Gruss Philipp
Hi Philipp, der ist in der LV Variante, R10 Das mit dem Umschaltpunkt glaube ich nicht, ich hatte verschiedene Akkus (Spannungen) versucht und auch verschiedene Entladeströme. Konnte das aber immer beobachten. Mich wundert auch, dass sich der tatsächlich gemessene Strom nicht ändert. Das Programm müsste doch ansonsten, wenn es von einem schwankenden Wert ausgeht auch versuchen den Strom nachzuregeln, oder? Die Spannung am AVREF schau ich mir aber trotzdem mal an.
:
Bearbeitet durch User
Hallo Holger, Die Regelung geschieht nur in Hardware. Der Sollstrom wird als Analogspannung (PWM-Wert) ausgegeben und vom OP IC5A geregelt. Wenn du sagst, dass der Wert am DMM stimmt, dann heisst das, dass dieser Regelkreis grundsätzlich funktioniert. Ev. schwingt dieser Regelkreis, das kann so noch nicht ausgeschlossen werden. Für die Messung wird ein Mittelwert von 4 Messwerten gebildet. Wenn nun da etwas falsches angezeigt wird, kann das nur heissen, dass entweder die Spannung am OP Ausgang IC4B wirklich schwingt oder dass die Referenzspannung nicht in Ordnung ist.
Ach ja stimmt ja, ich hatte die Schaltungsbeschreibung schon wieder vergessen. Die krux wenn so viel Zeit vom entdecken bis zum aufbau vergeht. Ja dann macht das natürlich eher einen Sinn. Ich werd die Spannungen mal prüfen, bin heute nicht dazu gekommen.
Angehängte Dateien:
-
Newfile1.jpg
87,1 KB, 364 Downloads -
Newfile2.jpg
90,2 KB, 330 Downloads
So, ich bin einen kleinen Schritt weiter, jedoch der Lösung noch nicht näher. Also AVCC ist glatt wie ein Babypopo. Am Ausgang von IC4b schwingt es jedoch ganz ordentlich. Wie Eigenschwingen sieht es aber nicht aus, es ist eher ein Ripple der mit steigendem Entladestrom auch immer größer wird. Habe mal Bilder bei 1A / 2A Entladestrom angehängt. Dieses Ripple ist auch Eingangsseitig bereits zu sehen und wird vom OpAmp entsprechend mit hochgezogen. Ich frag mich nur was die Ursache dafür ist?! Edit: Habs mir jetzt nochmal etwas länger angesehen, glaube nun doch eher auch an Eigenschwingen...
:
Bearbeitet durch User
Ich hole jetzt mal weiter aus: Die Schaltung für die kleinen Spannungen habe ich selber nie aufgebaut sondern nur auf dem Papier kreiert. Da das ganze ein paar Jahre her ist, und ich jetzt ein bisschen schlauer bin, müsste ich wahrscheinlich noch ein paar Sätze anfügen :-) Der TLC272 ist zwar ein Rail-2-Rail OP, aber in der Realität kommt der natürlich nicht ganz an die Rail heran. Wenn ich mir deine KO-Bilder ansehe, dann könnte es sein, dass der OP den Ausgang nicht genügend nahe auf GND bekommt, oder die Eingangsspannung zu nahe bei GND ist. Nichts desto trotz kann irgendetwas nicht stimmen, denn wenn du 1A bzw. 2A effektiven Strom misst bei einem 0,1 Ohm Messwiderstand, dann sollten 0.1V am +Eingang von IC4B anliegen. Mit einer Verstärkung von 9 müsste das ca. 0.9V geben. Um meine Behauptung zu verifizieren, würde ich dem OP mit einem zusätzlichen Netzteil einfach mal eine Speisung von ca. -4V an den Pin 4 geben (max. 16V Speisespannung). Dann hat er sowohl am Eingang als auch am Ausgang genügend Reserve gegenüber der Speisung.
Hallo Philipp, nein, das ist am Ausgang der Lastregelung, also an der Basis vom TIP142 gemessen. Ich hatte schon versucht in die Gegenkopplung vom Lastkreis einen C einzusetzen, wie Frank das beschrieben hatte, was aber rein gar keinen Einfluss hatte. Letztlich dachte ich mir aber genau das was Du geschrieben hast, das die LV Variante nur eine theoretische Abwandlung ist, und habe zuletzt vermutet dass das Eigenschwingen vielleicht in IC5b (war es glaube ich, habe den Plan gerade nicht zur hand) auftritt, da dieser in der normalen Veriante ja überhaupt nicht verwendet wird. Dieser Ausgang liefert ja wiederum das Feedback für den Lastkreis - der wiederum würde dann zwangsläufig mitschwingen. Ich wollte dann mal versuchen dort mit einem zusätzlichen C zu arbeiten aber ach... Da kam mir schon wieder was dazwischen. Das mit der negativen Spannung ist aber auch eine Idee, ich komme darauf zurück, wenn die Dämpfung auch hier nichts bringt. Gruß Holger
Also irgendwie will das nicht gelingen. Es scheint IC4b zu sein der schwingt, also wie vermutet der von Dir nur auf dem Papier erdachte LV Teil. Zumindest schwingt IC4 am Pin 7 munter weiter, selbst wenn ich den Regelkreis mit einem größeren Elko an Pin 1 stabilisiere (was ihn natürlich unglaublich träge macht). Jedoch, sobald ich versuche zwischen dem Spannungsteiler R10/R21 und Pin6 mit einem C abzublocken geht IC5 hops. Ich glaube ich geh jetzt den Weg des geringsten Widerstandes, lasse den Aufholverstärker IC4b weg und ändere einfach die Software entsprechend...
Moin, Schade das hier nicht mehr wirklich geschrieben wird. Bin zufällig auf das Projekt gestossen weil ich ebenfalls Modellbau betreibe und meinw Akkus testen möchte. Habe das Projekt jetzt mal nachgebaut und es funktioniert soweit. Was ich bisher testen konnte. Habe die Menüs noch etwas angepasst, sodass man von Entladen und Ri Messen auch wieder zurück zum Hauptmenp gelangt. Außerdem noch einen zusätzlichen Einstellungspunkt hinzugefügt wo man einstellen kann in welchen Schritten man den Strom und die Spannung ändern will. Das war mir wichtig, da ich Taster anstelle eines Drehencoders nutze und damit nicht so schnell die Schritte wählen kann. Außerdem musste ich den Messwiderstand auf 1 Ohm ändern weil ich nichts anderes da hatte. Könnte man mit dem Tester nicht auch versuchen Zellen bzw Akkus zu formieren?
Nächster Schritt wird noch sein, eine Entladekurve anzuzeigen. Wenn schon GLCD dann sollte man das auch nutzen :) Kann man eigentlich aus der bestehenden Hardware einen Akku Lader verwirklichen ?
Nabend, Ich hatte Probleme beim Entladen. Die Spannungsanzeige schwankte immer sehr stark. Jede Sekunde +-400 mV und mal mehr. Dadurch kam es, dass das Programm abgebrochen wurde beim Entladen weil anscheinend die Entladeschlussspannung erreicht war obwohl das nicht stimmte. Habe jetzt eine andere Methode eingebaut den ADC zu lesen und zu mitteln. Und jetzt funktioniert es. Die Anzeige schwingt nicht mehr und ist auch genauer jetzt. Desweiteren habe ich ein Entladeprogramm eingebaut welches mir eine Entladekurve auf dem Display anzeigt über Spannung und Kapazität. Gibt es hier eigentlich noch Interessierte? Man könnte das ganze Thema ja mal neu starten unter Projekte.
Roman schrieb: > Na, wie weit bist du mit deinem Projet? Glaube nicht, dass der TO dir das beantworten wird nach all den Jahren.
Angehängte Dateien:
-
20191130_212547.jpg
239 KB, 202 Downloads
Hab noch die Entladezeit (hh:mm:ss) hinzugefügt. Gerät funktioniert einwandfrei!
Hallo zusammen Es freut mich natürlich das mein Projekt auch heute noch nachgebaut und verbessert wird. Ich selber brauche ihn leider nicht mehr so oft, hier aber mein Senf zu ein paar der aufgekommenen Fragen: > Könnte man mit dem Tester nicht auch versuchen Zellen bzw Akkus zu > formieren? Genau dafür habe ich ihn unter anderem gebaut. Bei NiCd kann man damit den Memory-Effekt ein bisschen kurieren. Für Blei Akkus hatte ich mal einen Aktivator aus einem Elektor-Heft nachgebaut, der Erfolg war aber sehr bescheiden. > Kann man eigentlich aus der bestehenden Hardware einen Akku Lader > verwirklichen ? Theoretisch ja, ich habe mir damals beides selber gebaut. Man müsste noch einen zweiten Kanal mit FET und Drossel zur Glättung hinzufügen. Die Frage ist nur warum du das machen möchtest. Ich habe es damals nur gemacht um NiCd/NiMH Akkus mit Temperaturabschltung (+5°C über Umgebungstemperatur) abzuschalten. Das gab es damals nicht zu kaufen. Aber Blei Lader gibt es wie Sand am Meer und ein Lader für Lithium Akkus selber zu bauen davon würde ich startk abraten. > Gibt es hier eigentlich noch Interessierte? Man könnte das ganze Thema ja mal neu starten unter Projekte. Es gibt doch schon einen Artikelbeitrag Akku Tester, was ihr aber machen könntet sind eure Änderungen dort hinzuschreiben. Noch besser wäre natürlich den Code auf dem SVN einzuchecken, dafür müsstet ihr euch aber beim Admin melden. > Desweiteren habe ich ein Entladeprogramm eingebaut welches mir eine Entladekurve auf dem Display anzeigt über Spannung und Kapazität. Wow, das war warscheinlich eine menge Arbeit und klingt als Feature nicht schlecht. Ich habe mir damals die Arbeit nicht geamcht weil für mich das Speichern auf SD-Karte und auswerten mittels Octave einfacher war. Und mein Bildschirm hat deutlich mehr als 128x64 Pixel für die Darstellung verfügbar ;-) > Habe jetzt eine andere Methode eingebaut den ADC zu lesen und zu mitteln. Und jetzt funktioniert es. Die Anzeige schwingt nicht mehr und ist auch genauer jetzt. Kannst du beschreiben was das Prblem mit der aktuellen Routine war? War es die Messung oder die Mittelung? Ev. holft das anderen in Zukunft
Hallo Philipp, schön, dass du dich meldest! ;) Bezüglich Lademöglichkeit: Damit könnte man ein Programm einbauen welches zyklisch lädt und entlädt. Im Moment muss man dazu immer den Akku an ein Ladegerät hängen anstatt ihn an dem Akku Tester zu belassen. Ein formieren wäre dadurch einfacher. Aber okay, dafür bräuchte man dann natürlich auch einen 2. Kanal. Wenn das wäre es für mich eh nur für NiXX Akkus interessant. Zur Entladekurve: Eigentlich nur Spielerei. Genauere Werte bekommt man natürlich von der SD Karte. Habe mir ein Excel Diagramm erstellt wo man die Werte nur reinkopieren muss. Den Rest macht Excel. Die Kurve auf dem GLCD erstellen ist nicht das Problem. Größte Herausforderung ist es die Spannung und Kapazität so zu skalieren, dass sie immer aufs Display passt. Artikelseite: Ich meinte eigentlich den Thread in die "Projekte" Ecke verschieben. Dort sind ja alle "fertigen" Projekte und werden dort diskutiert. Zum ADC_Read(); Gute Frage, ich habe folgendes eingebaut:
unsigned int ADC_Read(void) { int i=512,j=512; long int analogwert=0, analogwert1=0, analogwert2=0 ; while(j){ while(i){ ADCSRA |= (1<<ADSC); //ADCSRA=0x80; // ADC eingeschaltet, kein Prescale //ADMUX=kanal; // ADC Ref auf Avcc, PC0 gewaehlt, normale Formatierung //ADCSRA |=_BV(ADSC); // single conversion mode ein while (ADCSRA & (1<<ADSC)) {;} // auf Abschluss der Konvertierung warten analogwert+=ADCW; i--; } analogwert1 = analogwert/512; analogwert2 += analogwert1; j--; } analogwert=(analogwert2/512); return (analogwert); } |
Dadurch schwingt meine Spannungsanzeige nicht mehr. Ich hatte echt Probleme damit. Die Entladekurve war eher eine Berg und Talfahrt. Jetzt ist alles stabil und auch die Messung ist viel genauer!! Außerdem habe ich nur noch die AVCC Referenz genommen anstatt die interne. Jetzt stimmt auch die Anzeige der Kalibrierung. Vorher: Soll 182/ Ist 92, Jetzt: Soll 182 / Ist 176 Was ich bislang geändert habe: - Piezo Buzzer für Tastentöne und Melodien bei beendeten Messvorgängen (Klingt schon geil wenn die Messung beendet wurde. Düdellüdüüü) - Änderung der Schrittweite für alle Eingaben (Gut wenn man Taster benutzt und schnell von 10mA auf 2000mA stellen möchte. - Entladezeit in hh:mm:ss wird angezeigt - Fehlermeldung wenn kein Akku angeschlossen wurde oder Akku von Gerät getrennt wird während einer Messung - Simulationsprogramm (Messung ohne Akku mit festen Werten, ohne DAC(), zum testen - Programm um den Akku real zu entladen, sprich mal mit 1A, mal mit 500mA, mal mit 4A, usw. wie in einem RC Modell eben. Da fährt man auch nicht 10 Minuten auf Vollgas. - Hauptmenü lässt sich jetzt aus allen Modi erreichen. Vorher war es so, dass man das Gerät aus und einschalten musste wenn man in den Entladeeinstellungen war. - und noch ein paar andere Kleinigkeiten Werde noch weitet an der Software feilen und ein paar Schmankerl einbauen. Schön wäre natürlich noch ein Kanal zum Laden. Dann könnte man richtige Refresh Programme schreiben. Ansonsten passt die Hardware aber.
:
Bearbeitet durch User
Hallo Max Wenn ich das richtig sehe, machst du aus 512*512 Werten einen Mittelwert, bei den 62 kHz Samplingfrequnz braucht das ja kanpp 4 Sekunden für eine Messung? Bist du sicher, dass nicht einfach etwas mit der Referenzspannung schief ist und diese schwingt? Kann z.B. sein wenn AREF nicht sauber mit einem Kondensator gepuffert ist, oder der ADC schlicht hinüber ist. Gruss Philipp
Hallo Philipp, ja du hast Recht. Ich hab nicht mehr daran gedacht, dass du ja den Prescaler auf 128 gesetzt hast. Habe die Werte jetzt runtergesetzt. Mein ADC ist ordnungsgemäß beschaltet, sogar mit Spule. Da ist also alles bestens. Ich denke mal es liegt im Allgemeinen an der Umschaltung zwischen interner Referenz und AVCC. Mir reicht aber AVCC als Referenz da ich mein Gerät eh nur mit Modellbauakkus füttere.
Hallo, melde mich auch mal wieder in dieser Sache, da ich damals mein Projekt wegen "Nichtgelingens" gestoppt und das ähnliche Projekt von Sprut gebaut hatte. Dieses funktioniert, ist aber softwaremäßig nicht so komfortabel wie die Philipp-Lösung. Mein Problem war die Prüfung von 1,2V NC-NM-Akkus, also die Niederspannungsvariante. Der Adapter war von mir einfach nicht "vernünftig" zum Laufen zu bringen und die Messungen, wie viel weiter oben beschrieben, nicht die richtigen Ergebnisse brachten. Nachdem ich die neuen Erkenntnisse gelesen habe, werde ich mich erneut auch mit meiner Variante beschäftigen. Doch zunächst die Frage nach dem Hardware-Adapter also dem Teil, das die Spannungs- und Stromaufbereitung macht. Verwendet Ihr den Niederspannungsadapter von Philipp (der ja selbst sagt, dass er ihn nie ausprobiert hat) oder gibt es eine andere Variante? mfG Frewer
:
Bearbeitet durch User
Hallo Werner, schön das auch du noch dabei bist nach all den Jahren :) Nein, ich habe mich gegen die LV Variante entschieden. Zum Einen, weil sie nicht getestet wurde von Philipp und zum anderen weil ich einen Kompromiss finden wollte bzw. musste. Mir geht es in erster Linie um Modellbauakkus, von daher fallen einzelne 1,2V Zellen bei mir schon mal raus. Würde es zusätzlich eine Ladefunktion geben, dann wäre die Geschichte mit den Einzelzellen vlt wieder interessant. So aber habe ich die Software optimiert um meine Akkus entweder auf Kapazität und Ri zu messen, sie realistisch zu entladen oder sie zu kontrolliert zu entladen mit variablen Entladestrom. Für die Kapazitätsmessung nutze ich 0,5C Entladerate. Für eine optimale Entladung ist mir aber wichtig, dass bei Unterschreitung der Entladeschlussspannung keine Abschaltung erfolgt sondern eine Pause und dann ein niedrigerer Entladestrom. Denn die Entladeschlussspannung die angezeigt wird ist die Klemmspannung. Also unter Last. Nimmt man den Strom zurück, steigt die Spannung wieder um gute 1-1,5 Volt. Könntest du nicht das Sprut Projekt mit Phillipp seinem kombinieren?
Ich habe gerade aber ein anderes Problem... Sobald ich einen Akku anhänge, sinkt die Temperatur um fast 10°C. Klemme ich den Akku ab stimmt die Temperatur wieder! Was könnte das denn jetzt sein??? Also bis gestern hat alles funktioniert.
Hallo Max Das deutet darauf hin, dass mit dem GND etwas nicht stimmt. Wichtig ist, dass R12, R21 und IC6 so direkt wie möglich an AGND vom AVR angeschlossen sind bzw. der Minus-Anschluss des Akkus muss möglichst weit weg sein. Wenn man alles auf eine Leitung hängt und darüber Strom fliesst, dann hat man "auf der GND Leitung" einen Spannungsabfall und somit hat alles was mit GND angeschrieben ist nicht mehr das gleiche Potential. Das resultiert dann in Messfehlern.
Mh... das ist komisch. Es hat nämlich alles so weit funktioniert bis jetzt. Dann werde ich nochmal über die Hardware schauen. Was meinst du mit IC6? Meinst du die OPAmps IC4 und IC5?
:
Bearbeitet durch User
Max B. schrieb: > Mh... das ist komisch. Es hat nämlich alles so weit funktioniert bis > jetzt. > > Dann werde ich nochmal über die Hardware schauen. > > Was meinst du mit IC6? > Meinst du die OPAmps IC4 und IC5? Nein, den Temperaturfühler weil du gesagt hast die Temperatur verreist.
Achso... Ja ich werde den was näher legen. Mein jetziges Gerät besteht aus mehreren Platinen. Da ist wohl fie Verbindung zwischen selbigen zu schlecht bzw. zu lang. Baue gerade ein zweites auf wo alles auf einer Platine ist. Ja aber wie gesagt, bis vorgestern hat alles funktioniert. Temperatur war einwandfrei. Und plötzlich bricht die Temperatur ein wenn ein Akku dranhängt. Berühre ich die Kabel von Sensor dann zeigt sie wieder die richtige Temperatur an. Habe aber nichts geändert an der Hardware.
Angehängte Dateien:
-
discharger.png
73 KB, 177 Downloads -
IRF540.pdf | anzeigen
11,5 KB, 68 Downloads
Werner F. schrieb: > Mein Problem war die Prüfung von 1,2V NC-NM-Akkus Ich betreibe einen IRF540 als Stromsenke und steuere diesen aus einen D/A-Wandler an, UGS ab etwa 3,5 Volt. Bis 0,8V herunter kann ich den Strom zuverlässig halten. Ich hätte den gerne stärker gegengekoppelt, aber dann wird das mit der Spannungsuntergrenze nichts mehr. Meine Regelung macht der µC, dass sie langsam ist, stört beim Test von Akkus nicht. Um den IRF540 bei höherer Spannung / höheren Strömen thermisch zu entlasten, schalte ich Widerstände parallel - meine Auslegung geht bis 14 Volt bei maximal 1,5A Laststrom. Ich hänge ein Schaltbild an: Das ist nicht vollständig, wurde erst erstellt, nachdem das Gerät samt diverser Schmierzettel fertig war. Von daher sind auch Fehler nicht ausgeschlossen, aber nicht beabsichtigt.
So... Temperatur ist wieder stabil. Werde morgen mal mit einem IR Thermometer gegenchecken. Hab heute einen NiMH Akku 7,2 Volt, 2200mAh getestet. Entladekurve machte zur Halbzeit einen Absturz um 1 Volt und hielt sich 2-3 Sekunden unter Entladeschlussspannung. Danach ging sie wieder hoch und Akku wurde normal entladen. Ergebnis: 2700 mAh wurden gemessen. Mh.... da stimmt doch was nicht! Ein anderer Akku mit 3500mAh hatte zum Schluss um die 2880mAh. Das kann ja hinkommen.
Was mir noch aufgefallen ist: Ri messen funktioniert irgendwie nicht so wie es soll! Angezeigt wird immer ein komplett falscher Strom. Bei der Akkuspannung wird ab und zu anstatt 7500 mVauch mal 10400 mV angezeigt. So und am Ende des Messvorgangs zeigt er mir einen mittleren Ri von sage und schreibe ca. 15000 mOhm an. Das kann ja nicht sein! Zum testen habe ich mal folgendes gemacht: Die ganze Routine rausgeschmissen und stattdessen die Leerlaufspannung gemessen und in eine Variable gespeichert. Dann den eingestellten max. Strom angelegt, 5 Sekunden gewartet und die Klemmspannung gemessen. Danach: ULeer-ULast / Strom Als Ergebnis kam etwas um die 130mOhm raus. So und das wiederrum kommt eher hin bei einem 6 Zeller NiMH als 150000. Ich blicke sowieso nicht ganz durch bei der Routine von dir Philipp. Du machst 20 Messungen, hast in der Schleife aber for(i=0;i<21;i++) stehen. Das sind dann doch 22 Durchläufe oder nicht? Da etwas nicht stimmen kann zeigen schon die Anzeigen. Wenn ich meinen Strom (1000mA) durch 20 teile dann sollte er mit 50mAh anfangen und sich auf die 1000 zubewegen. Macht er aber nicht. Es wird willkürlich ein Wert genommen. Und die Spannungsanzeige stimmt auch nur bei jeder 2. Messung/Durchlauf. BerndS kam bei seiner Einzelzelle auf 2140mOhm Innenwiderstand. So hatte er das damals geschrieben. Das kann nicht stimmen!
So... Das Hauptproblem ist, dass während der Ri Messungen immer wieder mal eine Spannung von 10000mV auftaucht. Das verfälscht natürlich das Ergebnis. Warum das aber passiert weiß ich nicht. Beim Entladen tritt das Problem nicht auf. Die Routine Read_Voltage() ist dieselbe. Was aber sein kann ist, dass er den Kalibrierungswert nochmals hinzu multipliziert. Rein rechnerisch würde das hinkommen. Aber das macht er wie gesagt nur bein Ri messen, nicht beim Entladeprogramm. Muss mir das nochmal anschauen. Wenn das Problem gefunden ist kann ich auch 20 Messungen machen ohne einen falschen Wert dazwischen. Dann nehme ich aber nicht den durchschnittlichen Ri sondern den niedrigsten Wert der bei den 20 Messungen rausgekommen ist.
Ich habe mir meinen alten Code noch einmal zu Gemüte geführt. Das mit den 21 stimmt schon, wenn du 20 mal ein Delta berechnen möchtest, dann brauchst du dafür insgesamt 21 Werte. Was ich heute anders machen würde ist, nicht mehr 5 Werte zu nehmen sondern einen Mittelwert aus 4 zu machen. Das gibt weniger Rauschen durch ungenaue Ganzzahldivision. Leider habe ich keine Konstante dafür gemacht und man muss einfach alle 5 durch 4 ersetzen:
// Messvorgang
// ***********
ks0108ClearScreen();
writeBarGraph(0, 5);
// Einstellungen speichern
SRAM_To_EEPROM();
// Teststrom für Testvorgang berechnen
Ri.currentStep = Ri.maxCurrent / 20;
for (i=0; i<21; i++) {
Ri.currentPoints[i] = Ri.currentStep * i;
}
// Die Messungen werden nur im letzten viertel
// des Messintervalls durchgeführt
Ri.startTime = (Ri.messintervall * 3000) / 4;
// Zeitspanne zwischen den Messungen
Ri.intervall = ((Ri.messintervall * 1000) - Ri.startTime) / 4;
// 20 Messpunkte aufnehmen
for (i=0; i<21; i++) {
// Entladestrom einstellen
DAC(Ri.currentPoints[i]);
// Zeit zurückstellen
Ri.msTick = 0;
// Warten bis 75% der Zeit verstrichen
while (Ri.msTick < Ri.startTime) {;}
// 4 Spannungen und Ströme einlesen
voltage = 0;
current = 0;
for (j=0; j<4; j++) {
voltage += Read_Voltage();
current += Read_Current();
Ri.msTick = 0;
while (Ri.msTick < Ri.intervall) {;}
}
// Spannung und Strom speichern
Ri.voltagePoints[i] = voltage / 4;
Ri.effectiveCurrentPoints[i] = current / 4;
// Fortschritt anzeigen
ks0108FillRect(0, 0, 127, 40, WHITE);
page = 1;
LCD_WriteInteger_Medium_Center(Ri.effectiveCurrentPoints[i], 0, 100);
CopyLang(buffer1, txt_mA);
column++;
LCD_WriteString_Medium(buffer1);
page = 3;
LCD_WriteInteger_Medium_Center(Ri.voltagePoints[i], 0, 100);
CopyLang(buffer1, txt_mV);
column++;
LCD_WriteString_Medium(buffer1);
writeBarGraph(100/20*i, 4);
}
|
Als zweites würde ich dann mal folgendes anpassen:
// Teststrom für Testvorgang berechnen
Ri.currentStep = Ri.maxCurrent / 20;
for (i=0; i<21; i++) {
Ri.currentPoints[i] = 150; //Ri.currentStep * i;
}
|
Damit hast du einen fixen Strom, den du einerseits mit dem Multimeter prüfen kannst, ob die Sollvorgabe stimmt. Andererseits kannst du am ADC-Eingang messen ob das Signal gut aussieht. Ich traue aber deiner ADC-Routine nicht ganz. Ich habe eine Mittelung nur aus 4 Werten gemacht, was ev. ein bisschen knapp sein könnte. Ich würde den ev. auf 16 erhöhen, aber wenn eine so starke Mittelung rechnerisch immer noch nicht reicht, dann muss man eher mit einem RC-Glied nachhelfen. Mehr Werte würde ich nicht mitteln. Nebenfrage: Hast du auch einen Mega32 mit 8 MHz internem Clock?
Hallo Philipp, Schande über mein Haupt. Die ADC Routine war es. Dachte ich hätte sie wieder geändert aber sie stand immer noch auf 512 Mittlungen. Okay... Kommando erstmal zurück. Voltage ist jetzt wieder korrekt.... aber: Habe jetzt einen Ri von 650mOhm. Das ist definitiv zuviel. Selbst mit allen Übergangswiderständen. Die Spannung schwankt auch zu sehr. Führe ich die Messung mit dem Multimeter durch, also Spannung Leerlauf und unter Last komme ich auf ca 90-120mOhm bei einem konstanten Strom. Ist es nicht besser mit einem konstanten Strom zu messen und bei 20 Messungen den niedrigsten Ri zu nehmen anstatt den durchschnittlichen? Was mir noch Sorgen macht ist halt die Stabilität der Spannung. Mit 4 Mittlungen ist sie schneller aber sie schwankt wie Hölle. Was könnte man da machen? Danke übrigens für deine Hilfe Ps: nutze einen Atmega644 mit ext. Quartz. Aber das läuft alles soweit gleich.
:
Bearbeitet durch User
> Ps: nutze einen Atmega644 mit ext. Quartz. Aber das läuft alles soweit > gleich. Wie schnell läuft dein Quarz? Und was hast du als Prescaler für den ADC eingestellt (ADCSRA)? Du hast geschrieben dass meine 128 viel zu hoch seien, aber der ADC darf ja nur zwischen 50 und 200kHz laufen, daher könnte man bei 8MHz maximal auf 64 runter gehen.
Philipp K. schrieb: > {;} wie sinnfrei ist das den und wo lernt man sowas? besser entweder nur ";" ODER "continue;" mt
Philipp K. schrieb: >> Ps: nutze einen Atmega644 mit ext. Quartz. Aber das läuft alles soweit >> gleich. > Wie schnell läuft dein Quarz? Und was hast du als Prescaler für den ADC > eingestellt (ADCSRA)? > Du hast geschrieben dass meine 128 viel zu hoch seien, aber der ADC darf > ja nur zwischen 50 und 200kHz laufen, daher könnte man bei 8MHz maximal > auf 64 runter gehen. Ich habe alle Einstellungen am ADC übernommen. Also auch den Prescaler. Ich sagte ja, es funktioniert ja soweit alles. Nur beim Ri messen halte ich als Ergebnis 650mOhm für etwas viel. Deswegen fragte ich ja: Müsste mab nicht 20 unabhängige Messungen machen mit einem konstanten Strom und davon nacher den niedrigsten Wert nehmen? Also: 1. Messung ULeerlauf speichern, Strom drauf, ULast speichern, Strom weg, Ri berechnen 2. Messung, ULeerlauf speichern, Strom an, etc etc.
Ich habe jetzt beide Arten der Ri Messung mit in das Menü genommen. Bei der die ich gemacht habe wird noch ein Log auf der SD Karte gespeichert mit den Daten wie ULeerlauf, ULast, Strom, Ri und Kurzschlussstrom. Also ich komme mit einer einfachen Messung eines alten 6 Zellen NiMH Akkus auf ca. 95-120 mOhm einschließlich Übergangswiderständen.
Denkanstoss zum Projekt... Max B. schrieb: > Log auf der SD Karte > gespeichert mit den Daten wie ULeerlauf, ULast, Strom, Ri und > Kurzschlussstrom. Logs sind nie verkehrt, allerdings würde ich eher nur die tatsächlich gemessenen Werte speichern, rechnen und interpretieren (zB Ri) kann man später mit einem Auswerteprogramm. > Also ich komme mit einer einfachen Messung eines alten 6 Zellen NiMH > Akkus auf ca. 95-120 mOhm einschließlich Übergangswiderständen. Alte Zellen und minimalwert...ohne temperaturangabe ein beeindruckender aber nichtssagender Wert. Frisch geladen, sofort heiss in Betrieb genommen wunderbar, doch wie sieht es zwei Stunden später, nach Abkühlung der Zellen, aus? ;oftmals zeigt sich genau erst dann der Schaden. MMn sussagekräftiger_er (vergleichbarer_er) Ri und leistungsfähigkeit gealterter Zellen: Bei gegebenem Laststrom in der Reihenfolge ULeerlauf, dann ULast: ULeer könnte bei der ersten Messung unbrauchbar (falsch) hoch sein (das solltest du in deinen vorhandenen Logs erkennen können). Besser (an der "kalten" Zelle) zur Interpretation des Ri erst die Last "einige Sekunden" (lang genug bis einigermassen stabil, kurz genug um ein durchwärmen zu vermeiden), dann ULast messen, dann sofort ULeer (oder Ulast50%) messen, daraus Ri berechnen. Auch denkbar: Erst Ulast50% "einige Sekunden", dann Ulast100% messen, daraus Ri berechnen. Den nächsten Durchgang (falls erwünscht) frühestens nach 10*"einige Sekunden" wiederholen. Wie du wohl selbst schon erfahren durftest, bei gealterten Zellen kommt (je nach Messverfahren und Timings und Temperatur) jedesmal ein anderer Überraschungswert heraus :D Ins Tagebuch der Akkus würde ich eher nicht deren Tagesbestwert, sondern eher den Schlechtswert vermerken, die Zahlen sollen ja nicht "schön", sondern belastbar (im wahrsten Sinne des Wortes) sein, selbst wenn dann mal (Kontaktprobleme) ausreisser und Messfehler drin sind. HTH
Danke für die Tipps. Soweit mache ich das ja auch :) 2 Cent schrieb: > Logs sind nie verkehrt, allerdings würde ich eher nur die tatsächlich > gemessenen Werte speichern, rechnen und interpretieren (zB Ri) kann man > später mit einem Auswerteprogramm. Das kann ich ja immer noch. auf die SD Karte kommen ja eh alle Werte. 2 Cent schrieb: > Alte Zellen und minimalwert...ohne temperaturangabe ein beeindruckender > aber nichtssagender Wert. Frisch geladen, sofort heiss in Betrieb > genommen wunderbar, doch wie sieht es zwei Stunden später, nach > Abkühlung der Zellen, aus? ;oftmals zeigt sich genau erst dann der > Schaden. > > MMn sussagekräftiger_er (vergleichbarer_er) Ri und leistungsfähigkeit > gealterter Zellen: > Bei gegebenem Laststrom in der Reihenfolge ULeerlauf, dann ULast: ULeer > könnte bei der ersten Messung unbrauchbar (falsch) hoch sein (das > solltest du in deinen vorhandenen Logs erkennen können). Besser (an der > "kalten" Zelle) zur Interpretation des Ri erst die Last "einige > Sekunden" (lang genug bis einigermassen stabil, kurz genug um ein > durchwärmen zu vermeiden), dann ULast messen, dann sofort ULeer (oder > Ulast50%) messen, daraus Ri berechnen. Auch denkbar: Erst Ulast50% > "einige Sekunden", dann Ulast100% messen, daraus Ri berechnen. Natürlich wird man nie den realen Ri messen können. Dazu gehört mehr als den Akku nur anzuklemmen. Aber es geht auch gar nicht darum Absolutwerte zu ermitteln sondern Vergleichswerte sammeln zu können. Und dafür sollte man natürlich auch immer gleich messen. Sprich, vollgeladener Akku, bei der und der Temperatur, gleiche Messkabel, etc. Alles andere würde ja keinen Sinn machen. Und so mache ich es ja zur Zeit: ULeer messen, konstanten Strom als Last, kurz warten, ULast messen.
Angehängte Dateien:
-
4814_1.jpg
158 KB, 103 Downloads
Hallo, könnte man so eine Schaltung wie im Anhang per zusätzlichen Transistor mit dem Akku Tester ansteuern um einen NIMH Akku mit einem konstanten Strom zu laden? Also ob man die Ausgänge dieser Schaltung an die Klemmen für den Akku der bestehenden Akku Tester Schaltung klemmen kann ohne das was passiert? Oder müsste man extra Klemmen nehmen? Weil, dann könnte man einen Akku entladen und auch mit einem konstanten Strom laden und gleichzeitig die Akkuspannung mit bestehender Schaltung messen. Geht das? Gruß Anton
Ich glaube nicht, weil hier Masse geschaltet wird. Der Akku Tester hängt an der Plusleitung vom Akku. Richtig? Aber man könnte doch einen LM317 nehmen als Konstantstromquelle und parallel zum Akkuanschluss schalten und diesen wiederrum der Atmega und 2 Transitoren schalten oder? Dann könnte man mit einem festen Strom den Akku laden und gleichzeitig die Spannung anzeigen lassen.
Hab mir jetzt ein 2. Untermenü gebastelt für die Ri Messungen. Dann kann ich wählen zwischen beiden Varianten. Außerdem einen LM317 hinzugefügt mit 3 verschiedenen, für mich relevanten, Konstantströmen die ich per Drehschalter wählen kann. Noch ein Menüpunkt, Formieren, eingefügt. Da wird der Akku erst entladen und dann mit 1/10 C aufgeladen. Ladezeit lässt sich einstellen. Soweir die Theorie. Jetzt noch testen...
Angehängte Dateien:
-
PNP_Stromquelle.jpg
358 KB, 104 Downloads
Die gezeigte Schaltung von Akkulader lässt sich auch ganz einfach in eine PNP Schaltung umbauen die dann Lasten gegen GND unterstützt (siehe Anhang)
Danke Philipp, Ich teste es erstmal mit meinem LM317. Ist zwar blöd, dass ich die Widerstände für den LM317 fest einstellen muss aber egal. Für das Formieren gebe ich den entsprechenden Ladestrom ein der durch meine Widerstände erzeugt wird und die Kapazität des Akkus. Das Programm errechnet mir dann die ungefähre Ladezeit. Man kann sie trotzdem noch ändern wenn man das möchte. Dann wird der Akku bis zur Entladeschlussspannung entladen und dann mit 1/10 C geladen für die errechnete Zeit. So um die 13-14 Stunden. Bin mal gespannt ob es funktioniert.
Angehängte Dateien:
-
20191216_105956_1_.jpg
199 KB, 133 Downloads -
20191216_110025_1_.jpg
222 KB, 137 Downloads
Anbei mal 2 Fotos vom Innenleben (Lastwiderstand und Transistor fehlen noch) und von dem aktuellen Menü "Formieren". Ich habe auch die Fußzeile geändert und als weiteren Punkt "speichern" hinzugefügt. Jetzt kann ich die geänderten Werte manuell in das EEPROM speichern und nicht mehr automatisch. Da das mein 2. Gerät ist was ich aufbaue, habe ich hier jetzt auch einen Drehencoder benutzt für die Eingaben. Deutlich besser als mit Tastern!! Tastentöne lassen sich ein- oder ausschalten. Nach jedem Laden, Entladen, Formieren, RiMessen ertönt eine Melodie. Bei Übertemperatur, Abziehen des Akkus, etc. ertönt ein Alarmsignal. Im Hauptmenü gibt es jetzt noch den Eintrag "Rechner". Da habe ich zur Zeit den Ladezeitrechner eingebaut. Die dort eingegebenen Werte und Ergebnisse werden automatisch unter "Formieren" übernommen!
Moin, Also mein formieren scheint tatsächlich zu funktionieren. Sobald beim Entladen die Schlussspannung erreicht wird schaltet das Gerät um auf laden. Sehr geil! Heute noch einen kurzen Selbsttest integriert welchen man abrufen kann unter Einstellungen. Warte jetzt noch auf meinen SD Kartenslot dann dokumentiere ich mal alles falls hier noch Interesse besteht.
Max B. schrieb: > Moin, > > Also mein formieren scheint tatsächlich zu funktionieren. > Sobald beim Entladen die Schlussspannung erreicht wird schaltet das > Gerät um auf laden. Sehr geil! > > Heute noch einen kurzen Selbsttest integriert welchen man abrufen kann > unter Einstellungen. > > Warte jetzt noch auf meinen SD Kartenslot dann dokumentiere ich mal > alles falls hier noch Interesse besteht. Natürlich 👍🏼
Angehängte Dateien:
-
20191219_135522.jpg
232 KB, 117 Downloads -
20191219_135535.jpg
229 KB, 107 Downloads
So, ich habe mal was vorbereitet... Vorweg: Ich bin noch lange nicht fertig!! Also, was gibt es Neues? ATMEGA644 ist nun die Ausgangsbasis!! - Kalibrierung von Spannung, Temperatur und Strom (Strom noch nicht implementiert). Zur Temperaturkalibrierung am Besten ein Thermometer neben den LM335 am Kühlkörper halten, Wert einstellen und speichern. Bei der Kal. wird die Temperatur in mV angezeigt um genauer einstellen zu können. - Temperatur wird nun mit einer zusätzlichen Dezimalstelle angezeigt - Neues Menü: Werkzeuge. Dort gibt es einen Monitor für Spannungs- und Temp. Anzeige sowie den Ladezeitrechner und den... - Selbsttest: Gerät testet die Ladespannung, Ladestrom, Lüfterfunktion und Temperatur. Anschließend wird das Ergebnis angezeigt und die gemessene Ladespannung. Bei einer Fehleranzeige kann das Problem entsprechend eingekreist werden (OpAmps, LM317, PWM, etc.) - Formieren. Akku wird entladen und danach mit dem eingestellten Strom geladen (14 Stunden, einstellbar). Das Ganze habe ich bislang NUR für NiMH Akkus getestet woebi die Funktion noch nicht ganz fertig ist. Es fehlt die Abschaltung nach der eingestellten Ladezeit. Also mit Vorsicht genießen diese Funktion. Desweiteren lässt sich der Strom nur hart per Drehschalter und entsprechenden Widerständen einstellen. - 2 Ri Mess-Menüs. Die langsame und die schnelle Mess-Variante. - Töne. Tastentöne lassen sich ein und ausschalten. Für jeden Fehler oder Fertigmeldung beim Laden, Entladen, Messen ertönt eine Melodie Anbei ist der Quellcode sowie ein PDF mit der aktuellen Menüstruktur und ein PDF mit der Änderung am Controller. Dort ist jetzt noch die Ladeschaltung sowie der Piezo Buzzer hinzugekommen. Der Quellcode ist noch nicht wirklich gut strukturiert oder aufgeräumt und es gibt bestimmt den Ein oder Anderen der manches anders programmiert hätte.
Und weiter geht's: 2. Temperatureingang für Akkuüberwachung realisiert. Außerdem 2 Leuchtdioden die mir Lade und Entladestatus anzeigen. Selbsttest wurde nochmal überarbeitet. Dank der Formierungsfunktion habe ich es geschafft einen alten NiCd Akku zu reanimieren. Das Einzige was mich etwas stört, ich komme nicht auf den maximalen Entladestrom von 5A. Bei 3,3 Ampere ist Schluss. Weiß nicht warum?!
:
Bearbeitet durch User
Angehängte Dateien:
-
Lastverteilung.png
4,47 KB, 87 Downloads
Max B. schrieb: > Das Einzige was mich etwas stört, ich komme nicht auf den maximalen > Entladestrom von 5A. > Bei 3,3 Ampere ist Schluss. > Weiß nicht warum?! Möglicherweise reicht Ugs einfach nicht aus --> dann eine mögliche Lösung siehe Bild.
2 Cent schrieb: > Max B. schrieb: >> Das Einzige was mich etwas stört, ich komme nicht auf den maximalen >> Entladestrom von 5A. >> Bei 3,3 Ampere ist Schluss. >> Weiß nicht warum?! > Möglicherweise reicht Ugs einfach nicht aus --> dann eine mögliche > Lösung siehe Bild. Danke! Mhhh... Also eigentlich so wie Philipp es in seiner letzten Hardwareversion gemacht hat? Sprich 2 TIP142 verbauen? Das wäre eine Lösung. Aber da macht mir der fehlende Platz am Kühlkörper ein Strich durch die Rechnung :(
Max B. schrieb: > fehlende Platz am Kühlkörper ein Strich durch die Rechnung Bei Lastverteilung brauchen zwei kleinere KK insgesamt weniger Platz als ein grosser. Theoretisch. Praktisch willst du wohl im Moment mit dem auskommen was du bereits verbaut hast. > Also eigentlich so wie Philipp es in seiner letzten Hardwareversion > gemacht hat? Sprich 2 TIP142 verbauen? Ohhh. Bin auf der Schaltbildsuche (rückwärts) vom ersten Bild im Faden ausgegangen https://www.mikrocontroller.net/attachment/437471/discharger.png wahr wohl verkehrt. Wo finde ich denn das aktuelle SB? Beim TIP142 (Bipolartransistor anstelle Mosfet) erwarte ich eher keine Probleme wegen nicht erreichbarer Basisspannung, eher zu kleinem Basisstrom.
Gefunden :-) Ausgehend von https://www.mikrocontroller.net/articles/Datei:Power_V1.1.png TLC272 kann 30mA (laut Dabla) liefern. TIP142 hat bei Ic von 5A ein hfe von mindestens 1000, also liegt das Problem eher nicht daran. Emitterwiderstand 1R8, bei 5A also 9V am Emitter des TIP142. Grob geschätzt also 10,2V an der Basis notwendig. Ist deine Versorgungsspannung TLC272 hoch genug? Laut https://www.mikrocontroller.net/articles/Akku_Tester brauchst du 12V, mal nachgemessen direkt am OP?
Jepp... Sind knapp 11,4 Volt direkt am OP. Deswegen wundert mich das. Bei voller PWM werden nur 3,3 A angezeigt. Und ich messe sie auch. Der aktuelle Schaltplan liegt nicht im Artikel sondern in den SVN Ordnern. Link im Artikel ganz unten. Da werden 2 TIP142 benutzt. Naja wie auch immer. Die Spannungsversorgung stimmt. Ich werde morgen aber nochmal was testen und nochmal messen. Denke mal die Spannung bricht irgendwo ein.
Jaja, Spannungabfälle können bei 5A schon richtig eklig werden. Soweit ich dein Problem jetzt verstanden habe ist deine "aktuelle" Version mit nur einem TIP142 aufgebaut, die offiziell aktuelle Version mit 2*TIP142 (für dein Problem irrelevant) bräuchte sogar noch 0,25V mehr. LOL, dein uC rennt aber schon mit 5V (volle PWM), oder mit 3V3? Ich mein ja nur, wegen 3,3A anstelle 5A ROFL
2 Cent schrieb: > LOL, dein uC rennt aber schon mit 5V (volle PWM), oder mit 3V3? > Ich mein ja nur, wegen 3,3A anstelle 5A ROFL Ich betreibe meinen Atmega morgen mal mit 10 Volt. Dann müsste ich meine 5 A ja bekommen und hätte 5 A noch übrig für andere Sachen :))))) Ja keine Ahnung... leider hat hier noch niemand getestet wieviel max. A wirklich beim Entladen möglich sind. Außer Philipp.
Max B. schrieb: > Ich betreibe meinen Atmega morgen mal mit 10 Volt. Dann müsste ich meine > 5 A ja bekommen und hätte 5 A noch übrig für andere Sachen :))))) Geniale Idee, mit den übrigen 5A könnte man die Schaltung selbstversorgend machen, die Lösung aller weltweiten Energieprobleme, lass dir das baldmöglichst patentieren :D Genug gefrotzelt, ich bin gezwungen jetzt StarTrek zu guggen, Wiederstand ist zwecklos, die DVDs sind geborgt... Viel Erfolg beim debugging morgen!
Das wäre genial! Dann bräuchte ich kein Netzteil mehr. Lol Ja viel Spaß beim StaR Trek Abend! Friede und langes Leben ;) Debugging gerade flott durchgeführt. Spannung ist und bleibt 11,4 Volt am OP. Keine Ahnung wo die fehlenden A hin sind. Phiiiiiilliiiiipp??
Max B. schrieb: > Das Einzige was mich etwas stört, ich komme nicht auf den maximalen > Entladestrom von 5A. > Bei 3,3 Ampere ist Schluss. Du brauchst mehr Spannung am Gate oder eine andere Lösung. Man sollte auch die Verlustleistung am FET beachten. Ich habe 03.12.2019 meine Lösung dargestellt, die für Deine Anwendung natürlich anders dimensioniert werden muß: Ich habe zwei niederohmige LL-FETs samt Leistungswiderstand eingesetzt, der IRF540 im Analogbetrieb übernimmt nur noch die Feinregelung bzw. wenig Leistung. Wann welcher Widerstand zugeschaltet wird, kann der µC rechnen.
Jetzt haben meine Augen jeweils die Form eines Kubus :D @Max: dir auch die Hand "I_II_II" Manfred schrieb: > Du brauchst mehr Spannung am Gate Das dachte ich (das war afair dein Schaltbild) bis vor wenigen Sekunden (bei Warp-8) auch, Max (be-)nutzt aber offensichtlich die Version mit einem Darlington TIP142, wie wohl im Treadstart verlinkt https://www.mikrocontroller.net/articles/Datei:Power_V1.1.png Erstmal regenerieren, dann bereit um fremde Welten zu erforschen :D
Nachtrag Sternzeit 80m15s, kann jetzt nicht regenerieren Youtube-Video "RAMMSTEIN live @ Luzhniki stadium, Moscow, Russia, 29.07.2019 MULTICAM BY RADLIGHT" wartend auf das Licht :-)
Moin zusammen... Also an der Basis vom TIP messe ich eine Spannung von 7,5 Volt sobald der Entladestrom fließt. Mhh... Edit: Ahhh... Moment. Ich glaube ich hab den falschen Kondi am Ausgang des OP sitzen. Ich Depp...
:
Bearbeitet durch User
Hat trotzdem nicht geholfen. Spannung an der Basis bleibt bei 7,5 Volt. Max. Entladestrom bei ca. 3,4 Ampere. Verstehe das nicht :( Sind alles noch so kleine Baustellen. Auch die Temperaturanzeige. Da bricht die Spannung um ca. 30-40mV ein sobald ich einen Akku anschließe. Aber auch nur in der Monitoranzeige, nicht etwa in der Entladeanzeige. Grummel...
:
Bearbeitet durch User
Also ich rechne mal nach: 3.4A * 1.8 Ohm = 6.12V 7.5V - 6.12V = 1.38V Soweit ist alles korrekt, denn der TIP 142 ist ein Darlington Transistor mit 2x 0.7V Basis-Emitter Spannung. Die V_CEsat ist etwa 2V bei 5A. Der TLC272 hat auch noch mal etwa 2V Spannungsabfall. Wenn du 5A Entladestrom haben möchtest, müssen folgende 2 Bedingungen erfüllt sein: Minimale Batteriespannung: I_L * R + V_CEsat = 5A * 1.8Ohm + 2V = 11V Minimale Speisespannung: I_L * R + V_BE + V_OP = 5A *1.8Ohm + 1.4V + 2V = 12.4V Die 12V Speisespannung die ich verwendet haben sind also sehr knapp. Wahrscheinlich ist der OP Besser als im Datenblatt angegeben und hat weniger als 2V abfall. Welche Batteriespannung hast du versucht?
Hallo Philipp, Danke für's rechnen... Ich habe einmal 12V und sogar mal 15V getestet. Es bleibt beim selben Ergebnis. Achso nochwas. Klemme ich einen Akku an fällt die Temperatur um 3-5 Grad Celsius. Problem ist die Basis vom Transistor. Klemme ich die nämlich nicht an, bricht die Spannung auch nicht ein und die Temperatur stimmt. Kabel von der Basis zum OP ist jetzt nicht wirklich lang.
Hallo Max Also wenn die Spannung an der Basis 7.5V ist, was sind denn die Spannungen an den Operationsverstärkern? IC5 1,2,3 und IC4 Pin 1 wären interessant, um zu sehen was diese machen. Welche Spannung hat denn dein Akku?
Also... Entladestrom eingestellt: 5000 Entladestrom angezeigt: 3300 IC5, Pin1: 10,35V IC5, Pin2: 2,94V IC5, Pin3: 4,47V IC4, Pin1: Wie Basis eben 7,5V Akku ist ein 6 zelliger NiMH mit eben 7,2V und 3500mAh (Ist aber egal welchen Akku ich nehme) Aber wie gesagt, selbst mit der Temperatur stimmt was nicht sobald die Basis angeschlossen ist. Verstehe das nicht
:
Bearbeitet durch User
Achso..... Ja warte mal, stimmt. Die Spannung vom Akku ist ja auch noch wichtig! Naja ich befinde mich halt im normalen RC Modellbau-Bereich mit 6 Zellen. Okay, was wäre denn, wenn ich den Lastwiderstand von 1,8 Ohm auf 1 Ohm änder. Dann dürfte das doch hinhauen mit den 5 Ampere oder? Eventuell löst das ja auch das Temperaturproblem? Edit: Ja ich glaube es liegt daran. Bei meinem 1. Gerät war ja noch ein 1 Ohm verbaut. 1,8 Ohm ist vermutlich eher was für Akkus > 12V
:
Bearbeitet durch User
2 Cent schrieb: > Max (be-)nutzt aber offensichtlich die Version mit > einem Darlington TIP142, wie wohl im Treadstart verlinkt Ja Mist, hätte er besser mal den Stromlauf direkt in den Thread kopiert. Das wird so nichts: Philipp K. schrieb: > Also ich rechne mal nach: Philipp hat vorgerechnet, warum. Mit der nachgeschobenen Info, dass das Testobjekt 6 NiCd sind, schon garnicht mehr - der hat Entladeschluß bei 5,1..4,8 Volt. Der TIP hat laut Datenblatt bis zu 2V UCE, an der Längsdiode verschwinden geschätzt 0,6 Volt, damit sind maximal 0,47 Ohm im Emitter möglich. Damit wird auch klar, weshalb ich einen FET eingesetzt und keine Längsdiode habe, ich kann eine NiXx-Einzelzelle messen. Max B. schrieb: > Okay, was wäre denn, wenn ich den Lastwiderstand > von 1,8 Ohm auf 1 Ohm änder. Der 'Lastwiderstand' erfüllt zwei Aufgaben, Gegenkopplung und Stromfühler (Shunt). Sowas musste ich in der Berufsschule rechnen, genau das fehlt Dir leider. Ich empfehle, den OP abzuklemmen, ein Drehpoti zwischen 12V und GND samt Schutzwiderstand an die Basis des TIP142 zu klemmen, um erst einmal die Leistungsstufe zu verstehen.
Manfred schrieb: > Ja Mist, hätte er besser mal den Stromlauf direkt in den Thread kopiert. Warum? Der "Stromlauf" ist der, der im Artikel zu finden ist. Der hat sich nicht geändert. Und danach wurde aufgebaut. Nunja, wenn ich lese: bis zu 40V Akku, bis zu 5A Entladestrom dann gehe ich davon aus, dass das so passt. Wenn natürlich die Temperatur schon einbricht weil mein angeschlossener Akku nur 7,2V hat und das zu wenig ist, es aber beim 1 Ohm Widerstand funktioniert hat dann wechsle ich natürlich wieder. Ein anderer aus dem Thread hatte ebenfalls 1 Ohm wegen kleinerer Spannungen.
Max B. schrieb: > Nunja, wenn ich lese: bis zu 40V Akku, bis zu 5A Entladestrom dann gehe > ich davon aus, dass das so passt. Versuche bitte, die Rechnung von Philip nachzuvollziehen: Beitrag "Projet um die Kapazität von Akkus zu messen" und auch, das ohmsche Gesetz zu bemühen: U=IxR WENN 5A fließen, erzeugen die am Emitterwiderstand 9 Volt, wenn dieser 1,8 Ohm hat. Der Darlingtontransistor benötigt 1,4V UBE, also müssten 10,4 V an die Basis, um den aufzusteuern. Das hilft aber nicht, da Du keine 9 Volt hast und das auch nicht alles ist. ----- Jetzt bringen wir den Emitterwiderstand auf 1 Ohm, das wären bei 5 Ampere 5 Volt, plus UBE brauchen wir 6,4 Volt an der Basis. Der TIP142 hat eine Restspannung Kollektor-Emitter bis zu 2 Volt, also müssten am Kollektor schon 5 + 2 = 7 Volt anstehen, damit der Strom fließen kann. Reicht aber noch immer nicht, weil in Reihe zum Kollektor noch eine Diode ist, die schätze ich auf 0,6 Volt. Also: Sebst wenn der Transistor komplett offen ist, sind mindestens 7,6 Volt vom Akku nötig, die gewünschten 5 Ampere fließen zu lassen! Jetzt rechne die Kette mit 0,47 Ohm im Emitter, da kommt man der Sache schon näher - aber nur, solange der Akku halbwegs voll ist.
Danke Manfred, das habe ich verstanden. Okay Also sind die 5A nur möglich wenn ich einen größeren Akku habe. Mir ist das ja auch aufgefallen wenn dee Akku >8 V war, gab es keine Probleme mit den Spannungen. Nun gut, das ist jetzt nicht wirklich so schlimm. Dann bleibe ich bei meinen 3,3 A Entladestrom. Nur wie gesagt hängt das auch irgendwie mit dem ADC zusammen. Die Temperatur beträgt, sagen wir mal 20°C. Klemme ich nun meinen Akku an, fällt die Spannung am ADC und die Temperatur zeigt nun 15°C an. Bei meinem 1. Gerät mit 1 Ohm passierte das nicht. Oder wenn ich die Basis vom Transistor abklemme ebenfalls nicht. Ich hätte nicht gedacht, dass es so einen Unterschied macht ob der Akku jetzt 6 Volt oder 8 Volt hat. Bei einer Einzelzelle kann ich das noch verstehen. Da gabs ja bei einigen Probleme hier. Grummel... Ok also verzichte ich auf die 5 A Entladestrom und schaue das ich den Rest stabil bekomme. Dann eben mit 1 Ohm. Achso: theoretisch könnte ich ja auch noch die Diode gegen Verpolung am Kollektor entfernen um noch was rauszuholen.
:
Bearbeitet durch User
Mh... Spannung bricht trotzdem ein. Temperaturwert fällt. Bin ratlos.
Max B. schrieb: > Wenn natürlich die Temperatur schon einbricht weil mein angeschlossener > Akku nur 7,2V hat und das zu wenig ist Fehler in der T-Messung und nichterreichen der 5A Entladestrom sind zwei völlig verschiedene Probleme! Max B. schrieb: > Nur wie gesagt hängt das auch irgendwie mit dem ADC zusammen. Die > Temperatur beträgt, sagen wir mal 20°C. Klemme ich nun meinen Akku an, > fällt die Spannung am ADC und die Temperatur zeigt nun 15°C an. Klingt nach Spannungsabfall auf der nichtidealen GND-Leitung > Bei meinem 1. Gerät mit 1 Ohm passierte das nicht. Dann hattest du dort entweder viel niederohmigere GND-Leitungen, oder ein besseres Layout (Leitungsführung deiner GND-Leitungen). > Oder wenn ich die Basis vom Transistor abklemme ebenfalls nicht. Dann hast du einen Entladestrom von 0A, in Folge auch keinen Spanungsabfall auf "dünnen" Leitungen, und deswegen keine Verfälschung der Temperaturmessung. Miss bei maximalem Entladestrom (auch wenns gerade nur etwa 3A sind) doch mal den Spannungsabfall auf deinen GND-Leitungen (GND am Controller, GND am LM335, GND am 1R8...) gegeneinander, dann solltest du die Ursache der Temparaturfalschmessung nachvollziehen können.
Ich glaube ich habe das Übel gefunden. Getrost nach dem Motto: Funktionalität geht vor Design! Sieht schon schön aus, wenn alle dicken Kabel gebündelt auf eine Klemmleiste geführt werden. Ich muss mich aber an die Layoutvorgaben von Philipp halten. So kurz wie möglich, so nah am Akku wie möglich! Habe jetzt den Transistor mal fliegend neu verdrahtet und siehe da, Temperatur bleibt stabil. Werde also den Leistungsteil nochmal neu verdrahten. Auch wenn es dann nicht mehr so schön aussieht und servicefreundlich ist :( Hab die Diode am Kollektor jetzt auch mal rausgeworfen. Gefällt mir aber auch nicht so ganz. Denn jetzt zeigt er mir auch ohne Akku eine Spannung von ca. 400mV an. Naja, immerhin scheint es jetzt zu funktionieren.
:
Bearbeitet durch User
Max B. schrieb: > Also sind die 5A nur möglich wenn ich einen größeren Akku habe. > Mir ist das ja auch aufgefallen wenn dee Akku >8 V war, gab es keine > Probleme mit den Spannungen. Aber nicht mit 1,8 Ohm, sondern mit 1 Ohm. Gibt es einen Grund, den nicht noch weiter zu verringern? Auch, wenn ich mich wiederhole: Beachte den Spannungsbereich Deiner Akkus. Ein NiXx-Zelle kommt frisch aus dem Ladegerät mit 1,4 Volt, das Entladeende liegt aber bei 0,9..0,8 Volt. Wenn Du unterhalb 8 Volt keinen stabilen Strom mehr einhalten kannst, sind nur Akkupakete mit mindestens 10 Zellen messbar. > Achso: theoretisch könnte ich ja auch noch die Diode gegen Verpolung am > Kollektor entfernen um noch was rauszuholen. Und bei Verpolung brennt dann der Endtransistor durch! Ich wähle eine zerstörende Lösung mit erzieherischer Wirkung, siehst Du in meiner Schaltung: Eine dicke Schottkydiode antiparallel zum Akku und in Reihe eine Sicherung. Bei einer Verpolung brennt die Sicherung durch, im Normalbetrieb wird der Spannungsverlust an der Sicherung irgendwo um 100 mV liegen.
Hallo Manfred, Das ist mir schon klar mit der Verpolung. Solange das Gerät aber kein Dritter bekommt halte ich eine Verpolung für ausgeschlossen. Zumal ich Tamiya Stecker dran habe. Also eine fahrlässige Verpolung ist nicht möglich. Werde die Diode aber trotzdem wiedee mit reinnehmen. Nein, gegen einen geringeren Widerstand spricht eigentlich nichts. Außer, dass ich keinen anderen da habe in der Leistungsgröße. Entladen mit max. 3 A ist also möglich bis runter auf 6000 mV. Das sollte passen. Bzw. es passt. Selbst wenn ich ab 7 V nur noch mit 2 A entlade reicht mir das.
:
Bearbeitet durch User
Was auf jeden Fall klappt, und da bin ich stolz drauf, ist, dass ich einen totgeglaubten 6 zelligen NiCd wiederbeleben konnte. Es ist zwar jetzt ein auf meine Bedürfnisse angepasstest Lade-/Entladegerät und kein Universalgerät mehr aber okay... Eine simple Ladeschaltung mit einem LM317 ist zwar kein Hexenwerk aber die Kombination von beiden ist schon echt cool.
Max B. schrieb: > Entladen mit max. 3 A ist also möglich bis runter auf 6000 mV Dazu fällt mir noch etwas ein: Entladen bitte auch nur maximal 6 NiMH Zellen wegen Umpolungsgefahr, siehe Kapitel 4 von https://www.mikrocontroller.net/attachment/34643/Tiefentladung.pdf Mach dir deine Akkus nicht mit Gewalt kaputt.
Max B. schrieb: > Was auf jeden Fall klappt, und da bin ich stolz drauf, ist, dass ich > einen totgeglaubten 6 zelligen NiCd wiederbeleben konnte. Glückwunsch! Sowas edles kann man heute ja nicht mehr kaufen.
2 Cent schrieb: > Max B. schrieb: >> Was auf jeden Fall klappt, und da bin ich stolz drauf, ist, dass ich >> einen totgeglaubten 6 zelligen NiCd wiederbeleben konnte. > Glückwunsch! Sowas edles kann man heute ja nicht mehr kaufen. Na es geht doch nicht um's kaufen. Wenn es danach gehen würde dann wären hier im Forum ca. 740 Threads gar nicht nötig gewesen zu veröffentlichen. Man kann alles kaufen. :) Selbst Taschenrechner, Transistorentester, Netzteile, etc. Und nein, ich entlade die NiMH natürlich nicht tief.
Thread beobachten
Seitenaufteilung abschalten
