Programma herschrijven CDI

Ik heb wel ervaring met zulke dingen, maar weinig tijd om zulke projectjes aan te gaan. Kun je posten wat er nu is, en wat er aangepast moet worden? Als het maar kleine wijzigingen zijn, kunnen we misschien wel helpen.

op deze website staat alles wat er nu is.
In de exelsheet staat ook de gehele code.
www.electronics.gompy.net/cditci

Vergeet ik erbij te zetten wat mis is.
Ten eerste start de timing vanaf 1800 rpm wat relatief hoog is voor een grasmaaier of kettingzaagmotor.
Ten tweede onder de 1800 rpm is het een zooitje met de ontstekingstijd, de ontsteking vliegt van her naar der.
Ten derde is de timing niet zuiver, ik heb bij ~8000rpm een afwijking van 4 tot 7 graden.
Ten vierde si de gekozen 40 graden voor het dodepunt van de pickup is een beetje ongelukkig bij sommige motoren qua montage, variable zou beter zijn.

Mvg, Rob

[Bericht gewijzigd door Rob / gompy.net op vrijdag 19 februari 2010 16:08:12 (66%)]

Die code verdient nu niet direct een schoonheidsprijs zeg; alles op basis van polling, een timer starten en pollen of deze de gewenste waarde al heeft bereikt, een 8-bit timer voor de interval tussen de pulsen, geen filtering op de interval, etc.

Ik zou de interval meten met een hardwarematige input capture op een 16 bit timer (eventueel overflow afvangen), en deze gebruiken voor het berekenen van de hoeksnelheid om de juiste ontsteekhoek vast te stellen, met behulp van een hardware timer. Eventueel een paar druktoetsen om de ontsteking te vervroegen of verlaten, en die instelling in de EEPROM opslaan, zodat je het ding kunt afstellen zonder de sensor te verschuiven.

Ik denk dat alles beter is dan wat er nu is hoewel ik dit ook al heel wat vind......maar dat zal wel komen omdat ik daar net geen sjoege van heb.
De ontsteekhoek wordt berekend in de exelsheet en als vaste waarde in de pic gezet.
Eea is gedaan om het niet te moeilijk te maken voor de gebruikers.
De ervaring leert nu al dat niet iedereen begrijpt wat er gedaan moet worden, het moet dus simpel blijven.
Ook is het belangrijk dat het niet te zwaar wordt, bedenk dat je drukknoppen/display/enz ook omhoog moet slepen als het in een vliegtuigje zit waar iedere gram telt.
Tevens hebben al veel mensen dit schema nagebouwd en in hun model zitten, ondanks de gebreken, dus aan de hardware gelieve niet zoveel veranderen.

Ik kan alleen maar zeggen, ga je gang.....meer verstand heb ik er niet van.

Ik zal wel kijken of ik daar binnenkort tijd en zin voor heb, nu in ieder geval even niet.

Die drukknopjes hoef je er niet vast aan te maken; als het ding vliegt, kun je er toch niet op drukken. Die knopjes heb je alleen nodig om het ding goed af te stellen, en op die manier kun je de afwijking in de plaatsing van de sensor en zo opvangen. Je zou het ook met een RS232 verbinding naar een laptop kunnen doen, als je dat zou willen.

Laptop eraan is wel heel erg luxe )
Als de cdi inprinciepe afgesteld staat doe je er niets meer aan.
Het is geen ding wat je van de ene motor op de andere monteert.
Daarnaast als hij eenmaal goed ingeregeld is doe je er nooit meer wat aan.
Ik denk dat de meeste gebruikers al heel erg tevreden zouden zijn als wat ze nu hebben naar behoren zou werken.
Natuurlijk zijn ze al tevreden met het gene ze nu hebben, het werkt en ze hebben een programmeerbare CDI die voor hobbyisten niet is weggelegd.

Toch alvast bedankt ondanks dat je nog geen tijd hebt.

Mvg, Rob

Beste Rob,

Misschien vind ik het wel leuk om er eens een vrije zaterdag in te gaan steken.
Waar zit je? (Ik zit in regio Eindhoven)

Ik woon halverwege Noord-Holland, niet echt naast elkaar.

Testen doe ik met een electro motortje en een cd'tje met een gleuf welke door een optocoupler draait.
http://www.electronics.gompy.net/cditci/testrig/
Op deze manier hoeft iemand die zelf wat wil knutselen niet over een echte benzinemotor te beschikken.
Qua werking van de cdi maakt het niets uit, de opto is zelfs nog iets nauwkeuriger dan de hallsensor.

Ik heb vast een schema gemaakt van hoe ik een CDI zou willen uitvoeren.
Pinnummers zijn op de + en - na willekeurig gekozen.

Ik dacht dat je de hardware niet meer aan wilde passen?

