www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Projet um die Kapazität von Akkus zu messen


Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger klabunde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Klaubunde

Könntest Du das BITTE mal korrigieren :(
Das erste 'u' gehört da nicht hin.

Autor: Frank B. (frankman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (m8nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

den Apparat aus modernster Hochtechnik* habe ich mir gestern/vorgestern 
schonmal angekukkt, sowas suche ich noch, sowas universelles eben. Es 
reicht mir vollkommen aus, wenn ich die Akkus mit verschiedenen Strömen 
entladen kann, also nen 14Ah Akku z.b. mit 200mA oder auch mit 3A. Noch 
cooler wäre, wenn mehr als ein Akku gleichzeitig gehen würde. Anhand der 
Meßwerte kann ich ja selber entscheiden, ob ich die Akkus weiter benutze 
oder weg damit. Außerdem weiß ich dann auch, welcher Akku unter Last bei 
einem 4er Pack z.B. als erster abschlafft. Von der Rechenleistung 
schafft der Prozessor das, aber wie es mit dem Handling dann 
aussieht......

Der Tiefpaß zur Generierung einer Gleichspannung aus einer PWM läßt sich 
sehr gut mit einem Sallen-Key-Filter machen, besser als mit einem 
einfachen RC-Tiefpaß. Siehe Anhang & Wikipedia, auch zur Berechnung.
Die Formeln bzw. Rechenschritte dazu:
1) Cutoff-Freq. festlegen, z.B.
f_o = 10kHz wegen Störungen bei 50 kHz
f_Sig < 5 kHz (input)
2) C2 = 10 pf .... 100 nF
3) C1 = 2x C2
4) R1 = R2 = 1/(2*pi*f_o*C1*sqrt(2))

Wie das jetzt genau zusammenhängt mit C2 von 10 pF bis 100 nF weis ich 
auch nicht mehr, habe hier nur meine Notizen abgeschrieben. Aber ich 
denke mit Filter ist schon vorteilhafter.

Dann wäre noch super, wenn man zur Log-Datei einstellen könnte, ob mit 
Semikolon die Werte getrennt sind oder mit Tabulator. Mit Tabulator hat 
den Vorteil, daß man die Datei direkt ankukken kann und die Meßwerte 
spaltenweise passend übereinander stehen. Außerdem kann man die Daten 
dann mit gnuplot sich ausgeben lassen, auch wenn es mehr als 16000 
Zeilen an Daten sind. Office-Proggis machen da schlapp. Und 
Office-Proggis können auch mit Tabulator getrennte Datenfelder 
importieren.

Dann wäre vllt. noch vorteilhaft, den Akku wahlweise mit einem 
konstanten Strom oder mit einem konstanten Widerstandswert zu entladen.

Achso, bevor ich's vergesse. Den Namen....
>>Klaubunde
>Könntest Du das BITTE mal korrigieren :(
>Das erste 'u' gehört da nicht hin.
....ich hab's mal eben schnell korrigiert.

Mehr fällt mir zu dem allermodernsten Hochtechnologiemaschienegerät* 
nicht ein, so spontan.


*) Begriffierungen geklaut aus Ion Tichy Raumpilot, Teil 1-6

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kachel-Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anna Pulski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Projekt ist doch in der Rubrik "Wettbewerb". Sind da auch 
Gemeinschaftsprojekte vorgesehen?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hegy wrote:

> Und dann mal ne Frägh:
> So'ne Dingers versteht mein avr-gcc nicht (Ver. 4.10)
> data |= 0b00000010;
>
> Die Schreibweise 0bxxxxxx ist es, mußte ich auch manuell ändern.
> Was muß ich tun, damit der's frißt?

Einen passend gepatchten gcc nehmen. Ich habe meinen vor einem halben 
Jahr selbst uebersetzt und musste auch erst die neusten AVR-Patches 
manuell hinzufuegen. Die aktuellen Versionen im Studio sollten aber 
AFAIK o.k. sein...

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

@Hegy
1. Du kannst den Widerstand auch durch eine Lampe ersetzen und den Strom 
voll Raufdrehen,
daher wird der PWM auf 100% nun du entlädst mit deinem Widerstand.

2. Mit dem Verpolungsschutz hab ich mir zuerst auch den Kopf zerbrochen, 
aber ich habe jetzt eine
Lösung. Man kann vor den Transistor eine Diode oder besser eine 
Schottkydiode einbauen.
Der Proz schützt sich selber, da er am Eingang zwei Dioden hat und da 
der Spannungsteiler
Hochohmig ist fliesst da nur wenig Strom

3. Ein 1.24 V kann man eben nicht mit vollem Strom entladen und irgendwo 
hat jedes Gerät seine Grenzen.

4. Um die Spannung un den Strom zu messen verwende ich die interne 2.56V 
Referenz oder AVCC (5V)
somit ist die Auflösung bei kleinen Spannung hoch und bei den höheren 
Spannung ist dann der
Prozentuale Fehler etwa gleich gross, obwohl die Auflösung weniger genau 
ist.
Der Kondensator C17 ist um Störungen vorzubeugen.

5. Auch in der Lüfterschaltung arbeitet der Transistor als 
Spannungsfolger. Der Kondensator soll die Stomspitze
abfangen, die  der Lüfter duch das interne Schalten verursacht. Der PWM 
hat mit dem ganzen eigentlich
wenig zu tun, da der Transistor mit einer Analogspannung angesteuert 
wird.

6. Das mit den Dateinamen ist mir noch gar nicht aufgefallen, aber auch 
das werde ich in der nächsten
Version ändern.

7. Ich verwende den AVR-GCC 4.3, daher würde ich dir raten ein Update zu 
machen.
Ich werde noch ein Hinweis anbringen, dass der Source mit AVR-GCC 4.3 
kompiliert ist.

@Anna
Ja, das ist erlaubt. Zudem ist das hier eine Community und der Sinn 
einer Community ist,
dass man sich gegenseitig hilft.

mfg Philipp

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber jetzt funktioniert nichts mehr mit kompilieren.
Wie lauten denn deine Fehlermeldungen?

