|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
>Klaubunde
Könntest Du das BITTE mal korrigieren :(
Das erste 'u' gehört da nicht hin.
|
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
Angehängte Dateien:
-
Sallen-Key-Filter.png
1,22 KB, 1696 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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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?
|
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
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?
|
Datum:
|
Das Projekt ist doch in der Rubrik "Wettbewerb". Sind da auch Gemeinschaftsprojekte vorgesehen?
|
Datum:
|
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...
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
> 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!
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
@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
|
Datum:
|
Angehängte Dateien:
-
Spannungsverstaerkung.png
7,83 KB, 2149 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.
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
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?
|
Datum:
|
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-Zustandsautoma... Hoffe das ich es erstmal einfach nachbauen kann. Fragen tauchen erst bei wirklich auftretenden Problemen auf. Bernd_Stein
|
Datum:
|
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
|
Datum:
|
lad dir den tarball (unten links, wenn du auf den link zum svn rep. klickst) 7 zip kann das entpacken. MfG
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
@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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
@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.
|
Datum:
|
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...
|
Datum:
|
|
Datum:
|
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... Bernd_Stein
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
@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.
|
Datum:
|
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
|
Datum:
|
Angehängte Dateien:
-
Webbild_Akkutester_005.jpg
745 KB, 1849 Downloads -
GLCD-TG12864B-05_128x64_Pixel.PDF | anzeigen
110 KB, 391 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
|
Datum:
|
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
|
Datum:
|
Angehängte Dateien:
-
Akku_Tester.pdf | anzeigen
104 KB, 273 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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
> > 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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
Angehängte Dateien:
-
Akku_Tester.pdf | anzeigen
104 KB, 245 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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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-Zustandsautoma... Bernd_Stein
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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 ;-)
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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 ;-)
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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
|
Datum:
|
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?
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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?
|
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
Hallo Philipp, okay, danke für Dein Feedback. Dann werde ich das mal in Angriff nehmen. Beste Grüße Holger
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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
|
Datum:
|
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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
Angehängte Dateien:
-
Newfile1.jpg
87,1 KB, 87 Downloads -
Newfile2.jpg
90,2 KB, 95 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
|
Autor:
Philipp Kälin
(philippk)
Datum:
|
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.
|
Datum:
|
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
|
Datum:
|
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...
Thread beobachten
Seitenaufteilung abschalten