Als je toch nog de mogelijkheid hebt, zet de ingang van de hall-sensor dan op een pin met input capture functie, en de bobine op een output compare uitgang.

Ik ben wel even bezig geweest met een ontwerp, maar tot dusver weinig code geschreven. Als je nog even geduld hebt, wordt het misschien wel iets. In het ontwerp wordt rekening gehouden met capacitieve en inductieve ontstekingen, en meerdere cilinders die onder een hoek op de krukas staan. De eerste implementatie wordt in ieder geval maar voor 1 cilinder.

Het was de bedoeling eigenlijk ook niet, maar er zijn wat probleempjes met de flybacktransformer.
Bij de een loopt hij als een haas en bij de ander wordt de boel roodgloeiend omdat de oscilator niet wil aanslaan.
Tevens lijkt het erop dat de thyristor zijn eigen leven gaat leiden, zelfs zonder input van de hal vonkt hij er lustig op los.
Is het goed als ik je een PB'tje stuur ?

Mvg,Rob

prima, mijn email adres staat in mijn profiel, die lees ik meestal meerdere keren per dag.

En toen werd het heel erg stil.......

Ja, sorry, beetje druk de laatste tijd, maar ik ben er wel nog steeds mee bezig hoor!

Ik vind het wat lastig om het eisenpakket duidelijk te krijgen, ook omdat er nogal wat mensen zijn met tegenstrijdige meningen / uitspraken en onrealistische eisen. Daarom had ik maar besloten dat ik het ga maken zoals ik denk en vind dat het moet zijn, en wie het daar niet mee eens is, mag het zelf beter doen.

Voorlopig ga ik er van uit dat de sensor goed staat voor de ontsteking bij het starten, aangezien er nogal wat ontstekingsmodules zijn die een bypass hebben voor het starten, waarbij ze ook ontsteken zodra de puls komt.

Een hall sensor of pickup spoel maakt me niet zoveel uit, de externe hardware zal voor de pulse shaping moeten zorgen, en het reageren op de opgaande of neergaande flank wordt instelbaar.

Bij de eerste versie zal het noodzakelijk zijn om de code opnieuw te compileren en laden na het veranderen van de vervroegingstabel of andere instellingen.

De eisen zijn afhankelijk waar de gebruiker de CDI voor wil gebruiken.
Ik vind persoonlijk dat de CDI universeel moet zijn en niet toegespitst op één enkele toepassing.
Mijn gedachten ervoor zijn redelijk eenvoudig van opzet.
Stel sensor staat 50 graden BTDC (eventueel aan te passen in tabel)
Sensor start timer en klokt 1 rotatie.
Als er gestart wordt zal deze rotatietijd zeer lang zijn, in ieder geval langer dan minium toerental van bv 15 omw/sec.
Wanneer de prm is lager dan 15 omw/sec dan zal er een vaste onsteektijd zijn van ingegeven in tabel bv 15 graden BTDC.
Loopt het toeretal op tot boven de 15 omw/sec, dan wardt de rotatietijd, 1 rotatie + vertraging vanuit tabel.
De sensor moet denk ik om technische reden meer dan 40 graden BTDC staan wil je ook bv nog 38 graden zoals de meeste grasmaaiers hebben kunnen instellen.
Op deze manier heb je ook tijd om de pic te laten rekenen en het onsteektijdstip te zetten binnen 1 rotatie.
Simpel gezegt zou ik dit ongeveer in gedachten hebben.

1 -sensor pikt 1e x signaal op = start timer
2 -sensor pikt 2e x signaal op = stop timer
3 -reken tijd van 1 rotaie
4 -als tijd is < 15 omw/sec = vast onsteektijdstip 15 graden BTDC
5 -Als tijd anders dan 15 omw/sec = rotatietijd + tabeltijd

De tabel kan uit 255 tijden bestaan en dus zouden er over een toerental dus ook 255 aanpassingen van het onsteektijdstip kunnen zijn, waarbij ik me afvraag of dat nodig is.
Mocht dit teveel correctie / afwijking van de onsteektijd vergen dan kan het ook met wat minder.

Lang verhaal, ik hoop dat het wat duidelijk is wat de bedoeling is.
Laten we er ook maar vanuit gaan dat wat de rest wil zo iets is, al het andere zijn uitzonderingen die te ver gaan voor een hobby CDI.

Mvg, Rob

Precies, ik wilde het wel vrij eenvoudig houden. Wat ik wel ga proberen, is het ding geschikt maken voor zowel CDI als TDI toepassingen, en voor meerdere cilinders.

