Batteriecontroller - ein Selbstbauprojekt

Details

Erstellt: Samstag, 17. Januar 2015 11:43

Geschrieben von Martin Erger

Wie ich an anderer Stelle (Batterie - Ladezustand messen) bereits ausgeführt habe, sind sogenannte Batteriecontroller die derzeit beste Möglichkeit den Ladezustand einer Batterie in der Praxis zu überwachen. Dabei handelt es sich im Grunde um einen selbstbilanzierenden Rechner, der die entnommenen Ah gegen die zwischendurch immer wieder geladenen aufrechnet. Stark vereinfacht könnte man von einer „Tankanzeige“ für die Batterie sprechen.

Batteriecontroller (z.B. NASA, NASA mini, Votronic, Victron, Philippi) werden aktuell in verschiedenen Versionen am Markt zu Preisen zwischen etwa 130 und 500 € angeboten. Auch die billigen sind schon recht brauchbar und unterscheiden sich von den teureren im Wesentlichen durch den Bedienkomfort. Manche der Oberklasse behaupten auch von sich, sich automatisch an die sich mit der Zeit verändernden Batteriedaten anzupassen. Ob dem wirklich so ist, oder ob es sich lediglich um vollmundige Marketingaussagen handelt, lässt sich kaum nachprüfen.

Normalerweise werden Produkte ganz gezielt in eine Marktlücke hineinentwickelt. Bei diesem Projekt stand dagegen für mich das Bedürfnis etwas zu lernen im Vordergrund. Von daher beschreibe ich ganz bewusst die sonst bei Entwicklungsprojekten eher unüblichen evolutionären Schritte und die Überlegungen, die ich dabei angestellt habe. Darüber hinaus setze ich auch einige Kenntnisse voraus, und erlaube mir deshalb den unter Elektronikern üblichen Laborjargon zu verwenden.

a

Motivation für einen Selbstbau
Als Ingenieur habe ich ein Berufsleben mit der Entwicklung elektronischer Geräte verbracht, die letzten Jahrzehnte vorwiegend im Management. Meine direkten Erfahrungen an der Front in den Niederungen von Bits und Bytes gehen daher auf die frühen 80er Jahre des vorigen Jahrhunderts zurück. Die Detaildimensionierung von Schaltungen sogar noch ein bisschen weiter. Nach ein paar Jahren im Ruhestand, mit genügendem Abstand von beruflicher Tätigkeit und dem Aufkommen von Schaltungen wie „Raspberry Pi“ und „Arduino“, regte sich bei mir wieder das Interesse an Beschäftigung mit der Technik. Wie sich herausstellte, für mich genau das Richtige um dem Novemberblues entgegenzuwirken und die Zeit bis zum nächsten Segelsommer zu verkürzen.

Ich begann mit einem Raspberry Pi, der mir viele Déjà-vue-Erlebnisse und Erinnerungen an lange vergangene Unix-Zeiten bescherte. Nachdem die ersten Hürden überwunden waren, wurde die Beschäftigung mit Lehrprojekten wie blinkenden Leuchtdioden und Temperaturmessungen schnell langweilig. Außerdem wusste ich aus Erfahrung, dass man nur dann wirklich etwas lernt, wenn man nicht von anderen Leuten schon Vorverdautes nachkaut, sondern sich wirklich durch Neuland beißen muss. Irgendwie setzte sich dann bei mir die Idee fest einen Batteriecontroller zu entwickeln und ließ mich nicht mehr los.

a

Raspberry Pi B+

Erste Überlegungen
Batteriecontroller laufen im Dauerbetrieb und werden aus der Batterie, die sie überwachen, versorgt. Entsprechend robust muss ihre Technik ausgelegt sein. Wichtigste Eigenschaften sind eine gute Strommessung, leicht abzulesendes Display, simple Bedienoberfläche und nicht zuletzt ein sehr geringer Eigenstrombedarf. Besonders letzteres ließ mich schnell an meiner anfänglichen Idee, alles um den zu Lernzwecken angeschafften Raspberry Pi B+ aufzubauen, zweifeln. Einerseits war der für die angedachte Verwendung viel zu leistungsfähig, andererseits stellte ich es mir schwer vor, den nicht unerheblichen Stromverbrauch drastisch zu senken. Eine Ethernet-Schnittstelle zum Internet, HDMI und gleich 4 USB brauchte ich gar nicht, dafür müsste ein A/D-Wandler zur Messung von Spannung und Strom extern hinzugefügt werden. Darüber hinaus war unklar, wie sich das Weglassen von nichtbenötigten Schnittstellen und eine deutliche Reduzierung des Taktes zur Stromreduktion auf das Linux-Betriebssystem auswirken würde.

Arduino uno

