1) Differentiating position for rate could lead to a noisy signal
if the timebase is not calculated properly. For instance, if
it is not calculated in the serial interrupt, or a time stamp
is not placed on it, one would not be certain of the time elapsed
between samples due to jitter. The same applies
at the origin of the samples (in this case Guide), it must be
accurate time wise. A further hitch is that piping rate will
lower the effective sample rate to the TCS. But it would
probably be outweighed by the advantage of this higher order
term.

2) Rate and position offers one iteration less delay as opposed to
computing rate in the TCS.

3) True, the function is smooth and could be calculated in the TCS,
or a correction factor would be smooth and predictable.

4) I would think most of us would accept the 'drive holes', as more
often then not, the path would be far enough from it, at least for an
equatorial (best path is straight above!). Besides, as you mentioned,
the rates near these are large and may not be possible for our scopes.
We're not about to build a research grade satelite mounting!

5) Boils down to where the satelite path is calculated or approximated.
I'm not about to write code for this when it already exists in Guide.
Again, Bill's suggestion of a file containing positions and
time stamps is good (in that case, rate can be dropped as the file
is read by the TCS prior to tracking).

6) As for the LX200, what stops Guide from pumping data out faster!
Guide could always allow the user to choose the update rate (oops,
Markus posted this in his second message).
The problem is the LX200 format is wasteful in serial bandwidth.

7) I was going to point out that a PID is the simplest and not
necessarily the best controller. At least it forms all or part
of the inner loop. But as you said, estimating the future is
an excellent approach. I was looking forward to doing this if
Guide was to provide the info. I was also going to allow joystick
inputs at the scope or outright manual motion to correct or
completely take over the path estimation. If a satellite happened
to be crossing your field of view, you'd slew after it and the TCS
would quickly figure out an approximate path, but it might
be hard to get it within a tiny CCD frame for long...

Cheers