Zoals ik ook al (elders) vertelde, maakt de positie van de sensor helemaal niets meer uit, zodra we een betrouwbare en nauwkeurige snelheidsmeting hebben. Vandaar dat het me het handigst lijkt om de sensor goed te zetten voor de ontsteking bij het starten, daarna kan de software wel voor de juiste timing zorgen. De ontsteking kan dan voor of na de puls van de sensor komen, omdat de software constant de huidige snelheid meet, en de positie schat op basis van die informatie. Bij elke puls is de exacte positie bekend, en wordt de geschatte positie gecorrigeerd. De ontsteking is afhankelijk van de geschatte positie, en daarmee dus onafhankelijk van de plaats van de sensor.

Het enige wat nog een beetje lastig is, is dat de hoeksnelheid veel hoger ligt dan bij de toepassingen waar ik eerder iets dergelijke voor gemaakt heb, en het i.v.m. de beschikbare processortijd niet mogelijk is om een loop om de positie te schatten hard genoeg te laten lopen, waarbij eigenlijk gepolled wordt of de huidige positie al de juiste is om een output event te genereren. De juist tijd zal dan toch vooraf berekend moeten worden, waarbij een timer wordt ingesteld die een interrupt of een flank op een uitgang genereert.

Ik denk dat we maar moeten stoppen gezien de voortgang.

Mvg, Rob

Ja, dat zou je kunnen doen, maar ik denk dat dat eerder is omdat jij geen voortgang ziet, dan dat hij er niet is.

Ik heb intussen een ontwerp (in tekst), waarvan ik denk dat het goed gaat werken. Als het goed is, krijg ik van de week wat hardware (programmer/debugger), en heb ik een PIC om mee te testen. Tot dusver had ik alleen hardware voor AVR controllers (en andere controllers die niet interessant zijn voor zo'n project).

Ik moet nog even kijken wat handig is om mee te testen; een CD op een motortje, met een gradenboog erop, een lichtsluis als sensor en een LED aan de uitgang (dat was ook jouw testopstelling, toch?) lijkt me op zich wel te doen. Ik kan ook wel wat testen met een functiegenerator en een scope, en dat ga ik eerst doen, denk ik.

We zijn nu dik 10 weken verder en buiten een paar op- en aanmerkingen is er nog niets wat ook maar op een programma lijkt.
Elmowww laat na 10 weken weten dat hij toch geen tijd heeft en SparkyGSX zwijgt nu ook in alle talen
Heren bedankt voor de medewerking, maar doe in de toekomst geen toezegging naar anderen die jullie toch niet waar gaan maken.
Nu de zomer en het mooie weer er aankomen is het een stuk moeilijker om nog iemand te vinden die achter zijn pc wilt kruipen.

Mocht er nog iemand zijn die wat van programmeren weet, ik houd me aanbevolen.

Mvg, Rob

Ik zit met hetzelfde prbleem, ben geen held in c programmeren en het werken met interrupts, voor iemand met een beetje verstand moet het toch niet al te moeilijk zijn.

Graag zou ik erbij willen hebben:

remote killswitch;
dmv inlezen van ontvanger servopuls op een pen van de pic.

Curves preset
Een 8 polig Dipswitch blokje aan de pic hangen, een 8 tal 0-1 switches. Je zou hiermee in bcd, 256 combinaties kunnen maken. Waarbij je bijvoorbeeld je pick-up offset in graden kunt verstellen.
Of verschillende mappen curves kunt laden.

Tijden start up zou het programma de switch uitmoeten lezen en de juiste tabel laden.

Zo kan je makkelijk in het veld tunen.

Op 19 februari 2010 14:20:59 schreef Rob / gompy.net:
Ik ben samen met iemand aan een project begonnen, hij de software en ik de hardware.
Bij hem is echter een echtelijke knik in de kabel gekomen waardoor hij me niet verder kan helpen.
Nu zoek ik iemand die mij op dit gebied verder helpt, het is dus programmeerwerk.

Ik zal even uit de doeken doen waar we mee bezig waren.
Voor onze modelbouwhobby gebruiken we benzine motoren van bv grastrimmers en kettingzagen.
Op deze motoren zit echter een loei zware ontsteking die ook nog eens slecht af te regel is.
Nu heb ik een stukje hardware gemaakt met een pic (16F628a) en hij heeft de software in C geschreven.
We waren zover dat het werkt, er zouden alleen nog wat kleine aanpassingen nodig zijn.
Aangezien ik nooit heb leren programmeren zijn die regels voor mij acacadabra en ben dan ook niet in staat om wijzigingen aan te brengen.

Wie zou mij en de rest van de modelbouwwereld uit de brand willen helpen en het programma af te maken zoals het was bedoelt ?

Mvg, Rob

Hi Rob,

Zoeven ook al een reactie geplaatst in vergelijkbaar topic van Frederik T.

Ik weet niet veel van CDI's en vervroegingshoeken e.d. maar wil dat wel graag leren. Ook omdat ik zelf een CDI voor mijn motor wil maken.

Ik kan wel meer dan prima uit de voeten met PIC's en C.

Kan ik je ergens mee helpen?

Willem

Mail me maar even.