As Andre points out, the signal can be 'noisy' due to timing problems.
I handled this in the file-based scope communication by putting a 't0'
value in the file, and something like that could be sent over the cable.
Then the scope would get t0, RA, dec, and rates in each axis, and
could compute

RA(t) = RA + (t - t0) * RA_rate

and similarly for declination... adding in RA_accel * (t - t0) ^ 2
and the cubic terms if desired.

Andre also mentioned: "I was under the impression we were always
talking about high rate position updates obviating the need for
polynomial coefficients. Is this not so?" This might work, but I'd
hate to count on it. Is dealing with rate data that problematic?
(It's easy for Guide to compute it.)

Since Guide runs under Windows, a decidedly non-real-time OS, I'd
expect occasional glitches in the data sent to the scope. Even if it
_were_ a real-time OS, there will be problems due to serial communications
errors. All in all, I'd feel a lot more comfortable if rate data were
being used.

Besides, you know that someday, someone will want to image Mir
passing overhead at the one-arcsecond level. If it's moving half a
degree a second, that would require an 1800Hz update rate. Send
motion data, and that update frequency drops a _lot_.

One _could_ still do as Markus suggests: take the positions fed to
you and extrapolate. Assuming you get all the data, you can do this.
Though I don't see how it saves you anything in comparison to using
rate data...

Markus points out that "...drive rate control does not help, if the
mount is of the equatorial or altazimutal type." That's true. On the
other hand, almost _any_ system is going to be in trouble if an object
insists on going through a pole. (As you mentioned, some setups
evade this issue by moving the scope's polar axis around until it's
far from the path of the satellite.)

-- Bill