Alles moet draaien

Door Infant op zondag 07 september 2014 19:21 - Reacties (10)
Categorie: Gemod / Gefix, Views: 3.276

Dit is een vervolg op:
Dooie Fiets
Banana?
Bananen Taal
Cyclic Banana Checks
En je zit nu hier: Alles moet draaien
Volgende deel

Boe!

Om het wrak dat heet mijn fiets in ieder geval van verlichting te voorzien, had ik een ruime tijd geleden al bedacht dat het wel lollig zou zijn als ik dat op zijn minst iets kon doen met die roterende bonk koper in mijn achterwiel, gezien het op dat moment niet zo veel deed.

Mijn ervaring met fietslampjes is dat ze altijd stuk zijn of slecht contact maken. Of het blijkt dat een of andere onverlaat de draadjes heeft gejat. Of je dynamo zit vol met zand/sneeuw/blaadjes of andere NS-smoesjes, waardoor het allemaal niet werkt.

Een motor die werkt als dynamo daarentegen, werkt tot nu toe vrij geweldig. Ik heb dat ding al meer dan een jaar als dynamo laten werken, en hij doet het nog steeds. En dat is lang, voor mijn doen. (Ik hou o.a. erg van trappetjes op en af rijden..)

Normaliter is een dynamo iets van 6V. Deze niet. Om de 0 tot veel volt die hier uit komt vliegen tot iets zinnig om te zetten, heb ik daar voor zo'n Chinees doosje voor van eBay gesloopt, en op een heel andere manier toegepast dan normaal. Hij zat zonder accu aan gesloten. Dan maakt hij zelf c.a. 27V als je eerst voldoende snelheid maakt, en op die 27V konden dan weer mooi 2 Chinese 12V led lampen branden.

Dat werkt op zich vrij aardig, maar heeft ook een aantal nadelen:
- De verlichting staat nu altijd aan, ook overdag.
- Er komt een irritant hoge pieptoon uit mijn frame, als ik mijn hoofd 2 centimeter beweeg.

Nou valt dat allemaal nog wel op te lossen. Deze Nederlander is ook met deze controllers bezig geweest: http://www.avdweb.nl/sola...u63-motor-controller.html

En deze meneer heeft een vrij leesbare en gedetailleerde verzameling foto's, schema's en feiten op een rij gezet, zodat je in theorie niet eerst 32 Euro aan kapitaal hoeft te verbranden om te weten wat je in huis gaat halen.

Hij heeft er een zogenaamd legislation-device in gemaakt, wat inhoud dat het doet wat het volgens de wet moet doen: mee trappen. En dat heeft heeft hij prachtig weg gewerkt:

Het werkt toch?

Ineens is het duidelijk waarom er voor een n aderig communicatie protocol is gekozen: Het maakt het leven van degene die alles in en uit elkaar moet halen een stuk eenvoudiger en vereist zo veel minder mechanisch geneuzel. (Als ik ergens moe van wordt, dan is het wel mechanisch geneuzel.)

Als ik bij deze fiets de motor los wil maken, haal ik de moertjes los. Doe ik "Plop", en voila. De motor is los.

Het is alleen zo jammer dat het vervolgens never nooit meer gaat werken omdat de dealer er eerst wat software-voodoo op los moet laten omdat Infant er weer zo nodig met zijn nieuwsgierige jatten aan moest zitten.

En dat Chineese ding gaat natuurlijk never nooit met het lollige ronde display werken waar ik jullie de afgelopen tijd mee verveeld heb. Kortom:

Tijd om zelf een motor controller in elkaar te zetten:

Hoe moet dat?
Als je zelf iets gaat maken, helpt het altijd om te kijken of niet iemand anders het stiekem ook gedaan heeft. Motoren aansturen is niets nieuws, en er bestaat dan ook een Open source motor controller.

Hier zit een STM microcontroller op die alle aanstuur logica doet.

In de orginele Sparta en Batavus motoren die ik heb, zit een Motorola chip. En voor specifiek die chip, is ook een application note beschikbaar.

Ze zijn echter nergens echt te koop, en al waren ze dat wel: ik heb er toch geen programmeer spul voor liggen, of zin om er aan te beginnen.

Ik ga deze met een ATxmega opbouwen.

Op wat merk component keuze na, zitten al deze controllers verder stiekem hetzelfde in elkaar. (Ze moeten ook hetzelfde doen... dus dat is niet heel vreemd.)

De motor die deze elektronica moet aansturen is een zogenaamde Brushless DC Motor. Het is eigenlijk een soort combinatie tussen brushed DC, een stappen motor en een 3-fase AC motor.

Een brushed DC motor gebruikt kool borstels om de stroom richting door de spoelen om te draaien, hier moet de elektronica dat gaan doen. Dit scheelt ons een setje koolborstels.

Het heeft net als een DC motor magneten in het rond draaiende deel zitten (de rotor).
Het heeft drie aansluit draden. Net als de 3-fase draden uit een 3-fase AC motor.

En het heeft 8 pool paren, wat inhoud dat als de drie fases een rondje gedraaid hebben, de motor maar 1/8e rondje gemaakt heeft. (Dat is een beetje stappen motor-achtig.)

Het duidelijkste plaatje wat ik heb kunnen vinden...
Zes mogelijkheden.


...laat zien dat er 6 verschillende mogelijkheden zijn waarin de stroom kan rond lopen. Als de controller dit fout doet, gebeurt er of niks, of de motor blijft vast zitten, of hij draait de verkeerde kant op.

Om het gemakkelijker goed te laten gaan, zitten er drie hall sensoren in deze motor. Deze geven aan in welke positie de magneten staan, zodat je weet welke van de 6 mogelijkheden je moet kiezen om de motor vooruit of achteruit te laten draaien.

Niet zo muizen. Dat kietelt.

De back-EMF van deze motoren heeft een trapezoide vorm, i.p.v. een sinusode.


Hall sensoren komen in veel verschillende smaken. Degene die hier in zitten zijn zogenaamde open-drain types. Dat wil zeggen dat je hun uitgang d.m.v. een pull-up op 5V moet zetten, die laten ze met rust als het signaal hoog is, en trekken ze omlaag als het signaal laag is.

De Chinese motor controller gaat van precies het omgekeerde uit (hij trekt ze zelf omlaag) en ziet als je ze direct aansluit geen sensoren.Hij kan vervolgens wel de motor laten draaien door naar de back-EMF te kijken, maar vooral bij lage snelheid loopt dit niet zo lekker.

Het belangrijkste ding wat al dit stroom-omdraai werk gaat verrichten zijn 6 mosfets gerangschikt in 3 halve bruggen:

http://prinsprojects.nl/dprins/tweakers/banaan/three_phase_inverter.png


Een synchrone buck DC-DC converter gebruikt ook een halve brug, om van een hoge ingangsspanning een lagere uitgangsspanning te maken. Hier gebeurt per fase hetzelfde. Bij een laag toerental krijg je minder spanning over een winding dan de accu spanning, hoe hoger het toerental hoe meer spanning je nodig hebt om vooruit te blijven gaan.

