meedenkers gezocht voor een low rpm counter


Mijn ervaringen met fiets-trainers is dat er altijd ergens een overbrenging in zit voor het vliegwiel, dat relatief gezien, snel ronddraait.

De snelheid daar uit afleiden lijkt mij persoonlijk makkelijker, of inderdaad voor de oplossing van klein is fijn gaan: zo doen ze dat ook in miniDV-systemen kwam ik laatst achter ;)

http://www.m-voorloop.nl --- Ik? Welnee! Ik zit nog lang niet achter de germaniums.
EricP

mét CE

Op een AVR zou ik een counter op een mij passende frequentie laten lopen om die vervolgens op een puls van je trainer uit te lezen en te resetten. Ik kan me zo voorstellen dat je iets ronde de 10kHz ofzo doet. Dan heb je bij 60 rpm een counter van rond de 10000 en ook als je 10x zo hard trapt houd je nog een redelijke waarde over. En ook bij 6x zo langzaam heb je nog geen overflow. En dan ff kijken of je met een 'handige' frequentie (passend met pre-scaler en clock die je zelf denkt nodig te hebben, en een beetje leuk uitkomend in je rekenwerk daarna) weg komt.

Met die waarde kun je vervolgens wel rekenen. Evt. nog wat middelen indien wenselijke. En zo vaak displayen als je zelf nodig vindt.

Als je dat combineert met meerdere pulsen per omwenteling (evt. je counter wat harder laten tikken), dan moet je er wel komen.

Aan jou om het om te zetten naar een pic-ding.

Op 22 september 2017 23:14:02 schreef hadv:
Ik wil een rpm counter maken voor op mijn hometrainer. De verwachte frequentie ligt rond de 1 Hz. De aanwijzing ligt dus ronde de 60.

De uitlezing kan dus gaan van 1 tot 99 waar 60 = 1Hz
Is dat een 7seg display?

(ik gebruik een PIC op 4 MHz....

Interne oscillator of kristal? bij dat eerste zul je iets moeten hebben om te calibreren moest dat gewenst zijn.
Welke PIC?

Eens per minuut vind ik niet voldoende, het moet vaker. Voorlopig ben ik happy met elke 15 seconden, 4 metingen per minuut dus.

De frequentie van uitlezing is volledig afhankelijk van het aantal metingen.
Dat is het eerste wat je zou moeten weten vooraleer te beginnen programmeren en 4 per minuut is volgens mij wat te weinig, vooral als je er zit op te kijken ;)

LDmicro user.

Je moet de CCP mogelijkheid van de PIC gebruiken om de periode tijd te meten. Omrekenen na frequentie en vermenigvuldigen met 60 voor RPM. Op deze manier kan je elke seconde (bij 60RPM) je display updaten met een resolutie van voor mijn part een honderdste RPM (Dus 59.83) alhoewel een tiende mij zinvoller lijkt. Omdat de waardes natuurlijk elke seconde heen-en-weer springen gebruik je een sliding-window-averaging filter (voortschrijdend gemiddelde) om het display rustig te krijgen.
Voordelen ten opzichte van het tellen van pulsen: Veel vaker display updates en een veel hogere resolutie en nauwkeurigheid.

Ik kan wel code posten die zoiets doet in PicBasic (Was een frequentieteller die bijvoorbeeld een frequentie van 1.357 Hz kon displayen zonder daarvoor 1000 seconden pulsen te tellen). Zat volgens mij ook nog een RPM optie in.

[Bericht gewijzigd door JoWi op 23 september 2017 09:21:43 (16%)]

Je kunt toch de capture (CCP module) gebruiken? Daar kun je pulsen vrij nauwkeurig mee meten...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
mel

Golden Member

Waarom nou altijd een microprocessor gebruiken?
Gewoon een TTl telgeval, Werkt in dit geval toch prima?
Is geen rocketscience, :)

u=ir betekent niet :U bent ingenieur..

Niet iedereen wil een schoenendoos vol met losse TTL logica... :)
(terwijl 1 chipje het ook kan. Pulslengtes meten en verwerken met standaard TTL lijkt me niet echt het makkelijkst...)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Als je een teller gewoon laat lopen en een pin-change interrupt regelt als de pin aan de IR sensor verandert... dan heb je gewoon op de microseconde nauwkeurig de tijd voor 1 rotatie.

