I am building a device that will correct for mechanical errors in a telescope drive by reading a high resolution encoder.
I believe I’ve sorted out the ADC issues, etc. However I have a big problem in timing.
The “sidereal day” or time it takes for the earth to rotate once on its axis, is 86,164 seconds. This translates to 15.04 (roughly) arc-seconds per second.
A “perfect” telescope drive would rotate at precisely 15.04 arc-seconds per second, but most do not. Even if you control the motor speed precisely, tiny imperfections in the telescope gear train will cause the final output shaft to speed up and slow down by an imperceptible amount. Not enough to be seen, but enough to ruin long-exposure (multiple-minute) photos.
To my problem. I can read the angle of the telescope shaft at any time with my interpolated encoder. However I need to calculate the current error so I can correct it. To calculate the error, you need the “perfect” value, which is simply 15.04 * millis() / 1000.
My problem. After only 8 minutes (one worm cycle) the error is huge. I know this is not true, because the error must return roughly to zero at the end of each worm cycle. And I have measured the error of this telescope drive by watching a star, and I know it’s not that huge.
I was only able to “correct” the error by setting the sidereal day to 84950 seconds - a 1.5% deviation from the actual value. Is the ceramic resonator that bad?? because the only way such a huge error could pile up, is if millis() is inaccurate. But that inaccurate, after only 8 minutes?
Try using micros() instead.
May need to switch to crystal based time source as well.
Or bring in 1 PPS from GPS and sync up to that.
You could check the timing accuracy against a PC clock, by writing a sketch that prints millis() at regular intervals and use Realterm to log that to a file with timestamping. After a few hours, you'd get a pretty accurate indication of the Arduino's clock accuracy.
In case the problem is a logic fault in your sketch, I suggest you post your current sketch.
I have achieved less than 1 sec/day drift using micros() and crystal/cap equipped Duemilanove (my standard test bed, not a resonator equipped Uno with 16U2 for USB/serial - its what I have on hand and it mimics my designs) with time tracked against US Official Time.
A ceramic resonator is not very precise, 1000 PPM and more.
For timing accuracy, you may want to research interfacing with a TCXO, these are more precise than the crystals driving the Arduinos or regular computer clocks. For example, the CW750CT-ND is 0.28 PPM, which means it can drift 24 milliseconds every day.
After calibrating in software... I've been able to get 1sec/10 days drift with Arduino Uno. Assuming the temp is constant.
That's great! I was toying with the idea of just subtracting a second at midnight every day, haven't actually tried it yet.
I know the ceramic resonator is bad. My "solution" is I moved the sketch to a digilent board. It (looks like) it has a TCXO. Certainly it's a real crystal.
I don't "need" long-term accuracy, but I do need the time to be accurate over a period of several hours. I understand that the PPM rating is for stability, but the actual frequency could be quite a bit off from 16 MHz - and that, I think, is what may be causing my issues. I don't have a scope so I can't measure the clock frequency directly.
Probably I will try checking versus PC clock, since I can NTP-discipline my PC clock.
It (looks like) it has a TCXO.
Very unlikely, I've never see a standard commercial board with a TXCO. If it has that will be in big red letters in the specs section because they will want you to know.