Ich habe mir nochmal die Ver. 0.6 gezogen und mit den 
Original-Dateinamen versucht zu übersetzen. Hier mal nacheinander die 
Fehlrmeldungen und Gegenmaßnahmen.
$ make
-------- begin --------
avr-gcc (GCC) 4.1.0
[....]
Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d main.c -o main.o 
main.c:1: error: target system does not support the "dwarf-2" debug format
make: *** [main.o] Error 1

Verstehen tue ich das nicht wirklich. Vermutlich liegts an meiner 
Version.
Also aus dem Makefile, sorry, makefile das DEBUG=dwarf-2 auskommentiert.
$ make
Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -g -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d main.c -o main.o 
In file included from KS0108.h:21,
                 from Init.h:18,
                 from main.c:24:
ks0108_def.h:11:21: error: ks0108.h: No such file or directory
In file included from main.c:24:
Init.h:22:18: error: FAN.h: No such file or directory
In file included from main.c:25:
GLCD.h:97:7: warning: no newline at end of file
make: *** [main.o] Error 1

>ks0108_def.h:11:21: error: ks0108.h: No such file or directory
es heißt KS0108.h
>Init.h:22:18: error: FAN.h: No such file or directory
es heißt Fan.h

Und weil das ja ewig lang werden könnte, hier meine Änderungen:
In File ks0108_def.h, Line 11: #include "KS0108.h"
In File ks0108.c,     Line  9: #include "KS0108.h"
In File Init.h,       Line 22: #include "Fan.h"
Das sind die 3 Änderungen, die notwendig sind.
GLCD.h:97:7: warning: no newline at end of file
Das ist ja ganz fix gefixd.
dir.c:59: warning: pointer targets in passing argument 2 of 'MakeFileName' differ in signedness
dir.c:59: warning: pointer targets in passing argument 3 of 'MakeFileName' differ in signedness
dir.c:225: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness
dir.c:447: warning: pointer targets in passing argument 2 of 'strncmp' differ in signedness
dos.c:514: warning: pointer targets in passing argument 2 of 'MakeFileName' differ in signedness
dos.c:514: warning: pointer targets in passing argument 3 of 'MakeFileName' differ in signedness
.....
von den Warnungen bzgl. "differ in signedness" bekomme ich eine ganze 
Latte.
Abhilfe:
File fat.c, Line 112 und 113 ändern, das "unsigned" rausschmeißen, z.b. 
so:
/*unsigned*/ char FileName[8];^M
/*unsigned*/ char FileExt[3];^M
File fat.h, Line 172 und 173, hier auch das "unsigned" rausschmeißen
/*unsigned*/ char DIR_Name[8];      //8 chars filename^M
/*unsigned*/ char DIR_Ext[3];       //3 chars extension^M
Line 260 und 261 ändern, das "unsigned" rausschmeißen
extern /*unsigned*/ char FileName[];^M
extern /*unsigned*/ char FileExt[];^M
Wenn das alles geändert ist, dann rödelt das bei mir in einem rutsch 
durch, ohne Warnungen & Fehlermeldungen.
Einzige Fehlermeldung, die ich bekomme, ist aus dem Makefile.
Ändere mal Zeile 436
von
ELFSIZE = $(SIZE) --mcu=$(MCU) --format=avr $(NAME).elf^M
auf
ELFSIZE = $(SIZE) -A $(NAME).elf
Dann kommt auch was zum schluß raus
Size after:
AkkuTester.elf  :
section     size      addr
.text      25960         0
.data         36   8388704
.bss        1316   8388740
.noinit        0   8390056
.eeprom        0   8454144
.stab      46692         0
.stabstr   17481         0
Total      91485

und jetzt poofen!

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mit den Dateinamen in komplett kleingeschrieben in der Ver. 0.7..... 
naja, so war das nicht gemeint. Ich hatte für MICH die Dateien alle in 
kleingeschrieben umbenannt, damit ich das compiliert bekommen. Damit du 
dir die scheiß Arbeit sparen kannst, habe ich ja nochmal die 0.6 Version 
ausgepackt und nachmal mit make rumgekachelt und mal genauer hingekukkt, 
was da faul ist. Du hättest alles beim alten lassen können, nur in 2 
oder 3 Dateien was ändern, ne Kleinichkeit, das wärs dann schon gewesen. 
Also, schreib so wie du willst, ich will die nicht unbedingt in 
kleinschrift haben die Dateinamen. Deine Schreibweise war schon voll ok.

Nochmal was zur Projektseite, Abschnitt Speicherung der Daten
Ich war mal so frei und habe die einzelnen Leerzeichen durch TAB 
ersetzt, zumindest optisch. Somit steht das erste Zeichen in Spalte 1, 
nach dem 1. Tab das nächste Zeichen in Spalte 9 usw. Dann wüder ich noch 
vorschlagen, die Spaltenüberschriften abzukürzen, also t für Zeit (müßte 
es nicht Entladezeit heißen statt Ladezeit?), U für Spannung usw. So 
sähe das aus:
t[s]    U[mV]   I[mA]   C[mAs]   E[mWs]
11      660     22      73      46
31      660     33      358     226

Ganz Allgemein finde ich, daß grundlegende Angaben, wie z.B.
- min. & max. Entladestrom,
- min. & max. Akkuspannung,
- Schrittweite der Einstellung,
- verwendbar für welche Akkutypen
fehlen. Falls diese Werte noch nicht festgelegt sind, festlegen! Is 
unheimlich wichtich, darauf baust du dein Projekt auf! Ich versuche 
gerade einen der ToDo Punkte auszuradieren, daher nehme ich mal folgende 
Werte an:
minimaler Entladestrom 10 mA
max. Entladestrom 10 A über bei allen Spannungen (1.2V bis 12V)!
Schrittweite zur einstellung des Entladestroms 10 mA.

Damit gehts schon los, 10A Entladestrom bei 1.2V Akku. Es gibt ja so 
größere Tonnen, die können das. Oder auch einzellige Blei-Akkus. Es soll 
ja universell vielseitig sein.

...ca. 3 Std. später....