Een buck converter kan ook van de uitgang naar de ingang werken (door alleen maar de manier van schakelen te veranderen), en de lagere spanning van de motor terug de accu in persen. De motor gaat dan tegen werken, en als je verder niks doet, rem je dus af.

Het is verder de taak van de microcontroller te zorgen dat er niks spontaan in de fik vliegt. Als je bijv. accu en een snel rond draaiende motor hebt, en je denkt: "Kom, laat ik eens heel hard gaan afremmen." kan de stroom die het remmen oplevert nergens heen. Het gevolg is dat de spanning door het dak schiet en het gros van de componenten sloopt.

Dit brengt mij tot de twee belangrijkste eisen van het eerste prototype, namelijk:

1: Het moet de motor kunnen laten draaien en vooral ook weer afremmen.
2: Het moet niet stuk gaan, ook al trek ik halverwege het testen accu's en kabels los.

Vervolgens moet het natuurlijk (niet per-s in volgorde):
3: Met een rem en een gas hendel kunnen werken. (Met zo'n mumsel bijvoorbeeld.)
4: Moet met het display kunnen babbelen.
5: Moet in het wiel passen en trap ondersteuning kunnen doen.
6: Moet knetter hard kunnen gaan tot er dingen gaan smeulen.

De hardware
De orginele motor controller in deze motor, bestaat uit twee losse printjes.

Op de power-print zit de aansluiting die het wiel uit gaat.
De 6 mosfets + gate driver.
Een 12V regelaar voor de gate driver.
Een stroom meet ding + weerstanden.

De andere bevat de microcontroller, die voor elke 6 mosfets een PWM signaal produceert, die gaan door een kabeltje heen.

De andere kabel komt de accu spanning op binnen, gaat 5V voor vermoedelijk de stoom meting naar buiten.

Ik heb i.p.v. een enkele driver, 3 losse drivers: IRS2001.
En verder heb ik alles gewoon op n printje geplempt, zodat het makkelijker te testen is. Vervolgens is het zo snel en goedkoop mogelijk bij een chinees besteld:

Beetje vol...


Een weekje later was PCBtje binnen, en zat het in elkaar:

Beetje vol...


Om het testen makkelijk te maken, heb ik de hall sensoren (5 draadjes) plus de 3 fase draden naar buiten gehaald, zodat de motor verder dicht kan blijven, ook als ik de inbouw versie ga testen. Hiervoor heb ik een los wiel, uiteraard defect, van marktplaats getrokken. Een accu boor zonder accu uit het afval gehaald, de accu inhoud uit de de banaan aan de boor geknoopt, alles met als doel mij het gevoel te geven dat de fiets zich zelf kan kannibaliseren:

Moehahaha!


Met als resultaat:

Floep!


Vervolgens is wat programmeer werk en uitzoeken welk draad in nou waar aan vast gemaakt heb, maar na een tijdje deed het in ieder geval wat:

https://www.youtube.com/watch?v=_d-LPEhaNIY

En in het volgende filmpje: https://www.youtube.com/watch?v=T1ocqZR6tVY heb ik de hall sensoren aangesloten, en kan de snelheid vooruit/achteruit via een console venstertje ingesteld worden.

Als mensen het interessant vinden om het schema en de code in detail besproken te hebben, laat maar weten... dan doe ik dat.

Er komen de volgende keer(en) zowiezo wat horror pics van hoe de eerste test sessie is afgelopen, hoe de nieuwe testopstelling er uit ziet, en waar dit alles uiteindelijk heen gaat.

Cyclic Banana Checks

Door Infant op woensdag 30 juli 2014 18:15 - Reacties (14)
Categorie: Gepruts, Views: 2.114

Dit is een vervolg op:
Dooie Fiets
Banana?
Bananen Taal

Het gaat zeker helpen om die een beetje door te lezen, anders heb je geen flauw idee waar dit over gaat.
Mijn titel-verzin-o-matic kwam na afloop met deze zeer gepaste titel: Cyclic Banana Checks.
Dit gaat waarschijnlijk ook de meest on-duidelijk post tot nu toe worden, maar ja... het dient voornamelijk ter documentatie.

*Kuch pas op spel fouten kuch*

De vorige post hield op met de cliffhanger dat er wellicht nu een kookwekker van de ronde Batavus display gemaakt kan worden. Dat gaan we natuurlijk niet doen, om meerde redenen:

1: Ik hoef geen kookwekker.
2: Hij piept / vibreert niet, wat een must is voor een degelijke kookwekkert. (geen typo)

En als derde punt: Mijn PC is c.a. 50W aan vermogen aan het verstoken, om er data naartoe te slingeren. 50W zou je, mits hij het aan kan, toch nog 3 minuten lang uit een AA batterij kunnen halen.
(En als hetgene wat je aan het kook-wekkeren bent bijv. een zacht gekookt ei moet worden, kan die 50W voor ei-verwarming gebruikt worden.)

Dat is allemaal vrij aardig, maar zo gezegd sub-optimaal.

Hoe kan het optimaler?

Het probleem is nu, dat we wel berichtjes naar het display kunnen sturen, maar we moeten steeds de checksum aan het einde gokken. Omdat de communicatie ook nog eens moeilijk traag is, staat de PC daar eigenlijk 99% van de tijd op te wachten.

Om de volgende onorthodoxe en enigszins lompe manier van aanpak te volgen, is het handig dat je een soort van een idee hebt hoe een crc ongeveer werkt. In plaats van de Wiki, kan ik deze aanraden:
A Painless Gguide To CRC Error Detection

Op zich hoef je helemaal niet te weten hoe een crc precies werkt om ze te kunnen gebruiken. Er staan namelijk talloze voorbeelden online, die al in software verwerkt zitten.Pak bijv deze 8-bit CRC uit een of andere linux kernel module:
http://lxr.free-electrons.com/source/lib/crc8.c

Of deze bijv. bijv uit chromium:

De laatste gebruikt een tabel waarmee de CRC berekeningen gedaan worden, de eerste niet.
Met een tabel-loze functie, zou je zo'n tabel kunnen generen. Dat is wat reken intensiever. Maar daarna kun je de snelle tabel-functie kunt gebruiken, met als nadeel dat die wat meer geheugen gebruikt, en maar een vaste CRC variatie kan implementeren.

Een andere eigenschap van een CRC functie kan zijn dat je hem in een of meerdere stappen kan uitvoeren:

C:
1
2
3
4
5
6
7
8
9
10
11
12
13
//Any CRC8 function interface:
uint8_t crc8(uint8_tdata,uint8_t lenuint8_t crc);

//Data
uint8_t data[4] = {1,2,3,4};
uint8_t crc;

//In one go:
crc = crc8(&data[0],4,0x00);

//Same result, in two goes:
crc = crc8(&data[0],2,0x00);
crc = crc8(&data[2],2,crc);

Hierboven een stukje voorbeeld code:
Als eerste een definitie naar een willekeurige crc8 functie. Deze functie geeft als output een crc getal. Als input moet je hem een stuk data geven, en de lengte waarover de crc berekend moet worden.

Ik zou de functie in twee stappen kunnen aanroepen, of in een enkele keer. Als ik het in twee stappen doe, geeft ik de crc die de eerste stap oplevert mee als argument aan de tweede. In beide gevallen is het argument in de eerste stap 0x00, en het eindresultaat hetzelfde.

Je zou dit in zoveel stappen kunnen doen als je zelf wilt. In de code uit de eerste link is dat het makkelijkst te zien:

C:
1
2
3
while (nbytes-- > 0)
    crc = table[(crc ^ *pdata++) & 0xff]; 
return crc;


Als kan deze loop halverwege afbreken, en in een nieuwe verder gaan met dezelfde crc.

Stel dat we zo'n functie, waarvan we de details nog niet precies weten, op de volgende display data willen los laten:

10 C1 29 26 03 0c c0 00 c0 00 f0 13 37 68

Dit gaat overigens 1337 op het display zetten:
Pakketje!


Het probleem is dat ik niet weet waar de crc precies over berekend wordt. Het kan over alles zijn, het kan dat bijv de eerste waarde C1 een samenvoeging van 0xC0 en 0x01, en dat daar een CRC over gedaan wordt. Maar het wordt in ieder geval over de data gedaan, en die staat aan het einde.

Dus ik dacht: Als ik nou een tabel maak, waarin ik voor verschillende getallen aan het einde van de data, de correcte CRCs opsla, dan kan ik in ieder geval later op mijn gemak een crc functie gaan zoeken die diezelfde output produceert, zonder dat ik deze hele opstelling mee hoef te nemen.

Nou, zo gezegd, zo gedaan. Dat levert dus weer een klein programmatie op. Dat heeft iets van drie kwartier getallen naar het display geschoten, en leverde toen de volgende tabel op:

code:
1
2
3
Data from 01
5F CE 3E AF 9D 0C FC 6D 98 09 F9 68 5A CB 3B AA 
.....


De data aan het einde van het display commando was dus 0x01 0x00 en levert in dit geval CRC 0x5F op (Eerste waarde in de tabel.
0x01 0x01 leverde CRC 0xCE op, etc.

Maar er is een probleem: 0xFF komt 4 keer voor, en dat zou niet moeten. (Alles hoort in een crc tabel maar 1 keer voor te komen).

Dat zou een aantal dingen kunnen betekenen:
1: Dat er drie getallen zijn die nooit geaccepteerd worden door het display.
2: Ik heb iets fout heb gedaan.
3: Er wordt een brakke/rare crc gebruikt.

2 lijkt me het meest voor de hand liggende. Om het iets zekerder te weten, besloot ik om er ook maar bij te loggen of het antwoord terug ontvangen ook gelukt is ja of nee, en laat dat een nachtje draaien.

De volgende dag had ik een berg met prachtige tabbelen, behalve 1tje.

code:
1
2
3
4
5
Data from 10
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
....
Succes table:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


Moment dat ik ergens in mijn fop-data een 0x10 stop, faalt het en is het bericht nooit goed.

Nou... dat zou op zich kunnen, en zou betekenen dat je het nooit kan zien als je exact 10 km/h fietst. Maar hij zou dan ook nooit kunnen weergeven dat je 10km hebt afgelegd.... niet erg waarschijnlijk.

Het bericht begint ook altijd met 0x10... dat is vast geen toeval. Grote kans dat er iets van escaping wordt toegepast.

Zucht, dat kan natuurlijk ook op 100 verschillende manieren, maar ik dacht, ik probeer het door achter elke 0x10 in de data gewoon nog een 0x10 te vrotten.

...en dat werkte in n keer! Feest!

En nu?
Het volgende programmatje heb ik gewoon een hele berg crc functies in gepropt, en die gaat dan domweg wat eigenschappen naar de crc functie slingeren, en een tabbelletje bijhouden, net zolang tot die overeen komt met de hiervoor ge-log-te tabellen. (Ge-logde? het krijgt allebij geen rode streepies!)

Zo ziet het dat er uit.?!

De init waarde is het argument wat aan de crc functie mee gegeven word. Omdat de tabellen die ik zojuist gemaakt heb halverwege de data begonnen, weet ik niet wat de vorige crc waarde was, dus daar probeert deze gewoon alle combinaties van.

Een crc wil ook nog wel een een xor operatie aan het einde doen, en ten slotten kunnen de operaties in de functie in LSB of MSB volgorde met een verschillend aantal polynomen gedaan worden.

Dit programma probeert gewoon alles, en dat zou best wel eens even kunnen duren.

Bij de tweede crc functie die hij ging proberen, kwam er na een aantal minuten al het volgende te staan:
Pakketje!

253 matches! Dat betekent gewoon dat hij het heeft gevonden!

De persoon die dit protocol verzonnen heeft heeft er vast met opzet 0x42 als magisch polynoom in gestopt. Ik weet het zeker.

Nu de gebruikte crc functie bekend is, is de laatste stap uitvinden over wat de crc berekend wordt. Dat was ook een vrij kort stukje code.

Ik nam dan twee willekeurige berichtjes die gelogd waren. Als je nu de crc functie het correcte startgetal en startpositie mee geeft, en over het hele bericht inclusief de crc laat heen lopen, zouden beide het zelfde getal moeten op leveren. Dat is ook een handige eigenschap van een crc functie.

Dat was in no time gevonden: Het start getal is 0x07.

De uiteindelijk crc-code is een aanpassing op code die hier vandaan komt:

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
/*
    CRC-8 for Sparta ION bus communication.
*/

uint8_t crc8_bowuint8_t *data_inuint8_t lenuint8_t init){
    uint8_t crc;
    uint8_t i,j,f;    
    uint8_t data;
    crc = init;
    for (j = 0j != lenj++){
        data = data_in[j];        
        for(i = 8ii--) {
            f = ((crc ^ data) & 0x01);
            if (f == 0x01){
                crc = crc ^ 0x42;
            }
            crc = (crc >> 1) & 0x7F;
            if (f == 0x01){
                crc = crc | 0x80;
            }
            data = data >> 1;
        }
    }    
    return crc;
}

En je dient hem als volgt aan te roepen:

C:
1
2
//Do a CRC check:
uint8_t crc = crc8_bow(data,len,0x07);

Het lollige is nu dat ik zo snel als het display het aan kan er berichtjes naar toe kan schieten.
(Hij haperde hier af en toe nog omdat ik 0x10 nog niet escapde.)
Youtube

Niet alleen dat, ik kan nu het verkeer fatsoenlijk in kaart gaan brengen. Van elk bericht kan ik verifiren of de CRC okee is, en nog belangrijker: Ik kan zelf berichten samen stellen, en kijken of daar een antwoord op komt.

Nou, hier kwam een bedroevend lage hoeveelheid elektronica en mechanisch geneuzel aan te pas, namelijk niks. Dat zal ik volgende keer goed maken.

Bananen taal

Door Infant op zaterdag 14 juni 2014 18:44 - Reacties (29)
Categorie: Gepruts, Views: 5.239

Dit is in vervolg op de vorige post: Banana? en degene daarvoor Dooie Fiets

Deze post zal spelfouten, semi-technisch gebrabbel en eindeloze ritsen aan compleet nutteloze data bevatten. Als je daar allemaal geen zin in hebt, zou ik vooral niet verder lezen.

Ik was zover dat ik een accu en display op elkaar aansloot, en hij spontaan beeld gaf. Geweldig.
De eerst volgende stap was om er een scope aan te hangen, om een idee te krijgen wat er zo ongeveer gebeurt.

Snuf snuf
Er komen 3 draadjes uit het display zetten, de accu zet daar 5V, 24V en GND op.

De 24V lijn zou de data bus moeten voor stellen, dus dat is het eerste waar de scope wat aan mag ruiken.
Er komt gigantisch veel verkeer voorbij. Er zit wel wat structuur in, bijvoorbeeld:

Elke overgang van geen data, naar wel data, begint met het karakter 0x10.

Pakketje!


Uit de vorige post:
De Atmega die nog met 4V aan staat, geeft op de TX pin inderdaad signaal uit:
10 04 20 CC en af en toe 10 C1 21 22 80 5F.


Mooi. Het is nu toch wel 99% zeker, dat het standaard seriele communicatie is. Deze scope kan dat ook decoderen, maar om dat vervolgens allemaal met de hand te gaan zitten over krijten... daar heb ik niet zo'n zin in. Dat moet gemakkelijker kunnen.

Het eerste geschikte object wat ik op mijn plank tegen kom, is een USB naar RS-485 adapter.

RS-485 is een standaard, verzonnen in een donker verleden door een of ander instituut.

Om bitjes te kunnen lezen en zenden, heeft RS-485 twee signalen nodig die het tegenovergestelde van elkaar zijn. Als het ene signaal hoog is, en de andere laag, komt er een 1 uit zetten, en als de andere hoog is... en de ene laag, komt er een 0 uit zetten. Okee?

Die "andere" en "die ene" heten officiler A en B, en iedereen (lees: Infant) haalt ze altijd door de war:
The RS-485 signaling specification states that signal A is the inverting or '-' pin and signal B is the non-inverting or '+' pin.
This is in conflict with the A/B naming used by a number of differential transceiver manufacturers...
These manufacturers are incorrect, but their practice is in widespread use.
To avoid these confusions, some equipment manufacturers have created a third D+ and D- naming convention.

-Wiki

Okee, rant time. Kort samengevat:

De helft van de fabrikanten implementeert de standaard verkeerd. Dat vinden we met z'n allen dan onduidelijk. Vervolgens fixen we dat door de onduidelijkheid te voorzien van een nieuw label, die niet in de standaard genoemd is.

Dit is waarom elke handleiding die ik heb gelezen m.b.t. RS-485 ongeveer zo gaat:
"Sluit A op A aan, B op B. Doet ie ut niet? Draai ze om."

Anyhow, met een voeding en twee weerstanden, kan deze converter ervan overtuigd worden dat de 24V fiets bus een hele brakke RS-485 lijn is:

Weer zo'n super duidelijk schema.


Na dat zo aan te hebben gesloten, en de A en B een keer te hebben verwisseld, slinger ik mijn favoriete serial terminal aan en steek het display opnieuw in de accu.

Meteen wordt je overspoeld met een muur aan gegevens, dat gaat zo'n 10 seconden door. Het display toont de foutcode E0005 net als de vorige keer, en daarna gaat het hele zaakje uit.
banaan:
1
2
3
4
5
6
7
8
10 c1 21 22 06 5d 10 22 c2 22 00 ad 77 10 a4 20  .!".]."".w.¤ 
ee 10 a4 20 ee 10 a4 20 ee 10 a4 20 ee 10 c1 21  .¤ .¤ .¤ .!
22 07 cc 10 22 c2 22 00 bc 2b 10 c1 21 22 08 39  ".."".¼+.!".9
10 22 c2 22 00 bd ba 10 c1 21 22 09 a8 10 22 c2  ."".½.!".¨."
22 00 bf db 10 c1 21 22 0a 58 10 22 c2 22 00 c0  "..!".X."".
cb 10 04 20 cc 10 04 20 cc 10 04 20 cc 10 04 20  .. .. .. .. 
cc 10 c1 21 22 0b c9 10 22 c2 22 00 d0 06 10 c1  .!"..""...
21 22 0c fb 10 22 c2 22 00 d1 97 10 c1 21 22 0d  !".."".—.!".
Kansloos!

Dit is een stukje uit dat gelogde verkeer, om je een idee te geven. Het hele bestand staat hier.

Zoals je kunt zien, komt er geen enkel nuttig leesbaar stukje tekst in voor. Niet dat ik dit echt verwachtte.

Stap twee was dan toch maar eens de motor er op aansluiten, want daar zal hij toch ook wel mee willen babbelen? De motor heb ik helaas uit elkaar gehaald, maar de ingewanden zijn nog heel:

En dit is een motor ... hoe precies?


Dus, die draadjes vrot ik in de daarvoor bestemde connector, start een nieuwe log sessie (dataverkeer wat er bij hoort.), en wat schetst de verbazing?
OMG!


OMFSM! Een getal!

Het eerste wat je dan natuurlijk op stom geluk doet, is kijken of dat getal ergens toevallig voorbij komt vliegen.

Ik heb de data in het log in regels opgesplitst, zodat op elke regel een begin van een pakketje staat.

Meerdere malen komt 10 C1 29 26 0c 0c c3 54 c0 00 f0 59 41 21 voorbij, en dat is het enige waar 59 41 zo pats boem in voor komt. (De hex waarde van 59 41 is 17 35 of 10 3F, afhankelijk van de endianness, maar beide komen niet voor.)

Dat is vrij veel belovend, maar nog niet echt een zekerheid.

De laatste banaan die ook nog een teken van leven toonde, heb ik er toen ook maar aan gehangen en gelogd.

Deze doet het ook, en zodra het display de km stand geeft haal ik hem er weer uit. Dit display geeft 7052 km aan, en what do you know: vlak bij het einde van het log staat:

10 C1 29 26 03 0c c0 00 c0 00 f0 70 52 49

Consistentie!

Veel meer kan ik van deze opstelling natuurlijk niet maken. De "motor" gaat nooit kunnen draaien, het is berhaupt een wonder dat hier leven uit komt.

De volgende stap leek mij daarom, uitvinden of ik zelf iets tegen het display kan zeggen, bijv een andere kilometer stand. Daarvoor moet ook terug gepraat kunnen worden, en dat vereist een iets andere en wellicht ook nettere opstelling.

Terug babbelen
In plaats van het gebeunde RS-485 ding nog langer te misbruiken, heb ik een oud Olimex bordje uit de kast gehaald.

Deze heeft er een RS-232 geval erop zitten, wat weer zo'n standaard is die gewoon hetzelfde op een andere manier doet, en daar heb ik het volgende op geprikt:

Hee, een leesbaar schema.


De communicatie bus, is een los draad wat d.m.v. een pull-up weerstand(R3) op 24V gehouden wordt. Als de bus 24V is, maakt de deling R4/R5 daar ietse van 8 keer minder van (3V ongeveer) zodat dat op het ontvangst pinnetje van het RS232 ic kan zonder dat die direct in rook op gaat.

Om de bus omlaag te trekken, moet het 5V tx-signaal ge-level-shift worden naar 24V. Dat kan met twee transistoren: Als tx hoog is en Q2 in gaat, is de ingang van Q1 laag en laat hij de bus met rust. De bus is dus 24V.

Als tx laag is, wordt de ingang van Q1 hoog, en trekt hij de bus door een 100 Ohm weerstand R2 naar de GND toe. De bus is dan nog ongeveer 2V, gedeeld door c.a. 8 is dat laag genoeg om als 0 gelezen te worden.

Een nuttige feature die deze bus automatisch heeft, is dat alles wat je nu over RS-232 verzend, ook direct terug krijgt. Als twee dingen op exact hetzelfde moment op deze bus proberen te praten, kun je dat direct vast stellen, je krijgt namelijk niet hetzelfde terug als wat je er op zet.

Het bordje ziet er nu zo uit. Er zit een connector op waar het display in geprikt kan worden. En als je dat doet, gebeurt er niks.

Hm...

Misschien moet hij eerst wat aan gemasseerd worden, door er data naar toe te slingeren. Dus ik verzend het stuk waarvan ik vermoed dat het 5941 km op het display weer gaat geven:

Hallo!
Blauw is verzonden, groen is ontvangen.


Ooh!

Voor een halve seconde ofzo verschijnt inderdaad dezelfde km stand op het display, en verdwijnt daarna weer. Als ik eerst dit bericht, en daarna allemaal onzin verzend blijft het display aan, net zolang tot ik ophoud met verzenden.

Veel interessanter nog, is dat het display kennelijk antwoord geeft:
10 22 c0 26 d9.

Het versturen van het pakket met de andere km stand, geeft hetzelfde antwoord.

Dat is heel aardig, want dan kan ik wat van het gelogde verkeer op een rijtje zetten:

10 C1 29 26 0C 30 C3 54 C0 00 FC CC C0 71
10 22 D0 26 D9
10 C1 29 26 03 0C C0 00 C0 00 F0 70 52 49
10 22 C0 26 D9
10 C1 29 26 0C 30 C3 4F C0 00 FC CC C0 4E
10 22 C0 26 D9

Die gaven allemaal hetzelfde antwoord, maar er is ook:

10 C1 29 27 03 30 C0 00 00 00 3C CC C0 D4
10 22 C0 27 48
10 C1 29 27 03 00 00 00 00 00 1e 00 05 b7
10 22 c0 27 48

Bij tet verzenden van deze twee pakketjes, gaat het display niet meer uit. En kijk:

10 C1 29 27 03 00 00 00 00 00 1e 00 05 b7
10 22 c0 27 48

Deze geeft de foutcode E0005 permanent weer!

Verder komt dit bericht vaak voorbij:
10 C1 21 22 00 FE.

Het een na laatste getal loopt steeds op:
10 C1 21 22 01 6F
... 02 9F
03 0E
04 3C
05 AD
06 5D
07 CC
08 39
09 A8
0A 58
0B C9
0C FB
0D 6A
0E 9A
0F 0B

En na 0F begint hij weer opnieuw.

Dit doet sterk vermoeden dat de laatste byte een CRC is. Als ik namelijk een bit aanpas in het bericht naar het display toe, en bijv. foutcode 0004 ervan maak, gebeurt er niks, en krijg ik ook geen antwoord.

En ik wil zo graag dat het display 666km aangeeft.

CRCs
CRC's zijn geweldige dingen. Het is een controle getal wat in dit geval achter het bericht geplakt zit.

Als tijdens de verzending de data in het bericht veranderd, komt de CRC niet meer overeen. Ze zijn ontworpen om bij een kleine verandering, van. bijv maar 1 bit, een zo groot mogelijke verandering in het controle getal op te leveren.

Maar een 8-bit CRC is natuurlijk niet zo veel. 8 bits zijn 256 verschillende mogelijkheden.

Als ik zo'n bericht compleet omgooi, en er een willekeurige CRC achter bengel, heb ik een 1 op 256 kans dat ik die goed gok.

En gezien dit display zo vriendelijk is om niks te zeggen als ik puin verstuur, en netjes te antwoorden als hij het met me eens is, kan ik in theorie gewoon maar wat getallen op het eind proberen totdat het goed gaat.

Nou, dat gehele proces heb ik samengevat in een quick and dirty programmaatje.

(Mocht je het willen proberen... het werkt onder Linux of Windows + cygwin door make uit te voeren. Hij opent standaard /dev/ttyS23, maar je kunt een ander device als opstart argument mee geven. Bijv:
code:
1
./tryme /dev/ttyUSB0


Als je die opstart, vraagt hij weke waarde hij naar het display moet smijten:


Het getal wat je invoert gaat door een binare gehaktmolen heen:
C:
1
2
3
4
5
6
7
8
9
 //The encoding is kinda weird, it's the HEX representation of what you see:    
 uint8_t dec[3];
 //Break it into powers of 10.
 dec[0] = speed / 100;
 dec[1] = (speed - (100*dec[0])) / 10;
 dec[2] = speed % 10;
 //Convert it to ...something
 data[8] = 0x01 * dec[0];
 data[9] = ((0x10 * dec[1])) | dec[2];

Dat propt hij op de plek waar ik ondertussen stiekem van heb uitgevonden dat het de speedo locatie is, hij laat zien wat hij verzonden heeft en wat het vorige antwoord was:


En na een aantal pogingen komt er een antwoord terug van het display:


En verschijnt het getal automagisch op het scherm!
Evil!


Enig.

We zijn nu in ieder geval op het punt beland dat je Sparta Ion display in combinatie met deze enigszins lompe manier van communiceren, kan omtoveren tot bijv een kook wekker.

Hij piept alleen niet...

Banana?

Door Infant op maandag 09 juni 2014 12:37 - Reacties (16)
Categorie: Gemod / Gefix, Views: 7.461

Ik acht mij niet verantwoordelijk voor hoge bloeddruk en/of ongecontroleerde woede aanvallen veroorzaakt door spellingfouten.

Eens in de zoveel tijd struin ik rond op Marktplaats, gewapend met mijn favoriete zoektermen. Afgelopen week vond ik dat eindelijk een defecte banaan, waar ik al een hele tijd naar op zoek was. (Uiteraard was dat niet de zoekterm.) Het betreft een accu in de vorm van een banaan, voor in mijn kapotte zombie fiets.

Ik heb er drie gekocht, gezien ze zo schandalig goedkoop waren. Ze werden door een fietsen winkel aangeboden en ik kreeg er zelfs een mooie marge factuur bij opgestuurd. Ik blij, en de fietsenmaker in kwestie denk ik ook.

Hij neemt deze dingen in als iemand bij hem komt om nieuwe accu's te plaatsen.

Uiteraard mag zo'n klant dan 6 Euro verwijderingsbijdrage betalen bovenop de andere willekeurige kosten die hij in rekening gaat brengen. Normaliter moet hij dat bedrag weer afstaan aan de plek waar hij die dingen heen brengt, denk ik. De gemeente? Een donker plekje ergens in de bosjes? Chemisch afval?

In plaats daarvan krijgt hij nu nog meer geld, om het naar mij op te sturen. Een win situatie voor de de fietsenmaker, een verlies-verlies-verlies situatie voor de persoon die hem bij hem heeft ingeleverd.

Na een paar dagen komt de TNT/PostNL met een berg langwerpige dozen aan zetten:
Doosch.

De eerste 30 seconden van dit filmpje beschrijven extreem exact hoe je je dan voelt.

Open maken!
Na wat gepiel en gepeuter, gaat ook deze banaan open. Het gaat hier om een 9Ah accu, t.o.v. 10Ah , maar het printje is identiek aan degene die in mijn fiets zat. Het enige verschil is dat deze minder kapot lijkt, en helemaal geen coating heeft.

Ooh!


Uiteraard doet ook dit ding 10 keer niks.

Stiekem heb ik een tijdje geleden, toen ik me verveelde, een beginnetje gemaakt om het schema van dit printje te tekenen. Het is maar een twee-laags pcb, er zit alleen een idioot oerwoud aan analoge meuk op met weerstanden die overal overheen, naartoe en tussendoor gaan.

Ik dacht, ik begin bij de 6-pins connector, want die lijkt verdacht veel op de standaard 6-pins Atmel ISP header. Dit is de staat waarin ik het "schema" achter heb gelaten:

Hoeft niet aan elkaar?

Als je een ongesorteerde doos elektronica onderdelen zou weergeven in schema vorm, zou het er ook ongeveer zou uit zien.

Het fijne aan grote SMD onderdelen als deze (de weerstanden zijn 2 bij 1.25mm) is dat je er nog gemakkelijk draadjes aan kunt solderen. Nog handiger is dat in plaats van een idiote kleur codering, de waarde er gewoon met getallen op geschreven staat. Dus dat werk wel makkelijk.

Alle kleine zwarte onderdelen kun je niet altijd iets zinnigs over zeggen, helemaal niet als het potentieel stuk is. Een drie pootje kan een spannings regelaar, diode, mosfet of transistor zijn, en de waarde mag je raden want die staat er niet op.

Het goede nieuws is dat de 6-pins connector direct naar de programmeer pinnen van de Atmega gaat (door een 1k serie weerstand), en de voeding door een 10 Ohm weerstand op de Vcc pin aankomt. De pin-layout is niet standaard, maar een klein verloopje zit zo in elkaar.

Omdat het printje zelf geen spanning maakt, geef ik hem extern een beetje prik. Rond de 4 Volt ofzo zou moeten werken om in ieder geval met de Atmel te babbelen.

Netste opstelling tot nu toe.

Het is in de programmeer omgeving 1 keer raak: Hij wordt herkend! Jeej!

Daar houd het feestje helaas ook op. Niet geheel tegen de verwachting in zijn de lock bits ingeschakeld, wat betekend dat de applicatie niet uit het geheugen gelezen kan worden.



De chip start op in zogenaamde bootloader mode. (De BOOTRST fuse zorgt daar voor.) De lock bits staan zo ingesteld dat hij nooit de bootloader mag overschrijven, maar wel de applicatie. Als er niks ge-update hoeft te worden, wat bij normaal gebruik het geval is als je de fiets aan zeg, start hij de applicatie... en gaat hij banaan-management doen.

Deze lock-bits zijn dingen die op de chip letterlijk weg branden. Op deze wijze kunnen vervelende mensen zoals ik niet eenvoudig de applicatie uitlezen, maar kan een Sparta dealer wel de firmware in de accu updaten om er meer dubieuze en ongedocumenteerde functies in te prakken.

Op zich had iemand op het circuits online forum dit ook al bevestigd, 4 jaar geleden. Als je de chip wist, kun je wel het EEPROM uitlezen, en die inhoud heeft hij ook online gekwakt. Ik schiet daar nog niet zo veel mee op, dus ik ga deze niet wissen en laat hem verder met rust.

Hallo?!
Alle onderdelen in deze fiets praten met elkaar over een enkel geel draad, een bus. Deze staat normaal 24V op, en kan door een van de onderdelen (de motor, het display of de accu) gebruikt worden om over te communiceren.

Er is verder echt extreem weinig nuttigs te vinden over de elektronica in deze fiets, de enige hint komt wederom van CO, en die is dat er standaard USART op 9600 8N1 over die draad heen gaat.

De Atmega die nog met 4V aan staat, geeft op de TX pin inderdaad signaal uit:
10 04 20 CC en af en toe 10 C1 21 22 80 5F.

In banaan-taal zal dat hoogstwaarschijnlijk het volgende betekenen:
"Hello moto?"
"Hello display?"
(Of in andere volgorde.)

Op de ontvang pin verschijnt niks. De 24V bus wiebelt ook niet mee. Omdat de bus maar 1 enkel draad is om over te babbelen, kan deze print niet verzenden en ontvangen tegelijk. Sterker nog, als hij iets zegt op de bus hoort hij dat zelfde bericht ook weer terug. Dat is erg handig ter controle. Als de bus namelijk kapot is, zoals nu, kun je iets zeggen:
"Echo!"

En als er dan niks terug komt... weet je dat er iets niet goed is.

De communicatie vanuit het oogpunt van de microcontroller zou er normaliter (vertaald vanuit het banaans) ongeveer zo uit kunnen zien:
"Display?"
"Display?"
...
"Ja, wat is er?"
"Niks."
"Niks."
...
"Okee."

"Motor?"
"Motor?"
...
"Ja wat moet je?"

Als je geen dubbel bericht, of geen enkel antwoord terug krijgt... is er duidelijk iets mis.

In het display
De kassa forum leden klagen dat elk wissewasje een bezoekje aan de dealer vereist, die alles aan elkaar moet aanmelden via het internet.
Dit zou in houden, dat stel ik heb een werkende fiets, ik pak een willekeurige accu van Marktplaats af en prik hem er in, dan zegt de fiets: "Dat is niet mij accu, vriend." En vertikt het verder.

Verder wordt de suggestie op het CO forum gewekt dat er een of ander obscuur en horrific protocol overheen loopt, wat voorzien is van 1000 lagen encryptie, server communicatie, backdoors en andere ellende die geen enkele vorm van zinnige analyse toe staan.

Ik kan het me haast niet voorstellen. Deze accu heeft al vrij veel functies, hij moet een hele berg aan metingen doen, allerlei klant specifieke dingen bij houden, zichzelf kunnen updaten, en alles door babbelen over een enkel draad.

Dat is best een complexe applicatie. Dit ding heeft maar maar 32kB aan ruimte. (De kans bestaat dat het maar 16 kB is, als je eenvoudiger een applicatie update wilt kunnen doen.)
Stel dat je daar dat ook nog encryptie overheen wilt doen, moet je sleutels gaan zitten uit wisselen met de rest van de onderdelen.... het kan, maar ik schat de kans klein in.

Het display, wat ik vorige keer nog niet open had gemaakt, heeft verrassend weinig onderdelen:


Voorkant Achterkant

Aan de ene zijde zit een bosje passieve onderdelen, en een condensator die iemand er later tussen gevrot heeft. Aan de andere kant zitten de contactjes naar het LCD, en twee COBs.

Bijna elk LCD display wat je open maakt, in welk apparaat dan ook, heeft zo'n blob er op zitten. In 95% van de gevallen gaat het dan om een ASIC waar geen standaard verpakking omheen zit. Het chipje zit dan direct aan het PCB verbonden. Het kan ook dat ze er epoxy overheen gedaan hebben, gewoon om het je lastig te maken.

Het zou kunnen dat er een microcontroller onder de blob zit, maar ik verwacht het eigenlijk niet. Gezien er knopjes op het display zitten, en je de hele fiets met het display bedient, moet dit ook data terug kunnen sturen.

Er zit verder een stikker op, met een nummer, en met de hand is op de andere zijde... het zelfde nummer geschreven. Als er dingen op elkaar aangemeld moeten worden, zou dat wel eens voorbij kunnen komen?

Er is meer!
Ik heb nog een hele doos met bananen staan, waar nog niks mee gedaan is.

Wellicht is het nu wel interessant om te noemen dat deze bananen ongeveer 185 kCal aan energie bevatten. (10*24*3600 / 4184). En dat is ongeveer 4x zoveel als een echte banaan. :+

Alles is uiteraard ook verkocht als defect, dus ik verwacht er niet veel van. Maar de tweede uit de doos is wel het eerste exemplaar waar ik spanning op de display pinnen meet: 5V en 24V.

... :Y) ...

Nou, displaytje erin prikken op hoop van zegen dan maar.

En wederom zit het mee: Het display gaat aan! (Ik dacht eigenlijk dat die ook stuk was.) Een relais in de accu zegt tik, en de display geeft een foutcode: E0005.

Als ergens veel documentatie over te vinden is in dit project, dan zijn het wel de foutcodes. De eerste online bron heeft dit over de foutcode te zeggen:

E05: Slechte verbinding naar de motor.

No shit.

Voor mij is dit veel belovend, want zo'n melding betekend data verkeer. En data verkeer, dient gesnoven te worden... met een snuiver...

Slimme Adapters

Door Infant op dinsdag 15 april 2014 13:28 - Reacties (26)
Categorie: Gemod / Gefix, Views: 4.322

Dit sluit een beetje aan op de vorige blogs: een oneindig lange hoeveelheid gepruts om de eigenaardigheden van HP laptops op het gebied van stroomvoorziening in kaart te brengen:
Domme Batterijen
Domme Batterijen - Accupologie
Domme Batterijen - Verkeer(de)informatie
Domme Batterijen - Spoof
Slimme Batterijen
Slimme Adapters

Door verder te lezen, accepteert u dat er wellicht her en der een aantal spellingsvoudten in kunnen zitten. Stuur maar een PM, dan soep ik ze er uit.

Once upon a time.

Een weekje geleden of zo, lag er een prachtige notebook adapter bij het afval, en dan wel precies degene die in mijn 2730p past. Hij zag er nog netjes uit, dus mee nemen die handel. Nieuw zijn die dingen toch weer 60 Euro of zo, dus het zou leuk zijn als deze stiekem gewoon nog werkte.

Helaas, te vroeg gejuicht. Als je hem in het stopcontact steekt, blijkt dat A: de stekker niet past:
Ja... dat past dus niet.
Maar dat is op zich nog wel op te lossen door een andere mickey-mouse stekker te pakken.

En vervolgens B: Hij maakt een tikkend geluid.

Mooi! Dat betekend stuk! En stuk, betekend dat het open mag. :Y)

