Timen met microcontroller (voor CDI)

Dat lijkt mij een zeer uitdagend project.

Volgens mij kan dat prima met een microcontroller.
Ik zou je willen adviseren een pic uit de 18 serie te nemen.
Die kunnen goed met tabellen omgaan en hebben een multiplier.

gemeten 
tijd x		
sensor  
L-C		
in µs	a	b
20000	1	0
18182	1	0
16667	1	0
15385	1	0
14286	1	0
13333	1,7	-10000
12500	0,95	0
11765	0,95	0
11111	0,95	0
10526	0,95	0
10000	0,95	0
9524	0,95	0
9091	0,95	0
8696	0,95	0
8333	0,95	0
8000	0,95	0
7692	0,95	0
7407	0,95	0
7143	0,95	0
6897	0,95	0
6667	0,95	0
6452	0,95	0
6250	0,95	0
6061	0,95	0
5882	0,95	0
5714	0,95	0
5556	0,892	333,333
5405	0,892	333,333
5263	0,892	333,333
5128	0,892	333,333
5000	0,892	333,333
4878	0,892	333,333
4762	0,892	333,333
4651	0,892	333,333
4545	0,892	333,333
4444	0,892	333,333
4348	0,892	333,333
4255	0,892	333,333
4167	0,892	333,333
4082	0,892	333,333
4000	0,892	333,333
3922	0,892	333,333
3846	0,892	333,333
3774	0,892	333,333
3704	0,892	333,333
3636	0,892	333,333
3571	0,892	333,333
3509	0,892	333,333
3448	0,892	333,333
3390	0,892	333,333
3333	0,892	333,333
3279	0,892	333,333
3226	0,892	333,333
3175	0,892	333,333
3125	0,892	333,333
3077	0,892	333,333
3030	1	0
2985	1	0
2941	1	0
2899	1	0
2857	1	0
2817	1	0
2778	1	0
2740	1	0
2703	1	0
2667	1,123	-333,333
2632	1,123	-333,333
2597	1,123	-333,333
2564	1,123	-333,333
2532	1,123	-333,333
2500	1,123	-333,333
2469	1,123	-333,333
2439	1,123	-333,333
2410	1,123	-333,333
2381	1,123	-333,333
2353	0,983	0
2326	0,983	0
2299	0,983	0
2273	0,983	0
2247	0,983	0
2222	0,983	0
2198	0,983	0
2174	0,983	0
2151	0,983	0
2128	0,983	0
2105	0,983	0
2083	0,983	0
2062	0,983	0
2041	0,983	0
2020	0,983	0
2000	0,983	0
1980	0,983	0
1961	0,983	0
1942	0,983	0
1923	0,983	0
1905	0,983	0
1887	0,983	0
1869	0,983	0
1852	0,983	0
1835	0,983	0
1818	0,983	0

Hier is een tabel
het is de bedoeling dat de PIC de tijd gaat meten tussen sensor L en C, en als de tijd groter of gelijk aan het getal in de eerste kolom, maar kleiner dan het getal erboven, moet het met de waarden A en B uit dezelfde rij de formule y=ax+b oplossen

dus als er een tijd gemeten wordt van 3265µs (ongeveer 6125.5 tpm), dan is a 0,892 en b 333,333, en dus y= 3246µs (en dat komt overeen met een vervroeging van 20,7°)

nu moet dus de PIC vanaf sensor R beginnen te tellen tot 3246µs, en dan een uitgang hoog maken

