Svenska ElektronikForumet

Hej o tack för alla svar. Har inte hunnit svara på allt pga jobb.
Syftet med det här programmet är att jag ska registrera rullarnas hastighet med exakt tid emellan. Själva varvtalsmätningen tror jag inte att jag har några problem med utan det är att mätningarna av varvtalet inte kommer på den exakta tiden jag vill. Jag börjar logga värdena när det är ca 700rpm och jag accelererar så att det är ca 4500 rpm på rullarna. Jag kör med 1 puls per varv (har testat med 20 och 4 men det blev ännu värre) jag kör picen på 20 Mhz och en prescalern på 1:8 på timer1.
Så jag börjar att logga, sparar det aktuella varvtalet, väntar tex 100 millisek, sparar det aktuella värdet, väntar 100 millisek, o så vidare tills att det inte ökar något mera. Sedan ska jag ta skillnaderna mellan dom sparade varvtalen och använder dom i en beräkning för Nm och Hk. Blir det en annan oregelbunden tidsskillnad mellan mätvärdena blir beräkningarna åt skogen.
I grafen nedan så har jag bara tagit skillnaderna mellan mätningarna och som ni ser så blir det väldigt "taggit". Jag kan ha fel att det är tiden mellan som inte blir bra utan att det är mitt program som strular. Alla tips och idéer är välkomna. Jag har tagit till mig allt ni har skrivit o ska försöka med vissa tips. Någon kanske ser direkt på grafen vad jag har gjort för fel!
[img]
http://proxy1.pixbox.se/arkivet/synligt ... 2773.jpg?0
[/img]

Ok, det är förmodligen enklare att mäta ett pulståg än enstaka pulser, så förslagsvis ser du till att du får betydligt fler pulser per varv. Är det rullarna du mäter på som snurrar med säg 4,5 krpm, eller är det motorvarvet. Om rullarna snurrar med 4500 rpm så har du en frekvens 75Hz, vilket ger dig en puls var 13 ms ungefär. Om du mäter var 100 ms, hinner rullarna bara snurra 7,5 varvmellan mätningarna.
Vettigare vore nog att göra tvärtom, ungefär som ett tändsystem för bilar är uppbyggt, dvs en krans med tänder så man får en stadig signal, då kan du laborera med upplösning och samplings perioder på ett helt annat sätt.
Sedan behöver du kika på pulserna med ett oscilloskop, så att du vet att du har rena pulser och ingen skit i signalen.

4500 RPM ger 13,33ms och att vänta 100ms 2 gg ger, som jag ser det, allvarliga fel.

Att inte läsa ut tokmånga värden kan vara helt OK men att _vänta_ i en delay är fel.

13,33 ms motsvarar 12 tecken @ 9600 baud, det borde alltså vara fullt möjligt att, seriellt, överföra varenda mätvärde utan något större problem men om det är för mycket kan jag förstå det, det ville dock ge en mycket bra upplösning och noggrannhet.

Nåväl, jag är ganska säker på att det just är dina delay som är problemet och det kan lösas på olika sätt.

Själva mätningen ska göras som jag beskrev tidigare men det går att lägga till ytterligare en timer som kan ge signal var 200ms vid att flippa en flagga som sedan mainrutinen fångar och detta utlöser då att den skickar det nuvarande mätresultat direkt, då är alla jitter-problem borta.

Problemet med att använda delay till att time funktioner är att den reella tid är delay + tiden det tar att skriva ut (eller vad som nu händer), detta gör att 100ms kan bli 121ms t.ex. lösas detta med interrupt och hårdvaratimer försvinner detta problem och det är bara programmets responstid som bestämmer jitter.

Så grundproblemet är helt enkelt att du har angripit själva mätningen grundläggande fel, resten är följdproblem av detta dåliga val.

Hej!
Att jag skulle göra mätningar med 100 ms mellanrum vad ett exempel jag tog men jag förstår hur ni menar och jag har tagit lärdom av allt ni skrivit.
Ni tyckte att jag skulle ta bort så mycket som möjligt från picen o använda det i pc. Om jag förstår Icecap rätt så skulle det gå att överföra varje mätning utan att missa någon med 9600 baud. Skulle jag inte då kunna att använda pc för att sköta avläsningarna med en viss tidsintervall istället för att ta det i picen?

Se det så: med varenda mätning i PC'n kan du sedan välja o vraka efter bästa förmåga och varje mätning ger en total tid, du kan alltså stega igenom precis som du vill, till och med interpolera för att få exakt 100ms mellan varje mätning om du vill det.

Då blir det så att jag kör med att göra tidsmätningen i pc. Om jag skulle vilja öka pulserna till 20/varv skulle det fortfarande räcka med 9600 baud eller blir jag tvungen att öka det? Hur räknar jag på det?
Tyvärr så kan jag inte testa av det här förrän nästa helg men jag meddelar hur allt gick så fort som möjligt. Tack för all hjälp!!

1 byte är 10 bit och vid 9600, n, 8, 1 kan man sända 960 bytes/sekund som mest.

Minst en unik separeringsbyte lär behövas och sedan är resten en fråga för hur många siffror som behöver sändas, allt som sänds är ju tiden mellan varje puls så när det går som fortast är det samtidig "få" siffror att sända.

Sedan är det bara att du räkna på upplösning (och får fram antal tecken att sända).