Alles moet (kapot) draaien

Door Infant op zondag 21 september 2014 15:20 - Reacties (18)
Categorie: Gepruts, Views: 9.500

Dit is een vervolg op Alles moet draaien.

Ik had net een stukje hardware in elkaar gefrommeld, en het jeukte enorm om het op mijn fiets te monteren.

Voordat ik dat ga doen, wou ik eigenlijk wel graag weten hoe hard ik fiets. Want... SPEED IS KEY!
Op het moment is alle orginele Batavus rommel er uit gehaald, en ligt nog ergens in een doos niks te doen.

De accu die er oorspronkelijk in zat is helemaal uit elkaar, gezien ik daar geen teken van leven meer uit kreeg. En de elektronica daarvan is tot op het bot kaal geplukt. Het leek me niet zo'n geweldig idee om die weer terug in elkaar te zetten.

Gelukkig heb ik nog een werkende banaan,uit de debug-sessie een aantal posts terug. Als ik die kan laten werken met de orginele motor controller, kan die op zijn minst als kilometer teller ingezet worden... tenminste, dat is het plan.

Tijd om de motor controller die ik uit mijn motor gesloopt heb op te graven, en op mijn kuuroord te leggen. (Mijn bureau is verheven tot kuuroord, waar defecte elektronica tot leven gemasseerd word.)

Stap 1: Kuuroord
Ik ben er 99% zeker van dat de kilometer teller de hall sensoren gebruikt om vast te stellen hoe hard het wiel rond draait. Alles op dom geluk in elkaar zetten werkt bij mij nooit, dus ik pak dit stap voor stap aan.

Als je dit plaatje van de vorige keer er bij pakt...
Hall... o.

... zie je dat de hall sensoren een vrij gemakkelijk signaal produceren, makkelijk om na te doen. Dus ik dacht, als ik die gewoon zelf fabriek, en op de hall sensor ingang aansluit.... wellicht denkt hij dan dat er iets van rotatie plaats vind?

De plek waar de hall-sensoren aansloten zaten, zijn netjes gelabeld, dus daar friemelen we een stekker aan:

Zo. Een stekkert.

Vervolgens heb ik dit (de motor controller), banaan-accu en display allemaal aan elkaar gehangen. Het Olimex bordje geeft nu continue een signaal uit zoals uit het plaatje hierboven, en luistert tussendoor al het dataverkeer af en duwt die door naar de de PC.

Met een berg draadjes zit alles aan elkaar gefriemeld, en ziet het kuuroord er ongeveer zo uit:

Klein h? Klik dan!
Wat zie je allemaal? Links een programmer, het olimex bord (wat langzaam een puinhoop begint te worden) dient hier als data-snuiver. Een ourwoud van krokodillen klemmen, die de voeding en data van de accu aftappen, de twee ronde PCBtjes die de zwaartekracht trotseren, een bosje van 5 draadjes die van het olimex bord naar het ronde PCB gaan. (En een firewire kabel die ook mee wil doen.)


En eigenlijk al direct na het aansluiten, kijk... onderin op het display... Kijk wat hij zegt: We gaan 16.1 km/h! Op een bureau! We hebben zelfs al 1km afgelegd! Hoe is het mogelijk?

Het kan deze motor/display combinatie kennelijk geen enkele moer uitmaken dat ik er een jaar later een andere accu op aan heb gesloten. Sterker nog: Ik heb nog nooit zo weinig foutmeldingen gezien op dit display.

Als bijkomstigheid is het leuk om naar het dataverkeer te kijken: De accu vraagt aan het display om zijn serie nummer tegen de motor te vertellen. Kennelijk moet de motor dat dan goed vinden, en vervolgens geeft hij de snelheid en afgelegde afstand en nog wat rommel door.

De accu ziet deze data voorbij komen, en zet dit eens in de zoveel tijd op het display. Ik heb hier uiteraard een tooltlje voor geschreven, want ik werd helemaal gestoord van Termite output heen en weer copy/pasten:

Die kleurtjes ben ik het langst mee bezig geweest.
Al mijn tootljes doen meestal n ding, en over drie maanden weet ik niet meer wat dat was. Het lijkt erop dat de accu met nog een aantal dingen probeert te babbelen, die er niet zijn.

Dat is allemaal heel leuk en enig, maar nu eerst: Inbouwen die handel. Wie weet, doet hij het straks gewoon weer?

Als ik mijn fiets nou in elkaar kon solderen...

Op het tweede plaatje vraag je je af: Zit die dropveter niet wat karig? Nee, want er moet ook nog een isolatie flapje tussen. En dat werkt niet als je het draadje er netjes doorheen doet.

Nu begin ik een beetje te begrijpen waarom deze dingen zo duur zijn. De fiets zelf zit het hem niet in: Dit type motor is zo'n beetje het goedkoopste wat je kunt maken. Het heeft verder geen versnellingen, en de verlichting is een standaard 6V gloei lampje.De spatborden laten los, en het plastic om de kettingkast ratelt als een zak grind in een wasdroger. Zo'n beetje elke schroefje en boutje heeft een andere maat, en ze zijn allemaal verroest.