Twee vleeswonden en ~15 minuten later, ligt het er als volgt bij:
Rubber rubber rubber...
De rede dat deze dingen 60 Euro kosten mag duidelijk zijn, als je hem bijv. naast mux' 4$ adapter legt:
Er zitten ongeveer 3 keer zoveel componenten op, alles zit netjes vast. En zelfs onder het rubbertje, staat dat er een rubbertje moet. Dat hebben condooms niet eens.

Maar toch is het stuk.

Wat ik nu eigenlijk wou uitvinden is hoe dit ding tegen mijn laptop verteld, dat het een 65W adapter is. Als ik namelijk een 65W adapter in een 8540W steek, plopt er een ballonnetje uit de taakbalk tevoorschijn die iets zegt in de trand van: "Deze adapter is sub-optimaal, overweeg er een moeilijk grote in te steken."

Dat overweeg ik dan altijd kort, en denk dan.... "Neuh, ik vind de kleine leuker." Het enige wat die grote adapter doet, is mijn accu's sneller opladen, en die zijn toch allemaal kapot. So what's the point.?

Mijn eerste gedachte, is dat het waarschijnlijk op dezelfde manier als bij Dell gaat: met een obscuur chipje.
Deze post bijvoorbeeld, is van iemand die zo'n ding uit elkaar gepeuterd heeft.
Kort samen gevat komt het er bij hem op neer, dat er in elke Dell adapter een ID-chipje zit die je notebook verteld of de adapter een 65W, 90W of 120W model is.
Als er niks verteld wordt, omdat het chipje bijv. stuk is, gaat de notebook ook niet aan.