Solche Überlegungen ließen mich auch einen Blick auf den im Internet häufig als „Konkurrenz“ zum Raspi genannten Arduino werfen. Schnell war mir klar, dass von Konkurrenz im eigentlichen Sinne keine Rede sein konnte, da es sich um etwas völlig anderes handelt. Ein Arduino hat kein Betriebssystem on Board sondern lediglich einen Bootlader um über eine USB ein Programm aufspielen zu können. Im Grunde handelt es sich um ein Ein-Chip-System, das alle wichtigen Funktionen, einschließlich der benötigten A/D-Wandler, schon enthält. Der Stromverbrauch beträgt nur 1/6 des Raspi und lässt sich leicht durch späteren Ersatz des Arduino durch den Prozessor (mit einem ganz kleinen bisschen „Garnitur“) bei gleichzeitig niedrigerer Taktung weiter drastisch reduzieren. Von daher erschien mir ein solches Board für meine Zwecke wesentlich geeigneter und mit den Tücken von Linux würde ich mich auch nicht mehr herumschlagen müssen. Ich entschied mich daher zunächst ein Breadboard um einen Arduino Uno herum aufzubauen und damit ein paar Versuche zu machen.

a

Das Breadboard
Da der Arduino schon fast alles enthält was man braucht, war eine erste Schaltung noch als Handskizze auf Papier schnell entworfen. Weil genügend A/D-Wandler standardmäßig vorhanden waren, entschloss ich mich von vornherein gleich einen Controller zu entwerfen, der zwei voneinander unabhängige Batterien parallel nebeneinander vollständig überwachen konnte. Vollständig heißt in diesem Fall für die zweite Batterie auch eine Strom- und nicht nur eine Spannungserfassung, auf die sich viele Industrieprodukte beschränken. In der Praxis an Bord braucht man das zumindest auf kleineren Booten eher selten, aber man muss die Schnittstelle ja nicht nutzen.

Ein funktionsfähiges Breadboard lässt sich mit wenigen externen Bauteilen aufbauen. Auf dieser Basis kann man die SW vollständig entwickeln.

Ein Breadbord, also einen Versuchsaufbau mit fliegenden Drähten, aufzubauen, war dann nicht mehr schwer. Außer dem Arduino benötigt man dazu nur noch ein LC-Display, 3 Taster und ein paar Widerstände. Ich entschied mich dafür ein aus 2 Zeilen à 16 Stellen bestehendes Standarddisplay (HD44780) zu benutzen welches man z.B. günstig (2,39 €) bei Amazon bekommt. Die Sensoren für Spannung und Strom kann man in dieser Entwicklungsphase durch ein Trimmpoti simulieren, was beim Debuggen der SW praktischer als ein echter Sensor ist, da man so beliebige Werte auf einfachste Weise vorgeben kann. Weitere Informationen zum Breadboard finden sich im Abschnitt Schaltung.

a

Bedienoberfläche
Die Bedienoberfläche besteht lediglich aus dem schon angesprochenen zweizeiligen LCD und drei Tastern: UP, DOWN und SET. Sie ist weitestgehend selbsterklärend.

Displayanzeige im Grundzustand

Im Grundzustand wird oben links die angewählte Batterie angezeigt und rechts die daraus entnommen Ah. Diese Darstellungsart habe ich bewusst gewählt weil ich sie für praxisgerechter halte als irgendwelche Restkapazitätsanzeigen. Weil sich die Restkapazität einer Batterie über die Lifetime langsam vermindert, kann man bei dieser Anzeigeart schnell entscheiden wann es wieder Zeit ist um die Batterien nachzuladen. Ich arbeite bei mir an Bord seit Jahren mit dieser Methode und bin damit sehr zufrieden.

Unten links wird die Batteriespannung angezeigt und rechts der aktuelle Strom. Das Minuszeichen kennzeichnet, dass der Batterie Strom entnommen wird, andernfalls wird sie geladen. Alle Anzeigen erfolgen mit zwei Stellen nach dem Komma. Die Anzeige davor kann max. 3-Stellige Werte annehmen.

Über die UP- und DOWN-Taster kann in diesem Zustand die Displaybeleuchtung verändert und damit den Umgebungsbedingungen angepasst werden.

Displayanzeige im Menue Anzeige

Mit der SET-Taste wird jeweils das nächste Untermenue aufgerufen. Aus dem Grundzustand ist das das Menue Anzeige. Der Titel des Menues wird jeweils in der oberen Zeile angezeigt. In der Zeile darunter können mit UP bzw. DOWN die Auswahlmöglichkeiten durchgescrollt werden. Im Menü Anzeige sind das „Batterie 1“, „Batterie 2“ und „Einstellungen“. Mit der SET-Taste wird die Auswahl jeweils bestätigt. Bei „Batterie 2“ werden bspw. ab sofort im Grundzustand die Daten der Batterie 2 angezeigt. Wählt man „Einstellungen“ kommt man in ein weiteres Menue in dem man nach gleichem Muster die Batteriedaten einstellen kann. Damit lässt sich der Ladefaktor (Das ist der Korrekturwert für den Wirkungsgrad beim Laden.) in 0,05 Schritten zwischen 0,5 und 0,95 einstellen und außerdem der angeschlossene Stromsensor (20, 50, 100, 150 und 200 A) auswählen.

Innerhalb der ganzen Bedienung ist ein Timeout aktiv, der mit jeder Tastenbedienung neu aufgezogen wird. Hat man sich bspw. „verlaufen“ wird 10 Sekunden nach der letzten Tastenbedienung automatisch wieder in den Grundzustand geschaltet.

Unabhängig von der gerade angezeigten Displayanzeige werden die Daten beider Batterien im Hintergrund im Sekundenrhythmus erfasst. Damit ist sichergestellt, dass keine Informationen verloren gehen.

a

Schaltung
Abgesehen von den Tasten und den Stromsensoren zeigt das Bild die komplette Schaltung des Batteriecontrollers. Gegenüber dem Breadboardaufbau, der noch über den USB mit Energie versorgt wird, ist bereits die Stromversorgung aus der Batterie enthalten.

Links oben ist der Anschluss an die Batterien. Die Versorgung des gesamten Gerätes erfolgt immer über den Anschluss der Batterie 1. Diese Batterie muss deshalb immer angeschlossen werden, während der Anschluss für die Batterie 2 offen bleiben darf, wenn man keine zweite Batterie anschließen möchte. Zu beachten ist, dass beide Leitungen in der Nähe der Batterie durch eine eingefügte Sicherung (z.B. 100 mA) abgesichert werden müssen.

Die gesamte Schaltung ist so ausgelegt, dass an den Batterieanschlüssen max. 35 V anliegen dürfen. Es können also sowohl 12 als auch 24 V Systeme (auch gemischt) überwacht werden. Zur Messung werden die Batteriespannungen durch einen Spannungsteiler (links) auf ein für das Prozessorsystem zulässiges Maß herabgesenkt. Die Auflösung der Anzeige erfolgt in Schritten zu 32,5 mV.

Über die Widerstände R 8 und 9 oben rechts wird der Kontrast des Displays eingestellt. Die Helligkeit der Hintergrundbeleuchtung erfolgt über Pulsweitenmodulation (PWM) vom Prozessor. R3 dient lediglich zur Strombegrenzung falls versehentlich ein zu großer Wert eingestellt werden sollte.

An die 3-poligen Anschlüsse „I Bat 1“ bzw. 2 werden die Stromsensoren angeschlossen, die in einem eigenen Kapitel später näher beschrieben werden.

Die Tasten legen unterschiedliche, über einen Spann- ungsteiler erzeugte Pegel, auf einen Analogeingang.

Da das Ganze für mich vor allem auch Experimentalcharakter hat, habe ich für den Anschluss der 3 Tasten eine etwas ungewöhnliche Lösung gewählt. Über einen Spannungsteiler werden unterschiedliche Pegel erzeugt und auf einen Analogeingang des Prozessors gelegt. Die Auswertung der Pegel und die Entprellung der Tasten erfolgt mittels Software.

Stromsensor
Damit man den Controller individuell an persönliche Bedürfnisse anpassen kann und außerdem hohe Ströme heraushält, wurde der Stromsensor bewusst nicht in die Basisschaltung integriert. Er wird immer in die Minusleitung direkt am Anschlusspol der Batterie integriert um wirklich alle Ströme zu erfassen.

20A-Stromsensor mit ACS 712

Die Schnittstelle ist dreipolig und umfasst neben der Systemspannung zur Versorgung des Sensors, lediglich eine weitere Leitung, an der eine Spannung proportional zum fließenden Strom anliegt. Exakt die halbe Systemspannung entspricht dabei keinem Strom. Kleinere Spannungen repräsentieren Ent- größere Ladeströme. Der A/D-Wandler des Prozessors löst den Gesamtspannungsbereich mit 10 Bit auf. Die maximale Auflösung der erfassten Ströme entspricht damit 1024/2 = 512. Bei einem 20 A‑Sensor sind das bspw. 39 mA bei einem für 100 A 195 mA.

An diese Schnittstelle kann man beliebige Sensoren adaptieren. Ganz simpel geht das z.B. mit den auf Hall-Basis arbeitenden Chips von Allegro, die außerdem den Vorteil haben keinen zusätzlichen Widerstand in die Leitung einzufügen. Während der Entwicklung habe ich bspw. mit einem 20 A-Modul auf Basis des ACS712 gearbeitet, das leicht (Amazon 3,49 €, aber auch bei Ebay) zu bekommen ist. Für größere Ströme bis 200 A eignet sich der ACS758 besser. Diese Chips bekommt man z.B. bei DARISUS für unter 10 Euro.

Natürlich kann man auch ganz konventionell mit einer Stromerfassung über einen Shunt arbeiten. Die Wandlung in eine proportionale Spannung passender Größe übernimmt dann ein Operationsverstärker. Diese etwas altertümlich anmutende Lösung hätte den Charme mit sehr wenig Strom auskommen zu können, während die auf Hall-Basis arbeitende etwa 10 mA bezogen auf die Systemspannung braucht.

Software
Die Software entwickelte ich mit der zum Arduino gehörenden Entwicklungsumgebung (IDE), welche sich als einfach zu handhaben, in der Praxis aber nicht als völlig unproblematisch, erwies. Vor allem jedwede Möglichkeiten zum Debugging habe ich sehr vermisst. So habe ich z.B. keine Möglichkeit gefunden das Programm an bestimmten Stellen anzuhalten und die dann aktuellen Werte der Variablen auszulesen. Ich half mir mit Code, der die Werte ins Display ausgab. Alles in allem ein Unding wenn man bedenkt , dass unsere Entwicklungsysteme (zugegeben Profigeräte) so etwas vor über 30 Jahren schon selbstverständlich konnten. Auch der Compiler scheint nicht ganz unproblematisch zu sein. Ein vergessenes Blank in einer Case-Anweisung ergab keinen Syntaxfehler, führte aber zu unsinnigem Code, was mich einen halben Tag beschäftigte.

Das Programm selbst habe ich als „state machine“ angelegt. Dadurch ist alles in überschaubare „Häppchen“ gegliedert, die man bei Bedarf leicht ändern kann. Die Daten für die beiden Batterien werden in einem „array of structures“ gehalten, was die Bearbeitung sehr einfach macht.

Um einen mechanisch stabilen Aufbau zu bekom- men, habe ich die die wenigen exteren Bauteile auf einer Lochrasterplatte um den kopfüber mon- tierten Arduino angeordnet.

Das ganze Programm ist zeitlich völlig unkritisch, da die Daten innerhalb einer Interrupt-Service-Routine (ISR) erfasst werden. Die blinkende LED an Pin 13 ist vom Ablauf her eigentlich völlig unnötig. Sie zeigt lediglich, dass die ISR regelmäßig bedient wird und das wiederum ist zumindest jetzt in der Testphase ganz praktisch.

Von vornherein habe ich auch berücksichtigt die CPU zur Stromreduktion langsamer takten zu können. Außer der Normalfrequenz (16 MHz) des Arduino sind alternativ auch 8 und 4,194304 MHz (ein Standarduhrenquarz) möglich. Dazu muss lediglich ein einzelner Parameter bei der Datendefinition geändert und neu kompiliert werden. Bis auf eine eingebundene Library für das Display habe ich das Programm komplett selbst geschrieben. Von daher sind Eingriffe für Änderungen und Fehlerbeseitigung kein Thema.

a

Zusammenfassung des bisherigen Standes
Um zu einem mechanisch einigermaßen stabilem Aufbau zu kommen habe ich den Arduino auf dem Kopf liegend auf eine Lochrasterplatte montiert und die wenigen externen Bauteile darauf angeordnet. Damit hatte ich ein stabil laufendes Muster, das mehrere Tage im Dauerbetrieb ausgiebig getestet wurde. Danach ergaben sich aus meiner Sicht einiger Handlungsbedarf:

• Den Arduino uno (24,50 €) als Herz des Controllers zu nutzen ist viel zu teuer, er sollte durch eine auf die wirklich benötigten Funktionen abgespeckte Version ersetzt werden.
• Der Strombedarf des Arduino mit ca. 55 mA ist für einem Batteriecontroller entschieden zu hoch. Es muss nach Möglichkeiten gesucht werden diesen drastisch, zumindest in die Größenordnung von 10 mA, zu senken.
• Die zwei Stellen nach dem Komma sind bei der Anzeige des Stromes eine Farce, wenn die Auflösung bei der Messung bedingt durch den 10-Bit Analog-Digital-Converter des Arduino nur 39 mA (20 A Sensor) bzw. 195 mA bei einem 100 A Sensor beträgt.

Wie ich mich dieser Problematik genähert habe, beschreibe ich im zweiten Kapitel meines Berichtes.

Weiterlesen: Batteriecontroller - ein Selbstbauprojekt Teil 2