Op zich is het verder een prima ding, ik rijd er graag mee trappetjes op en af, en hij doet het nog steeds.

Maar... het gros van de kosten zal wel zitten in het in elkaar zetten van dit ding. Wat een pokke werk. Alles past precies net niet, en moet meet een zekere hoeveelheid geduld terug in elkaar gedwongen worden.

Nu is het printje terug gesoldeerd, de motor weer dicht en achterin de fiets. De "nieuwe" accu zit terug in het frame, en het display zit weer op zijn plek. Eens kijken wat hij doet....

Ik rijd naar buiten, zet de ondersteuning op standje 3, (klik hoor je dan) en begin te trappen. Meteen geeft hij keurig de snelheid aan. Maar ondersteunen doet hij nog niet echt.

Maar...

Ik zal wel iets verkeerd om aangesloten hebben, want op het moment dat ik op houd met trappen gaat hij er uit zichzelf vandoor, en het moment dat ik weer trap stopt hij met mee helpen. 8)7

...

Dat is vrij irritant als je een helling op fietst. Het moment dat je ene voet kracht zet, stop hij, dan heb je even zo'n punt dat beide voeten niks doen, waarin hij eventjes mee helpt, en dan bij de volgende voet doet hij weer niks.

Nou heb ik ook op een berg werkende exemplaren van deze fiets gereden, en ik vind trap ondersteuning sowieso irritant: Het moment dat je ophoud met trappen gaat hij nog even eigenwijs n seconde door, en als je weg rijd moet je lekker even wachten.

Maar dit boeit me allemaal niet. Zonder trapondersteuning doet de snelheid en afstandsmeter het ook, en dat was het doel. Next!

Stap 2: Meer mechanisch geneuzel.
Stap twee is de MUT (Motor Under Test) aansluiten. Waar gaat die? Juist, in het voorwiel. Waar anders?

Meteen loop ik weer tegen een probleem op: de as diameter achter is anders dan voor. Achter is 12mm, en het voorwiel is 10mm. (Waarom kan dat niet hetzelfde zijn? Nu heb ik twee types moertjes en sleutels nodig.)

Gelukkig is het frame en de voorvork van aluminium gemaakt, en dan ook nog aluminium van het type zacht als boter. (Ik weet niet welk DIN nummertje dat is...) En is echt twee seconden werk voor de banaan-powered-power-tool (BPPT). (Door een boor van 14.4V op 24V te draaien gaat alles sowieso veel sneller, en houd hij je hand ook lekker warm.)

Probleem twee is dat wiel wat ik voorin wil hebben, gewoon echt veel te vadsig is en er niet tussen past. Het voornaamste wat er dan in de weg zit is het tandwiel, en een stuk aluminium aan de andere kant... waar allerlei accessoires zoals remtrommels op geschroefd kunnen worden.

Ik heb niet zoveel tools. Een veil, een metaal zaag een berg schroevendraaiers en ongeveer 10 boren zonder accu... en een bezem. Die gaan dit allemaal niet zo makkelijk kunnen doen.

Maar deze fiets heeft een ongekend vermogen om zichzelf op eigen kracht kapot te maken: Door de motor terug in de opstelling te plaatsen, en de zelfbouw-controller te vertellen dat ik continue een even grote hoeveelheid stroom de motor in geperst wil hebben, krijg je een constant koppel. En dat werkt ideaal als draaibank. Zo hoef ik de metaal zaag er alleen maar op te houden, en dan vreet het overtollige aluminium zichzelf langzaam op:

Doei tandwiel!. Te koop: Motor, als nieuw.

Na een minuutje of 10 waren beide stukjes aluminium er af, en met een overmatige hoeveelheid spacers pastte het eindelijk in de voorvork.

Volgende probleem: Ik was iets te enthousiast met aandraaien, en nu sprong het ding wat de motor op zijn plek moet houden (een torque washer... is in het nederlands?) van ellende uit elkaar.

Pfff. Ik wil gewoon testen. Goed vast draaien, en hopen dat het blijft zitten.

Laatste stap: Deze motor + controller moet natuurlijk ook prik hebben, en het zou zonde zijn om de gloednieuwe banaan in het frame open te maken. (Ze zouden eigenlijk van kleur moeten veranderen, groen - geel - bruin naarmate je ze leeg trekt.)

Nou heb ik nog een ongebruikte 24V NiCd accu uit een boor in de kast liggen, die verder nergens op past. Die kan opzich wel dienst doen. Dit leverde na niet al te lange tijd de volgende contraptie op:

Dit kan zo kickstarter op.