Aan dit soort praktijken stoor ik mij echt enorm.
Mijn vorige notebook (een oude N410c) had een andere aansluiting dan deze nieuwe, terwijl die adapter hetzelfde vermogen had: 65 Watt bij 19.5V. En ik heb het in het vorige blog ook al genoemd: Die dingen kunnen werkelijk van alles lopen. 9V tm 20V, allemaal geen probleem. Waarom moet het stekkertje dan nu weer anders, en waarom moet er nu weer van alles extra overheen gebabbeld worden?

Maar het geeft allemaal niet.
Nu ik dit adapter karkas tot mijn beschikking heb, kan er aan gemeten worden.

Allereerst heb ik de drie draadjes log gemaakt, zodat ik een mooi lang snoer met een stekker aan 1 kant:
Zo ziet die er uit.
En drie losse draadjes aan de andere kant heb. Vervolgens 19V uit een labvoeding op de plus en min gezet....

KABAM!

Wat? Nu al kabam? Ik heb nog niks gedaan?

Het blijkt, dat de stroom door het draadje een kortere weg terug naar de voeding gevonden heeft: Hij is kort gesloten.

Na het eerste stukje weg gesnoeid te hebben:
Ergens tussen de linker en rechter kant is iets niet helemaal jofel.
doet in ieder geval het draad weer normaal.

