[billbo911]

Originally Posted by Kevin Watson

...Okay, so yesterday I modified the code to gain more headroom (ADXRS150 w/ default settings rolls over in just over five revolutions) and implemented a scheme where complete revolutions are detected, counted, and then subtracted from the total angle. In this way the number of revolutions is accounted for separately from the angle. The downside is that the code is somewhat bloated and convoluted. I guess I'd like to keep the status quo with additional headroom and dump the loop counting code, but I'd like to get some feedback on what teams want.

-Kevin

Thanks for the background description. It helps in understanding how and why the code operates the way it does.

As for feedback;
Honestly, currently we don't have a need to keep track of heading for up to five revolutions. In fact, this year we will really only be expecting the code to track up to one and a half revolutions. So, as it is now, it will work just fine. On another note, I am curious as to the outcome of the question/observation PhilBot had when he posted this"

I think the problem is that GYRO_CAL_FACTOR is defined as 1000/1000, but the multiplication is being done AFTER the prior expression is cast to an integer... Therefore if ((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE)) calculates to anything above 32 or below -32, then multiplying it by 1000 will cause the number to exceed the valid range of an integer.

I think the second to last bracket is misplaced... I think it should be:

return((int)((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE) * GYRO_CAL_FACTOR));

Is there a problem with the Get_Gyro_Rate() function? We will be depending on it heavily this year, and need it to function correctly.