gaat dit met een PIC, en is er iemand die mij hierbij wilt helpen? (van PIC's en het programmeren ervan ken ik niks, maar ik wil het wel kennen)

Een timer op een bepaald punt starten. Bij een verandering de teller uitlezen, in jou voorbeeld 3265µs. Daarna de teller opnieuw starten en controleren wanneer deze de 3246µs heeft bereikt en dan actie ondernemen.

Overigens ga je het met een pic-processor nooit op 1µs nauwkeurig krijgen. Daar zijn ze veel te traag voor. Ooit gedacht om het op te lossen met een fpga? Het maakt het project waarschijnlijk een stuk ingewikkelder, maar ik denk dat het wat betreft timing dan een heel eind in de buurt komt.

hoe snel kan ik timen met een PIC? op 11000 toeren (wat mijn motor waarschijnlijk nooit haalt) komt 1 graad overeen met 15,15µs, en ik had toch op de hoogste toeren een maximale tolerantie van 0,25° gehad, dus 4µs mag hij er desnoods naast zitten op de hoogste toeren

in de PIC microcontroller tutorial bij artikelen staat dit

Een µC loopt net zoals je pc op een bepaalde frequentie. Dit heet de klokfrequentie. Alle bewerkingen van de µC lopen op dat signaal. Om het juiste clocksignaal aan te bieden kun je een oscillator aansluiten zoals te zien is in de onderstaande afbeelding. Intern wordt de frequentie van de clk door 4 gedeelt en de uitkomst daarvan is de snelheid waarmee instructies worden uitgevoerd. De reden hiervoor is dat de interne processor een instructie eerst moet ophalen en decoderen voordat deze het daadwerkelijk kan gaan uitvoeren. Zou je dus een externe clock van 4MHz aansluiten dan worden de instructies uitgevoerd met 1MHz, en dat is dus 1 instructie per 1µs. Hieronder zie je hoe een externe clock (kristal) wordt aangesloten.

voor zover ik begrijp kan het dus?

[Bericht gewijzigd door Henry S. op donderdag 8 april 2010 20:16:42 (21%)]

Heb ook ooit zoiets gedacht. Leuk idee. Kun je er mappings inzetten e.d.

Is het geen idee om het met een PLL oid te doen? En dan de faseverschuiving af te regelen met de uC. Zo hoeft je uC niet 'synchroon' te lopen met je krukas en blijft je motor ook goed lopen als de uC even met wat anders bezig is.

Wordt natuurlijk helemaal gaaf als je je gasstand, spruitstuk onderdruk , lambda sensor allemaal als input hebt naar een x-dimensionale mapping en daarmee pulsbreedte van je injector ook kan moduleren (tov van originele signaal)...

Toevallig ben ik nog met zo'n projectje bezig (zie dit topic: http://www.circuitsonline.net/forum/view/81962).

Op zich hoeft het helemaal niet zo moeilijk te zijn, maar er zijn een aantal zaken waar je goed over na moet denken.

Ik gebruik de input capture functie, om het exacte tijdstip van de flank van de sensor vast te stellen, en een output compare op dezelfde timer voor het sturen van de uitgang. Het voordeel hiervan is, dat de tijd die je code nodig heeft, niet kritisch is. Na het optreden van de flank, hoeft de code alleen uit te rekenen wat het juiste tijdstip voor de volgende flank aan de uitgang is. Zolang de code maar snel genoeg is, en dus op tijd is met het instellen van de timer, zal de timing altijd kloppen. De tijd die je nodig hebt voor het uitvoeren van de code is dan dus geen onderdeel van de vertraging.

Ik betwijfel ten zeerste of je een PIC uit de 18 serie nodig hebt; een paar getallen opzoeken in een tabel in de EEPROM of flash hoeft helemaal niet lang te duren, en we hebben het over 1 hele vermenigvuldiging die je moet uitvoeren. Daar heb je echt niet meteen een hardware multiplier voor nodig.

Als je het op de manier maakt die M14 beschrijft, ga je de nauwkeurigheid inderdaad niet halen. Je moet ook niet zelf in software controleren of de tijd al verstreken is, daar heb je hardware voor.

Met het juiste gebruik van de hardware, kun je een resolutie van 200ns halen, dus met de maximale afwijking in zowel de input capture als de output compare periferals, zit je er 400ns naast (of eigenlijk, tussen de -200 en +200us).

Dat je 1us "nooit" gaat halen, is dus bullshit, als je het ook maar een klein beetje slim aanpakt.

Hmz, had idd niet aan die compare functie gedacht. Dan zou het idd moeten lukken om die tijden te halen. Enige waar je mee zou kunnen zitten is bij hele lage toerentallen. Had net snel een berekening gemaakt, met een 40MHZ klok en timer1 op 1:8 krijg je, met 1 puls per rotatie, onder 19rpm een probleem. Met 3 pulsen per rotatie zou dat op ongeveer 6.3rpm uitkomen. Voor een motor zou dat geen probleem moeten zijn lijkt me.

Ik zou de timer gewoon zo hard mogelijk laten lopen, het is niet alsof het moeilijk is om softwarematig de overflows te tellen of zo.

Op 8 april 2010 23:41:32 schreef M14:
Had net snel een berekening gemaakt, met een 40MHZ klok en timer1 op 1:8 krijg je, met 1 puls per rotatie, onder 19rpm een probleem.

Hoe langzaam kan jouw motor dan wel niet blijven draaien?
Onder je ondergrens die je kan halen zet je de ontsteking toch gewoon vast op een bepaalde waarde, daar maakt het overigens ook niet veel uit...

Ben zelf ook van plan iets te maken waarbij ik een map nodig heb ifv toerental en andere waarde, maar bij mij komt het zo strikt ook weer niet. Ik telzoals Sparky zegt ook mijn overflows, want op lagere toerentallen maakt het allemaal niet veel uit. controleer dus gewoon op overflow en stel dan vast in. (tijd is mijn ergste vijand in dit project)

ik ben ondertussen nog bezig geweest met hoe ik dit kan gaan doen. Van microcontrollers en de programma's ervoor ken ik nog steeds zeer weinig, maar het begint te beteren

ik heb gelezen dat ik de tijd tussen 2 sensoren gemakkelijk kan timen met de CCP module van sommige PIC's, maar hoe dat werkt, weet ik (nog) niet

ook ben ik bezig geweest met Crocodile Technology 3D (omdat je daarvoor niks hoeft te kennen over prgorammeren en toestanden), en daarheb ik de functie pulsin gebruikt, die meet de pulsbreedte. Als ik een RS flip-flop gebruik, met sensor L als set en R als reset, krijg ik een puls die net zo lang duurt als de tijd die ik kan meten met de CCP module (ik zal maar een tekening bij mijn rare uitleg voegen), of is het beter dat ik met de CCP module werk

alleen weet ik niet hoe ik de gemeten waarde kan vergelijken met de waarden in de tabel, kan iemand mij hiermee helpen, ik heb tot nu toe hier nog niks zinnig gevonden op het net (of zoek ik slecht)

hier dus de tekening; (op klikken als je hem wat groter wil)

effe off topic in m'n eigen topic, de TL lamp die hier boven mijn hoofd hangt (een nieuwe, de vorige was al een heeele tijd kapot) zoemt verschrikkelijk, is daar iets aan te doen (en dus niet gewoon het licht uitzetten, want dan zie ik niks)

EDIT; ik heb lang moeten zoeken eer ik mijn topic terug gevonden had, is het de gewoonte hier dat topic's verplaatst worden zonder de topicstarter hier iets van te zeggen?

en de delay tijd (pause) is ook nog verkeerd zie ik, dat moet dan X zijn IPV die 2 sec die er nu staat

en het zoemen boven mijn hoofd is plots gestopt (nee, ik heb het licht niet uitgedaan)

en de rotor draait linksom

Op 13 april 2010 22:22:53 schreef Frederik T.:
alleen weet ik niet hoe ik de gemeten waarde kan vergelijken met de waarden in de tabel, kan iemand mij hiermee helpen, ik heb tot nu toe hier nog niks zinnig gevonden op het net (of zoek ik slecht)

Deel ze op in verschillende waarden die in in een eerste kolom zet, controleer dan in welk interval je zit en neem de waarde uit kolom2 van die rij... of als je het juister wil doen maak je ook nog interpolatie (lineair) tussen je ingevulde punten.

ben ook een hele tijd bezig geweest om dergelijke zaken uit te zoeken,
totdat ik op internet een volledig programeerbare ontsteking vond
van rond de 160 euro ( 20 maand terug )
je kan er alles aan hangen, alles is instelbaar
cdi of dci enz enz
afstellen en instellen met de pc (usb).

voor die prijs ga ik echt niet meer prutsen..
(imfsoft)

het probleem is vooral dat voor mijn motor maar 2 electronische ontstekingen gemaakt wErden, 1 vind je soms nog nieuw, maar is niet meer dan een omgebouwde voor een andere motor die niet altijd even goed werkt, en de andere wordt zelden verkocht.
en voor 160 euro kan ik zeker nog wel zelf prutsen, de sensoren hebben mij 5 dollar per 15 gekost, en de rest van de electronica is rond de 50 euro, en daarbij komt dan nog eens dat zelf maken stukken plezanter is (en ineens leerrijker als ik achteraf met PIC's kan werken)

ja ben ik wel met je eens, maar ik had wat gebrek aan tijd,
ik weet hoeveel tijd er in gaat zitten om iets dergelijks te maken,
nog veel meer tijd om het ook goed te maken..
ik houd het bij het vorige
...... ik ben benieuwd wat het wordt.

ik ben weer wat verder met behulp van crocodile 3D
ik denk dat dit zo ongeveer niet al te verkeerd is? alleen kan crocodile niet vermenivuldigen, een PIC kan dat toch wel hoop ik?

symbol x = b0

main:
label0:		pulsin 0,1,x			hij meet de pulsbreedte, maar wat is de eenheid, en wat is de 0 en 1?
		if x < 1818 then label3
		if x < 1835 then label4
		if x < 1852 then label5
		if x < 1869 then label6
		...				gewoon hetzelfde, alleen de getallen veranderen		
		if x < 20000 then label103

label3		let x = x + 0,983		moet niet plus maar vermenigvuldigen zijn
		let x = x + 0
		goto label1

label4		let x = x + 0,983		moet niet plus maar vermenigvuldigen zijn
		let x = x + 0
		goto label1

label5		let x = x + 0,983		moet niet plus maar vermenigvuldigen zijn
		let x = x + 0
		goto label1

label6		let x = x + 0,983		moet niet plus maar vermenigvuldigen zijn
		let x = x + 0
		goto label1

...						gewoon hetzelfde, alleen de getallen veranderen


label103	let x = x + 1			moet niet plus maar vermenigvuldigen zijn
		let x = x + 0
		goto label1

label1		if Input1 is On then label2
		goto label1

label2		pause x
		high 0
		low 0
		goto label0

hier de bijhorende flowchart gedoe in Crocodile, alleen de flowchart is veranderd, de rest is nog gelijk aan de vorige afbeelding;

de getallen zijn wel een beetje veranderd

Als de cpu zo bij het hoogste toerentaql elke keer bijna 100 If statement moet doorlezen die elk uit 3 instructies voor de cpu beslaan zit je al aan 300 klok cycli dat is op 40Mhz 30µS dat is te langzaam als je binnen 11000 toeren wilt blijven (15µS)

JE bent misschien sneller al je een geheugen neemt. Zet dan op geheugen adress 1818 de waarde 1818 toeren. JE hoeft dan enkel maar een extern geheugen uit te lezen.

Ik weet enkel niet hoe snel je serieel geheugen uit kan lezen.

HEt verloop van die reeks zit daar niet een formule achter of heb je die waarden zelf bepaald. Als je daar een formule bij hebt kan je daarmee een getal uitrekenen en met dat getal direct naar een geheugen plaats springen.

Daarom ben ik begonnen met de kleinste waarde (dat komt overeen met de hoogste toeren) vanboven, als hij die waarde meet, gaat hij (hopelijk) de overige 100 if statements overslaan
achter de getallen zitten een hoop formules, maar ook een getal dat zelf in geven is.

[Bericht gewijzigd door Henry S. op zaterdag 17 april 2010 01:31:11 (0%)]

De toerentallen 1:1 naar geheugen mappen, gaat waarschijnlijk niet, aangezien je dan wel heel erg veel geheugen nodig hebt. Je zou de laagste 4 bits kunnen negeren, maar dan is de stapgrootte bij lage toerentallen al weer vrij groot.

Een binary search algoritme zou al beter zijn; je neemt dan een array van de toerentallen, en doet een spelletje "hoger-lager". Getal tussen de 0 en 100 -> je kiest 50 -> lager -> je kiest 25 -> hoger -> je kiest 37 -> lager -> etc. tot je de juiste waarde gevonden hebt.

Dat is nog altijd een stuk trager dan in een keer uitrekenen waar je in de array moet zijn, maar je hebt dan wel vrijheid in de stapgrootte.

Nu zitten jullie het probleem dat een PIC te traag is voor dit doeleind. Maar een PIC is ook traag. Kijk eens naar een AVR die is een tandje sneller. Desnoods een M3 cortex controller die heeft intern een PLL en kan op 72MHz draaien. Geen probleem.

begin bij het juiste begin...

De toerentallen 1:1 naar geheugen mappen, gaat waarschijnlijk niet, aangezien je dan wel heel erg veel geheugen nodig hebt.

20.000 Als grootste getal komt overeen met 20kB. Dat is toch helemaal niets speciaal voor een geheugenchip. Maar een algoritme zou wel beter zijn. Kies de toerental volgens een formule.

Je kan een geheugen indelen in blokken van bv 32kB met elke keer andere timings voor relax, normaal en sportief rijden

EDIT
Ik zie nu mijn probleem. Als er per meting 4 bytes aan info nodig is kom je inderdaad aan een stuk meer geheugen. Maar moet ook nog wel te doen zijn.

[Bericht gewijzigd door benleentje op zaterdag 17 april 2010 16:28:37 (15%)]

4 bytes is wel wat veel, met 2 bytes kom je er ook wel, denk ik. Het zou inderdaad wel kunnen als je een controller met 64k flash neemt. Met een 32k controller kom je wel ook wel, als je de grens op 14-15k RPM legt. Daarbij is natuurlijk niet gezegt dat je perse in RPM moet indexeren, en zelfs als je dat doet, is het een beetje zinloos om een andere waarde te hebben voor 1 omwenteling per minuut meer of minder. Je zou ook RPM / 4 (of 8, 16, whatever) kunnen gebruiken. Over het algemeen ga je toch niet vervroegen voor 1000-1500 RPM, bij een motor met een kleine cilinderinhoud. Met een grotere cilinderinhoud begin je wel eerder, maar die kunnen weer lang geen 20k RPM halen. Bij 1500 RPM en een entry voor elke 8 RPM heb je maar een afwijking van ~0.5% (in de snelheid, niet in de absolute timing). Dat lijkt me zeker acceptabel.

Dat een PIC te traag is, is echt volkomen onzin, dan moet je alleen wat slimmer programmeren. Een PIC is te traag om 100MByte data per seconde te verstouwen, hoe slim je ook programmeert. Een pulsje in en uit met een maximale frequentie van 333Hz is gemakkelijk te doen. Als je de juiste hardware gebruikt, kun je de timing op 62.5ns (1/16MHz) nauwkeurig krijgen. Bij 20k RPM is dat ruim 48000 delen per omwenteling.

Je moet natuurlijk wel zorgen dat de berekening op tijd is uitgevoerd, maar bij dergelijke hoge snelheden maakt het niets uit als de berekening een omwenteling achterloopt. Je kunt steeds het resultaat van de berekening bufferen, en op het moment dat je de timer in moet stellen voor de volgende vonk, pak je gewoon de meest recente berekening. Als je daar ook nog een klein FIR of IIR filtertje bij maakt, springt de ontsteking ook niet zo heen en weer.

Voertuigen hebben het vele jaren moeten doen met contactpuntjes en mechanische vervroegers, die waren bij lange na niet zo nauwkeurig, en dat liep ook prima, het was alleen een beetje slijtage gevoelig.

Sparky je uitleg is erg verhelderend.

Label 3 4 5 en 6 zijn allemaal gelijk: dat ga je toch anders doen?!?!
Volgens jou tabel heb je eigenlijk maar 7 Labels nodig

Waarom doe je niet:

If T < 2381 and T > 1818 THEN Goto label1
If T < 2703 and T >= 2381 THEN Goto label2
If T < 3030 and T >= 2703 THEN Goto label3
If T < 5714 and T >= 3030 THEN Goto label4
Etc.

Verder nog een reaktie op pulsin :

PULSIN 12 14 16

Syntax

Variable = PULSIN Pin , State

Overview

Change the specified pin to input and measure an input pulse.

Operators
Variable - a user defined variable of type bit, byte, byte array, word, word array, dword or float.
Pin - a Port.Pin constant that specifies the I/O pin to use.
State - a constant (0 or 1) or name HIGH - LOW that specifies which edge must occur before beginning the measurement.
Example

DIM VAR1 as BYTE
Loop:
VAR1 = PULSIN PORTB.0 , 1 ' Measure a pulse on pin 0 of PORTB.
PRINT Dec VAR1 , " " ' Display the reading
GOTO Loop ' Repeat the process.

En over de waarde van pulsin:

The units are dependant on the frequency of the crystal used. If a 4MHz crystal is used, then each unit is 10us, while a 20MHz crystal produces a unit length of 2us.

Dus ligt er aan welk kristal je gebruikt

labels 3,4,5 en 6 zijn in dit geval hetzelfde, het zou kunnen dat deze getallen veranderen
en als de gemeten tijd T kleiner is dan de waarde, gaat hij naar de aangegeven label, is hij groter, dan gaat hij naar het volgende statement, hij hoeft niet nog eens te controleren of de tijd echt groter is dan de vorige waarde

Maar klopt de code voor de rest een beetje (stel dat de PIC snel genoeg is)
en wat is de eenheid van de gemeten pulsbreedte (wat de 0 en 1 is weet ik ondertussen)

[Bericht gewijzigd door Henry S. op vrijdag 23 april 2010 19:31:31 (37%)]