Domme Batterijen - Verkeer(de)informatie

Door Infant op zondag 23 december 2012 17:32 - Reacties (14)
Categorie: Gemod / Gefix, Views: 3.944

Ook deze post gaat weer over notebook accu's(of batterijen, ik haal ze willekeurig door elkaar), en is een vervolg op de eerste en tweede.

Ik heb een frumsel gemaakt om het verkeer tussen notebook en accu te kunnen afluisteren. Ik laat in deze deze post ziet wat je daar zoal mee kan doen.

Links
De alsmaar groeiende lijst van pdfjes:
SMBus v1.1 Specification
Smart Battery Data Specification v1.1
BQ2084 Datasheet
Atmega16U4 Datasheet
Elitebook 2730p Schema (Mediafire)

Boem! Uit
Er zijn op het internet aardig wat mensen te vinden die wel eens een notebook batterij uit elkaar gesloopt hebben.
Wat ze meestal doen is de kapotte cellen vervangen door nieuwe, voor een bedrag van veel minder dan een nieuwe accu, en daarmee hopen ze klaar te zijn.
Ik ben er weinig tegen gekomen die vervolgens weer een zo goed als nieuwe accu hadden. Ze lopen allemaal tegen het probleem aan:
  • Accu doet nog steeds niks.
  • Hij wil niet kalibreren.
  • Bij 50% valt de notebook uit.
  • Capaciteit is wel toegenomen, maar nog steeds niet wat je verwacht.
  • Hij laad niet volledig op.
Op tweakers zijn er misschien wel twee hele topics te vinden waar accu's uit elkaar gehaald worden. Er zijn wel honderden topics te vinden waar mensen een probleem uit bovenstaande lijst melden.

Het fundamentele probleem bestaat uit twee dingen:
1: 'Smart Batteries' zijn dom.
2: De standaard is te vaag.

Deze gast is een van de weinige die ook cellen vervangen heeft, en vervolgens door het moeizame proces van chipjes los solderen en flashen is gegaan.
En bij 'Further observations en rants' verteld hij precies de twee bovengenoemde punten.

Accu informatie wordt door een Host IC uit de accu gehaald, en beland in je BIOS. Zo staat daar bijvoorbeeld in:

State of Charge: Een getal tussen de 0 en 100. Je raad het al. Dat is gewoon het percentage peut wat er nog in je accu zit.
Battery Voltage: De totale spanning van de accu.
Remaining Capacity: De hoeveelheid mAh of mWh die nog in de accu zit.
Full Charge Capacity: Hoeveel er in kan, ook in mAh of mWh.
Design Capacity: Hoeveel er in kon toen hij nieuw was.

Al deze waardes komen uit je batterij wandelen. Ze worden aan de accu gevraagd, en die verteld ze ook keurig netjes terug.
Maar... neem nou bijvoorbeeld State of Charge. Die kunnen we zelf ook wel uitrekenen, namelijk:
(100% / Full Charge Capacity)*Remaining Capacity.

Wear level is een soortgelijk sommetje: (100% / Design Capacity)*Full Charge Capacity.

Gezien al deze waardes bij mij door een ongedocumenteerd chipje, wat achter duizend lagen van NDA's zit verstopt, worden uitgelezen... is het volledig onduidelijk wat er nou precies met deze waardes gebeurt.
En dat is dus probleem 2.

Er is geen standaard die fatsoenlijk zegt wat een OS of een BIOS met accu waardes moet doen. Als de accu zegt: "Yo, volgens mijn teller ben ik leeg...."
Dan zegt het BIOS: "Nou, dan ga ik uit. Doei!"
En boem. Je notebook is uit.

Wat je zou willen, is dat de BIOS wat intelligenter is en het volgende zegt: "Is dat wel zo? Ben je echt leeg? De spanning is nog meer dan voldoende hoor. Ik ga gewoon verder, tot je er mee ophoud."

In plaats daarvan, valt de notebook dus gewoon uit, of wisselt hij naar de tweede accu.

