Gubi,
Thank you for your reply. I much appreciate all your efforts.
To your points:
I do have a very clear understanding now, I believe, of the specific differences between the functional operations of indi_synscan_telescope and indi_skywatcherAltAz mount. Though I am not a C/C++ programmer, I have written commercial complex networking, motor control and remote operations software in assembler and Java for over 40 years. I have now read through the code for the two drivers, along with the motor control spec for the Skywatcher 250P, along with the INDI protocol programming specifications. I have also spent some time looking at INDI for Java, because I believe I can solve -my- problem there, though that entire platform seems dead. If I can contribute testing time to solve the greater problem, I'd feel better about it than just fixing my setup.
I agree that there is a strong possibility of translation issues between RA/DEC and Alt/Az. It -feels- like that from my testing....which is not, by the way, random. I set out with each test to prove or disprove particular steps. I admit to having a warped sense of humor, so sometimes my explanations of tests and results are more literary than specifically factual. You must forgive me for that.
There are a few places I would look for the potential inaccuracy in coordinates. Time, location, and (my favorite) JNow vs. J2000. The latter could be different in different areas of the driver, or calling program and cause some odd results.
Like you, I have been concerned about WiFi issues and RPi time/date. To that end, I moved the Pi to the scope used the Pi WiFi to talk to my local network for NTP and image transfer, then hardwired the Pi (ethernet) to a fairly powerful Cisco WiFI N router, also mounted on the scope, for an on-scope WiFi network, to connect to the Skywatcher WiFi motor client. I would go to a serial connection for the mount motor, but my model requires the hand unit for the serial USB cable connection. I have not had good luck with connectivity from a FTDI/USB cable yet, though finalizing that is a TODO for me. Meanwhile, my high-density WiFi signal should be fairly reliable for the half-meter it has to cover. Image traffic is on a different WiFi channel on the local network.
I have had good results guiding with PHD2 using the indi_synscan_telescope driver. I don't trust it at all for general operations, but once pointed, it will keep you on a star with a little help from PHP2. So, whether that is on or off the current project table is of no consequence to me presently. And, since it involves pulse and not sync, I don't believe it is part of the larger problem.
The big problems are GOTO and SYNC reliability. And by reliability, I don't mean it must go with extreme precision to the target, but at least somewhere close. And the cross-hair must be accurate with where the scope thinks it is. SYNC must work properly and not break things.
I also agree that plate solving is not optional. Both blind solving and relative...but at LEAST blind solving. But that is reliant on a reliable SYNC as well.
The version I am using is a recent (this week) GitHub get from
github.com/indilib/indi. I haven't noticed if it has the RA-DEC/AltAz switch. If it has the option, I'll switch it to RA-DEC. Otherwise, I'll look for an update.
If there is anything I can do to test further, please let me know.