Dat blauwe spul is een silicone matje wat extreem precies op maat geknipt is (Not). Links zit een zekering zodat ik 's nachts ietsje beter slaap, en verder heeft het alle standaard items die je moet willen hebben: duc(k)(t)tape en tie-wraps voor gegarandeerd mechanisch succes.

Dit dient vervolgens met dezelfde hoogwaardige mechanische tools tegen het frame gemonteerd te worden, met als eind resultaat:

Ik werd een beetje raar aangekeken in de lift...
Werkelijk prachtig. What could possibly go wrong?

Het controller printje was voorzien van de meest basis functionaliteit: het gas hendeltje uitlezen. (Thumb throttle van een chinees op eBay, mag je lekker 5 weken op wachten.) Vervolgens werd dit vertaald naar een combinatie van snelheid en stroom: 50% hendel betekend 50% van de maximale stroom en 50% van de snelheid. (Ongeveer...)

Dit ging best wel aardig.. je voelde dat je vooruit getrokken werd. Maar de 5 Ampre waar de stroom limiet op ingesteld stond leek op de test opstelling gigantisch veel, (het heeft al vrij veel aluminium krom gebogen) maar als je er vervolgens met je kont bovenop gaat zitten stelt het niet zo veel meer voor.

Dus dat was na 2 minuten rondjes rijden al niet interessant meer, dus dan maar eventjes om programmeren en gewoon de stroom limiet op veel: 20 Ampre.

Nou is 24V en 20 Ampre op zich niet zo veel, maar in stilstand vertaald dit zich naar een veelvoud daarvan aan stroom richting de motor...en dat moet allemaal door die arme draadjes van 1.5mm2 heen. En die worden daar een beetje warm van.

Het reed wel een stuk beter, uit zich zelf haalt hij zo ongeveer 25 km/h. Het duurt even voordat je daar bent, en bij elke vorm van wind of helling zakt het in naar 20 km/h.

Als ik dan ook de achter motor aan zet, gaat het opeens als een raket, en haal je tegen de 30 km/h. De motor achter ondersteunt tot 27 km/h, en houd dan op, de voor motor kan er dan nog net 3 km/h bij krijgen.

Toen dacht ik, kom... laat ik ook eens mee trappen. Dit heeft bij 30km/h geen zin op dit ding, want je benen moeten dan modus roadrunner mee draaien.

Zo heb ik 15 km gefietst, als ik het display mag geloven, en toen viel het me op dat de draadjes naar de motor toe steeds korter werden. Vrij snel daarop volgend werd de rit iets minder comfortabel:

Hij is een beetje opgewonden...

Alle draden uit de motor waren kapot, en de uiteindjes zaten tegen elkaar aan kortsluiting te maken. (Vandaar het schokkerige gevoel.)

De draadjes uit de controller zaten ook tegen elkaar, en de hall sensor draadjes waren ook niet echt jofel meer.

Ik vond dat hij het nog lang uit heeft gehouden. Het goede nieuws is dat de controller deze kleine mechanische tegenslag heeft overleeft.

Zodra hij geen hall sensoren meer ziet (Omdat bijv. iemand de draadjes om een as gewikkeld heeft.), stopt hij met stroom de motor in te sturen. En al waren de hall-draadjes nog heel, dan zou hij rustig de draden naar de motor op gewarmd hebben omdat er bij kortsluiting veel te veel stroom zou gaan lopen.

Conclusie/bevindingen
- Je moet alles vast willen maken. Een torque arm of torque washer is een must, deze motoren vreten aluminium als ontbijt.
- De motor krijgt het vrij warm als je er 500 Watt in duwt.
- Een motor in het voorwiel rijd voor geen ene meter. Want ook als ik hem als normale fiets gebruik, gaat dit ding helemaal zijn eigen leven leiden als ik het stuur los laat. Elke bocht voelt het alsof hij recht door wilt.
- Twee motoren gaan harder dan 1 motor. (Duh.)
- Gashendels zijn awesome, maar ik zet hem eigenlijk de hele tijd op 100%. Dus het had net zo goed een knopje kunnen zijn.
- Trapondersteuning is suf.
- Je moet twee remmen willen hebben. (De voor-rem zit niet vast, gezien dat een trommel rem is.)
- Trommel remmen zijn poep.
- Deze methode van testen is sub-optimaal en kost veel te veel tijd. De rij/pruts verhouding is niet goed. (4 uur prutsen, 20 minuten rijden).
- Ik moet meer tie-wraps kopen.

Op naar het volgende deel.

Alles moet draaien

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

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 (15)
Categorie: Gepruts, Views: 2.807

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.963

Dit is in vervolg op de vorige posts:
Dooie Fiets
Banana?
Je zit nu hier:
Bananen taal
En het gaat hier verder:
Cyclic Banana Checks
Alles moet draaien
Alles moet (kapot) draaien

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.
code:
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: 8.154

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

Dit is in vervolg op: Dooie Fiets - Vervolg, en gaat hier verder: Bananen Taal

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...