Maar wacht! Als het draad stuk was... dan zou de adapter misschien nog wel eens kunnen werken?

En ja hoor, na alles weer op zijn plek terug te hebben gesoldeerd, is het getik weg, en gaat de notebook aan.

Weer een rede om een wat duurdere adapter te kopen: Als er kortsluiting in de draad zit, gaat hij netjes uit in plaats van dat er rook en vuur uit komt.

Dat is heel mooi! Want dan kan ik nu gaan kijken, wat er over dat 3e draadje heen loopt.

En dat is eigenlijk helemaal niet zo veel. Er staat een constante spanning spanning op het draad van het middelste pinnetje. Als je hem in de notebook prikt, zakt het wat naar beneden naar iets van 6 volt of zo, maar lijkt niet echt iets van communicatie overheen te lopen.

Hm... tijd om in het schema te duiken. Ja! Er is een schema van deze laptop! (Media fire link.) Of het ook overeenkomt weet ik niet, maar tot nu toe heeft het aardig geholpen.
Dit stukje ziet er interessant uit.

Het stukje hierboven komt uit het hoofdstuk genaamd ADP OCP, en het signaal waar het 3e pinnetje binnen komt heet limit_signal.

Dat signaal gaat als we dit schema mogen geloven naar twee opamps lm393 comperators toe: Waarvan de bovenste comperator het signaal genaamd ADP_ID op zijn uitgang heeft staan, en de tweede het signaal: ADP_EN.