So, feddich gemalt. Ich habe meine Ergüsse mal gemalt! Kukkense mah in 
Anhang.

Muß ich das jetzt erklären?
Ok, Kurzform, schon wieder so spät, ich will inne Poofe und nicht erst 
noch was essen, krich wieder schmacht.
Zum Themer.
Aufgrund meiner gemachten Annahmen habe ich 2 Entladestrompfade gebaut. 
Der obere Zweig (L für Low Current) ist für max. 100mA Entladestrom und 
sollte auch mit 1,2V Akkus erreichbar sein. Am Shuntwiderstand des T1d 
(10 ohm) wird bei 100 mA max. 1V abgegriffen, mit nicht invertierendem 
OP und Verstärkungsfaktor 5 auf max. 5V für den AD-Wandler hochgebracht. 
Selbiges mit den untern Strompfad (H wie High Current), ausgelegt 
(theoretisch) für max. 10A und mit Umschaltung auf max. 1A für bessere 
Auflösung.
Die generelle Umschaltung zw. H und L geschieht mit TTL-Pegel an T5, der 
als Inverter arbeitet. Somit kann nur einer der MOSFETS, die übrigens 
bei U_GS=5V schon fast voll durchschalten, durchschalten und die aus der 
PWM generierte Gleichspannung zum entsprechenden Transistor 
durchschalten. Somit ist entweder der L- oder H-Strompfad aktiv.
Je nach dem, wie beim Setup der Entladestrom gewählt ist, wird per SW 
der Verstärkungsfaktor der H-Strompfades umgeschaltet (und generell die 
H/L-umschaltung entsprechend gesetzt), Faktor 8 im Bereich über 1A bis 
10A, sonst Faktor 80.

Das ist nur erstmal ein Entwurf. Wahscheinlich fehlt am S-Pin von T3 ein 
Widerstand nach GND (oder Widerstand von Basis T1a/b/c nach GND wie bei 
T1d). Dann noch offen sind die 3 Entkoppelwiderstände zu je 1k an den 
Emittern von T1a/b/c zum OP. Ob das funktioniert, weis ich nicht.
Den H-Strompfad habbich übrigens mal aus 3 Transistoren aufgebaut. Grund 
ist, daß die Wärmeverteilung besser ist, also nicht ein Hot-Spot in 
schweineheiß, sondern 3 Hot-Spöttchen in etwas wärmer. vllt. sind auch 
die errechneten Werte allesamt für die Tonne......

Außerdem hat der TIP142 eine parasitäre Diode zw. E und C in 
Sperrichtung drin. Wenn jetzt also der Akku verpolt angeschlossen wird, 
sind die Dioden leitend oder auch schon tot und der Transistor übrigens 
auch! Aber auch dafür gibt es Möglichkeiten, das zu verhindern. Z.B. 
vorher abchecken, ob überhaupt ein Akku angeschlossen ist und wenn, die 
Polung feststellen. bei falscher Polung darf dann eben der Lastkreis 
nicht bestromt werden.

Achso, die 3 Shunts am T1a/b/c sind 5 Watt Geräte (0.18 Ohm × (3.33A)² = 
2W) und brauchen nicht mehr auf den Kühlkörper montiert zu werden.

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Akron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Akron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MarioG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Kälin schrieb:
> Hallo zusammen
>
> ich habe mit einem Projet angefangen, mit dem man die Kapazität von
> Akkus messen kann.
...
> auch gerne Fragen beantworten.
>
> MfG Philipp
>
Hallo und Danke,

schön das Du dir die Mühe für uns gemacht hast. Hatte vor einiger Zeit 
mal in einem anderen Forum versucht etwas ähnliches zu finden.

http://www.heise.de/ct/foren/S-Akku-Zustandsautoma...

Hoffe das ich es erstmal einfach nachbauen kann.
Fragen tauchen erst bei wirklich auftretenden Problemen auf.

Bernd_Stein

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dunno.. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lad dir den tarball (unten links, wenn du auf den link zum svn rep. 
klickst) 7 zip kann das entpacken.

MfG

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch eine Frage.

Würde es ein ATmega16 auch tun ?

Und was müsste dann geändert werden ?

Da der Quellcode in C geschrieben ist, kann ich es schlecht selber 
machen, da ich mich noch in Assembler übe.

Die Unterschiede liegen in den Speichergrößen und in den 
Interruptvectoradressen.

http://atmel.com/dyn/resources/prod_documents/doc2538.pdf

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MarioG
Selber gehört habe ich noch nie etwas von einem LC7981 Controller, auf 
die schnelle habe ich aber den Thread hier gefunden:
Beitrag "GrafikDisplay mit LC7981; Darstellungsprobleme"

Allerdings möchte ich dich darauf hinweisen, dass du da mehr als nur den 
Hardware Treiber ändern musst. Ich muss zugeben, dass die Menü Funtionen 
nur genau für ein LCD mit 128x64 Pixeln zugeschnitten sind, es gäbe also 
eine gröbere Arbeit die zu ändern. Ich wüde dir empfehle ein günstiges 
LCD z.B. bei eBay zu kaufen 
Ebay-Artikel Nr. 160491739561

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: MarioG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Egon Spengler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Kälin schrieb:
> @Bernd Stein
> Nein, der würde nicht reichen. Vom Flash Speicher vieleicht noch, aber
> um auf die SD-Karte zu speichern brauchst du mehr als 1K RAM. Alleine
> der schreib buffer für FAT ist 512 Byte gross. Wenn du auf die logging
> Funktion verzichtest, könnte es jedoch ev. gehen.
>
Danke für die Antwort. Naja, da muß ich halt in den sauren Apfel beissen 
und ein paar ATmega32 kaufen. Brauche ja eh noch den SD-Card-Slot.
Hoffe diese ist geeingnet :

http://www.pollin.de/shop/dt/MjU4ODQ1OTk-/Computer...

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der TLC272 ist ja gar kein " Rail to Rail " ist es trotzdem egal ?

Der LM336 soll der 2,5V oder 5,0V sein ?

Bernd_Stein

