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
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
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:
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:
Angehängte Dateien:-
Webbild_Akkutester_005.jpg
744,9 KB, 362 Downloads -
GLCD-TG12864B-05_128x64_Pixel.PDF | anzeigen
110 KB, 82 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
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
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
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:
Angehängte Dateien: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
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten