Mein Schaltungsvorschlag wäre folgender, ggf. mehr 18650er parallel daneben.
Das ist nicht schön, wird aber funktionieren. Designziel ist „billig und reicht“.
Auf die Protection würde ich mich keinesfalls verlassen, ich hatte selbst bei Sanyo und Samsung-Markenzellen bereits den Fall, dass die Endabschaltung teilweise erst bei unter 2,0V eingetreten ist, auch sind die so zum Balancen der Zellen ungeeignet.
Eine Solarzelle (gerade in der von uns benötigten Größe) direkt an einen Akku anzuschließen dürfte wohl leider auch nicht so toll funktionieren. Wenn man Solarzellen mit hohen Strömen belastet bricht umgehend die Spannung und damit die Leistung ein. Daher gibt es sogenannte MPPT-Ladegeräte, welche dann automatisch versuchen, den Strom entsprechend auf die maximale Effizienz einzustellen.
Nicht sicher bin ich mir, was passiert, wenn man LiIon einfach mit z.B. 20 Volt lädt, und diese nicht im CV-Betrieb laden lässt. Ich könnte mir vorstellen, dass das auch nicht soo toll ist, aber das müsste man mal testen.
EDIT: Oh, habe den oberen Post von eberhab gar nicht gesehen:
Also: Ich könnte dir gerne eine Anleitung geben, wie du so etwas aufbauen kannst, die Schaltung selbst zusammenlöten müsstest du allerdings schon selbst (schwer ist das nicht, 1 Arduino, 4 Widerstände und nen paar Kabel).
Mittlerweile muss man auch keine LEDs mehr opfern, ich habe das so direkt ganz zuverlässig am laufen.
Der Arduino hat einen internen ADC und kann somit direkt auch deine Batteriespannung (mittels Spannungsteiler) messen. Hier müsste man nur aufpassen, wie man den Dimensioniert…
Viele Grüße,
Manawyrm
Hmm, also zumindest bei den Rotschwarzen 2,4Ah-Trustfires funktioniert das.
Ich habe mit einer ähnlichen Schaltung (auch so brutal „gebalanced“ lange Zeit eine Outdoor-HID herumgetragen)
Waren afaik 16 Stück 18650, die da in einer 4x4-Konfiguration zusammengebaut waren.
Wichtig halt nur, dass man die „frisch ab Werk, aus einer Charge“ zusammensetzt.
Angsichts der 10€-Modulpreise würde ich glatt vorschlagen, so einen billigen (angeblichen) NiMH-Regler zu probieren an zwei seriellen Zellen.
http://www.ebay.de/itm/Solar-Laderegler-Solarpanel-Ni-MH-AKKU-Ladegerat-Kontroller-PWM-7-2V-3A-/
Einfach schauen, welche Schaltpunkte der nutzt.
Das klingt sehr gut! Diese Anleitung nehme ich gerne, löten ist kein Problem! 
Kann man sich hier PM’s schreiben, oder gibt es die schon wo online, oder wie wollen wir uns austauschen? Gibt es Unterschiede bei den HW-Revisionen? Ich würde vermutlich mit einer v10 arbeiten.
Also ist der Arduino dafür also doch aktuell noch am höchsten im Kurs? Hier wurden ja noch einige diverse andere Bauteile benannt mit denen das evtl auch gehen könnte?
Grüße,
Benni
Darf ich Forum oder ein Wiki vorschlagen, ich hätte das auch gerne und kann mir beim besten Willen nicht vorstellen, dass es nicht noch viele andere Interessenten gibt. Lasst uns doch hier bleiben damit. Danke von mir.
Du kannst Die Batterie direkt an den 841er anschließen. Der hat einen Spannungswandler drauf, der bis 18 V mitspielt und von den 5V bis 18V annähernd die gleiche Leisung zieht. Beste Wirkungsgrade scheint mir der Wandler so um die 7-10V zu haben.
ABER, dann macht Dir der Router die Akkus kaputt, wenn er sich nicht abschaltet und die Akkus tiefentlädt. Darum geht es hier im Thread beim Thema Akku ja letztlich. Ich habe einfach einen kommerziellen Solarregler mit Tiefenaldeschutz gekauft und eingebaut. Und das mit einem 7,2 Ah 12 V Bleiakku gepaart. Läuft ohne Solarpanel fast eine Woche und schaltet sich auch selber rechtzeitig ab. Ist dann halt nicht mehr billigst und das Selberbasteln entfällt fast. Aber funktioniert.Solarpanel kommt dran, sobald ich einen Standort habe, der auch etwas Sonne bekommt. Aktuell stehen zu viele Häuser um mich rum. So sieht das dann aus:
Ich suche gerade noch ICs, die Unterspannungsschutz drin haben und bin auch fündig geworden. Ich suche noch Schönes bei der Frage, wie ich dann wirklich den Akku abwerfe.
Hallo zusammen,
danke für die Infos! Da muss man dann wohl mit leben, dass die 12V Batterie da etwas über dem Optimum liegt. Meine Frage ziehlte eher darauf ab herauszufinden ob es noch einen effizienteren Weg gibt den 841er an die „12V-Batterie“ zu hängen als über den internen Wandler zu gehen, das scheint aber nicht der Fall zu sein.
Ich habe ebenfalls schon einen Laderegler bzw eine fertige Solaranlage mit vorhandenem Tiefentladeschutz. Zu diesem Teil sind keine Fragen mehr offen. Ich weiss nicht was der steca kostet aber wenn man hauptsächlich den tiefentladeschutz nutzen möchte gibts bei amazon so 10-euro pwm regler die bei 11.3 V abschalten.
Mich interessiert hier hauptsächlich ob es evtl zum arduino eine „4 Euro“-Alternative gibt welche man nicht mehr programmieren muss…
Zum DC-DC-Wandler:
effizienteren Weg gibt den 841er an die „12V-Batterie“ zu hängen als über den internen Wandler zu gehen
Der DC-DC Wandler im 841er ist erstaunlich effizient, und ich bezweifele sehr stark, dass es einem Bastler möglich ist, die Effizienz noch zu überbieten. Da sollte man lieber dran ansetzen und „echte“ Verbraucher deaktivieren bzw. unschädlich machen, z.B. die LEDs auf dem Board, die Schutzdiode und evtl. sogar die Ethernet-Übertrager.
Zum Tiefentladeschutz: Ich mache mir da schon ne ganze Weile Gedanken zu:
Bei 1 Zellspannung als gesamte Akkuspannung (also alles paralell) ist das ganze total easy:
da schlägt man alle Fliegen mit einer Klappe, hängt an den Arduino noch einen MOSFET und der Arduino kümmert sich um alles (zumindest mit etwas cleverer Software 
).
Bei 12V, z.B. ist das ganze nicht mehr so einfach. Damit der AVR selbst nicht noch, obwohl er bereits die CPU deaktiviert hat, die Batterie leer nuckelt, kann (und sollte) man Ihn in den Sleep-Modus schicken. Das mache ich auch bei den Einzel-Zell Lösungen. Allerdings muss der AVR ja auch mit Spannung versorgt werden, hier kann bzw. sollte man evtl. nicht mit Schaltwandlern arbeiten, da diese im Idle auch Strom bzw. Leistung benötigen.
LT hat da z.B. den LT3009, ein sogenannter Low Quiescent Current LDO Regulator, welcher im „Leerlauf“ selbst nur wenige µA zieht, und somit den Akku nicht mehr viel weiter entlädt.
Also: Bei Bleigel-Akkus oder ähnlichem einen vernünftigen LDO, ATMega, Spannungsteiler und einen P-Channel FET.
am besten lässt man sich dafür mal beim China-Mann kleine Platinen fertigen, wo man nur noch die Teile drauflöten muss. Das benötigt aber hauptsächlich bei mir größere Mengen Zeit, weil ich mir da gedanken machen muss 
Meine Lust 2 verschiedene Layouts für Single- und Multi-Cell Konfigurationen zu machen, ist eher eingeschränkt, daher möchte ich eig. gerne eine „One-Size-Fits-All“-Lösung.
Ein weiterer Vorteil der MCU basierten Lösung (nebem dem Datenlogging) wäre eine Software konfigurierbarkeit, man könnte also per SSH bzw. evtl sogar per Webinterface eine Spannung definieren, bei der abgeschaltet wird, bzw. eine Schaltung bei der wieder angeschaltet wird (Einschalthysterese, wichtig um ein oszillieren zu verhindern)…
Gerade letzteres in „Analogtechnik“ bzw. mit fertigen Lösungen hinzubekommen wird wahrs. gar nicht mal so trivial sein, deswegen tendiere ich (man merkt es kaum 
) zu einer Mikroprozessor-Lösung.
Das nur soweit…
btw: Sieht man irgendjemanden von euch morgen in Hannover auf der Maker Faire?
Viele Grüße,
Tobias
Moin Leute.
Wirklich schönes Projekt!
Warum nehmt ihr nicht einfach ein oder mehrzellige Handy Powerpacks. Die haben einen Tierenentladeschutz drin.
Für einen batterie-betriebenen Router wäre eine Powerbank ideal, nur leider nicht zum Solarbetrieb, da solche Powerbanks nur mit wenigen hundert Milliampere (die guten evtl. mit 1000mA) laden können, um mit Solar über den Tag und die Nacht zu kommen benötigen wir aber gut und gerne mal 3 Ampere Ladestrom, gerne/eher mehr.
Örks!
Habe mir gestern bei Reichelt noch nen paar WR841 mitgenommen…
Und: sind V11.1
Naja, dann halt nochmal nach GPIOs suchen!
EDIT: Die Duo-LED (Rot, Grün) find ich aber cool!
Cool verkleinertes PCB, dann ist ja mehr Platz für eigene einbauten 
Also 2 GPIOs habe ich noch gefunden, der eine ist der „alte“ JTAG/UART-Pin.
Dabei macht man sich halt einmal die UART kaputt und man muss einen Widerstand auslöten.
Der andere GPIO (bei R27) ist gut zugänglich.
Ich würde hier schon fast dazu tendieren, die LEDs zu deaktiveren, denn die UART ist eigentlich wichtiger.
Ansonsten: die Duo-LED hängt auch an den GPIO-Pins und die Tri-State-Pins des Controllers werden als H-Brücke „missbraucht“ um die Farbe der LED zu wechseln. Mir ist nicht ganz klar, wie man DAS mal sinnvoll in OpenWRT integrieren wird, aber es ist auf jeden Fall ganz cool und man kanns auch jetzt schon mit GPIO-Calls ansteuern
Viele Grüße,
Tobias
Hi Tobias,
coole Arbeit und vielen Dank fürs Teilen. Kannst du beschreiben wie du die GPIOs gefunden hast? Hast du da ein bestimmes Vorgehen?
Hallo rfelten,
ja, gerne.
Im OpenWRT Wiki gibt es dieses Script: GPIO [Old OpenWrt Wiki]
das packt man sich halt auf den Router und startet man mit ./gpio.sh 0 30
dann fangen alle GPIO-Pins an, im Sekundentakt zu blinken.
Mit einem Multimeter oder Oszilloskop kann man dann einfach rumsuchen. Masseleitung auf Masse legen und Gleichspannungsmessung im <6V Bereich und ab gehts.
In folgender Reihenfolge suche ich die Möglichkeiten ab:
Unbestückte Pin-Header (sowas wie den UART), Testpoints und zu guter letzt alle unbestückten SMD-Footprints für z.B. Widerstände.
So kann man relativ zuverlässig alle GPIOs finden
Viele Grüße,
Tobias
Super! Danke für den Link. Das Script hatte ich im OpenWRT Wiki bisher übersehen!
Weiterhin viel Erfolg!
TL;DR: Es sollte noch GPIO2 verwendbar sein, dieser ist jedoch zumindest auf der v9 PCB nicht auf ein Lötpad o.ä. rausgeführt.
Lange Version:
Ich habe mich den GPIO Thema mal eher von der theoretischen Seite genähert als mit dem Messgerät, sprich über das Datenblatt. Das Datenblatt für den in meinem WR841v9 verwendeten QCA9533 habe ich zwar nicht gefunden, aber dafür gibt es das vom QCA9531 nach bisschen Sucherei im Netz (s.u.). Ich unterstelle einfachmal die SoCs sind weitgehend identisch.
Laut Datenblatt S.45 hat der 9531/9533 18 GPIOs. Sieben gehen laut Code (mach-tl-wr841n-v9.c) für LEDs drauf. Zwei für die Buttons. Zwei fürs UART. Zwei hat bereits Tobias gefunden. 7+2+2+2=13. Fehlen also 5.
Schauen wir uns daher mal an, wie die Ports nach dem Booten der v9 mit nem nackten Chaos Calmer geschaltet sind. Dazu guggen wir mit io direkt in die entsprechenden Config Register und guggen dann im Datenblatt nach was Sache ist.
io hab ich nicht auf die schnelle für CC gefunden, aber das von AA tuts auch:
root@OpenWrt:~# wget http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages/io_1_ar71xx.ipk
root@OpenWrt:~# opkg install io_1_ar71xx.ipk
Installing io (1) to root...
Configuring io.
Sweet. Nun brauchen wir noch die relevanten Registeradressen und die Infos um den Registerinhalt zu interpretieren.
Wir wälzen das Datenblatt: Tabelle 7-5 auf S.107 gibt uns die Registeradressen der Pin Konfiguration (= welcher Function Block gemultiplext ist) Tabelle 3-9 GPIO Output Select Values auf S. 47 listet auf welcher Funktionsblöcke welchen „Multiplex Value“ hat, spricht mit was der Pin verbunden wird. Davon gib’s 127 Stück (nicht alle belegt) und es wird 1 Byte pro Pin im Konfigregister benötigt. Die Registerbreite ist 4 Byte, es werden 4 Pins in einem Register konfiguriert/abgelegt.
Beispiel: Konfigtregister GPIO_OUT_FUNCTION2 konfiguriert die GPIO Pins 8, 9, 10, und 11 und hat die Adresse 0x18040034. Wir fragen also 4 Byte an dieser Adresse ab:
root@OpenWrt:~# io -4 0x18040034
18040034: 00160000
Die Beschreibung des Registers ist: MUX values for GPIO[11:8]., also steht GPIO Pin 11 vorne. Wir zerschnippeln 00160000 byte-weise und schlagen den Wert (Achtung hex!) in Tabelle 3-9 (Achtung dez!) nach.
Ist der Wert 0x00, wird statt Tabelle 3-9 die „Default Function“ verwendet. Diese finden wir ebenfalls in der Beschreibung des Registers.
Wir erhalten:
GPIO8: 0x00 -> SPI_MISO
GPIO9: 0x00 -> UART0_SIN
GPIO10: 0x16 -> UART0_SOUT
GPIO11: 0x00 -> Reserved < --- dazu später mehr
Okay, das bestätigt das komische Verhalten, wenn man an GPIO8 wackelt: Am SPI hängt ja der Flash und wir funken ihm in den Output (MISO) 8)
Der Rest ist Fleissarbeit. Wir wiederholen das Datenblatt-wälzen für alle GPIO_OUT_FUNCTION*-Register.
Außerdem wissen wir die Pins an denen die LEDs und die Buttons hängen aus dem Quelltext (mach-tl-wr841n-v9.c):
#define TL_WR841NV9_GPIO_LED_WLAN 13
...
#define TL_WR841NV9_GPIO_BTN_WIFI 17
Wir können uns noch anschauen ob ein GPIO als Input oder als Output konfiguriert ist. Das verwenden wir als Plausibilitätscheck: LEDs sollten Output und Buttons Input sein.
Wir fragen das Register GPIO Output Enable (GPIO_OE) an Adresse 0x18040000, welches festlegt ob ein GPIO ein Input oder ein Output ist.
Die Beschreibung sagt: zum Registerinhalt: Per bit output enable, where bit [22] sets GPIO22, bit [21] sets GPIO21, bit [20] sets GPIO20, and so on. 0=Output, 1=Input.
root@OpenWrt:~# io -4 0x18040000
18040000: 00021303
Diesen Wert (00021303) zerlegen wir also bit-weise, ich hab das unten mal an als „In,In,Out,Out“ rangeschrieben wenn in der GPIO Gruppe die ersten beiden Pins Input und die letzten beiden Output sind.
Wir mischen alles Zusammen und erhalten:
GPIO Function 0 (GPIO_OUT_FUNCTION0) MUX values for GPIO[3:0]: root@OpenWrt:~# io -4 0x1804002C 1804002c: 00000000 GPIO0: 0x00 -> TCK ? -> Bereits gefunden von Tobias GPIO1: 0x00 -> TDI ? -> Bereits gefunden von Tobias GPIO2: 0x00 -> TDO ? GPIO3: 0x00 -> TMS ? -> TL_WR841NV9_GPIO_LED_QSS Input/Output? GPIO3:0 Out,Out,In,In GPIO Function 1 (GPIO_OUT_FUNCTION1) MUX values for GPIO[7:4]: root@OpenWrt:~# io -4 0x18040030 18040030: 0c080900 GPIO4: 0x00 -> CLK_OBS4 ? -> TL_WR841NV9_GPIO_LED_WAN GPIO5: 0x09 -> SPI_CS_0 GPIO6: 0x08 -> SPI_CLK GPIO7: 0x0c -> SPI_MOSI Input/Output? GPIO7:4 Out,Out,Out,Out GPIO Function 2 (GPIO_OUT_FUNCTION2) MUX values for GPIO[11:8]: # io -4 0x18040034 18040034: 00160000 GPIO8: 0x00 -> SPI_MISO GPIO9: 0x00 -> UART0_SIN GPIO10: 0x16 -> UART0_SOUT GPIO11: 0x00 -> Reserved -> TL_WR841NV9_GPIO_LED_LAN4 Input/Output? GPIO11:8 Out,Out,In,In GPIO Function 3 (GPIO_OUT_FUNCTION3) MUX values for GPIO[15:12]: root@OpenWrt:~# io -4 0x18040038 18040038: 00000000 GPIO12: 0x00 -> Reserved -> TL_WR841NV9_GPIO_BTN_RESET (input) GPIO13: 0x00 -> Reserved -> TL_WR841NV9_GPIO_LED_WLAN GPIO14: 0x00 -> Reserved -> TL_WR841NV9_GPIO_LED_LAN3 GPIO15: 0x00 -> Reserved -> TL_WR841NV9_GPIO_LED_LAN2 Input/Output? GPIO15:12 Out, Out, Out, In GPIO Function 4 (GPIO_OUT_FUNCTION4) MUX values for GPIO[19:16]. <--- sic!! # io -4 0x1804003C 1804003c: 00000100 GPIO16: 0x00 -> Reserved -> TL_WR841NV9_GPIO_LED_LAN1 GPIO17: 0x01 -> SYS_RST_L -> TL_WR841NV9_GPIO_BTN_WIFI (input) Input/Output? GPIO17:16: Out, In
Wir sehen also: Neben den 7 für die LEDs, 2 für die Buttons werden 2 fürs UART, werden 4 fürs SPI verwendet. 2 ex-JTAG die von Tobias gefunden wurden. Macht 17 GPIOs. Der letzte, bisher noch nicht gefundene GPIO ist GPIO2. Dieser sollte so wie GPIO0 und GPIO1 verwendbar sein.
Der Wert für GPIO17 ist mir etwas unklar.
Leider scheint er zumindest auf dem v9er PCB nicht rausgeführt zu sein. Man beachte die Lücke in den Leiterbahnen zwischen C146, C164 und dem SoC. Immerhin liegt er auf einem QFN Pin in der vorderen Reihe (also falls jemand fit mit dem Lötkolben ist … )
Hier noch paar Allgemeine Pitfalls:
Soweit bisher. Vielleicht mag ja jemand mit einer v8, v10 und v11 die GPIO Config mal gegenchecken 
VG
Robert
p.s.: Sorry, dafür das wir jetzt soweit vom eigentlichen Thema (I2C) abgekommen sind
p.p.s.: Man beachte die Benennung von Pad B42 und B49: USB_DP und USB_DM…
Quellen / Ressourcen
Datenblätter gibs hier:
Register auslesen (Beispiel):
Bild der Platine v9:
Vielen Dank für die Detailanalyse.
Mir ist es übrigens völlig egal, ob man evtl. 1-2 LEDs für LAN-Ports verliert für die Umrüstung.
Denn „besondere Firmware“ wird man sowieso backen müssen.
Und dass man zusätzlich in so einem Gerät auch noch mehr als 3 Ethernets braucht und dann auch noch zwingend auf LEDs angewiesen ist: Eher unwahrscheinlich.
Gerne. Mich hat es einfach die Frage gewurmt ob / wie viele freie GPIOs noch gibt
Denke auch das man bspw. auf die LED für LAN3+4 verzichten kann. Falls nicht jemand schneller ist, kann ich die mal bei Gelegenheit in nem OpenWRT CC deaktivieren. Der Patch sollte sich ja dann auch auf ein Community-eigenes Gluon anwenden lassen.
Alternativ würde sich auch ein I2C Portexpander (z.b. PCF8574, Datenblatt s.u.) anbieten, dann müsste man die FW gar nicht anfassen um sich (low speed) GPIOs zu verschaffen. Zusätzlicher Vorteil wäre, dass die Garage bei jedem Boot [Edit] nicht [/Edit] auf und zu geht, wenn die LEDs an gehen. Hehe.
Ich warte noch auf ADC Module (ADS1115) mit I2C aus China. Gibs auch bei ebay, aber ich habe es nicht eilig. Dann wollte ich das Setup von Tobias nachbauen, ohne den AVR Flasher aus der Kiste zu holen.
Durch den Verzicht auf AVR und mit I2C Fertig-Modul(en) und bei Verwendung von GPIO0+1 und I2C ist das denk ich ein leicht nach zubauendes Setup.
Und den Portexpander kann man auch noch an den Bus hängen, das wären dann 16x ADC zum messen + 8x I/O zum Schalten.
VG
Robert
Ressourcen:
Da würde ich die differenz aus zwei LEDs benutzen, abgeblockt mit einem RC. Denn beim Boot gehen die schließlich synchron an (und wieder aus)