Het verband is inderdaad niet lineair. Je moet een deling doen.

Op een STM32 zou ik een 32-bit timer op 24MHz laten draaien. Dat gaat "klokkie rond" na 180s, dus dat zit wel goed. Dan heb je dus na ongeveer 1s een resolutie van 1:24M. Je kan dan dus prima het verschil tussen 60 en 60.00003 RPM zien.

Die capture module van de CPU zou je ook kunnen gebruiken. Het is alleen niet nodig. Het geeft niet als je er 1 of 2 clocks naastzit omdat de interrupt opgehouden is door een instructie die 2 cycles duurde (dat kan op een AVR, of een PIC dat ook heeft weet ik niet).

Als je de timer op 1MHz zou zetten, dat rekent even prettig. Dan meet je ongeveer 1M clocks. Deel je 60Miljoen door dit getal krijg je precies je RPM getal. Maar doe je dit met integers, dan is de resolutie wat belabberd: je krijgt 59, 60 of 61.

Je kan nu 600 miljoen delen door het gemeten getal. Nu krijg je het aantal tiende-RPM, bijvoorbeeld rond de 600. Wil je twee cijfers achter de comma, dan is 6 miljard te veel voor 32 bits. Je kan ook de timer iets langzamer laten lopen: bijvoorbeeld 600 miljoen delen door het aantal perioden van 10 microseconde. Dus een timer op 100kHz is al voldoende om prima te kunnen meten met 2 cijfers achter de comma. (bij toerentallen van rond de 1s / 60RPM).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Het lijkt me niet dat een RPM getal met 5 cijfers achter de komma nuttig is of zelfs ook maar gewenst... :)
(beter helemaal geen komma's, is duidelijker in de aflezing)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
hadv

Golden Member

Pic628a, interne klok, 2x16 LCD.
De nauwkeurigheid is niet erg belangrijk, een RPM met een komma is voor mij absoluut niet nodig. Het gaat mij meer om te controleren of ik een beetje regelmatig trap en bij welke trapfrequentie ik in de problemen kom. Zoals mel al zei, het is geen rocketscience.
De suggesties over capture zal ik meenemen, daar heb ik tot nu toe nooit mee gewerkt.
Interrupt on change kan wel, maar is wat lastig ivm het gebruik van i/o door het display, ik gebruik nu RA0 als input voor de pulse.

@JoWi: ik ga gaarne in op je aanbod.

Just find out what you like and let it kill you

Ik zou zoals gezegd de capture interrupt gebruiken; die is daar tenslotte voor...
Ik zou ook wel middelen en/of onwaarschijnlijke waardes eruit filteren, er kan wel eens een hele rare waarde tussen zitten...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Ik zeg niet dat je de gegevens MOET displayen met hoge nauwkeurigheid. Wel is het m.i. fijn om de meting met voldoende nauwkeurigheid te doen.

Als je stabiel wilt trappen dan is als ie tussen 59 en 60 staat te wiebelen dat mogelijk een indicatie van dat je tussen 59.1 en 60.9 staat te schommelen of dat je tussen de 59.9 en de 60.1 zit. Dat verschil kan je niet zien. Nu kan het zijn dat je "tussen 59.1 en 60.9 " prima vindt. Maar ik denk dat als je even probeert netjes te fietsen je binnen 0.5 RPM nauwkeurig kan blijven. Dat kan je alleen maar zien als je iets nauwkeuriger displayed. Maar nauwkeuriger meten kan je ook helpen om bijvoorbeeld een rustiger display te maken.

In ieder geval kan een standaard PIC of AVR zonder extra toeters en bellen gewoon ruim nauwkeurig genoeg meten.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
hadv

Golden Member

OkOk, ik zeg met enige regelmatig dat het wel handig is de datasheet en het maunal te lezen. Met het schaamrood op de kaken beken ik nu dat ik dit dus ook niet helemaal heb gedaan.
Ik kwam er, toevallig, achter dat PicBasic hier gewoon een oplossing voor heeft:
resultaat = Counter Pin, Period.
Period is de tijd dat je wilt meten.

Just find out what you like and let it kill you

Ik zou verwachten, gezien de argumenten van de functie, dat ie telt hoeveel pulsen er langskomen in de opgegeven periode. Geef je 1s op en trap je 59 RPM, kan je 60 of 0 terugkrijgen, trap je 61, krijg je 60 of 120 terug. Dat denk ik hoor.

Afhankelijk van de toepassing moet je even iets beter nadenken over hoe de meting moet geschieden. Dus bij zulke "laag RPM" dingen, dan zou ik denken: NIET meerdere magneten op een omwenteling monteren. Je wilt steeds precies dezelfde magneet meten (of wat je meet-methode ook is. Als ik het zou maken gebruik ik de magneet en sensor van de union fietscomputer die ik al heb liggen.) En dan dus op basis van de tijd de RPM uitrekenen.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
hadv

Golden Member

je hebt gelijk waar het gaat om de periode. maar ik ben helemaal niet van plan om maar 1 sec te meten, het worden er minstens 5.
Ik zit wel degelijk na te denken over meerdere pulsen per omwenteling.
Afijn, we gaan het zien bij het uitproberen.

Just find out what you like and let it kill you

Als je twee inductieve sensors boven elkaar plaatst aan de staande framebuis en de ene naar de L krank kijkt en de andere naat de R heb je je aantal verdubbeld en weet je meteen of je vooruit trapt of terug of dat de trapper alleen maar heen en weer wiebelt.

Ik heb vroeger zoiets gemaakt maar dan met een 7 segment display.
Moest je ooit interesse hebben dan wil ik hier wel de hex-file posten als je mij het aantal impulsen per toer opgeeft.
Hieronder hoe het schema eruit ziet.

edit: zoals je kunt opmerken gebruik ik voor veel schakelingen hetzelfde schema met minieme aanpassingen.

[Bericht gewijzigd door MGP op 28 september 2017 20:30:41 (20%)]

LDmicro user.
hadv

Golden Member

Even een update.
Ik heb wat zitten struinen op het web en kwam tot een zeer simpele oplossing. Zo simpel dat ik niet begrijp waarom ik daar zelf niet op was gekome, ware het niet dat ik nooit zo naar een timer had gekeken.

Wat is het:
configureer timer0 als een counter
sluit de externe pulsbron aan op T0CKI
selecteer 8 bit
selecteer de gewenste flank modus
vervolgens

pic basic code:


while
   delayms 10000
   print at x,y, dec TMR0L
wend

Maar nu zit je nog met het debouncen, dat lukt zo natuurlijk niet in code.
Dus ik ben op zoek gegaan naar een hardware debouncer en één gevonden die prima werkt.
https://www.uploadarchief.net/files/download/hw-debouncer.jpg.
Met de weerstand en condensator waarde is het een kwestie van experimenteren tot je het lekker hebt werken. Deze waarden zijn voor gebruik met een microswitch.

Just find out what you like and let it kill you

Ik maakte die dingen vroeger wel eens in een plc
Elke puls de tijd in een schuif register zetten

bv 10 metingen , daarna gem van de 10 metingen.

Lijkt mij voor een pic niet zo moeilik

... maar tricky als je het signaal als een input voor een hardware module (hier timer) wilt gebruiken.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Ik zie dit topic nu voor het eerst, dus misschien komt het als mosterd na de maaltijd, maar waarom neem je niet gewoon een fietscomputertje? De wielmaat stel je dan zo in dat het getal in km/u overeenkomt met de rpm.

Alleen een c'tje over de switch is genoeg in dit geval (extra diode en weerstand heeft alleen nut als je de open/sluit vertraging apart wilt instellen)
Vertraging van 10...20mS werkt normaal gesproken prima.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
hadv

Golden Member

@klaasz: lichtelijk overdreven, er zit al een 'computertje' op die fiets, alleen geen toerenteller. Bovendien is het een hometrainer, en die heeft geen wielmaat.
@arco: daar ben ik mee bezig geweest, maar ik kreeg niet het resultaat dat ik zocht

Just find out what you like and let it kill you

Op 27 oktober 2017 22:52:22 schreef hadv:
Bovendien is het een hometrainer, en die heeft geen wielmaat.

Die hoeft ook helemaal geen wielmaat te hebben. Je moet een wielmaat invullen die het juiste getal op het display laat zien.

Als je het met 1 c'tje niet goed krijgt, heb je de delay waarschijnlijk veel te lang gekozen...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com