Het in elkaar beunen van algeheel nutteloze meuk, soms met andere meuk. Meestal 'omdat het kan'.

Alles moet (kapot) draaien

Door Infant op zondag 21 september 2014 15:20 - Reacties (22)
Categorien: Gepruts, Sparta: Fiets verbouwen tot het stuk gaat., Views: 16.114

Dit is een vervolg op Alles moet draaien. Het vervolg staat hier: Alles moet rond 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.

Cyclic Banana Checks

Door Infant op woensdag 30 juli 2014 18:15 - Reacties (15)
Categorien: Gepruts, Sparta: Fiets verbouwen tot het stuk gaat., Views: 6.788

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_t* data,uint8_t len, uint8_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_bow( uint8_t *data_in, uint8_t len, uint8_t init){
    uint8_t crc;
    uint8_t i,j,f;    
    uint8_t data;
    crc = init;
    for (j = 0; j != len; j++){
        data = data_in[j];        
        for(i = 8; i; i--) {
            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)
Categorien: Gepruts, Sparta: Fiets verbouwen tot het stuk gaat., Views: 11.559

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