Toch alleen de spanning, niet de frequentie ? Als je (en ik zeg ALS
) je de pulsen/signalen goed eruit weet te toveren, ben je al een heel eind.
De 'laadpulsen' uit de 3-fase gelijkrichter komen meestal rechtstreeks op de accupolen terecht. En zo niet dan gaat het door een minimale hoeveelheid elektronica heen.
Met als gevolg dat je op je accuspanning best nog een rimpel terug kunt zien die van de dynamo afkomt.
Verder hangt de amplitude van de 'generator' en 'ontstekings' rimpel af van de inwendige weerstand van de accu. Als je een goede, nieuwe accu monteert zal dit niet veel zijn.
Mijn idee is dat het wel kan, maar dat het toch een redelijk brokje analoge elektronica kost om het er enigzins betrouwbaar uit te filteren.
Wat bedoel je met naoscilleren ?
Als de bobine klassiek op 12V werkt, dan zal de stroom door de bobine verbroken worden op het moment dat er ontstoken word. Op dat moment heb je een LC-parallelkring die in resonantie komt, met een vrij langzaam uitdovende oscillatie.
Werkt de bobine met een CDI ontsteking, dan word het ding in een keer met een paar honderd Volt gepulst. En ook die puls exciteert een LC kring -> oscillatie.
Ben het helemaal met je eens, maar dat "vervelen" is ook maar erg relatief...als je 't hebt over inleren. Da's ruim minder dan 1 promille van de tijd dat hij/zij er gebruik van maakt ...
Ja, en meteen ook net de tijd dat er koppiekoppie en het lezen van een handleiding van de gebruiker word gevraagd.
Zenders programmeren van een TV of video doe ik ook nog niet 1 promille van de tijd, maar het is altijd wel een pokkeklus. Een TV die mij alle gevonden zenders presenteert en me vraagt op welk kanaalnummertje ik ze hebben wil vind ik wel zo makkelijk.
Het scheelt me denk ik toch behoorlijk wat tijd en ruimte in de flash. Ik denk dat de "prijs/kwaliteit" verhouding dan niet echt superieur is.
Komop zeg, je maakt mij niet wijs dat je meer dan 4K flash nodig hebt. Ik denk zelfs dat je het in 2K ook nog wel red. Uitgaande van een Atmel 90S dingetje.
Back propagation ... is dat zoiets als Viterbi met branch metrics en backtracking ?
Nee hoor, het is gewoon een duur woord dat de heren wetenschappers uitgevonden hebben voor het eenvoudigweg de fout in de uitkomst terug te koppelen naar de coefficienten in de 'neuronen'. Van daar die back propagation: je propageert de fout aan de uitgang van het netwerk terug de lagen in totdat het netwerk het wel goed doet. Beetje zoals je een kind iets leert; je laat 'm het cijfer '1' zien, en vraagt wat het is. Kind zegt: twee. Dan zeg jij: fout, da's een 1. En zo ga je door totdat het kind het snapt.
Met een neuraal netwerkje werkt het ook zo. Ze zijn handig om sommige problemen op te lossen waar je geen andere manier voor kunt verzinnen. Je leert het ding in met een stel datasets, en dan is de kans groot dat het ding bij een onbekende dataset het juiste antwoord voorspelt.
In jouw geval leer je het netwerkje in door het te voeden met toeren, snelheid, en de afgeleiden daarvan, en het dan te corrigeren met het achteraf bekende resultaat (omhoog/omlaag schakelen) als de voorspelling onjuist was. Met een beetje geluk worden de voorspellingen in de loop van de tijd steeds nauwkeuriger.
Ik ken iemand die afgestudeerd is in AI, misschien dat hij me wat meer kan vertellen waar je dit soort technieken voor gebruikt. Wel erg interessant, lijkt me.
't is leuk spul. Vraag het hem maar eens, hij heeft er meer verstand van dan ik. Ik heb ze wel eens gebruikt om te voorspellen welke kant een setje variabelen opging, en dat werkte redelijk goed. Het was een noodgreep omdat ik geen set regels op kon stellen. Maar dat netwerkje was vast niet optimaal.
Ditzelfde probleem hebben we hier ook: probeer maar eens een stel regels op te stellen in de vorm van 'als a>b of c<d en delta-a<10 dan schakelt de gebruiker omhoog'. Dat gaat niet meevallen, want het verschilt per gebruiker.
Dat was ik me zeker bewust... 
en da's soms ook het frustrerende dat inderdaad geen KIP weet wat er allemaal inzit, en dan is dit nog maar iets simpels.
Ik zit in de IC-industrie. Dan is het nog lastiger; alles zit uiteindelijk in een plastic of keramisch doosje.
Echt.. een paar seconde 2 pulsreeksen meten en dan delen .... *zucht*. Need I say more ?
Ach, soms zit mijn code ook zo in elkaar. Vaak boeit het namelijk echt niet of je slim bent of niet, en de domme oplossing zit vaker sneller in elkaar. Zeker als je debug-tijd mee gaat rekenen. Vaak zitten er bij slimme methodes nog addertjes onder het gras. En met slimme geintjes kun je ook jezelf gruwelijk tegenkomen als je een paar jaar later nog eens moet bekijken waarom je ook al weer dit-en-dat deed.
e zaak is dat het voldoet aan de eisen.
AT90S2313-10SI ...(I van industrial 
), 2k flash en naar ik meen 512 bytes RAM en 128 bytes EEPROM.
Mooi middelmaatje. Maareh, ik geloof dat zelfs een ATMega128L (in TQFP64 package) nog maar een euro of 3 kost bij 100 stuks. Tenminste, dat heb ik laatst ooit eens op een rekening zien staan van een prototypeprintje waar ik een ATMega128L op geprakt heb als 'vangnet' om dingen die krom zijn recht te trekken.
Moet je maar eens navragen bij EBV. Of Bergsoft, die leveren aan particulieren en zijn ook niet zo duur geloof ik. 't is wel een eeuwigheid geleden dat ik daar iets besteld heb, dus geen idee of ze nog bestaan.
Maar had jij de industrial versie van zo'n uC ? Misschien helpt 't door je/een design met foam in te spuiten of anderszins te isoleren.
Nee, destijds waren het 4 Atmel 89C2051's, commercial temprange, in eigenbouw dimmers op een carnavalswagen. Een nachtje vorst en het was einde uC's.
Isoleren zal niet werken. Het enige dat je ermee bereikt is dat de temperatuur langzamer zakt en sneller stijgt. Maar als die motor een paar dagen stilstaat in de vrieskou dan daalt de temp van die elektronica alsnog onder nul hoor.
Uitstel van executie dus.
iets heel intressants lijkt mij de Veypor (www.veypor.co.uk)
hij berekend de versnelling aan de hand van snelheid vs. toerental
het zou op elke motor moeten werken
verder heeft hij ook een G-krachtmeter, wat het mogelijk maakt om sprintjes (0-100kmh, 400mn, 1000m) en ook een remtest (100-0kmh afremmen)
er bestaad de mogelijkheid om het er af te klikken en het aan te sluiten op je pc en de gegevens te downloaden, aan de hand van bepaalde testen gecombineerd met het gewicht en toerental van je motor zou de software je de pk's van je motor vertellen
Dus Edgar, voeg wat extra opslagruimte toe in de vorm van een I2C eeprommetje (of een wat dikkere uC), en een IR-ledje op een Tx pinnetje van een van de uC USART's (of een software-UARTje als je er geen meer over hebt, zie Atmel appnotes). Of praat IrDA, dan kun je standaardoplossingen gebruiken. Notebookje ter plekke, een IrDA adapter op USB, alles. Geen idee hoe IrDA werkt hoor, trouwens. Maar moeilijk kan lowspeed IrDA nooit zijn.
Verkoop vervolgens een setje bestaande uit een fototransistor op de seriele poort en een VB/Delphi programmaatje dat de tabellen met RPM/snelheidsinfo interpreteert en daar acceleratie etc. uit berekent. Kun je best een leuk bedrag voor rekenen.
Connectortje met een kabeltje kan ook natuurlijk, maar dataconnectoren die tegen het harde motorleven kunnen zijn duurder dan een IR-ledje.
(vrijwel) dezelfde hardware, dezelfde kosten, en een schat aan functionaliteit meer wat je ook voor meer geld kunt verkopen. Wat zijn uC's en FPGA's toch prachtig spul
Maak trouwens niet de fout om te proberen alles gelijk zo mooi te maken. Dan komt het ding nooit af namelijk. 5 kleine stapjes is beter dan 1 grote.
Ik zou wel bij de productie-PCB's rekening houden met voor de hand liggende uitbreidingen. Dus vast die I2C eeprom in het schema en op de layout mikken, maar gewoon (nog) niet monteren. Idem met de IR-led, etc.
Een boardrevisiecode hardwiren op je PCB is ook altijd handig. Bijv. met 3 uC-pinnetjes. In de eerste proto-revisie knoop je die allemaal aan GND, code '000' dus. Tweede protorevisie word '001'. Eerste productierun word '010'. enz, enz.
Da's handig als je eventueel later een software-update uit moet voeren (al dan niet als extra betaalde service. Je hebt toch zeker wel die SPI-pinnen bereikbaar gemaakt via een headertje he?); hoef je maar 1 image te handhaven in plaats van het oerwoud van sourcebestanden en binaries voor elk board. Het kost je hooguit een paar bytes flash meer. Nou, jammer dan. Dan maar een microcontroller die $0.50 duurder is en twee keer zoveel flash heeft.
Al deze dingetjes zijn net als gestructureerd programmeren; in de eerste instantie is het lastig omdat het meer tijd kost / ietsjes duurder is, maar uiteindelijk pluk je er de vruchten van.
![:]](/styles/motor-forum/smilies/crossy.gif "Crossy :]")
/www.carmo.nl/FrameSet_NL.htm