Autor: Bernd Stein (bernd_stein)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CS vertauscht?

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Stein schrieb:
...
>
> Werde in später Zukunft die Endstufe nachbauen bzw. überlege evtl. diese
> hier aus der FUNKAMATEUR zu benutzten.
>
> "Einstellbare elektronische Last für maximal 20 A und 24 V"
> FA 3/11, S. 269
>
Hallo zusammen,

möchte mich nochmal bei dem Ersteller des Projekts bedanken.
Suche schon seit einiger Zeit nach so etwas, womit man feststellen kann 
was meine Akkus noch taugen.
Mit der Bedienung bin ich zufrieden, den SD-Kartenslot habe ich nicht 
verdrahtet, arbeite mit der SW-Version 1.6 vom 28.11.2010.

Ich möchte herausfinden wie ich die Anzeige von Spannung und Strom mit 
meinem Multimeter in Einklang bringen kann.

Habe den Leistungsteil wie im Anhang Seite 1 aufgebaut. Habe dann 
Versuche mit einem NiMH 1600mAh Akku gemacht und einige Dinge bemerkt.

1. Im Ruhezustand fließt bereits ein Strom von 3,7mA. An IC4A Pinn 1 
messe ich auch 0,7 Volt. Mit dem Multimeter ( Mum ) messe ich am Akku 
selbst eine Spannung von 1,277V und am µC selbst ( UBATT ) 116mV, was 
auch passt.
Am Shunt messe ich 6mV was am µC als IBATT mit 3,5mV ankommt und ja auch 
richtig ist. Ok, diese Sachen sind nicht so wichtig, da ja der Akku 
getestet werden soll und nicht ständig am Akkutester hängt.

2. Bei der Messung vom Ri bekomme ich für den Max,- und Mittelwert
Null milliohm angezeigt. Entladeschlußspannung ist 1V, Entladestrom 
160mA und das Messinterval 30s. Bei der Anzeige 0% messe ich mit dem Mum 
das was ich unter Punkt 1 beschrieben habe. Wenn anscheinend die erste 
Messung erfolgt ist, bekomme ich

bei  0%,  2mA, 445mV angezeigt. Mit dem Mum 9,6mA, 1,246V.

bei  5%,  8mA, 445mV mit dem Mum 15,7mA, 1,239V,
bei 10%, 12mA, 450mV             28,1mA, 1,230V,
bei 15%, 23mA, 450mV             34,3mA, 1,225V,
bei 20%, 29mA, 445mV             46,5mA, 1,216V,
...
ab  55%, ca. 90mA, ca. 440mV     ca. 59mA,  ca.1,200V

Stellt sich für mich zum einen die Frage, warum erreiche ich den 
eingestellten maximalen Entladestrom von 160mA nicht ?

Zum anderen, die Frage die mir erstmal wichtiger ist :

" Wo muß ich im C-Quellcode ansetzen, damit die angezeigten Werte von 
Spannung und Strom mit meinem Mum übereinstimmen " ?

Der Akku selbst brachte beim Kurzschliessen einen Strom von 5,4A und die 
Akkuspannung war bei 0,356mV, was einem Ri von 170mOhm entspricht.

Den Akkutester habe ich mit den 5V vom Spannungsregler IC2 von Seite 4 
des PDF-Anhangs auf der Platine kalibriert. Dazu habe ich die 
Senseleitungen
( Akku+ / Spannung- ) dort angebracht und kalibrieren gestartet.

Habe von C keine Ahnung und übe mich in Assembler. Hoffe trotzdem da 
durchzusteigen, falls mir jemand schreiben kann, wo ich im C-Programm 
ansetzen muß.

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigung das ich jetzt erst antworte.

Philipp Kälin schrieb:
> Hallo Bernd
>
> Zu der Frage warum du die 160mA nicht erreichst, als ich den AkkuTester
> gemacht habe war der Einsatzzewck für höhere Spannungen. Die
> Leistungstransistoren können nicht mehr als voll schliessen. Wenn du von
> den 1V Endspannung etwa 0,3V für D3 noch weg nimmst, dann bleibt nicht
> mehr viel für die Transistoren übrig.
>
Oh ja. Hatte nicht weiter überlegt.
>
> Wenn du den Akku Tester nur für kleine Spannungen verwendest wüdre ich
> als erstes D3 entfernen, und ev. den Leistungswiderstand R17 durch einen
> kleineren ersetzen oder ganz weg lassen.
>
Ja, will einzelne Akkus auf ihre Kapazität hin überprüfen,
überwiegend NiMH, NiCd in Größen AA, AAA und SubC.
>
> Die ungenauigkeit des Stromes kommt daher, dass als Mess-Shunt der
> Leistungswiderstand verwendet wird, der ist an sich nicht genau und
> driftet bei Belastung zusätzlich. Hier der selbe Grund, ich hatte ihn
> für Strome 2-5A ausgelegt.
>
Ich denke die Ursache liegt wo anders.
Habe nochmals eine Messreihe bezüglich des Ri ermittelns durchgeführt.
NiMH 1600mAh mit Entladestrom 160mA, Entladeschlußspannung 1V, 
Meßintervall 30s.
Diesmal habe ich die Spannung an Pinn 40 des µCs gemessen - Sprich 
IBatt, welche ja über einen Spannungsteiler erzeugt wird. Die Spannung 
IBatt ist somit die halbe Spannung am Shunt R17 ( 1,8 Ohm ). Das 
bedeutet :

Bei 5%, 6mA, 451mV in der Anzeige => gemessen und errechnet 13,2mVx2 / 
1,8 = 8,8mA
10%, 12mA, 450mV => 23,3mVx2 / 1,8 = 25,8mA
15%, 24mA, 461mV => 31,5mA
20%, 29mA, 445mV => 43,0mA

25%, 42mA =>  48,lmA
30%, 46mA =>  60,3mA
35%, 56mA =>  66,1mA
40%, 64mA =>  77,6mA
45%, 75mA =>  83,5mA
50%, 81mA =>  94,8mA
55%, 92mA => 100,5mA
60%, 99mA => 111,7mA
65%,110mA => 117,3mA
70%,116mA => 122,5mA
75%,122mA

