Hier heb ik idd ook aan zitten te denken. Het probleem is dat je het toerental eigenlijk moet middelen over de 360 graden. Ik ben namenlijk bang dat tijdens de compressie slag je zuigersnelheid is een stuk lager is dan tijdens de expantie slag (koppeling slipt). Maar opzich zal dit ook wel niet zo heel veel schelen.
Het tweede probleem is, hoe voorkom je dat hij twee keer per slag gaat onsteken? Hij teld namenlijk niet alleen van sensor 1->2 maar ook van 2->1.
Ik heb me digitale techniek boek er nog even op na geslagen en zie dat het aantal bits eigenlijk niet zo'n probleem is. Je kunt counters en rom'etjes gewoon parralel schakelen. Het probleem is alleen dat het schema weer lastiger word en dat is nouw net niet de bedoeling.
Even een samenvatting van de mogelijkheden:
In volgorde van "eenvoud".
* 1 klok & 1 counter -> hele brede adressbus en grote counter nodig.
* 1 sensor, 2 reflectoren, 1 klok & 1 counter. -> simple syteem, alleen twee vonken per omwenteling..
* 2 kloken & 2 counters -> kleine adress bus (8-bits!!) en kleine counters (8-bits).
* 2 sensoren en meerdere relectors ,1 klok & 2 counters -> kleine adress bus en kleine counter. Daarnaast een snellere uitlezing van het toerental.
Het toerental hoeft in principe maar met 250Hz te worden gemeten (15.000 is max). In principe is het gewoon een freqentie meter, alleen dan met een andere uitvoer. Als je een klok zouw gebruiken van 500Hz dan kan je nog toe met 8-bits techniek en heb je een bandbreete van 30 toeren (lijkt me meer dan zat).
Over de microcontollers:
Tegenwoordig is het een beetje de hype om je circuit in een microcontroller te stouwen, hoe simple het ook maar is. Dit is logish want een pic programeren is makkelijker dan 10 verschillende ic's bij elkaar rapen. Echter voor deze toepassing heb je een behoorlijke snelle pic nodig. Dit zorgt er voor dat ze ook snel worden gestoord door de bobine. Discrete componenten hebben daar minder last van, ten eerste omdat deze veel langezamer werken (1Mhz) en zijn oude TTL chips ongevoelig voor EMC. Dit in tegen stellings tot 'snelle' CMOS ic's die al gestoord worden door een TL-buis. In de luchtvaart word ook voornamenlijk TTL gebruikt wegen deze reden.
Daarnaast is het systeem veel transparanter als je het in discrete componenen opbouwd. Door een conecter er op de bouwen kun je evt ook een extra module (rom) er op bouwen om hem op twee verschillende tijd-stippen te laten vonken. Bij voorbeeld om 45 ATDC, zoals word aangeraden op het macdizzy forum.. Verder kun je er evt ook een tweede cilinder mee aan sturen, simpel weg door er een tweede eprom bij in de pluggen. Als je evt curve wil maken die je kunt aanpassen naar aanlijding van de stand van de gas schuif of een lamba sensor kun je de rom vervangen door een RAM en deze RAM bijwerken via een externe microcontroller. De CDI zelf hoeft niet slim te zij, en naar mijn mening kan je dan ook beter geen microcontroller gebruiken voor deze taak. Ik zie de CDI evt als een module van een groter systeem, niet als de boord computer zelf. De CDI heeft het nl al druk genoeg om het tijdstip te bepalen van de vonk. Door de cdi in dicrete componenten uit te voeren krijg je een heel robust stuk techniek.
Emails:
> Hoi,
>
> Voordat ik je ga bekogelen met vragen zal ik
> me eerst even voortstellen. Ik ben Joost van
> het brommerforum, de "n00b" die een Game-boy
> wou gaan gebruiken als boord computer .
Hey Joost.
> Het id achter de game-boy was niet om er
> een cdi van de maken, echter om hem te
> gebruiken als display voor meerdere singalen.
> Daarnaast wou ik er evt het mogelijk maken om
> de cdi curve via de GB aan te passen, zodat er
> geen aparte computer voor nodig is. Voordeel
> van de Game-boy (collor) is dat het al een
> kant en klaar systeem was. Je hebt een groot
> grafisch kleuren LCD scherm met een interface
> voor slechts 15 euro (kan ze tweedehands
> regelen). Daarnaast zijn er al de wereld aan
> ontwikkelings tools voor de Z80(gb cpu), en
> zijn er ook al diverse C compilers voor dit
> syteem te krijgen. Idiaal dus. Op de standaard
> 'rom' kaart heb ik twee parrallele poorten
> gemaped via 8255, en was van plan om er nog
> een I2C interface op te mappen. Maar wegens
> tijds gebrek en andere bezigheden heb ik het
> hele gedoe in de ijskast gezet.. Meschien dat
> ik er ooit verder mee ga.. ooit
Leuk idee om met een Game-boy te gaan knutselen. Een zeer doordacht idee, maar er zijn 2 nadelen aan de Gameboy, ik zal niet proberen een discussie te beginnen daar is het forum voor hehe maargoed, Gameboy is wel duur en erg
storingsgevoelig. Verder lijkt het een zeur leuk project.
> Maar nu zat ik laasts het scooter forum een
> beetje af te struinen en kwam het topic tegen
> over die zelf gemaakte ontsteking. Op het
> brommerforum zijn we momenteel met een
> gelijkig syteem bezig. Op dit moment zitten we
> nog een beetje in een begin fase dus de
> mogelijk heden liggen nog open.. Ik heb een
> aantal vragen over hoe jullie het vermogens
> gedeelte van de CDI hebben gemaakt.. Het is
> jha zonde om twee keer tegen de zelfde steen te
> trappen.
Ik zal even een kleine uitleg geven hoe ik de CDI heb ontworpen. Het vermogensgedeelte van de CDI is eigenlijk niet meer dan een standaard-CDI, bestaande uit een bruggelijkrichter, wat filters enzo, hoogvermogen condensator etc. gewoon een simpele cdi. Maar in plaats van dat
de CDI intern wordt getriggerd door de sensor bij het vliegwiel wordt het nu aangestuurd via een optocoupler door de PIC. De PIC berekent Verder het exacte tijdstip van ontsteking via vooraf ingestelde tabellen of via een formule(wat een mooiere ontstekingscurve geeft).
> * Ik had gelezen dat jullie de 12v accu
> gebruiken als spannings bron. Hoe converteren
> jullie deze 12v naar 400volt voor het opladen
> van de condensator? Een beetje onsteking trekt
> nl zo'n 4 ampere en de meeste dc-dc
> converters kunnen daar niet zo best tegen..
> En laden jullie de accu op tijdens het rijden
> of na die tijd?
>
> * Hebben jullie de waarde van de condensator
> ook doorgerekend? Dit inverband met de
> ontladings snelheid (rc waarde)? Of maakt dit
> niet zoveel uit?
>
> * Hoe hebben jullie de Pic geprogrameerd
> (asm?), bij 15.000 toeren gaat het namenlijk
> allemaal behoorlijk snel. 0.1 graad vliegt in
> een paar micro seconden voorbij, dus is een
> pic wel snel genoeg voor die nauwkeurigheid?
>
> * Doen jullie het ontladen van de condensator > via een triac of via een transistor?
>
> * Wat voor onderste grens hebben jullie voor
> de ontsteking gesteld (in rpms) ivm het
> starten.
>
> * Hoe vangen jullie de 'wasted sparks' af?
>
> * Hebben jullie de bobine ook aangepast voor
> dit nieuwe vermogen? Meeste bobine's kunnen
> namenlijk een dergelijke continue spanning
> niet, meestal heb je dan een ferriet kern
> nodig ipv metaal.
Nu de vragen:
* Klopt, maar dat zit niet in de CDI zelf, het is een soort add-on waar ik
nog mee bezig ben. De add-on bestaat eigenlijk alleen maar uit een kleine transformator en een paar hoogvermogen condensators. Als je meer hierover wilt weten moet je eens een schema van een stungun ofzo erbij pakken, die dingen halen 10kVolt uit een 9volts batterijtje Ik heb namelijk een schema van een stungun als leidraad gebruikt, alleen dan met wat "snellere"
componenten. De add-on is speciaal voor drag-races, waarbij het echt puur om gasreactie en optrekken gaat. Wanneer je deze plaatst, komt deze in plaats van het vliegwiel en de spoelen. Het enige wat er op komt is dan een kleine
aluminium plaat die aan de krukas zit en een sensor op het carter. De gasreactie wordt behoorlijk versneld doordat de krukas minder belasting heeft omdat het vliegwiel mist.
* De PIC wordt niet direct in assembler geprogrammeerd, ik gebruik een standaard C compiler. In het eerste ontwerp gebruik ik een aardig trage PIC van 4 mhz. Het eindontwerp zal een PIC van 20mhz bevatten die veel sneller
en dus nauwkeuriger is.
* Triac
* Met het starten zal tijdens de testfase worden ge?xpirimenteerd. Hier kan ik nog weinig over zeggen aangezien er meerdere oplossingen zijn.
* De CDI bevat een softwarematig filter die korte mette moet maken met o.a. 'wasted sparks', storing vanaf de sensor, etc.Dit filter wordt tijdens de testfase nog ff fijn afgesteld
* Plan is om een bobine mee te gaan leveren.
Ik hoop dat ik je vragen een beetje heb kunnen beantwoorden. Op dit moment ligt het project hier ook al een tijdje stil vanwege mijn stage,
hierdoor heb ik weinig tijd over maar ik probeer het project eind januari weer op te pakken waarna ik begin met het opbouwen van het eindontwerp en dan zullen de eerste testen worden gedaan.
Een hele lap teks, maar hopelijk het lezen waard. Ik denkt dat het nu het verstandigst is om een een van de bovenste methodes uit te kiezen en dan te beginnen met het onwerp. Mijn voorkeur gaan nu uit naar een aparte counter voor het bepalen van het toerental. Maar die methode van jouw vind ik ook goed, alleen je moet dan nog wel een methode bedenken om te verkomen dat hij twee keer vonkt.. Het belangrijkste is dat het syteem SIM-PEL blijft. Met meerdere sensoren heb je weer meer kans op storing, lijkt mij niet echt verstandig.
[Dit bericht is ge-edit door Joost op 16-12-02 12:52]