De sniffer die ik in het vorige artikel liet zien, kon deze data onderscheppen. En het eerste probleem waar ik dan tegenaan loop is dat het Host IC, diegene zonder documentatie, compleet willekeurige variabele opvraagt, in een ogenschijnlijk willekeurige volgorde. En ook nog eens heel traag. Waarom!!!!!?

Als we de data die opgevraagd wordt überhaupt uit kunnen lezen, gaat dat ongetwijfeld lelijke dingen op leveren. Dus we moeten voordat we dingen kunnen meten, de informatie die de accu beschikbaar stelt, er direct uit zien te halen.

Om dit de toen, moet de sniffer iets verbouwd worden.

Verkeer
De datasheet van het IC in mijn accu, een BQ2084, heeft op pagina 14 een mooie tabel met alle dingen die je kunt opvragen. Al die functies komen regelrecht uit de Smart Battery Data specification, en het verbaast me dan ook niet dat ze er in zitten.
Dit betekend, dat andere IC's ook aan deze standaard voldoen....

Een accu uit een EliteBook 8540w, met daarin een BQ20Z70 bijvoorbeeld. Met een klein verloop plugje meld ook hij zich netjes aan:
Hier moet nog een verloopje tussen
Hij doet het, maar is wel stuk...
Deze is er ook al na c.a. 280 cycli mee opgehouden. Wat betekend, dat als je elke dag naar college gaat, je accu het een jaartje vol houd, maar voor die tijd al significant minder gaat presteren.

Nu ik het verkeer tussen de notebook en accu heb kunnen afluisteren, weet ik ook welke adressen gebruikt worden. Die heb ik met groen en blauw(ish) aangegeven. Groen zijn dingen die je verwacht, zoals spanning, stroom, temperatuur en dat soort dingen. Blauw zijn de iets fabrikant specifiekere registers.Gemonitord(t)? verkeer uit een BQ2084Tabel komt uit de BQ2084 Datasheet, en staat ook in de Smart Battery Specification

Ik wil dus gewoon een paar van deze variabelen continu opvragen, en in een grafiekje douwen.

Hoi Accu!
Ja, hier word het weer een klein beetje technisch. De Atmega moet namelijk gaan doen alsof hij een laptop is. Dit is niet heel erg ingewikkeld, want het staat best wel goed wel aardig gedocumenteerd. (Dank u wel TI.)

Hoe er data opgevraagd moet worden, staat onder het kopje "Figure 5. SMBus Communication Protocol Without PEC". Er is ook een kopje "With PEC", maar die verschillen verder niet... ik vermoed een foutje?
PEC is een CRC-8 berekening die aan het eind van een bericht toegevoegd wordt.
De sniffer heeft al vast gesteld dat dat niet gebruikt wordt. De datasheet suggereerd dit:
BQ2084 Read Word
Maar eigenlijk is het dus dit:SMBus Read Word without PEC

Voor dit gebabbel kan de hardware TWI van de Atmega ingezet gaan worden. Het vereiste lapje code kan nu in één interrupt, waar de sniffer voor elke pin een aparte interrupt nodig had:

C: Interrupt.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
//Handles SMBus Read Word
ISR(TWI_vect){
    // Save TWI state in an array for debugging.
    smbus_data[chars] = TWDR;
    smbus_reg[chars] = TWSR;
    chars++;
    if (chars == SMBUS_BUFF)
        chars = 0;    
    // State machine:
    if ((TWSR & 0xF8)==0x08){
        //Send adress + R
        TWDR = 0x16;
        TWCR = (1<<TWEN) | (1<<TWINT) | (1<<TWIE); 
    }else if ((TWSR & 0xF8)==0x18){
        // Send Command
        TWDR = smb_cmd;
        TWCR = (1<<TWEN) | (1<<TWINT) | (1<<TWIE);     
    }else if (((TWSR & 0xF8)==0x28)||((TWSR & 0xF8)==0x30)){
        //Send Repeated Start        
        TWCR = (1<<TWEN) | (1<<TWSTA) | (1<<TWINT) | (1<<TWIE); 
    }else if ((TWSR & 0xF8)==0x10){
        // Repeated start Send, Ack REceived. Send Adress + Write        
        TWDR = 0x17;
        TWCR = (1<<TWEN) | (1<<TWINT) | (1<<TWIE); 
    }else if ((TWSR & 0xF8)==0x40){
        // Adres+Write sent, ACK received. Receive Data, return ACK.        
        TWCR = (1<<TWEN) | (1<<TWEA) | (1<<TWINT) | (1<<TWIE); 
    }else if ((TWSR & 0xF8)==0x50){
        // Receive Data, return NACK.
        smb_wrd_lo = TWDR;
        TWCR = (1<<TWEN) | (1<<TWINT) | (1<<TWIE);     
    }else if ((TWSR & 0xF8)==0x58){
        // Done. Send Stop condition    
        smb_wrd_hi = TWDR;        
        TWCR = (1<<TWEN) | (1<<TWSTO) | (1<<TWINT) | (1<<TWIE);         
        smb_done = 1;
    }else{
        TWCR = 0;     
    }
Ja, hier had een switch statement kunnen staan...

En vervolgens moet ik een functie in het leven roepen die ik het commando als argument mee geef, en die functie geeft mij dan de waarde van het register terug: Dus: sendcommand(Voltage) moet als waarde netjes de spanning terug geven:
C: read_word
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
volatile uint16_t read_smbus_word(uint8_t cmd){
    smb_cmd = cmd;
    smb_done = 0;    
    //Send start condition, enable intterupt.
    TWCR = (1<<TWEN) | (1<<TWSTA) | (1<<TWINT) | (1<<TWIE);    
    // For now, wait until the interrup completes and Stop has been sent.
    // If it takes too long, return.
    for (uint16_t i=0;i<0xFFF0;i++){
        if(smb_done){
            if (!(TWCR & (1<<TWSTO)))
                return ((smb_wrd_hi<<8) | smb_wrd_lo);
        }
    }    
    return 0;        
}
While loops zijn evil. Programma's crashen door overmatig gebruik van while loops. Als er na zoveel i++jes geen antwoord komt, gaat het ook nooit komen, en kunnen we beter ophouden.

En als laatste wordt dus de hele mikmak 25 keer per seconde opgevraagd, netjes geformatteerd en over de USB naar de PC geduwd . Dat levert dan bijvoorbeeld het volgende op:

Termite:
1
2
3
4
5
6
7
8
9
10
11
12
13
11433 3801 3815 3817    0     0   0
11433 3801 3815 3817    0     0   0
11433 3801 3815 3817    0     0   0
11433 3801 3815 3817    0     0   0
11433 3801 3815 3817    0     0   0
11433 3801 3815 3817    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
11434 3802 3814 3818    0     0   0
In volgorde: Vtotaal[mV], V3[mV],V2[mV],V1[mV], Current[mA], Capacity[mAh], SOC[%]

En dan kom je al snel tot de conclusie dat het nutteloos is om het 25 keer per seconde op te vragen. Dit chipje update alle waardes maar iets van 1 keer per seconde. Dat noem ik jammer.
Maar, een uur lang iedere seconde een meting, kan nog steeds leuke plaatjes gaan opleveren.

Op de PC hebben we dan een tooltje nodig wat het uitleest en in een bestand prakt, het belangrijkste daarvan ziet er zo uit:

C: Sniff-logger.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
void handle_line(uint8_tlineuint8_t len){    
    sscanf((char*)line,"%u %u %u %u %i %u %u %u",&voltage,&cel3,&cel2,&cel1,&current,&capacity,&soc,&temp);
    system("cls");
    if (dlog)
        printf("Logging...\r\n");
    else
        printf("NOT LOGGING!\r\n");
    printf("Voltage   (mV): %u \r\n",voltage);
    printf("Cell 3    (mV): %u \r\n",cel3);
    printf("Cell 2    (mV): %u \r\n",cel2);
    printf("Cell 1    (mV): %u \r\n",cel1);
    printf("Current   (mA): %i \r\n",current);
    printf("Capacity (mAh): %u \r\n",capacity);
    printf("State O.C. (%%): %u \r\n",soc);
    printf("Temperat. (*C): %2.1f \r\n",(float(temp)-2731.5)/10);
    
    tcurrent = time(NULL);
    tcurrent = tcurrent-tstart;
    printf("Runtime    (s): %u \r\n",tcurrent);

    sprintf(logline,"%u;%u;%u;%u;%u;%i;%u;%u;%u;%u\n",voltage,cel1,cel2,cel3,cel4,current,capacity,soc,temp,tcurrent);
    log_append();
}
Temperatuur wordt in Kelvin uitgepoept en op de PC naar graden C geconverteerd. Verder wordt er een timestamp aan vast geknoopt.

Serial-to-Excel converter v0.000001 pre-AlfaEen positieve current is opladen, negatief is ontladen.

De batterij die ik nu ga testen heb ik van een mede tweaker opgestuurd gekregen. Wat ik ook met deze batterij doe, hij blijft van mening dat er 1mAh in kan. Hij laad wel op, maar omdat hij foutieve informatie aan de notebook doorgeeft, heeft m'n noteboek zoiets van: "Ja, doei! Ik kap er mee. Je zoekt het maar uit!"

Wat we kunnen doen, is het helemaal opladen, en dan helemaal leeg laten lopen door er een halogeen lampje (bij gebrek aan iets beters) aan te hangen.

Dit levert de volgende interessante plotjes op:
Ontladen: Totale Spanning
Ontladen: Stroom

Nou, dit is precies wat je van een accu verwacht, als je je het plaatje herinnert uit de eerste post. En het plaatje hoe het er uit zou zien als je er 2x zoveel stroom uit zo trekken. De stroom is hier niet volledig constant, maar bij benadering wel. Het lijkt er daarom ook sterk op.

Ik heb nu ook voor het eerst iets goeds over deze accu te melden: Hij doet wat hij moet doen, namelijk stroom leveren, en uit gaan als hij te diep ontladen wordt. Dit doet hij op basis van de cel spanningen, en dat laat het volgende grafiekje mooi zien:

http://tweakers.net/ext/f/nQgM5SIfQLbyFT9d0Czp2HT4/full.png

Dit pack is uit balans. Dat wil zeggen dat een van de cellen niet zoveel capaciteit meer heeft als de rest, en daarom eerder leeg is. Idealiter gezien, is het aan de lader om deze te gaan balanceren. Dit kan door of alleen energie in de lege cel te stoppen, of door de twee volle leeg te laten lopen. (Dit laatste is meestal het geval.)

De chip in deze accu kan volgens het datasheet wel balanceren, maar het wordt gewoon niet gedaan. Lekker puh!

Wat verder opvalt is dat een kwartier nadat hij uit is gegaan, de spanning weer stijgt naar een waarde die lijkt te suggereren dat hij weer vol is. Omdat deze cellen toch echt wel een beetje versleten zijn (Ze waren normaal 4800mAh, en nu nog maar iets van 1600mAh).

Dit laatste grafiekje is voor geen mogelijkheid te maken op je PC. Er is geen enkel programma behalve de HP Tool die de individuele cel spanningen tevoorschijn kan toveren.

Verder wordt door mijn notebook alleen de stroom en spanning eens per 2 seconden ofzo opgevraagd. De rest van de dingen die je wilt weten, Idunno... ehm... capacity?, worden op compleet willekeurige tijdstippen met soms wel een minuut of langer er tussen, opgevraagd.

Daarom, als je dit ding aan de notebook hangt, produceert dat stront. Kijk maar eens wat een puinhoop alle Windows tools uitspugen. Er heerst totale anarchie!
Data Bonanza

Windows is van mening dat de batterij (#2) 100% vol is. (It clearly isn't...) Bij BatteryMon past het percentage niet eens in het venstertje... zo veel volheid is er.

Maar de State of Charge in de accu, hoewel niet super lineair, zegt wel netjes in het begin dat hij vol is, en aan het einde dat hij leeg is. Kijk maar:

Ontladen: State of Charge

Het percentage vol wat Windows aangeeft, wordt dus berekend aan de hand van de Remaining Capacity. Dit is in het geval van twee accu's te begrijpen namelijk:

(RemCharge1 + RemCharge2) / (FullCharge1+FullCharge2)*100%

Als het groter dan 100% wordt, maakt ie er netjes 100% van. Want in dit geval wordt het sommetje:

(3189+512)/(3355+1) *100% = 110%.

Na wat meer rond ge-analyseer kom je erachter dat de tijd die nog resterend is, niet berekend wordt als:

(RemainingCarge1 + RemainingCharge2) / AverageCurrent

Wat op zich best logisch zou zijn. Als je uit de eenheid mAh, wat dus stroom*uur is, de stroom weer weg deelt, houd je namelijk een tijd over. De resterende accu tijd.

Nee, in plaats daarvan wordt er naar de (berekende) State of Charge gekeken. En als die veranderd, wordt aan de hand van de afname, en hoe lang het duurde voordat die afname plaatsvond, een voorspelling gedaan.
Gezien de SMBus host hier op compleet willekeurige tijdstippen de Remaining Capacity opvraagd, met soms wel tien minuten ertussen, duurt het moeilijk lang voordat Windows een idee heeft hoelang de accu nog mee gaat, is de voorspelling nogal slecht, en krijgen alle tools die plotjes van de batterij maken van die mooie hoekjes er in:
Poehee, wat een soepel lijntje. Keurig.

Terwijl het met een data-ruiker, ook zo kan:
Opladen: Remaining CapacityGrafiek van de accu die door de lamp was leeg gezogen, weer aan de lader met data-snuiver er tussen.

Ja, leuk. En nu?
Nu... zou ik eigenlijk de dooie accu ervan willen gaan overtuigen dat hij een capaciteit van 1600mAh heeft, gezien de lamp-test zegt dat dat er uit aan totale energie uit komt rollen .

Het probleem is, als je in het gekleurde tabelletje aan het begin weer bekijkt, dat de acces voor RemainingCapacity op read staat. Wij kunnen de waarde dus niet zomaar aanpassen.

Kan het wel minder zomaar? In theorie: Ja.

De documentatie zegt bij het kopje Manufacturer Access(0x00) allemaal oninteressante dingen, behalve deze twee: SHIP Command en Seal command. En de description achter het Seal Command luid:
"Instructs the BQ2084 to restrict access to those functions listed in Table3. It completes the Seal function and clears the Manufacturer Access."

Als ik de Pack Status and Pack Configuration (0x2f) opvraag, staat de SS bit op 1. En dat betekend dat deze accu gesealed is.

Nu kan ik een uur lang gaan vertellen wat er toen gebeurde, maar de SFW-versie komt er in het kort op neer dat ik heel Google dood ge-queried heb met zoektermen als Unseal BQ2084, HP battery key, hp unseal, remove seal... etc etc. Er zijn te veel Aziatische, Poolse, Tsjechse websites voorbij gekomen. Allemaal levert het niks op. (De NSFW-versie bevat veel gevloek en dood ge-wens...)

Uiteindelijk kom je erachter dat er een default key bestaat, die vond ik op het TI forum. Iedereen die op dat forum om de default key vraagt (myself included) krijgt binnen een uur een persoonlijk bericht van een TI medewerker met de key, maar hij wordt niet op het forum geplaatst.... dubieus.

Verder is er geen enkel document van TI dat suggereert waar je die key precies naar weg moet schrijven, en al helemaal niet hoe. Er is alleen een document wat met de Evaluation Software van TI werkt, en die zegt: druk op Unseal, doe de key in box 1, doe de andere key in box 2... en tadaa!

Met veel pijn en moeite ben ik er dus achter gekomen dat de default key (*kuch* 0x2084 en 0x7A43 *kuch*) achter elkaar naar register 0 weg geschreven moeten worden, en dat zou dan de magic moeten doen. Het is me door een TI medewerker bevestigd.

Nou heb ik uiteraard alle combinaties hiervan geprobeerd, maar geen eentje deed iets. Ik heb dus het donkere vermoeden dat HP de code veranderd heeft. (Dat kan namelijk.)

En helaas zou een brute-force scriptje, bij 32 bits met iets van 100 keys/seconde er maximaal anderhalf jaar ofzo over doen.... En eigenlijk weet ik niet zeker of je er wel zo snel zoveel keys naartoe kunt smijten. (Ik heb het een uurtje laten draaien, en hij is niet stukker gegaan...)

Kortom, met een kans op falen van meer dan 0% en een looptijd van meer dan een jaar, heb ik daar niet zo'n zin in. Maar mocht je iemand kennen met een Raspberry-PI, Arduino o.i.d. en een stuk of 100 HP accu's ... ben ik wel te porren.

Samenvattend
It's all useless.

De standaard is op zijn best gezegd okee, maar hoe HP, en Windows hem vervolgens toe past is jammer.
Ik heb plotjes die echt de meest ranzige laad stroom laten zien die je een Li-Ion kunt toe wensen.
Er wordt niet gebalanceerd.
De nuttige beschikbare informatie die de accu bevat, wordt niet uitgelezen, of gewoon genegeerd.
De informatie die beschikbaar is, beland in een half-gedocumenteerde vage Windows API, waar vervolgens elk programma een waarde uit zuigt, door een staafmixer van onsamenhangende formules heen haalt, en in een scherm deponeert, wat dan zegt: "Dit is hoe het ermee staat."

De notebook besluit zelf wanneer de accu leeg is, terwijl de accu dit veel beter weet.
De belangrijkste logica zit achter een muur van NDA's, terwijl de accu zelf ook beveiligd is. Als hij dus (by design) voorbarig stuk gaat, kun je er nauwelijks iets aan doen.
Cellen vervangen heeft maar zoveel zin, gezien het onmogelijk is om de accu fatsoenlijk te kalibreren zonder er halogeen lampen aan te bengelen.

Maar, dat is allemaal mijn mening.

Gelukkig is het niet afgelopen, want ik heb op het gebied van communicatie één ding nog niet gedaan......

Volgende: Domme Batterijen - Spoof 12-'12 Domme Batterijen - Spoof
Volgende: Domme Batterijen - Accupologie 12-'12 Domme Batterijen - Accupologie

Reacties


Door Tweakers user Gtoniser, zondag 23 december 2012 18:18

Kan er weinig anders over zeggen dan dat ik dit onderzoekje echt geweldig vind :)
Kijk al uit naar het volgende deel!

Door Tweakers user Bjornski, zondag 23 december 2012 21:14

Allereerst; machtig interessant dit! KUTGW!

Niet gehinderd door enige kennis van wat er in de datasheet staat; Gezien hoe ver je nu bent, zou het imho niet meer zo moeilijk moeten zijn om een nieuwe, niet gelockte BQ2084 op die print te solderen en die een setje nieuwe cellen te laten calibreren? Goed, die IC kost 12 euro en het enige wat je dan overhoudt van de originele accu is de behuizing, maar het is (qua onderdelen) nog altijd goedkoper dan een nieuwe accu.
Bovendien moet je hem dan zelfs nog zo ver kunnen porren dat hij de verschillende cellen ook netjes balanceerd.

Of zie ik dat nou verkeerd?

Door Tweakers user Infant, zondag 23 december 2012 21:31

Nee, dat zie je allemaal, helemaal 100% goed.

Het was natuurlijk leuker geweest om hem te vertellen dat hij moet resetten, i.p.v. hem open breken. Ik krijg deze na open slopen niet echt meer netjes dicht.

Plus, het lost niet het onderliggende probleem op dat dit IC, wat 12 Euro kost, na een tijdje completely haywire gaat en capaciteiten tussen 1 en 65000 uit poept.

Door Tweakers user AcPower, maandag 24 december 2012 02:56

10/10 tweakblog! mijn complimenten!

Door Tweakers user Xessive, maandag 24 december 2012 08:43

Super post dit, het eerste deel was al interessant maar dit maakt het wel leuker.

Ik snap alleen 1 ding niet; een batterij calibreren door er een halogeenlamp aan te hangen? m.a.w. je trekt allebei de cellen helemaal leeg zodat ze beiden 'even leeg' zijn ?

Door Tweakers user Zerfox, maandag 24 december 2012 10:22

Bestaat er iets zoals Tweakblog of the year? Ik zou deze graag willen nomineren! :D

Door Tweakers user Infant, maandag 24 december 2012 11:49

Xessive schreef op maandag 24 december 2012 @ 08:43:
Ik snap alleen 1 ding niet; een batterij calibreren door er een halogeenlamp aan te hangen? m.a.w. je trekt allebei de cellen helemaal leeg zodat ze beiden 'even leeg' zijn ?
Het had achteraf gezien ook gewoon met de notebook gekund, maar ik kon niet netjes alle informatie uit de accu opvragen terwijl ook de notebook er aan hing.

Door Tweakers user Petervanakelyen, maandag 24 december 2012 13:19

Absoluut tweaker-waardige tweakblog, ik weet echt helemaal niets over accu's. :)

Door Tweakers user damouzer, maandag 24 december 2012 14:17

Heb je ook nog een idee waarom de fabrikanten het zo doen? Is het onkunde? Volgens is het zo dat de laatste tijd men toch probeert om een product zolang mogelijk op een accu lading te laten werken, dan concurrent x (mobieltjes/tablets).

Door Tweakers user biomass, maandag 24 december 2012 14:48

damouzer schreef op maandag 24 december 2012 @ 14:17:
Heb je ook nog een idee waarom de fabrikanten het zo doen? Is het onkunde? Volgens is het zo dat de laatste tijd men toch probeert om een product zolang mogelijk op een accu lading te laten werken, dan concurrent x (mobieltjes/tablets).
Je hoeft niet heel cynisch te worden om te denken dat hier het verkoopmodel van verbruiksmiddelen van printers(inkjetpatronen) op batterijen wordt toegepast? Waarom balanceren als je nieuwe accu's kunt verkopen?

Door Tweakers user damouzer, maandag 24 december 2012 19:19

biomass schreef op maandag 24 december 2012 @ 14:48:
[...]
Je hoeft niet heel cynisch te worden om te denken dat hier het verkoopmodel van verbruiksmiddelen van printers(inkjetpatronen) op batterijen wordt toegepast? Waarom balanceren als je nieuwe accu's kunt verkopen?
Het vergelijk met een inktcartridge had ik nog niet gemaakt. Goed punt.

Door Tweakers user Arokh, maandag 24 december 2012 23:33

En wat als je nou een Chinese Harry Warry laptop koopt. Zouden die dingen gelockter zijn of juist helemaal open omdat het duurder is om zelf aan te klooien terwijl je een standaard kunt gebruiken...

En een bedrijf als Apple? Daar kun je tegenwoordig de accu's niet meer vervangen. Zouden die dingen ingericht zijn op een langer gebruik? Beter gebalanceerd? Daar gaat wellicht het inktpatroonverhaal niet op dan...

Door Tweakers user Infant, maandag 24 december 2012 23:45

Bij de nieuwe lading HP's die ze op de TU uitdelen, zit volgens mij weer 3 jaar garantie op toestellen, en bij het duurdere model 3 jaar op de accu...

Ik zou er graag eens eentje in iedergeval aan de grafiek-o-matic hangen, om te kijken hoe ze die drie jaar gaan halen.

Het probleem met Chinese rommel is dat als de accu het al een jaar uithoud, de hardware meestal voor die tijd uit elkaar dondert.... dus dat vind ik minder interessant.

Apple accu's heb ik een artikeltje over gevonden. Daar zit uiteraard ook een BQ20 nogwattes chippie in.

Door Tweakers user - peter -, woensdag 10 april 2013 02:28

Mooie posts hier ook in je oudere artikelen.

T is misschien grappig om te melden dat ik dit type op een macbook early 2008 met een accu die t nog steeds doet: 740(!) cycli (en dat is berekend als zijnde een complete discharge). En nu nog op 70% capacity.

Officieel is ie bij 300 cycli al opgegeven door Apple en moet je een nieuwe halen. Tsja.

[Reactie gewijzigd op woensdag 10 april 2013 02:28]


Reageren is niet meer mogelijk