Ich denke die Meßreihe zeigt deutlich, das die Genauigkeit gut ist.
Jedoch scheint die Meßwertausgabe um einen Schritt versetzt angezeigt zu 
werden. Zum Beispiel wird bei 60% 99mA angezeigt und errechnet habe ich 
111,7mA.
Der Wert passt gut zu der Anzeige bei 65%  110mA und dies ist bei jeder 
Messung so.

>
> Wenn du den Leistungsteil anpassen möchtest, dann helfe ich dir nachher
> gerne beim anpassend der SW. Intern wird alles in mV / mA gerechnet, es
> muss also nur die Umrechnung vom AD-Wert in mV /mA geändert werden, was
> eine kleine Sache ist.
>
Warum jedoch die Akkuspannung immer als ca. 450mV angezeigt wird, obwohl 
diese ca. 1,2V beträgt habe ich noch nicht untersucht.
>
> Die 0,7V am IC4A Pin 1 kann ich mir im Moment nicht erklären. Hast du da
> den TLC272 verwendet, oder sonst einen der sauber gegen GND kommt?
>
Ja ich habe  den TLC272CP, jedoch ist bei mir IC4A als IC5B ausgeführt,
da ich die hintereinander geschalteten OpAmps in dem selben Gehäuse 
verwende ( IC5A und B ). Die Platine ist in Fädeltechnik ausgeführt.

Bei mir schwingt jedoch IC5A pinn 1 mit ca. 0,2Vss und ca. 625Hz, obwohl 
dies sicherlich durch die 100nF Kondensatoren C1 am +Input gegen GND und 
C18 an den -Input gegen GND verhindert werden sollte. Dies dürfte der 
Grund sein warum an IC4A Pinn1 ca. 0,7V mit dem Mum ( Multimeter )
zu messen sind.
>
> Wenn ich mich richtig erinnere funktioniert die Ri-Messung nur wenn der
> Endwert des Stromes erreicht wird.
>
Ach so. Ich denke den Ri kann man am genausten bestimmen, wenn der 
Entladestrom der Kurzschlußstrom ist. Deshalb denke ich das die eingabe 
eines Entladestromes unnötig ist und der maximal mögliche ( 
Kurzschlußstrom ) erzeugt werden sollte.

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> Bernd Stein schrieb:
>> Warum jedoch die Akkuspannung immer als ca. 450mV angezeigt wird, obwohl
>> diese ca. 1,2V beträgt habe ich noch nicht untersucht.
>>
>Philipp Kälin schrieb:
>
> Kann ich bei mir nicht nachvollziehen, wäre interessant ob das nur bei
> der Innenwiderstandsmessung auftritt oder auch beim Akku testen?
>
Seltsamerweise ist es beim Endladeprogramm nicht so gravierend, ich 
würde sogar sagen tolerierbar. Hier mal ein paar Messwerte :
Anzeige => gemessen
1155mV  => 1160mV
1127mV  => 1140mV
1127mV  => 1136mV
1100mV  => 1126mV
1100mV  => 1118mV
1100mV  => 1108mV
Habe diese Messwerte in unregelmäßigen Abständen überprüft.
>
> Als Anhang habe ich ein korrigiertes HEX-File, kannst du das bei dir mal
> testen und bescheid geben, wenns geholfen habe lade ich es ins SVN hoch.
>
Habe mit der Programmversion 1.7 und dem selben Akku bei gleicher 
Einstellung ( NiMH 1600mAh  Enladestrom 160mA, Messintervall 30s )
die Ri-Messung durchgeführt :

Mum = Multimeter

V_Mum ist an Pinn 40 ( I_Batt ) gemessen worden.
I_errechnet = V_Mum*2 / 1,8 Ohm.
Der Spannungsteiler für I-Batt besteht aus 1%igen Widerständen.

I_Anzeige/mA   I_Mum/mA  V_Mum/mV  I_errechnet/mA

 0% Nichts     4,3       3,7       4,11
 0%  2        10,34      8,7       9,67
 5%  8        16,21     13,8      15,33
10% 13        28,4      23,9      26,55
15% 23        34,4      28,9      32,11
20% 30        46,2      39,3      43,67
25% 41        52,0      44,5      49,44
30% 47        62,9      54,6      60,67
35% 58        64,5      60,0      66,67
40% 63        56,6      70,0      77,78
45% 75        52,0      75,0      83,33
50% 80        48,3      79,0      87,78
55% 86         "        78,8      87,55
60% "          "        78,7      87,44
65% "         48,2      78,5      87,22
70% "          "         "          "
75% 85        48,1      78,4      87,11
80% 86         "        78,3      87,00
85% 85        48,0      78,2      86,89
90% 86         "        78,1      86,78
95% 85        47,9      78,0      86,67

Ri Maximal = 8800mOhm, Ri Mittelwert = 2140mOhm

Wenn man sich die Tabelle anguckt sieht es immer noch so aus, als ob der 
angezeigte Wert versetzt angezeigt wird. Zum Beispiel bei 0% mit 2mA in 
der Anzeige, wird ein Strom mit dem Mum von 10,34mA gemessen und der 
errechnete Strom beträgt 9,67mA.
Das kommt den bei 5% angezeigten 8mA näher als den Angezeigten 2mA.
Dies kann man fortlaufend bis 35% beobachten. Desweiteren läßt sich 
erkennen das der errechnete Stromwert ( U_Batt*2 / 1,8 Ohm ) dem mit dem 
Mum gemessenen ( I_Mum ) ebenfalls bis 35% sehr nahe kommt.
Somit möchte ich behaupten, das die Spannung am AD-Wandler des µCs 
korrekt ist.

Ab 40% sieht es so aus als ob das Mum für die Strommessung spinnt.
Habe deshalb die Mum gegeneinander getauscht, so das das Voltmeter nun 
den Strom misst und umgekehrt. Die Werte sind jedoch bis im Unterschied 
bei der Kommastelle genau gleichgewesen.
Mit dem Osziloskop konnte ich sehen das I_Batt mit ca. 5mVss verrauscht 
ist. Dies macht ja so ca. 5mA aus - also nicht so schlimm ist.

