iS my photoresistor (LDR) too slow ? || tachometer

Hi guys

I've been making an optical tachometer, trouble is it can't seem to read fast RPM's like those of an average motor you get in a starter kit, it can read up to like 3000 RPM, but beyond that it's all over the place

my test motor has a 2 slot circle with an LED shining through onto the LDR, and the motor is powered by battery to rule out interference ( I thought at least :D). I tried different slot sizes to no avail.
Is my code alright? if so, is there fast and slow LDR's or something?

unsigned long time=0;
unsigned long time2=0;
unsigned long rpm;
unsigned long period;
int counts=0;
int potpin=1;
int motorpin=10;
int motor;
unsigned int runs=0;

void setup(){
Serial.begin(9600);
attachInterrupt(0,ping,RISING);
}

void loop(){
motor=analogRead(potpin);
motor=map(motor,0,1023,0,255);
analogWrite(motorpin,motor);
if(runs>2840){ // this no. of runs means it takes exactly 500 millis
noInterrupts();
time2=micros();
period=time2-time;
rpm=counts*60000000;
rpm=rpm/period;
Serial.print(period);
Serial.print(" ");
Serial.print(counts);
Serial.print(" ");
Serial.println(rpm);
counts=0;
runs=0;
time=micros();
interrupts();
}
runs++;
}
void ping(){
counts++;
}

thanks!!

CDS cells are very slow having a maximum speed of around 30 times per second (at best).

LDR's are inherently slow. In fact, the slow recovery of an LDR is often exploited as an advantage. (like 250rise to 300fall micro seconds) which is Damn Slow in my book and not good for anything faster than about 2000 RPM.

So in your case, it's just the wrong part. You should re-design your solution and consider using a Photo-Diode or a Photo-Transistor.

A photo-transistor traditionally would have higher sensitivity with a trade-off in response time compared to a photo-diode.

Honestly though, a Photo-Transistor should be just fine for what you want.

Example of how one gets used:

guess i'll have to go digging in a radio or something, i'll pst results with a phototransistor

cheers! a nice karma 4 u

wish it was called internets, " i award you +1 internets fine sir "

By the way, where is a good place to dig for a phototransistor?

If "the light" is not mandatory measurements object, why not try hall-effect? I think it is a better option....

Alternatively to a phototransistor/photodiode you might want to consider a photo-interrupter, preferably with logic output. This makes the design much simpler and you can avoid the analog signals. A very nice photo-interrupter I used to measure motor RPM of a quad rotor vehicle is Sharp GP1A53HRJ00F (http://au.element14.com/sharp/gp1a53hrj00f/photointerrupter/dp/9708006) and I highly recommend it.

HTH
-Igor

Examples of places to LOOK:

Old Ball Mice, VCR's, CDROM drives, Tape Drives, floppy drives (especially if you can find a real old 5 1/4 "real" floppy drive.

prawnstar:
By the way, where is a good place to dig for a phototransistor?

Digikey, Mouser, Allied electronics, possibly radio shack, maybe an old VCR.

As pwillard noted, the old school computer mice with a ball have nice encoder wheels and IR diodes and photo transistors.

Note if you go down the mouse route some of the photo sensors will only work if the light goes through the wheel because they are twin sensors and only give outputs on true quadrature light signals. I thought they were just simple sensors too but there is a vintage that are not.

WELL i couldn't find a ball mouse, so i took apart an optical one for the mousewheel. But it had a mechanical encoder, too noisy for this application.

So I went and bought ( ) a phototransistor from maplin and i can confirm it works great

edit

my code though seems to be a problem, it can go up to 8500 rpm or so then starts counting from zero again.

it still counts the revolutions and the period correctly, but when it divides them for some reason something is going wrong .. . . .
help!

100hz is too fast for the Arduino? shrug

okay i have it working, basicly just didvide counts first then scale to RPM, instead of all in 1 step . ..

whats better, to count the number of rotations in a set amount of time, or to find the time difference between a certain number of rotations? i b puzzl'd :~

smeezekitty:
100hz is too fast for the Arduino? shrug

No it isn't but I've found I have to be clever when polling anything at the same time as I'm reading and writing to lcd's. I suspect the same might be true for serial devices. To keep loop execution speed below 5ms on this latest project, I had to limit the reading and writing to one command per loop.

switch (lcd_command % 11)			// display updated one command at a time
	{				// to decrease loop execution time
	case 0:
		lcd.setCursor(0, 0);			// column 0 line 0
		break;
	case 1:
		if (run_state == RUN_RUNNING)
			lcd.print("Running   ");
		else
			lcd.print("Stopping  ");
		break;
	case 2:
		lcd.setCursor(10, 0);			// column 9 line 0
		break;
	case 3:
		lcd.print(cycle_count);
		break;
	case 4:
		lcd.print("c     ");
		break;
	case 5:
		lcd.setCursor(0, 1);			// column 0 line 1
		break;
	case 6:
		lcd.print(lcd_tenths / 10);
		break;
	case 7:
		lcd.print("s     ");
		break;
	case 8:
		lcd.setCursor(10, 1);			// column 9 line 1
		break;
	case 9:
		lcd.print(sense_count);
		break;
	case 10:
		lcd.print("p     ");
		break;
	}
	lcd_command++;		// increment for next iteration

RPM = rounds per minute
hz = cycles per second
(8500 / 60) * 2 = ~300hz

Any possibility of affixing a magnet on the rotating part and use a Hall switch? Many cars use hall sensors as optical path can easily be blocked by dirt and dust. I heard that and engine cylinder has a magnet attached to its rotating part and it triggers the spark plug so a Hall sensor near that will likely pick up the rotation speed.

smeezekitty:
100hz is too fast for the Arduino? shrug

After debugging, the aforementioned program was reliably reading a 26,000 rpm signal from a signal generator while updating four display values, polling two inputs without interrupts, and having a compiled size of almost 8K. It started getting flaky at about 28,000 rpm. Ditching use of the string class in favor of character arrays roughly doubled the speed. Not executing every display command on every loop iteration roughly doubled the speed once more while still achieving an approximate 100 Hz refresh rate.

prawnstar:
....
rpm=counts*60000000;//I think You have to divide it by number of rising edges, in your case it is 2
....

and nice for this aplication is CNY70 +optical encoder wheel

http://www.x-robotics.com/sensores_ing.htm#Reflexivo CNY70
http://thedenneys.org/pub/robot/encoders/