Hej,

Om du kör PHP så kan du använda det här:

http://members.aol.com/barryaandrew/baa ... guide.html

Använder det själv.

Mvh
JR

Tack för hjälpen Bearing, nu fungerar det!

Nu ska jag snygga till koden och lägga till lite user input möjligheter.

Återkommer säkert med fler frågor!

Sodjan:
Tanken var rätt, designen var fel.


//J-R

Jag är endast i interrupt rutinen i max 2ms. Jag ser det inte som ett problem att vänta där tills jag får andra passeringen. Jag har ett annat (läs ett till..) problem som jag inte får till. Jag använder Mikroc och deras inbyggda bibliotek. Problemet är att jag inte kan visa det uträknade värdet på ...

Tack för svaren. Läst på lite till om timers och tänker följa bearing's råd och använda Timer1 istället. Ny kod. Tar gärna kritik så man kan förbättra koden. Sodjan: Tanken är att trigga interrupten på RB0 (sensor 1) och avsluta interrupten mha sensor 2 på RB1. Får jag owerflow flaggan satt på Timer...

Har börjat lite smått att skriva kod men jag behöver lite hjälp med hur jag ska räkna ut hur lång tid varje loop tar. Vet jag tiden för varje loop så kan jag enkelt räkna ut tiden mellan när RB0 aktiveras och när RB1 aktiveras. Jag triggar interruptet på RB0 och ökar tmr0 tills RB1 blir hög. void in...

Vad tror ni om den här komponenten som sensor?

Har inbyggd schmittrigger, kan driva TTL kretsar direkt.

Fairchild QSE157. Vet inte om man får tag iden i Sverige.

Mvh
J-R

Ja, det är precis så jag tänkte göra.

Vet bara inte riktigt vilken typ av givare/sensor jag ska använde för att detektera passagen.

Det finns redan (självklart) komersiella kronografer och jag tror att dom använder någon form av foto/IR/xx-detektor, dvs inte ljud (mikrofon).

En tänkbar lösning skulle kunna vara att använda någon typ av gitter (tänk ljusridå) som detektor men vet inte om det skulle vara tillräckligt snabbt.

//JR

Grym, tror du det är bästa alternativet med en HW-räknare? Tänkte försöka hålla ner antalet komponenter.

Angående hastigheten så tänkte jag i första hand på pistol och där håller man sig runt 300 m/s.

//JR

Jag "tror" inte att själva programmeringen blir så komplicerad utan misstänker att det är detekteringen som kommer att bli den största utmaningen.

Tack grym, självklart är det som ni skriver!

Mvh
Jari

Jag är med på det.

Om jag vill ha en upplösning på 1m/s (som Swech skrev) så behöver jag en samplingstid på minst 100 kHz.

Var otydlig där. Tanken är att ha två givare där kulan passerar. Endast en kula åt gången. "Flygtiden" mellan givarna blir 1,6 ms och då måste man hinna detektera passagen på båda givarna. Tanken är inte att registrera fler kulor på samma gång. Eller tänker jag fel? Edit: Tack grym Mvh JR

Hej, Jag tänkte börja på ett projekt med en PIC (inte bestämt modell ännu) där jag ska mäta hastigheten på en kula, en s.k kronograf. Principen är enkel. Mät tiden under en given sträcka och du har vad du behöver. Hastigheten på kulan kommer att röra sig runt 300 - 400 m/s. Om sträckan är 0,5 m vid ...