Ab 50% bleibt der Strom konstant, was ja mit dem durchsteuern der 
Leistungstransitoren zusammenhängt. Seltsamerweise ist hier der 
errechnete Strom immer passend zum Angezeigten jedoch nicht mehr zum 
Gemessenen.
Warum hier beide Mum bei der Strommessung so reagieren kann ich mir 
nicht erklären.

Die Ri-Messung beim vertauschen der Mum brachte auch einen unerwarteten
Wert für Ri-Maximal, nämlich fast den doppelten 15090mOhm.
Ri-Mittelwert war 2299mOhm, was ja nicht so sehr abweicht.

Werde demnächst mal gucken, was die neue Programmversion ( 1.7 ) beim
Entladeprogramm macht.

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Stein schrieb:
>
> Habe bereits Spannungsmessungen mit der Version 1.7 durchgeführt.
> Werde hoffentlich heute Nachmittag bzw. Abend dazu kommen, die
> Ergebnisse hier im Forum mitzuteilen.
>
Hier nun die Ergebnisse :

Ri-Messung mit NiMH 1600mAh, eine Zelle, Enladestrom 160mA,
Messintervall 30s

I_Anzeige = Auf dem Display angezeigter Stromwert
U_Anzeige = Auf dem Display angezeigter Spannungswert
U_Akku    = Spannung direkt am Akku gemessen
U_Batt    = Spannung direkt am Mikrocontrollerpinn 39 ( U_Batt ) 
gemessen
U_Batt errechnet = Da U_Batt dem µC über einen Spannungsteiler zugeführt 
wird, ist mit folgender Formel gerechnet worden U_Batt * 11,
um zu ermitteln welche Spannung am Spannungsteiler ankommt bzw. wie hoch 
die Akkuspannung als Rohwert ist.

I_Anzeige/mA ; U_Anzeige/mV   U_Akku/V   U_Batt/mV   U_Batt errechnet/mV
 0%   -             -         1,208      109,6       1206
 0%   2            440        1,202      109,1       1200
 5%   8             "         1,196      108,5       1194
10%  12            396        1,185      107,6       1184
15%  24            440        1,179      107,0       1177
20%  29            352        1,167      105,9       1165
25%  42            230        1,161      105,3       1158
30%  47            241        1,149      104,3       1147
35%  59            236        1,143      103,8       1142
40%  64            230        1,132      102,8       1131
45%  74            220        1,127      102,3       1125
50%  82            225        1,132      102,8       1131
55%  94             "         1,139      103,4       1137
60%  88             "         1,143      103,8       1142
65% 101             "           "          "           "
70% 102            230          "          "           "
75%  "             225        1,142      103,7       1141
80% 101            230          "          "           "
85% 100            241        1,141        "           "
90%  "             230          "        103,6       1140
95%  99            241          "          "           "

Maximaler Ri = 17600mOhm
Mittlerer Ri =  4511mOhm

Die Tabelle zeigt ganz deutlich das U_Batt errechnet maximal 2mV von dem 
Wert der am Akku ( U_Akku ) gemessen wurde abweicht.
Somit ist der angezeigte Spannungswert falsch, da U_Batt ja richtig am 
AD-Wandlereingang ( Pinn 29 ) ankommt.

Somit liegt der Fehler in der Software bei der Ri-Messung, so wie es 
auch zuvor bei der Ri-Messung mit dem Strom bei der Version 1.6 
festgestellt wurde.

Beim Entladeprogramm in der Version 1.7 ist die Spannungsanzeige 
tolerierbar, wie zuvor auch bei der Version 1.6.
Mit dem Strom habe ich das bei der Version 1.7 noch nicht getestet und 
warte erstmal, auf ein neues Update wo diese Fehler behoben worden sind.

Philipp Kälin schrieb:
>
> Wenn du den Leistungsteil anpassen möchtest, dann helfe ich dir nachher
> gerne beim anpassend der SW. Intern wird alles in mV / mA gerechnet, es
> muss also nur die Umrechnung vom AD-Wert in mV /mA geändert werden, was
> eine kleine Sache ist.
>
Ja ich würde gerne den Leistungsteil anpassen. Und zwar möglichst das 
auch einzelne Zellen getestet werden können bzw. wie schon mal erwähnt
- den Artikel aus der Funkamatuer-Zeitschrift hier einfließen lassen.

"Einstellbare elektronische Last für maximal 20 A und 24 V"
FA 3/11, S. 269

Das jedoch erst, wenn bei dem jetzigen Aufbau auch das im Display 
angezeigt wird was ich mit dem Multimeter ( Mum ) messe.
Sowohl bei der Spannung wie auch beim Strom.

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Kälin schrieb:
>
> Ich werde mir das mit der falschen Spannung mal ansehen, auch dass die
> aktuelle Spannung angezeigt wird und nicht der letzte Wert, werde ich
> ändern.
>
> Im moment habe ich wegen der Semesterprüfungen nicht so viel Zeit und
> die Hardware gerade nicht zur Hand, ev. komme ich am Wochenende dazu.
>
Schön.
Lass Dir Zeit ich schaue ja bereits seit ( siehe Link ) nach so etwas.
Wenn es dann meine Wünsche, die ich im vorherigen Post geschrieben habe 
erfüllt, bin ich schon ziemlich zufrieden da ich merke das es ein 
Weiterkommen in dieser Richtung gibt. Kümmere Dich lieber intensiv um 
deine Semesterprüfungen, die sind wichtiger. Nutze besser das Wochenende 
zum Üben.
Verschiebe dieses Projekt, bis Du wirklich einen freien Kopf dafür hast.
Und noch mals Danke für dieses Projekt.
http://www.heise.de/ct/foren/S-Akku-Zustandsautoma...


Bernd_Stein