ADP_EN: Dat zal wel adapter enable zijn. Die wil ik hebben.

Verder verdwijnt het signaal in een oerwoud aan comperators, opampt, mosfets diodes en ander grut. Maar dat lijkt zo op het eerste gezicht, allemaal niet zo interessant.

Maar wat dit alles betekend, is dat er niet echt iets digitaals aan te pas komt. Je zou gewoon de middelste pin ook aan de 19V moeten kunnen hangen, en dan zou de notebook de adapter in schakelen.

Zo gezegd, zo gedaan. En wat schetst de verbazing:
Het werkt! Het lampje op de notebook gaat aan!

Dat was te makkelijk, but I'll take it.

Nu kan ik wat aan de knopjes gaan draaien, en kijken bij welk voltage hij ophoud met werken.
Zo'n beetje rond de 11V valt hij uit.

Dus: Wederom de vraag: Waarom bieden we dure 12V reisadapters aan, als het ook gewoon allemaal direct in je notebook geprikt kan worden? Je hebt echt letterlijk niets anders dan een 12V sigaretten stekker, misschien een zekering en wat grut om overspanning af te vangen. That's it.

Maar wacht: Ik heb te vroeg gejuicht. In de 15 minuten dat ik in dat schema heb zitten snuffelen, is de notebook nog steeds niet opgestart. Het lijkt wel of hij vast gelopen is.

