Chris Rowland said:
There's been a number of things like this, such as Mel Bartels scope drive system. This uses the parallel port of a PC to drive two stepper motors, but it has to run under DOS. This is because Windows will take over the CPU for enough time to give unacceptable jitter in the stepper pulses. I expect Linux will be the same.
Well, we did have some issues with jitter on heavier systems, but on a minimalist Debian install (no graphics, networking, etc., just basic needs and good old Bourne Again shell) that's dedicated to controlling the stepper motor, we fortunately get jitter-free results
It's unlikely that this would be used for long exposure astrophotography becuause field rotation will prevent long exposures and even if it is then guiding would cope with tracking rate errors.
I guess you already realize that field rotation is not a problem, but I wanted to point out for informational purpose that eliminating field rotation is part of the whole point of this particular class of platform -- the equatorial platform. Because the platform counter-rotates the Earth and thus rotates in tandem with the sky, it can be seen as rotationally (in every direction) "affixed" to the sky, as if great long steel beams were rigidly attaching points on the platform to moving points in the sky. Equivalently, had we not been using three motors, it woudld be physically impossible for this to be an "equatorial platform" to begin with.
The qkits thing looks like what"s needed, I suppose the step rate for each motor can be set in the controller, that"s what controls the tracking rate. It isn"t neccessary to adjust the rate that frequently, every few seconds will be fine. One thing to watch is that when you send a command to the controller to change the rate it does so smoothly.
I have already developed a software application which guides the motors appropriately based on the latitude. It doesn't even muck around with pulsing "rates" to accomplish this; it does so very precisely by constantly guiding the platform into "exactly" the position it should be in at the current time, based on a precise mathematical algorithm, with individual pulses to the motors (by "exactly", I mean as close as possible, given integral motor stepping). I communicate to the hardware through a translation layer / software driver that I also wrote myself, which converts instructions like "I want to pulse a certain motor twice; just do it" or "I want to pulse a certain motor 4,000 times, with gradual speed acceleration and deceleration so as not to jilt the platform too much" into the low-level binary signals that need to be sent out through the hardware driver. In a nutshell the basic problem of implementing tracking has already been solved on our current test equipment; thus the functionality that our new hardware driver is going to provide will be largely, if not completely, unneeded. All I need is the ability to say "I want to pulse that motor once" and what I've written knows how to take care of everything else.