Autor: frewer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KPhilipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KPhilipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KPhilipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KPhilipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alfred Bauer (mirkandol)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KPhilipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alfred Bauer (mirkandol)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also noch einmal zu meiner Feststellung bezüglich der Entladezeit. Wie 
bereits beschrieben wird "Akku.Entladezeit" beim Entladen sowohl im 
SecTick() hochgezählt als auch in der Entladefuntion Entladen(). 
Gebraucht wird die Entladezeit eigentlich nur zur Bestimmung der 30sec 
in der Prüf-Funktion Abschaltung(). Bei der Überprüfung mittels Anzeige 
der Entladezeit bestätigt sich meine Feststellung - sie wird zu schnell 
hochgezählt. Da sie nur im Programmteil Entladen() benutzt wird, habe 
ich das Hochzählen in SekTick() nunmehr gelöscht und damit funktioniert 
die Zeitangabe auch richtig. Bei meinem "großen Display" habe ich die 
Entladezeit nunmehr im "leeren" Sektor angezeigt -bringt etwas Bewegung 
ins Spiel -.
 mfG
frewer

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nach vielen versuchen und Einstellungen läuft das Gerät, dennoch bin ich 
nicht so richtig zufrieden. Die von mir vorgeschlagene PWM-Steuerung 
habe ich wieder entfernt, weil sie zum Schwingen neigte. Daneben habe 
ich aber noch folgende Schwierigkeiten:

1. Z.B. schaltet der Analogteil den Entladedarlington nicht völlig ab, 
es bleiben ca 20mA, die immer fließen. Statt dem TLC272P verwende ich 
allerdings den CA358E (war gerade da). Das jedoch kann eigentlich m.E. 
nicht dan Mangel hervorrufen.
Wo kommt das her: Ich messe an den Eingängen 3 und 2 des OpAmp (5A) je 
0,09mV (so zeigt es jedenfalls mein Multi im kleinsten Spgsbereich an). 
Daraus ergibt sich aber am Ausgang 1 1,25V und die stehen auch am 
Ausgang 1 des OpAmp (4A) und damit fließt natürlich ein kleiner Strom. 
Wegen des geringen Messwiderstandes von nur 1 Ohm (1,8 war nicht da) 
gibt es die kleine Spg am Eingang.
Hat das Problemchen noch jemand und wenn ja, wie konnte es gelöst 
werden?

2. Mit vielen Messungen habe ich jetzt auch eine einigermaßen genaue 
Anzeige der Messwerte einstellen können. Da der Messwiderstand zumindest 
bei höheren Strömen (1A) warm wird, ändert sich auch sein Wert und damit 
die Anzeige des Stromes. Elegant wäre deshalb, wenn man auch den Strom 
und die PWM kalibrieren könnte. In einem ersten Schritt habe ich sowohl 
in der Routine DAC() als auch ReadCurrent() die Berechnung der werte mit 
Rmess eingeführt, den ich dann einfach anpassen kann. Das klappt auch 
ganz gut. Im nächsten Schritt werde ich eine Kalibrierung der 
Strommessung ähnlich der Spgsmessung machen (5V mit einem bekannten 
Vorwiderstand), so dass ich den Widerstand Rmess und das 
teilerverhältnis automatisch ermittle. Daran arbeite ich aber noch.

3. nehme ich während des Entladevorgangs die Batterie mechanisch weg, 
dann bleiben bei mir ca 0,6 V Restspannung  am Spgsmeßpunkt zurück und 
das obwohl die Pullups bei Strom und Spannung ausgeschaltet sind. Auch 
dieser Effekt ist noch unklar.


mfG
frewer

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

erstmal vielen Dank für den rat, ich werde das heute mal mit Deiner idee 
testen.
Was die Software angeht, so bin ich schon etwas weg von Philipps 
Versionen. Ich hatte zuerst mal an ein anderes Display - 194x64 - 
angepasst und dann einige kleinere Änderungen vorgenommen. So kann ich 
jetzt die Entladezeit anzeigen und habe festgestellt, dass da was nicht 
stimmt, denn der Zähler zählt etwas zu schnell. Da ja aber die Zeit 
nicht benötigt wird, ist das wohl nicht so wichtig. Dann habe ich auf 
eine 3 Tastenbedienung umgestellt und die SD-Karte sowie die zweite 
Sprache mit dem ganzen Software-drum und dran rausgenommen. Mir scheint 
das für meinen Zweck ein bisschen übertrieben. Und im EEPROM speichere 
ich eigentlich nur den Wert für die Kalibrierung. Alle anderen werte 
stehen ja im Flash und nehmen dort auch kein "RAM" weg.

Mit Deiner vergleichenden Messreihe habe ich noch nicht angefangen, weil 
ich relativ lange für das Verstehen und Nachvollziehen der 
Anzeigemethode von Philipp gebraucht habe. Seine Programmtechnik finde 
ich interessant und ich lerne immer was dazu. Die ganze Rechenlogik ist 
bei mir noch Original Philipp.

Wie ich schon sagte, will ich erst mal das Problem mit dem "Reststrom" 
lösen, da ich eigentlich das Ganze für das Testen von 1 zelligen NiCD 
Akkus verwenden wollte und da stört mich dieser Reststrom. Das 
Analogteil habe ich dann auch vereinfacht und habe für die Tests nur 1 
BD639-Darlington mit 1 Ohm Messwiderstand.
Falls jemand an der geänderten Sotware Interesse hat, bin ich bereit sie 
weiterzugeben, wenn Philipp zustimmt.

mfG
frewer

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Reststrom messe ich bei mir auch mit ca. 6mA an einem 12V Akku.

Etwa 2.3mA kommen vom Spannungsteiler für die Spannungsmessung die 
restlichen rund 3.7 mA weiss ich nicht genau wo die hinfliessen, im 
Datenblatt habe ich jedoch gesehen, dasss die beiden Transistoren je 
einen CutOff Strom von 2 mA haben.

Um die Spitzen weg zu bekommen könnt ihr mal versuchen die DAC Funktion 
wie folgt zu ändern:
if (Current != 0)
{
    if ( !(TCCR1A & COM1B1) ) {
        TCCR1A |= (1 << COM1B1);
    }
    PWM = Current / 5.425;
    OCR1B = (unsigned int) PWM;
} 
else
{
    // Wenn der Strom 0 sein sollte den
    // PWM Ausgang deaktivieren und
    // manuell auf Low
    TCCR1A &= ~(1 << COM1B1);
    PORTD &= (1 << 4);
    OCR1B = 0;
}