Hm... ?

Laat ik mijn zelf geknutselde stekker er eens uit trekken...
Jahoor, het Windows-laad-animatietje gaat verder en 2 seconden later is hij opgestart.

Dat is vreemd.

Stekker er weer in terug: Laad lampje gaat aan, ventilator gaat ietsje harder draaien. Stekker icoontje zegt dat er een adapter in zit, maar het duurt nu makkelijk een minuut om het start menu tevoorschijn te toveren. Het ding is niet vooruit te branden.

Stekker er uit, en hij loopt weer als een raket.

Hm... Laten we er eens wat programmas bij pakken.
Met de stekker er uit, en de notebook op accu, geeft taakbeheer tussen de 0 en 5% CPU gebruik, en CPU-z zegt dat alles geweldig gaat:
Jeez wat veel processen zeg. En nog steeds loopt het als een raket?
(800MHz is de snelheid van de processor als er niks te doen is, en hij op accu werkt. Als je 1 kern aan het werk zet, gaat hij naar 2100MHz, en bij twee gaan ze beide op 1800MHz lopen. In deze generatie processors heet dat Speedstep.)

Maar kijk nu wat er gebeurt als ik de stekker er weer in doe:
Ja.... dat is anders?
Wat? Hij loopt op 133 MHz! Een Pentium I is sneller dan 133 MHz!

