We have just hooked up our gear tooth sensors and finally started getting readouts. problem is there are 238 gear tooths and when we spin it around we get gear counts in the hundred millions. we have no idea of why the gear count is reading out like this. We are using the easyC to program the geartooth sensors. Any input on what to do or what might be causing this problem would be much appriciated.
Hate to be the bearer of bad news, but i THINK the gear tooth sensors only sense direction, not tooth count.
http://www2.usfirst.org/2006comp/other/2006_Sensor_Basic_Operation.pdf
They definitely count. With Easy C, are you preseting them with zero?
The actual issue is the sample code included with EZ C. The printf display of the geartooth variable needs to be cast as a long. Otherwise the upper bytes will be filled in with random data that will make the count look incorrect.
Actually, the gear tooth sensor should sense ONLY counts and give NO CLUE as to direction.
Apparently, direction is possible. Just a little more convoluted.
See “GTS Counting” at http://www.chiefdelphi.com/forums/showthread.php?threadid=44479
well you should know what way you are turrning your motor . .so while the sensor may not know what way its going your code can.
if(motorPWM# <127)
gtscountdown():
if(motorPWM# >127)
gtscountup();
Sadly, that only works in theory.
When you are stopping and your motors are getting a pwm of 127 the gears still spin for a little bit. I guess this wouldn’t matter too too much but then your gear count wouldn’t register during these times.
i have found that using the IR sensors they gave us a few years ago and a visual encoder will also give fairly accurate results and with very little programming. The code to handle all the stuff for our visual encoders is about 10 lines in total including overload handling and reset capability.
I tried counting teeth (well sort of… I was using an optical sensor to count the number of revs of a shaft collar). I found the best way is to hook up the output of the sensor to an interrupt pin. That way when the sensor trips you increment your count (or decrement, depending on which way the motor was going last, use a tracking variable).
It’s quite a bit more accurate than counting in the main loop as the IRQ time on those PICs is in the microseconds.
And, it’s largely free.
In my opinion the gear tooth sensors are a pain. A cheap alternative solution is to use the vex encoders in place of the gear tooth sensors. They work with the same Easy-C functions as the gear tooth sensors. They are also higher resolution. They can be added to the kit chassis and frame very easily. The KOP trans output shaft is tapped. A piece of threaded rod can be coupled to a piece of 1/8" key stock. Attach the encoder with a piece of 1/16" aluminum angle. You’ll need a female by female PWM extension cable.
Works very well for going “x” feet during autonomous. Could easily be done Thurs. morning.
How do you interface with those in the code? Does it just give you a tick every revolution or something similar?
EDIT: 200th post! w00t!
The Vex encoders give 90 counts per revolution. There is no direction info. The same easy-c function that is for the gear tooth sensor can be used for the Vex encoder. They are not of the Grayhill quality or cost. You wouldn’t want to use one to measure the shooter wheel RPM but for measuring distance they’re not to bad.
When using GTS do you have to use interrupts? Because we wrote a code using simple counters, it kinda works. It would be great if maybe someone could help us up and give like a sample code for the gts. Thanks!
Using interrupts really isnt as hard as it seems. You can even use the same code you’ve already written… Just take the guts of your counter, put it in a function that whenever called will add one to the counter, and call that function in the ISR for whatever interrupt you choose to use. (I1-I3 are the easiest to get set up and running.)
How could I modify Kevin’s Encoder code so I could use it with Gear Tooth Sensors, I’m a programming rookie, and I’m really having a tough time with these! 
I don’t really have a way to test, except I have a switch hooked up to the proper dig inputs, which is supposed to represent 1 gear being counted everytime I press it. My counter code works with the switch, but I’m afraid that the gears will be moving too fast for a simple counter code to work.
Kevin Watson’s encoder code will work with the gear tooth sensors with virtually no modification at all. If you drive the robot too fast, you will start to get weird readings, but if you drive at a reasonable pace, his code will work just fine.
The necessary change is trivial. Just take out the piece of the encoder interrupt service routine that checks the “B” phase, so that it always increments the counter when it gets an interrupt. Or, if you like, you can get fancy and read the motor pwm value to decide whether to increment or decrement the couter.
My counter code works with the switch, but I’m afraid that the gears will be moving too fast for a simple counter code to work.
It’s not so much the speed you need to worry about, but the narrow pulse width from the GTS. It’s only active for a few tens of microseconds each time a tooth goes by, so reading its value in the Process_Data_From_Master_uP() loop is not likely to see it reliably. You really need to have it trigger an interrupt.
Use encoder inputs one and two and change this code:
void Encoder_1_Int_Handler(void)
{
// Encoder 1's phase a signal just transitioned from zero to one, causing
// this interrupt service routine to be called. We know that the encoder
// just rotated one count or "tick" so now check the logical state of the
// phase b signal to determine which way the the encoder shaft rotated.
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}
Into this:
void Encoder_1_Int_Handler(void)
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
Repeat the above for channel two.
If you want to change the direction the GTS counts, change the ENCODER_1_TICK_DELTA or ENCODER_2_TICK_DELTA value to -1 in encoder.h.
-Kevin
Thanks! I’ll test it on my temporary rig, and report back 
hopefully it works on the robot aswell, lol, considering I’m using a processor and a switch hooked up to the dig inputs.
EDIT:
If the GTS is stuck on a gear, does it’s value stay at 0?
EDIT:
I must have done something wrong. I can see that the switch is being activated, but the count stays at 0.
I called all functions in autonomous mode and I modified this part of the code:
void Encoder_1_Int_Handler(void)
{
if(ENCODER_1 == 0)
{
Encoder_1_Count++;
}
printf(“Encoder: %d”, Encoder_1_Count);
printf(“Switch: %d”, rc_dig_in06);
}
Encoder_1 is rc_dig_in06
I read the readme, and I assume I did everything correctly.
Please keep in mind that this is my first year programming, and I’m most probably overlooking something obvious…