dann noch hier änder
void Application(void)
{
    AnswMenue_Betribswahl answer;
    DAC(0);
    ...
}

Die Spitzen sollten nun weg sein. Bei mit hatte es jedoch keinen 
Einfluss auf den Reststrom.

Gruss Philipp

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner Freytag (frewer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Werner Freytag schrieb:
> Hi Bernd
> ...
> Ich stelle doch fest, dass Uanz durchaus mit Ubat in einem Zusammenhang
> steht. Die Abweichung kommt sicherlich von meinem Spannungsteiler, den
> ich jetzt korrigiert habe.
>
Bin jetzt mal Deine Tabelle mit dem Taschenrechner nachgegangen.
Nach den ersten Berechnungen für den Strom hab ich dann aufgehört,
da ich erkennen konnte das es da Deine beschriebenen " horrenden " 
Abweichungen gibt. Und bei der Spannung reicht mir ein Zusammenhang 
auch nicht. Ich möchte möglichst genaue Werte. Von einer schönen Anzeige 
und einer guten Bedienung des Gerätes habe ich also nicht viel.

Beitrag "Re: Projet um die Kapazität von Akkus zu messen"

Schade das Philipp hierauf nicht reagiert hat.
Vielleicht kannst Du ihn ja nochmal darauf hinweisen.
So lange jedoch die dort geschilderten Probleme nicht ausgemerzt werden,
ist das Projekt leider für mich uninteressant, da ich die nötigen 
Programmänderungen nicht selbst vornehmen kann.

Bernd_Stein

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schickes Projekt, eigentlich genau was ich suche aber mal eine Frage:

Wie sähe denn die LV Variante zusammen mit der letzten Revision mit 2 
Stück TIP142 aus? IBATT direkt auf GND zu klemmen macht ja wohl keinen 
Sinn, und direkt an die Emitter, damit würde ich ja die 
Emitterwiderstände brücken - auch nicht Sinn der Sache. Und nur einen 
Emitter anzapfen? Müsste man nicht strenggenommen - wenn man den 3055 um 
jeden Preis vermeiden möchte - den Messwert mit zwei OpAmps seperat 
erfassen?

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

Ja, ich hab mittlerweile auch mal geschaut, da es sich bei mir in erster 
Linie um AA und AAA Akkus dreht, dürfte ein TIP142 völlig ausreichen, 
die 5A die der 3055 mehr abkann schöpfe ich sowieso nicht aus. Von daher 
war meine Frage eigentlich schon wieder obsolet. Ich sollte mir mal 
angewöhnen mich nicht immer nur "abends" zwischen 01 und 03 Uhr mit 
solchen Sachen zu beschäftigen, dann findet meine CPU auch schneller 
solche Erkenntnisse.

Ich sträube mich ja auch nur gegen den 3055 weil der auf/durch nen CPU 
Kühler echt blöd zu montieren wäre.

Beste Grüße
Holger

Edit: Spannung, das sind Packs a zwei Zellen also 2,4V. Leider haben Sie 
keine Mittenanzapfung, sonst konnte ich irgend so kommerzielles Teil von 
Conrad oder so benutzen.

: Bearbeitet durch User
Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> Zwei Transistoren parallel schalten würde ich bei der LV/Variante nicht
> machen. Bipolartransistoren und auch Dioden haben einen Wärmekoeffizient
> von -2mV/°C. Das heisst, dass die Kollektor-Emitter Spannung bei
> steigender Temperatur sinkt.

Hmmm, habe mir jetzt nochmal die Dateien im SVN angesehen. Auch wenn es 
für mich jetzt irrelevant ist, aber nur des Verständnis halber: In der 
letzten Version sind in der Standardendstufe doch nun aber auch zwei BJT 
paralell geschaltet; mit kleinen Emitterwiderständen. Der Einfluss des 
Temperaturkoeffizienten mit den beschriebenen Auswirkungen (die mir 
wohlbekannt sind :-) müsste doch hier ebenso zum tragen kommen, bei 
hohen Strömen sogar noch schneller, oder - Achtung, ist schon wieder 
Mitternacht durch :-) - übersehe ich wieder was?

Gruß
Holger

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

okay, danke für Dein Feedback. Dann werde ich das mal in Angriff nehmen.

Beste Grüße
Holger

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Beitrag #4748700 wurde vom Autor gelöscht.
Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Philipp,

der ist in der LV Variante, R10

Das mit dem Umschaltpunkt glaube ich nicht, ich hatte verschiedene Akkus 
(Spannungen) versucht und auch verschiedene Entladeströme. Konnte das 
aber immer beobachten. Mich wundert auch, dass sich der tatsächlich 
gemessene Strom nicht ändert. Das Programm müsste doch ansonsten, wenn 
es von einem schwankenden Wert ausgeht auch versuchen den Strom 
nachzuregeln, oder?

Die Spannung am AVREF schau ich mir aber trotzdem mal an.

: Bearbeitet durch User
Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger Keil (zaldo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich bin einen kleinen Schritt weiter, jedoch der Lösung noch nicht 
näher. Also AVCC ist glatt wie ein Babypopo. Am Ausgang von IC4b 
schwingt es jedoch ganz ordentlich. Wie Eigenschwingen sieht es aber 
nicht aus, es ist eher ein Ripple der mit steigendem Entladestrom auch 
immer größer wird. Habe mal Bilder bei 1A / 2A Entladestrom angehängt. 
Dieses Ripple ist auch Eingangsseitig bereits zu sehen und wird vom 
OpAmp entsprechend mit hochgezogen. Ich frag mich nur was die Ursache 
dafür ist?!

Edit: Habs mir jetzt nochmal etwas länger angesehen, glaube nun doch 
eher auch an Eigenschwingen...

: Bearbeitet durch User
Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger Keil (zaldo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Keil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.