De notebook heeft zichzelf terug geklokt tot stenen-tijdperk snelheden, en besteed nu 42% van zijn reken kracht aan het aan mij vertellen dat hij 42% van zijn reken kracht gebruikt.... aan het aan mij vertellen... (Volg je dat? Volgens mij gaat deze zin oneindig verder.)

Hij is dus voornamelijk bezig om het taakbeheer tabelletje te updaten.

But why?

Het blijkt, dat dat oerwoud aan componenten en grut, waar ik het net over had, nog een belangrijk signaaltje de notebook in schiet.

Een signaal genaamd OCP#, wat waarschijnlijk overcurrent protection betekend. (Dat is ook wel een beetje hoe dat hele hoofdstuk heette...)

Nu begint ineens de keuze voor een derde draad duidelijk te worden:
Door dit 3e signaal draad loopt nauwelijks stroom. Als er door de notebook om een of andere reden te veel stroom uit de adapter gehaald wordt over de 2 andere draden, zakt de spanning van die twee draden bij de connector wat omlaag. Er zit namelijk een aardig lang draad tussen de notebook en adapter, deze zorgt dan voor een spanningsval.

De spanning uit de 3e pin is nu hoger, als de spanning uit het positieve draad.

Wat de notebook dan automatisch doet, is zoveel mogelijk zijn best om zo min mogelijk energie te gebruiken: Dat betekent, geen accu opladen en alles als een idioot terug klokken.

Eigenlijk best handig dus.

Het enige wat nu nodig is, om de laptop fatsoenlijk van een willekeurige spanning te laten lopen, is een eenvoudige weerstands-deling waarvan het midden naar het middelste pinnetje gaat.

Ik heb het een beetje zitten meten.
De voeding spanning Vin staat links, en het bereik op de ID pin waarbij de notebook normaal werkt staat rechts:

12V bij 4.2V - 4.8V
15.4V bij 5.3V - 5.9V
17.5V bij 5.6V - 6.5V
19.5V bij 6.0V - 6.9V

Helaas gaat het laad circuit pas aan vanaf 17.5V, wat een logisch getal is, gezien hij ook 4 cell's accu's moet kunnen opladen (Ook al verkoopt HP die niet voor dit type.)

Als de IDpin spanning boven het bovengenoemde bereik gaat, wordt de notebook intens traag, en er onder koppelt hij de adapter los.

Wat dit alles betekend, is dat je deze notebook heel eenvoudig direct uit een 4-cells accu kan laten lopen. Het enige wat dus nodig is, is een weerstands deling.
Z'n grotere broertje, een 8450W is er nu ook van overtuigd dat mij labvoeding een adapter is. Beide zijn ze met bijvoorbeeld een 39k / 22k deling vrij content:

Alweer gefopt. Hij blijft maar denken dat ik er orginele HP onderdelen in steek.

Dit maakt het extreem eenvoudig om een extra accu voor je notebook te maken. Je hebt 4 lithium cellen, twee weerstanden en een kappotte adapter nodig(zodat je de stekker + draad daaruit kan kannibaliseren) Misschien wat tape...

Wat ik dus niet wist, maar wat dus nu een handig weetje is: Als je notebook tergend langzaam is, is waarschijnlijk je adapter gaar.