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