meedenkers gezocht voor een low rpm counter

hadv

Golden Member

Ha lieden,
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.
Ik ben aan het klooien met een uC en heb nu een idee van hoe ik het wil hebben.
De sensor is een combinatie IR Led/IR fototransistor die op de kast wordt bevestigd en een stuk zilvertape op de trapper. Dit soort mechanismen heb ik al eerder toegepast, dus ik weet dat ik het wel aan de praat krijg.

Maar nu de firmware
Ik laat op de achtergrond een timer lopen (ik gebruik een PIC op 4 MHz, dat wordt Timer1). Deze heb ik intussen zodanig afgeregeld dat de firmware "weet" wanneer er een seconde voorbij is (en dus ook wanneer er een minuut voorbij is).

Maar nu zit ik te piekeren over het tellen van de IR pulsen en het tonen van de RPM. Eens per minuut vind ik niet voldoende, het moet vaker. Voorlopig ben ik happy met elke 15 seconden, 4 metingen per minuut dus.

Ik dacht er aan om een array van 4 variabelen te gebruiken waarbij er altijd wordt geteld in index 0. Na 15 seconden worden de getelde waarden opgeteld en wordt het totaal aantal getelde pulsen op een display getoond. Daarna worden de getelde waarden 1 positie naar 'rechts' geschoven.

Is dit een goede aanpak of kan het beter/slimmer of zijn er nog andere tips/aanmerkingen/opmerkingen waardoor ik wat beter kan maken.

Bij voorbaat dankz & groets
Harm

Just find out what you like and let it kill you

Gewoon de tijd tussen twee pulsen meten met voldoende nauwkeurigheid.
Dat omrekenen.

Henri's Law 1: De wet van behoud van ellende. Law 2: Ellende komt nooit alleen.
klein is fijn

Moderator

Als je meer resolutie wilt kan je ook meer reflectoren op de as plakken. Een makkelijke manier daarvoor is een zwart / wit streepjespatroon uitprinten op een strook papier en deze om de as heen te plakken.

Met lage frequenties kan je beter de tijd gaan meten tussen 2 pulsen.
En dan kan je eventueel per puls weergeven of per 2 3 of 4 enz. Het gemiddelde weergeven

hadv

Golden Member

Ik heb al geëxperimenteerd met de tijd tussen pulsen te meten, dat was mijn eerste opzet, maar kwam daarbij niet uit op een lineair verband. De pulsen werden gegenereerd door een 555 schakeling. Waarschijnlijk te onbetrouwbaar door het telkens opnieuw moeten configureren van die schakeling.

@kif: dit snap ik niet, het gaat hier om de as van de trapper naar de aandrijfas. Wat wel zou kunnen is een encoder wiel op die as monteren. Dank voor het op een interessant spoor zetten.

Just find out what you like and let it kill you

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/